Subject: [Hipsec] (not) using HITs as an application identifier

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jul 19 12:12:17 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Friday, July 16, 2004 9:57 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
>=20
>=20
> What if we used routable IP addresses *only* in the API level,
> and not even in the pseudo header? That is, what if the API layer
> would have a table of "HIPed" IP addresses, and would map
> an IP address returned by an application immediately, before
> passing it down the stack, into a HIT, an vice versa. =20

This is actually how our implementation works already-- we
do not pass HITs to user space applications.

The main difference that I see is a difficulty in deferring=20
context exchange for a transport session, in the LHIP case. =20
Receiver has to know how the pseudoheader was constructed,=20
and in absence of any context exchange, relies on the IP=20
addresses.=20

Tom=20

---

From: [email-masked] (Pekka Nikander)
Date: Mon Jul 19 12:12:21 2004

>> passing it down the stack, into a HIT, an vice versa.
>

Nice :-)

> The main difference that I see is a difficulty in deferring
> context exchange for a transport session, in the LHIP case.
> Receiver has to know how the pseudoheader was constructed,
> and in absence of any context exchange, relies on the IP
> addresses.

In a minimal LHIP exchange, you just exchange the HITs without
*any* verification at all.  Hence, you have them available in
your stack.  That can be easily piggybacked in TCP handshake.
In practise, you want to exchange also your WIMP hash anchors,
though still with no security for the HITs.  (Including the
HIT in the WIMP hash chain does not seem to add any security
wrt. the HITs, but may make sense as it seems to make a MITM
attacker's life slightly harder.)  Since a HIT is 16 bytes, and
a WIMP hash anchor should also be minimal 16 bytes (maybe 20),
including them + header overhead means some 40 additional bytes
to the initial TCP SYN and SYN ACK.  Plus, as you receive the
SYN ACK, you know if the other end supports LHIP or not.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Wed Jul 21 09:20:03 2004

Hi Pekka,

One question below...

On Friday 16 July 2004 20:35, Pekka Nikander wrote:
> >> and not even in the pseudo header? That is, what if the API
> >> layer would have a table of "HIPed" IP addresses, and would map

I like this idea.

> your stack.  That can be easily piggybacked in TCP handshake.

In the case of an opportunistic LHIP or HIP exchange (i.e., unknown 
responder HIT) piggybacked on the TCP handshake, how do you compute 
the pseudo-header of the initial TCP SYN? with IP addresses? Or does 
opportunistic mode conflicts w/ piggybacking?

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Jul 22 11:41:01 2004

> opportunistic mode conflicts w/ piggybacking?

Well, as a first approximation, if HIT_Responder==NULL, then the
TCP/UDP pseudo header should use the IP addresses.  In fact,
I would go one step further and define the IP or TCP Option
for the Opportunistic LHIP case NOT to include the Responder HIT
at all, and compute the TCP SYN using a fully backward compatible
pseudo header.  If the Responder does understand Opportunistic LHIP,
it will then answer with the same or a similar option, but start
using HITs in the pseudo header.  For robustness, the Option
could contain a single bit indicating which way the pseudo-header
has been constructed.

In the non-opportunistic LHIP case, there is no need for a IP or
TCP option.  Instead, one can use the (L)HIP protocol and just
piggyback the TCP SYN segment.

--Pekka