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

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> 
> Hi Mohan, and thanks for your comments. Some discussion
> inline:
> 
> > 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 ?
> 
> Actually, I believe the intent is to have just one address
> format, basically according to the SEND CGA draft with some
> optional data that is going to make things easier in some
> cases. So the cases that we have are:
> 
>    - CGA format + pure CGA: all rehoming events require a PK operation
>    - CGA format + pure HBA: a set of fixed prefixes is included and
>      no other addresses than the fixed ones are expected:
>      all rehoming events can be done with a symmetric
>      crypto
>    - CGA format + HBA + CGA: as above, but if you need to
>      go beyond the originally listed address set you can
>      switch to using the public key
> 
> As for the interoperability problem -- at least my
> main issue is that IPv6 components such as SEND or MULTI6
> do not require you to allocate different addresses; that
> you can actually use both features at the same time. You
> could of course do this so that MULTI6 module decides to
> use the CGA format if it also wants to do SEND or does
> not know the set of prefixes beforehand, and HBA format
> otherwise. But using a single format seems simpler. Plus
> I actually like the fact that the IIDs are different :-)
> 
I don't have any problems with IIDs being different :-) But i was more
trying to understand the compatibility problem.  Multi6 module anyway
has to do different processing if the address is a HBA address or
if it is a CGA/HBA address. Now you can still use the same format for
generating a single IID for all the prefixes e.g. using all zeroes or all
ones for the subnet prefix field of the CGA parameters data structure.
(but including the multi-prefix extension at the end as specified now)
Assuming we can find such a thing, would it be considered simpler ?


> > 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 ?
> 
> I think we need to treat fast path for payload packets and
> signaling differently. Either at the beginning or at a
> rehoming event there's going to be some signaling. I don't
> believe fast pathing this signaling is going to be necessary.
> However, once you have determined that an address belongs to
> the peer (either through HBA or CGA proof), presumably you
> should be able to set up whatever processing of fast path
> mechanism you need for packets arriving with any of the legal
> address pairs. And in the worst case all of these pairs are
> going to need a mapping from the on-the-wire address pairs to
> the ULID pairs. So, conceptually, if you receive the "M6 header"
> then you do the mapping. This should be fast too, I think.
> But if you receive an indication of a problem or some message
> from the peer claiming that it has changed its address, that
> is going to need at least a hash operation as well as some
> amount of data structure modifications in the stack.
> 
Agreed.

> >>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. 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. 
> 
> Reachability tests are needed to prevent flooding attacks,
> because HBA and CGA techniques can only show that you generated
> the address, not that you actually are on the link. HBA/CGA
> on the other hand is needed to ensure that you can't hijack
> any else's address. The "victims" in these two cases are
> different: in the first case its third parties, in the
> second case it is an "owner" of an address.
> 
This flooding attack is slightly different from the one mentioned in the
threats document because there is no real victim invovled. Just the
routers and links which still needs to be prevented.

-mohan

> --Jari
>