RE: about Wedgelayer 3.5 / Fat IP approaches

[Erik Nordmark <Erik.Nordmark@sun.com>]

> So, assuming that HIP hosts started to use low order bits of the
> HIT in their locators, and then used such a locator as an AID,
> the main differences I see are in the use of/reliance on PK crypto
> in the context establishment handshakes, as well as IPsec reliance 
> (HIP relies on PK signings for handshakes, and relies on IPsec, 
> while CB64 relies on neither), and some of the basic protocol 
> mechanisms of the two proposals (which one might argue are just
> details):
> - CB64 handshake occurs in parallel with start of data transfer
> (actually, after first data packet has been sent), while HIP holds
> the first packet waiting for HIP handshake to complete (or
> possibly piggybacks it on the HIP exchange). 

I think this is the only issue which is tied to the type of ID that
is used. In HIP as defined, since the ID used by the transport is not a
locator, the handshake must occur before ULP packets can be exchange.
But with a CB64 AID that is also a locator one has the option
to do them concurrently or even defer the handshake.

> - CB64 uses flow IDs and locators as keys to find context state
> for the session, while HIP uses IPsec SPIs

And Pekka Nikander has told me that it wouldn't be hard to have HIP
optionally use the same scheme if HIP wanted to support the case when
the payload is not encrypted.

> - CB64 adds new locator for peer upon discovering it as a source
> address in a packet (and issuing PK-signed challenge/response), 
> while HIP explicitly signals the new locator in a signed HIP 
> exchange.

For CB64 this derives from allowing router rewriting of the locators
as a way to signal changes in the working/desired path.
I don't think this is tied to the format of the ID so HIP and CB64
could be made to behave whichever way we desire here.

> Another difference is length of the hash of the key, which may
> cause some subtle differences.  With 64 bit IDs (or, strictly
> speaking, ID tags, since the public keys are the actual
> identifiers), we can provide an embedded stack name in the AID, 
> whereas with HITs, we can only provide a mapping between 
> (truncated) stack name and AIDs.  When we have discussed 
> shortening HITs to accommodate some structure to aid reverse 
> lookups, there have been concerns raised that 64 bit IDs might 
> not be strong enough to withstand server farm attacks in the 
> future (generating different key that hashes to same ID).  
> If a larger hash is used as the identifier, then the AID with 
> truncated HIT can be viewed as a slightly less secure 
> identifier used for support of referrals for non-multi6/HIP 
> aware apps, which keeps the door open for future HIP-aware 
> apps to directly use the full IDs.

But there are some cases where the larger ID (that doesn't fit in the AID
seen by the ULPs) does not help.

Example: busy server receives a context from a client with large ID = X
and AID=P1 | hash(X)
Server later receives a context from a client with large ID = Y
and AID=P1 | hash(Y)
and the hash values are identical.

Even though the multihoming layer can disambiguate the two contexts, it
can not handle both at the same time because the ULP can not tell them apart.
Thus when a packet would be passed down from the ULP, the multihoming
layer wouldn't know which of the two contexts to use for transmitting the
packet. The number of contexts the server can handle before this probability of
collisions is an issue is of course a function of the hash size. With 64 bits
of hash handling 4 Billion contexts concurrently would imply about .5
probability that two have the same hash, but the prefixes would most likely be
different so that the AIDs would be different.

   Erik