Subject: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10?

From: [email-masked] (Henderson, Thomas R)
Date: Fri Jan 14 13:56:00 2005

>=20
> Firstly, if we do adopt any scheme like this, I think that we must=20
> follow the usual "be strict in what you generate and liberal in what=20
> you accept" rule.  That is, even if we decided that current=20
> hosts MUST=20
> generate only 01/10 HITs, they also SHOULD accept any HITs. =20

I am OK with the proposed restriction, in the interest of facilitating
experimentation.  I would suggest making it SHOULD generate/SHOULD=20
accept, and explain the rationale for this, and that it probably will
be lifted in the future.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Mon Jan 31 08:07:01 2005

>> Firstly, if we do adopt any scheme like this, I think that we must
>> follow the usual "be strict in what you generate and liberal in what
>> you accept" rule.  That is, even if we decided that current
>> hosts MUST generate only 01/10 HITs, they also SHOULD accept any HITs.
>
> experimentation.  I would suggest making it SHOULD generate/SHOULD

Since I haven't seen any objections to this proposed restriction, I 
hereby suggest that we add the following text to the HIT section in the 
base specification.  Comments?

--Pekka

To facilitate experimentation and make certain kind of implementations 
easier, the following restrictions are temporarily placed on HITs.  
These restriction are to be lifted at the end of 2008.  That is, after 
January 1st 2009, any implementation claiming conformance to this 
specification MUST accept any HITs from peers and be able to process 
them normally.

The restrictions: Before the end of 2008, all implementations SHOULD 
restrict the HITs they generate to ones whose upper-most (left-most) 
two bits are either binary 01 or 10.  That is, when generating new HIs, 
if the resulting HIT has as its first two bits as 00 or 11, the 
implementation SHOULD generate new HIs until it generates one that 
fulfils this restriction.  Additionally, a conforming implementation 
MAY refuse to communicate with a peer that has a HIT with the 
upper-most bits either 00 or 11.  When refusing a HIP connection on 
this bases, the implementation MUST send an R2 with a NOTIFY payload, 
with the NOTIFY code being UNSUPPORTED_HIT_VALUE_RANGE.

A rationale: One way to implement HIP is to use unmodified IPv6, TCP 
and UDP implementations in the stack, using HITs in the place of IPv6 
addresses.  In such an implementation, modifications are only needed at 
the API level, where it may be necessary to convert HITs into LSIs and 
vice versa, and at or below ESP, where it is necessary to convert HITs 
into locators (IP addresses) and vice versa.  However, if the IPv6 
address space and the HIT value space overlap, it becomes quite hard to 
define secure IPsec policies.  Furthermore, there is also the 
possibility of having a conflict between a HIT value and an IPv6 
address, leading to potential confusion within the stack.

This restriction temporarily allows such simple minded implementations. 
  It is expected that such implementations will eventually migrate to a 
different implementation details, e.g., by tagging the values either as 
HITs or IPv6 addresses.  However, tagging the values may be hard in 
existing IPv6 implementations; the purpose of this restriction is to 
allow such HIP implementations that rely on and patch on existing IPv6 
implementations.