Subject: RE: about Wedgelayer 3.5 / Fat IP approaches

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 1 Jul 2004 16:12:40 -0700

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Jul 2004 11:13:54 +0200

I'm going to declare this a bogus concern for multi6.

If people need shorter prefixes than /48 because 65k subnets
are not enough, that is an IANA/RIR issue.

We should work within current assumptions, i.e. that the
IID is 64 bits. It would be good to avoid this being an
architectural restriction - but arguing for a 64 bit IID
on grounds of cryptographic strength is fine. If someone
wants to run with a 48 bit ID and accept the cryprographic
risk, that isn't our problem here.

   Brian (co-chair hat on)

Tim Shepard wrote:
>>>>CB64 -like split sounds good.  Right, there arises some AID
>>>>ownership problems if it is not bound to the HIT.
>>>>It would be nice to have a new version of Multi6 HIP draft that
>>>>describes how HIP could be used with CB64 -like AIDs.
>>>>
>>>
>>>how this would differ from the cb64 draft by Erik?
>>>
> 
> 
>>[...]
>>possibly piggybacks it on the HIP exchange).=20
>>address in a packet (and issuing PK-signed challenge/response),=20
>>while HIP explicitly signals the new locator in a signed HIP=20
>>exchange.
>>
>>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,=20
>>whereas with HITs, we can only provide a mapping between=20
>>(truncated) stack name and AIDs.  When we have discussed=20
>>shortening HITs to accommodate some structure to aid reverse=20
>>lookups, there have been concerns raised that 64 bit IDs might=20
>>not be strong enough to withstand server farm attacks in the=20
>>future (generating different key that hashes to same ID). =20
>>[...]
> 
> 
> 
> I am concerned about putting hashes in the bottom 64-bits of IPv6
> addresses, because that may lead to a future (albiet, probably a few
> years or decades out) when we discover that some situations are
> constrained by a shortage of IPv6 address space.  For example, someone
> who only gets a /48 prefix from their provider, and has gazillions of
> machines to deploy whose stacks and/or applications all expect the
> bottom 64-bits to be this hash thing, has to do all of their
> subnetting in a 16-bit field.  That 16-bit field is just too small for
> my taste.  I'd worry a lot less if it was 32-bits.  So maybe if we can
> figure out how to ensure that anyone who wants one can get a /40
> prefix from each and every ISP that they buy some connectivity from,
> and can confine the hash thing to the bottom 56 bits of the IPv6
> address, then that would laeve 32-bits in between, and it might then
> be OK.  But now 56-bits might not be long enough to get the security
> we want from the hash?
> 
> Maybe IPv6 should have been designed with 192-bit addresses so that
> there would clearly be enough bits to put together all of these sorts
> of techniques.
> 
> 			-Tim Shepard
> 			 [email-masked]
>