[Hipsec] A new HIT scheme (was: what fraction of IPv6 address ...)

On Thu, Mar 20, 2003 at 01:17:59PM -0500, Tim Shepard wrote:

>> Section 3.1 of draft-moskowitz-hip-06.txt proposes that we occupy the
>> center half of the IPv6 address space with HITs (in 4000::/2 and in
>> 8000::/2).  If any one else proposed to take that much IPv6 address
>> space, I would object.  Why shouldn't everyone else not object to us
>> doing this?  (IMHO, they should.)

Derek Fawcus wrote:
> Moreover I suspect objections will be raised, 'cause as far as I understand

Thanks, Derek, for these sharp observations.

As Tim already wrote briefly, we discussed this issue at the unofficial BoF on Friday morning. We came up with the following model.

All HITs are defined to be 128 bits long. There are two types of HITs just as earlier. The "long" hits begin with a zero and have 127 bits of the hash. The "HAA" hits begin with a one, contain a HAA field, and 64 bits of the hash.

In the current legacy APIs, though, the HITs are not present as such. Instead, there is a new representation that has a fixed 16 bit prefix and then 112 bits of the hash. In the HAA case, we want to align the HAA and the API prefix so that there is no difference. We will still have enough bits to be assigned to RAAs and RIs. Thus, we need two 16 bit prefixes assinged by IANA, one for representing the long HITs in the API, the other one for HAA HITs.

Example:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

   Let us assume that the long HIT prefix is 0600::/16

   I have a long HIT 3543:907a:356c:24ef:cd34:043a:431c:0953    At the API, it becomes 0600:907a:356c:24ef:cd34:043a:431c:0953

[The change in our implementation is fairly small. Basically,   we need to change to way we look up contexts, and probably   create a couple of different HIT retrieval functions that   are used separately depending on we need the API form or   the long form of the HIT.]

The design allows the length of the HITs to be later expanded if needed. That requires incrementing the protocol version, but it is doable since the HITs are only present in the HIP protocol messages, not in the current APIs or legacy IP protocols.

We should define the future APIs and wire formats so that it is possible to increase the length of the HITs easily, if there ever is a need.

In a way, this modification unifies the architectures between the IPv4 and IPv6 case. If we adopt this modification, we will be using a kind of LSIs in both cases. In the IPv4 case the LSIs are 32 bit long and have 24 index part, in the IPv6 case the LSIs are 128 bit long and have 112 bit hashed index part. In the IPv4 case we need to worry about collisions, in the IPv6 case the probability of collisions is low enough that we can ignore it for now.

[An idea: What if we reserved, say, 2 bits of both LSI formats   to act as a collision field? That is, the field would be   normally zero, but it could be something else if we happen to   have a collision?]

The remaining question is how to handle transport layer pseudo headers. The logical way would be to use full length HITs in the pseudo headers, since the sockets are bound to the HITs. However, that would somewhat complicate the implementations. In the v6 case the difference is not so big: The checksum can be fixed incrementally. The v4 case is not so easy, though. There we may end up in recomputing the checksums on both ways.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Now, opinions please!

1. Should we adopt the new HIT scheme?
2. What is the right API prefix length for the v6 case? 16? 20?
3. Should we reserve collision bits? If so, how many?
4. What to do with the transport layer checksums?

--Pekka Nikander