[Hipsec-rg] RE: Routable IP addresses as LSIs

[[e-mail] (Henderson, Thomas R)]

=20

> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]]=20
> Sent: Friday, October 07, 2005 1:55 AM
> To: Henderson, Thomas R
> Cc: [e-mail]; [e-mail]
> Subject: Routable IP addresses as LSIs
>=20
> Tom,
>=20
> > 3.   draft-henderson-hip-applications-01.txt
> >
> > Pekka suggested that this is soon ready for individual submission=20
> > (Informational).  Please email the list with your comments,=20
> even if it=20
> > is to say "I read the draft and have no comments."
>=20
> I am starting to think that we probably should start pushing=20
> routable IP addresses as LSIs, together with opportunistic=20
> HIP, for certain uses.  In other words, our work on this=20
> draft has finally been able to change my mind on this. :-) =20
> We might want to call this "invisible HIP", as whether there=20
> is HIP underneath or not is invisible to applications.
>=20

I think that such an "invisible" implementation could potentially be
quite flexible, with more features than our current implementation
provides (our kernel-mode Linux implementation is built this way, while
the Windows implementation uses non-routable LSIs). =20

The configuration can be performed by extension of the IPsec SPD and
related tools (e.g., setkey) and the applications do not have to change
or deal with non-routable LSIs.  For instance, rules could be based on
IP addresses or HITs, and HIP could either run opportunistically or
require that the HIT records match the IP addresses as fetched from DNS.
Also, there could be a few policy options for behavior such as requiring
HIP to allow communications to proceed, or just trying to use HIP if the
peer supports but allowing fallback to normal TCP/IP.  There is also a
possible tie-in to the OCALA overlay architecture that does not
necessarily require non-routable LSIs.

> I am planning to take this up during the shim6 interim in=20
> Amsterdam, tomorrow and on Sunday, with the goal of shim6 and=20
> this "invisible HIP" being semantically compatible with each=20
> other.  I'm afraid that the actual HIP base exchange protocol=20
> is still far too heavy for shim6, but I am hoping that we=20
> could share much of the path status maintenance and packet=20
> transport mechanisms for non-ESP case.
>=20

Thanks for the note-- please let us know how the discussion goes there.

Tom