Re: about Wedgelayer 3.5 / Fat IP approaches

>
>> 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.
>

I think that Tom was considering the case were apps have been upgraded 
and they are HIP aware (using a new api), so they can actually deal 
with the full HIT or even directly with the HI, so they can benefit 
from enhanced security.

Regards, marcelo

> 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
>