Subject: [Hipsec] Re: [Hipsec-rg] 128bit LSI -- why?

From: Pekka Nikander <[email-masked]>
Date: Mon, 1 Nov 2004 12:57:20 +0200

[This questions belongs to the working group, not the research
group.  Please direct all future discussion there.]

>   I found that in the new ID (draft-ietf-hip-base-01), a 128 bits LSI 
> is
> introduced.  In my understanding, 32bits LSI is used in the IPv4 
> headers to
> replace IP4 addresses. HIT is already 128bits and can be used in the 
> IPv6
> Header. What is the purpose of the 128bits LSI?

To make a difference between IPv6 addresses and HITs at
the legacy IPv6 API, for those applications that can
easily work without modifications both on HIP and on IPv6.

The only difference between a HIT and a 128-bit LSI is that
the upper most TBD bits of the value are fixed, while in HIT
they come from the hash.

Putting it in another way, we do not believe that we could
reserve a 2-bit prefix from the IPv6 address space for HITs.
On the other hand, from the HIP point of view it would be
wasteful not to use the upper most bits of a HIT, on the
protocol level.

Interoperability is currently preserved by requiring that
the host SHOULD ignore the top-most TBD bits when comparing
HITs for equality.

You may consider this as a transition mechanism, hopefully
to be deprecated at some (distant) point of time.

--Pekka

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Tim Shepard <[email-masked]>
Date: Mon, 01 Nov 2004 06:26:32 -0500

> wasteful not to use the upper most bits of a HIT, on the

Also, we cannot be sure that 128 bits of hash value will remain
secure, so HITs may need to be longer than 128 bits.  I think that may
be relevant for making a distinction between 128-bit LSIs which are
used across APIs and the HITs themselves which may need to be variable
length.  (Should 128-bit hash values not be thought secure enough for
HITs, then it may be necessary to think about whether 128-bit LSIs
introduce any security risks.)

			-Tim Shepard
			 [email-masked]