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

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

>=20
> To resolve this problem, I suggest that we temporarily restrict the=20
> allowed HIT values into the unused IPv6 address space.  That is, when=20
> generating a new HI, the generator MUST check that the resulting HIT=20
> has the two topmost bits as 01 or 10. =20
>=20
> Opinions?
>=20

When this restriction is lifted, what becomes of the legacy =
implementations that are enforcing it?  Will this practically cause such =
01/10 HITs to be forever avoided?

Tom

---

From: [email-masked] (Andrew McGregor)
Date: Fri Jan 14 01:02:01 2005

How about checking for that condition or an IANA assigned address, for 
which implementations MUST be configurable for after the fact?

Andrew

On 14/01/2005, at 6:55 PM, Henderson, Thomas R wrote:

>
>>
>> To resolve this problem, I suggest that we temporarily restrict the
>> allowed HIT values into the unused IPv6 address space.  That is, when
>> generating a new HI, the generator MUST check that the resulting HIT
>> has the two topmost bits as 01 or 10.
>>
>> Opinions?
>>
>
> When this restriction is lifted, what becomes of the legacy 
> implementations that are enforcing it?  Will this practically cause 
> such 01/10 HITs to be forever avoided?
>
> Tom
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>
>

---

From: [email-masked] (Pekka Nikander)
Date: Fri Jan 14 04:32:01 2005

>> such 01/10 HITs to be forever avoided?

(I assume that you mean that 00/11 HITs to be forever avoided.)

> which implementations MUST be configurable for after the fact?

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.  In 
practise I think, this would result most HITs being usable, as real 
collisions are likely to be quite rare.  That is, the only real reason 
that I can see for not accepting an 00/11 HIT is that it happens to 
collide with an IP address of some real host.  (How does the host know 
that is another issue.  It might be easier just to ignore HITs starting 
with 001 or 111110.)

Secondly, I agree with Andrew that this MUST be configurable.  Hence, 
even if we adopted this restriction, we can say that there MUST be a 
set of configuration options that
- allow the host to generate any HIT instead of just 01/10 HITs
- accept the host any HITs instead of 01/10 HITs
- others?

What comes to the "accept any HIT rule", there won't be any problems if 
the host uses always HIP.  In other words, I'm afraid that we would end 
up living with this rule until most of the world is converted to HIP, 
if ever.

But let's also consider the alternatives:
- Go back to HIT the prefixes.   Possible, but IMHO not the right 
architectural choice.
- Do not adopt this restriction.  Possible, but results at least in our 
case in much uglier implementation, and large rewriting of the code if 
we want to be able to accept all HITs, i.e., also such HITs that 
collide with some IP address.
- Do adopt this restriction, but with a fixed date when it will be 
lifted.  For example, let's decide that the restriction will be lifted 
by January 31st, 2007.  That would mean that all implementations MUST 
be upgraded to support all HITs by that day.

I would suggest that we would go with this restriction, with the above 
principles and configuration rules, and possibly with a fixed date for 
lifting the restriction.

Opinions?

--Pekka

---

From: [email-masked] (Tim Shepard)
Date: Fri Jan 14 07:14:01 2005

I guess I missed why this restriction is needed.

IIRC, there are no 128-bit hash functions left standing, so don't we
need to be thinking of 192-bit (or longer, in case confidence in the
security of SHA1 is lost) HITs?  We can still pass 128-bit LSIs
across the IPv6 APIs, using a (say) 120-bit suffix of the HIT with an
8-bit prefix as a handle (an LSI) that can be passed across legacy
APIs to refer to the HIT.

I don't see what problem is solved by restricting the top two bits of
the HIT itself.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Fri Jan 14 09:15:01 2005

> I don't see what problem is solved by restricting the top two bits of

There problems are implementation level.  One side of the problem is 
related to checksums, the other to IPsec policies.

The specification says (wisely IMHO) that the TCP or UDP checksum is 
computed with using the IPv6 pseudo header and HITs in the place of IP 
addresses.  Consequently, the stack must have access to HITs when 
computing the checksum.  Now, there are basically two possibilities for 
implementing this.  One is to use HITs in the place of IP addresses 
everywhere in the stack; i.e., the LSIs are converted to HITs just 
below the API, and from there down to IPsec the stack uses HITs.  
That's the way we have done our implementation.  The other possibility 
is to use LSIs in the stack, and rewrite the checksum computation and 
verification code the replace the LSIs with HITs during the checksum 
computation.

The second problem is in IPsec policies.  In order to allow ESP to be 
used both for HIP and other protocols, we currently have generic IPsec 
policies that rely on HIT prefixes.  That made it very easy to direct 
all HIP traffic to ESP and to make sure that all incoming HIP traffic 
uses ESP properly.  Now, if we used LSIs in the stack this problem goes 
away, as the LSIs have prefixes.  But then we have to modify the 
checksum code.  Alternatively, if we use HITs in the stack then we have 
to modify the policy code and accept the fact that there may be 
policies that conflict with real IP addresses.

Maybe it would be best for us to bite the bullet now, use LSIs in the 
stack, and just patch the TCP/UDP checksum code instead of introducing 
my proposed restriction.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Jan 14 09:29:03 2005

Hi Pekka,

I just got an idea (inlined below), which is probably stupid, but 
anyway...

On Friday 14 January 2005 15:14, Pekka Nikander wrote:
> > IIRC, there are no 128-bit hash functions left standing, so don't
> > we need to be thinking of 192-bit (or longer, in case confidence
> > in the security of SHA1 is lost) HITs?  We can still pass 128-bit
> > LSIs across the IPv6 APIs, using a (say) 120-bit suffix of the
> > HIT with an 8-bit prefix as a handle (an LSI) that can be passed
> > across legacy APIs to refer to the HIT.
> >
> > I don't see what problem is solved by restricting the top two
> > bits of the HIT itself.
>
> There problems are implementation level.  One side of the problem
> is related to checksums, the other to IPsec policies.
>
> The specification says (wisely IMHO) that the TCP or UDP checksum
> is computed with using the IPv6 pseudo header and HITs in the place
> of IP addresses.  

(...)

> The second problem is in IPsec policies.  In order to allow ESP to
> be used both for HIP and other protocols, we currently have generic
> IPsec policies that rely on HIT prefixes.  

(..)

> Maybe it would be best for us to bite the bullet now, use LSIs in
> the stack, and just patch the TCP/UDP checksum code instead of
> introducing my proposed restriction.

And what if the spec says that TCP/UDP checksum are ignored on the 
receiver side? After all if we have ESP encapsulating TCP/UDP 
payloads, we don't need to check for the packet integrity, and you 
might be able to compute the checksum with LSIs or HITs; who cares...

AFAICS the only problemis that we're in the process of removing ESP 
from the base spec, so we might run into problems if we use another 
protocol to carry the user data and that protocol happens to not 
implement an integrity check (like ESP does). In that case we might 
say: "If the protocol carrying user data implements an integrity 
check, the TCP/UDP checksum SHOULD be ignored on the receiver side".

But perhaps this is completely silly...

Thanks,

--julien