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

From: [email-masked] (Henderson, Thomas R)
Date: Wed Feb 2 00:27:01 2005

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

Generally OK with me-- a few minor comments below.
>=20
> To facilitate experimentation and make certain kind of=20
> implementations easier, the following restrictions are=20
> temporarily placed on HITs. =20
> These restriction are to be lifted at the end of 2008.  That=20
> is, after January 1st 2009, any implementation claiming=20
> conformance to this specification MUST accept any HITs from=20
> peers and be able to process them normally.
>=20
> The restrictions: Before the end of 2008, all implementations=20
> SHOULD restrict the HITs they generate to ones whose=20
> upper-most (left-most) two bits are either binary 01 or 10. =20
> That is, when generating new HIs, if the resulting HIT has as=20
> its first two bits as 00 or 11, the implementation SHOULD=20
> generate new HIs until it generates one that fulfils this=20

s/fulfils/fulfills/

> restriction.  Additionally, a conforming implementation MAY=20
> refuse to communicate with a peer that has a HIT with the=20
> upper-most bits either 00 or 11.  When refusing a HIP=20
> connection on this bases, the implementation MUST send an R2=20
> with a NOTIFY payload, with the NOTIFY code being=20
> UNSUPPORTED_HIT_VALUE_RANGE.

MAY instead of MUST (since NOTIFY is optional), and add
"Any such NOTIFYs may be rate-limited"

>=20
> A rationale: One way to implement HIP is to use unmodified=20
> IPv6, TCP and UDP implementations in the stack, using HITs in=20
> the place of IPv6 addresses.  In such an implementation,=20
> modifications are only needed at the API level, where it may=20
> be necessary to convert HITs into LSIs and vice versa, and at=20
> or below ESP, where it is necessary to convert HITs into=20
> locators (IP addresses) and vice versa.  However, if the IPv6=20
> address space and the HIT value space overlap, it becomes=20
> quite hard to define secure IPsec policies.  Furthermore,=20
> there is also the possibility of having a conflict between a=20
> HIT value and an IPv6 address, leading to potential confusion=20
> within the stack.
>=20
> This restriction temporarily allows such simple minded=20
> implementations.=20
>   It is expected that such implementations will eventually=20
> migrate to a different implementation details, e.g., by=20
> tagging the values either as HITs or IPv6 addresses. =20
> However, tagging the values may be hard in existing IPv6=20
> implementations; the purpose of this restriction is to allow=20
> such HIP implementations that rely on and patch on existing=20
> IPv6 implementations.
>=20
I suggest replacing the above two paragraphs with:

A rationale: One way to experimentally implement HIP is to use=20
unmodified IPv6, TCP and UDP implementations in the stack, using HITs=20
in the place of IPv6 addresses.  This modification makes it easier to=20
use existing IPv6 data structures to hold HITs and to distinguish=20
between the two data types.  If the IPv6 address space and the HIT value
space overlap, it becomes hard to define secure IPsec policies without
explicitly tagging the values either as HITs or IPv6 addresses.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Wed Feb 2 05:57:01 2005

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

Ok.

> A rationale: One way to experimentally implement HIP is to use
> unmodified IPv6, TCP and UDP implementations in the stack, using HITs
> in the place of IPv6 addresses.  This modification makes it easier to
> use existing IPv6 data structures to hold HITs and to distinguish

Looks good to me.

If nobody has any objections or comments, I suggest that Petri
would add the resulting text to the next version.

Opinions, others?

--Pekka

---

From: [email-masked] (Andrew McGregor)
Date: Wed Feb 2 06:03:01 2005

> would add the resulting text to the next version.

(unlurks)

Looks good to me.  I had no other comments, and Tom has just answered 
the last one.

Andrew