[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-bagnulo-multi6dt-hba-00.txt
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 :-)
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.
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.
--Jari