Re: about Wedgelayer 3.5 / Fat IP approaches

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?
>>>
> 
> 
>>So, assuming that HIP hosts started to use low order bits of the
>>[...]
>>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).=20
>>- 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),=20
>>while HIP explicitly signals the new locator in a signed HIP=20
>>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,=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 protected]
>