Re: Comments on draft-bagnulo-multi6dt-hba-00.txt

  > >
> >>
> >>> I had a few comments/questions on this draft. Sorry if some of them
> >>> have already been
> >>> asked (i did not look closely at the archives).
> >>>
> >>> 1) In section 1,
> >>>
> >>>    In addition, it should also be noted that it
> >>>    is not required that all interface identifiers of the addresses of
> >>> an
> >>>    HBA set are equal, preserving some degree of privacy through
> >>> changes
> >>>    in the addresses used during the communications.
> >>>
> >>> To create all addresses (for various prefixes) with same interface
> >>> identifiers, what is the
> >>> change that would be needed ? Does including the multi-prefix
> >>> extension and removing the subnet-prefix
> >>> in the second hash calculation (Hash1 in CGA draft) sufficient ?
> >>
> >> Yes, but this imply not to be compliant with CGA spec.
> >> in other words, if we are compliant with CGAs, the iid will be
> >> different and it wouldn't be possible to have equal iids
> >>
> >> we felt that cga compatibility was more important than supporting
> >> equal
> >> iids in the HBAs of a given set (note that we do see some value in
> >> having equal iids, for instance for simplified management, but this
> >> cannot be provided in the CGA format)
> >>
> > I thought we have 3 different types of addresses now. The procedure to
> > compute the hash is different depending on HBA or CGA  i.e include the
> > public key or extended modifier depending on CGA or HBA. So, why does
> > it matter if we can specify something different for HBA address ? Both
> > ends
> > know they are operating on an HBA address. So, what is the
> > compatibility
> > issue ? Could you elaborate on that ?
> >
> 
> Well, the HBA is defined always (in the 3 cases) as an extension of the
> CGA.
> i agree with you that we could define the HBA as an extension of the
> CGA when the CGA is also used (i.e. the HBA/CGA hybrid) and define the
> HBA in a different way when the CGA are not used (HBA only mode)
> But i am not sure this is worthy, since i guess it would be more
> complex since you need to handle multiple generation algorithms,
> depending in the case. suppose the case when a a communication has a
> CGA/HBA and a HBA only in the other side, this would probably would be
> more complex either. I mean, having a different generation for the

I don't understand this part. If one side is using CGA/HBA and the other
is using HBA, the common set is HBA, right ?

> generation of the HBA only case would essentially provide that all the
> iids are the same in an HBA set, but with an additional complexity in
> the implementation, do you think that it is worthy?
> 
I am not sure about the complexity part. We are computing a hash with
slightly different set of arguments depending on the type HBA, CGA, HBA/CGA.
So, i must be missing something. Perhaps it is not a big deal to have different
IIDs for each of the prefix. Did the DT see any use for generating addresses
with the same IID ?

 > >
> >>> I was wondering whether it would make any difference between
> >>> including
> >>>   the prefix Vs the whole address itself in the CGA parameter data
> >>> structrure ?
> >>
> >> i am not following you here.
> >> The CGA parameter data structure is used to generate the iid of the
> >> addresses, so how can you include the complete address in it if you
> >> still haven't generate it yet.... i am probably missing your point
> >> here
> >>
> > I mean, you can generate the address and include it..but it is not
> > needed as
> > you mention below..
> >
> >>>  I am not able
> >>>   to see anything less secure by including the whole address itself.
> >>> One possibility is that
> >>>   the peer can compute and validate the address ahead of time (which
> >>> is of no use if rehoming
> >>>   will never occur) and hash verification becomes a simple comparison
> >>>   when a packet with different locator comes in.
> >>
> >> but this can be done with the current CGA parameter data structure,
> >> right?
> >> i mean, the HBA set generation only uses the info contained in the CGA
> >> parameter data structure, so once the peer has the CGA parameter data
> >> structure, it can regenerate the whole HBA set before the rehoming, as
> >> you suggest.
> >>
> >> i mean, i think you can do this that you suggest already
> >>
> > Agreed.  I was thinking in a slightly different direction which may not
> > be needed i guess. Somebody in one of the multi6 meeting raised a
> > point about
> > computing the hash and verifying it as expensive. First, the hash is
> > not computed
> > always i guess. Only after the rehoming occurs. But once the rehoming
> > occurs, you
> > have to recompute always as long as the locator does not match the
> > ULID. Is that right ?
> > Then i was wondering whether it is a real problem because it affects
> > the fast path processing
> > of the packet. Perhaps not because it can be pre-computed.
> 
> >  But it may not be necessary
> > i guess. The first packet after rehoming will trigger the hash
> > computation, but that can
> > be cached i guess. Hence the subsequent packets can be compared
> > directly
> > with the cached value. Does that make sense ?
> >
> 
> Yes,
> I mean, i would do the following.
> first the communication is set up, and at some moment in time the CGA
> parameters are exchanged. For now, no hash calculation.
> Suddenly, an different locator needs to be used. So at this point, i
> would run the verification process, implying a hash calculation.
> then as long this is the locator that is used, i don't think that
> additional verification are needed, you just need to remember that this
> locator is OK
> So, i would say that for a HBA set with n prefixes, the maximum number
> of hash verifications needed is n (independently of the number of
> packets exchanged with each locator)
> 
Agreed. When we have this detail in the solution draft, there won't
be confusion about the complexity of the hash verification etc.

  
> >>
> >>>    Also, how important is return routability for the locators  before
> >>> they are used ? It is not discussed here.
> >>>    As it is hard for the attacker to redirect packets to a victim, is
> >>> it needed ? Can it be optional ?
> >>
> >> very good point
> >> HBAs are mainly used to prevent hijacking attacks and to prevent
> >> flooding attacks. We will need reachability tests to prevent flooding
> >> attacks. I will include this also in the doc.
> >>
> > I am not sure i understood the above sentence.
> 
> well as it is stated it is impossible to understand (i am sorry for
> that)
> 
> What i wanted to say was:
> 
> HBAs are mainly used to prevent hijacking attacks.
> We will need reachability tests to prevent flooding
> attacks.
> 
> 
> However, an additional consideration about this...
> Note that if HBAs are used, flooding a specific target host is very
> difficult, since i would need to find an HBA set that contains an
> address with the attacker prefix and that the address of the victim is
> included in the HBA set, agree?
> 
> this is very difficult (O^(59+(16*Sec)) difficult
> 
Agreed.

> However, the flooding attack can be easily directed to the access link
> or access router of the victim, since the attacker only need to include
> the prefix of the victim's network in the prefix set.
> 
> This means that the resulting HBA set won't contain any address of a
> real host within the victim's network, but in any case the flood will
> be routed to the access router of the victim's network flooding the
> access link and the access router.
> 
> So even if the flooding attack is slightly different, i guess that it
> would still make sense to provide some protection from it, agree?
> 
Agreed. Now i am not sure about RR being optional :-)

-mohan

> regards, marcelo
> 
> 
> >  First you say that HBA can
> > be used to prevent flooding attacks and then you say that we need
> > reachaility tests to prevent flooding attacks.
> >
> > -mohan
> >
> >> Thank you very much for your constructive comments
> >> I hope i can address them in a satisfactory manner in the next
> >> version.
> >> Please let me know if i wasn't successful
> >>
> >> regards, marcelo
> >>
> >>>
> >>> -mohan
> >>>
> >>>
> >> ------------------------------------------
> >> Please note that my former email address
> >> [email protected] is no longer in use
> >> Please send mail to:
> >> marcelo at it dot uc3m dot es
> >> ------------------------------------------
> >>
> >
> >
> ------------------------------------------
> Please note that my former email address
> [email protected] is no longer in use
> Please send mail to:
> marcelo at it dot uc3m dot es
> ------------------------------------------
> 
>