Subject: [Hipsec] Issue 16: Details of LSI handling

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 1 05:41:01 2003

Tom,

Thanks for clarifying this issue (again).  I think that your
description is very valuable, and I am planning to include it
into an appendix in -08 in some for or another.

> ...  In our discussions in SF, there were two schools of thought, if 
> I recall correctly:

> i) have resolver return an LSI in place of an actual IP address, and 
> have applications use the LSI instead of the IP address in socket 
> calls.

> ii) have HIP be kept in kernel land, with the kernel doing the right 
> housekeeping.  ... [T]he use of HIP is coordinated by a policy table
> that temporarily traps packets going to particular IP addresses until
> a HIP exchange completes and the security association is set up. 

We have now implemented i), but just always returning the default,
HIT based LSI, and not invoking the HIP exchange from the resolver.
We simply return the HIT or the LSI as the first "address" returned
by gethostbyname, gethostbyname2 or getaddrinfo.  The HIT or LSI
is then followed by the actual addresses.  Seems to work well enough
for the time being.

> Long term, I'd like to see host identity information exposed to 
> applications and explicitly used in socket calls, together with IP 
> addresses if need be, rather than the workarounds described above.

Agreed.  Actually, in our implementation if the application uses
the newer getaddrinfo API, it can check whether the first returned
"address" is actually a HIT/LSI or a genuine address.  The flags
allow this.  On the other hand, Miika's "native HIP API" seems to
be the right way to go in the longer term.

> For the time being (without changing applications), I favor approach 
> ii) above, because I haven't seen anyone effectively solve all of the
> issues associated with i), and because ii) basically works without
> changes to the applications except for some corner cases that we
> haven't encountered.  Whichever solution we adopt, we probably should
> document the various limitations or restrictions on use.

Since we apparently have implementations doing both i) and ii),
I would suggest that we leave this issue open for now.  In practise,
I propose that we have the current LSI exchange in I2/R2, but we
leave it undefined what the hosts should do if there is a collision,
referring to an appendix that contains your description of the
situation.

We are heading for an experimental RFC anyway, and therefore I think
we can live with a few loose ends if necessary.

Hence, unless I receive a very clever scheme with ready text from
someone, I am planning to leave this issue technically open, and
formally close it just to get -08 shipped.

Is this OK for everybody?

--Pekka Nikander