RE: about Wedgelayer 3.5 / Fat IP approaches

> -----Original Message-----
> From: Erik Nordmark [mailto:[email protected]] 
> Sent: Thursday, July 01, 2004 1:50 AM
> To: Henderson, Thomas R
> Cc: marcelo bagnulo braun; Jukka Ylitalo; Multi6 List; Erik Nordmark
> Subject: RE: about Wedgelayer 3.5 / Fat IP approaches
> 
> 
> 
> > 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.

I agree with you that this is the main issue tied to the ID, but the
CB64 approach might be usable by HIP if HIP were to define a
non-IPsec mode of operation.  Presently, the transport ID used by HIP
is the HIT, but I think that it could perhaps be the AID instead,
allowing a more CB64 operation.  The price to pay for deferred or
concurrent handshakes is perhaps weaker authentication.

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

This seems feasible to me.

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

Agreed.

> > Another difference is length of the hash of the key, which may

I'll respond to rest of this in the next post.

Tom