RE: about Wedgelayer 3.5 / Fat IP approaches

> -----Original Message-----
> From: Erik Nordmark [mailto:[email protected]] 
> Sent: Thursday, July 01, 2004 11:47 AM
> To: marcelo bagnulo braun
> Cc: Erik Nordmark; Henderson, Thomas R; Jukka Ylitalo; Multi6 List
> Subject: Re: about Wedgelayer 3.5 / Fat IP approaches
> 
> 
> > > 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.
> 
> But even if the application can do that it doesn't help the 
> TCP from telling
> the two peers with the same AID apart.
> 

If the locators are the AIDs, then there is indeed a problem because
two hosts have the same locator.  Administratively, this might be 
preventable in most cases by forcing a host to pick a new key if 
truncate(hash(key)) matches with another host within that prefix.
However, not in the mobility case, where a host might roam into
a prefix where there is an AID collision.

Anyway, if my m6 layer can differentiate between the two hosts, and
my applications have provided me with more than the AIDs, I don't
see why my transport couldn't work also (perhaps not by the AIDs 
alone, but by some context information passed in the implementation).    

If there is no exchange of larger IDs prior to conversation, then
yes, I agree that one can construct ambiguity scenarios where an
application intends to talk to one host but instead talks to 
another.  The CB64 draft seems to argue that applications can provide
the additional verification if desired (Sec. 4.1 point 7).

So in summary, if the (larger) IDs collide, there is potential for 
ambiguity.  If the IDs do not collide, there is still potential for 
ambiguity if AIDs collide and:
i) applications use AIDs only
ii) applications use larger IDs, but the handshake is delayed or
concurrent, causing the hosts to not be differentiated at the m6
layer by their IDs

Tom