Subject: RE: about Wedgelayer 3.5 / Fat IP approaches

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 30 Jun 2004 11:02:45 -0700

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Wednesday, June 30, 2004 7:42 AM
> To: Jukka Ylitalo
> Cc: Henderson, Thomas R; Multi6 List; Erik Nordmark
> Subject: Re: about Wedgelayer 3.5 / Fat IP approaches
> 
> 
> 
> El 30/06/2004, a las 16:15, Jukka Ylitalo escribió:
> 
> > Hi,
> >
> > Henderson, Thomas R wrote:
> >
> >>
> >> Rather than NOID kind of split, maybe CB64-like split is 
> preferable?
> >> (where lower bits of AID match the HIT and upper bits the prefix,
> >> rather than having the AID be unrelated to the HIT)?  It wouldn't
> >> have to be a /64 split necessarily-- just reverse mappable with
> >> DNSSEC.  I agree that HIP opportunistic mode should be 
> able to deal 
> >> with it.
> >>
> > 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?
> 

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). 
- CB64 uses flow IDs and locators as keys to find context state
for the session, while HIP uses IPsec SPIs
- 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.

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.

Tom

---

From: Tim Shepard <[email-masked]>
Date: Wed, 30 Jun 2004 16:06:33 -0400

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