Subject: [Hipsec] API and LSI resolution

From: [email-masked] (Henderson, Thomas R)
Date: Thu Mar 11 23:17:01 2004

In Seoul, I presented an API/LSI proposal for the base spec 
(see http://hip.piuha.net/meetings/ietf59/slides/pres-ietf59-hip-henderson-api.ppt)
Due to lack of opinion expressed, we decided to discuss more on the list.

So to reiterate my proposal, I suggest the following:

i) Remove LSI TLVs from the protocol; LSIs are statically derived from the 
HIT and are defined by 1.x.x.x where the lower 24 bits correspond to the 24 
lowest HIT bits.
ii) Any collisions, if they are handled, are handled by host NAT at the host 
that discovers the local collision (that is, the stack may NAT the LSI into 
one that doesn't conflict, and take care if it sees the changed LSI in the 
application data stream to flip it back)
iii) Add a subsection after 3.5 (TCP/UDP checksum) that describes ii) above,
and summarizes API issues and the issue of LSIs or HITs in the application
data stream, while deferring full API discussion to another draft
iv) remove Appendix A from the base spec

If there is no conceptual objection to the above, I will propose some 
specific draft text.

Tom

---

From: [email-masked] (Miika Komu)
Date: Fri Mar 12 01:18:00 2004

> If there is no conceptual objection to the above, I will propose some

Sounds ok to me.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 12 01:33:00 2004

To reiterate my position, here are my comments:

> i) Remove LSI TLVs from the protocol; LSIs are statically
> derived from the HIT and are defined by 1.x.x.x where the
> lower 24 bits correspond to the 24 lowest HIT bits.

This is OK to me as it can be added back later as an
optional parameter.

> ii) Any collisions, if they are handled, are handled by
> host NAT at the host that discovers the local collision
> (that is, the stack may NAT the LSI into one that doesn't
> conflict, and take care if it sees the changed LSI in the

This is OK to me as IPv4 apps must be prepared to
deal with NATs anyway.  However, I also see HIP as
a great opportunity to hide all NATting from apps.
Hence, I would like to see, perhaps later, a mechanism
that allows us to resolve LSI conflicts without the host
NATting of LSIs.  Hence, I would like to see using
host NAT as a "MAY", with text stating that there may
be other alternatives in the future, and the exact
method of resolving LSI conflicts in the long run is
an open issue.

> iii) Add a subsection after 3.5 (TCP/UDP checksum) that
> describes ii) above, and summarizes API issues and the
> issue of LSIs or HITs in the application data stream,
> while deferring full API discussion to another draft

I'm fine with explicitly deferring API discussion to another
document.  What comes to the TCP/UDP checksum, we use the
IPv6 pseudo header with HITs anyway, at least conceptually.
Consequently, I would say that any discussion of how to handle
this in the case of using IPv4 stack with possibly host
NATted LSIs belongs to an appendix.

Remember, already at the BOF in Minneapolis Jim Bound made
the comment that in his opinion the main body of the text
is too specific of how to implement things.  I tend to agree
with him.

> iv) remove Appendix A from the base spec

Ok.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Fri Mar 12 03:17:01 2004

Ok.

> a great opportunity to hide all NATting from apps.

The plan was to handle connections like this (if I remember correctly Seoul 
discussions):

We have a server (S) and two clients (C1, C2). Clients have both HITs that 
have the lower 24 bits exactly the same, thus their LSIs would then be the 
same (1.X.X.X = LSIc1 = LSIc2). The server LSI is thus 1.y.y.y = LSIs.

When the server receives the HIT of the peer, it can determine the LSI for the 
peer. At this point, the S can also find out if there is a collision between 
two clients (e.g. if C1 has set up already an SA with the S). It can mark the 
possible collision, generate a new LSI to represent C2 (LSIc2n) locally and 
make a NAT relation between the LSIc2 and LSIc2n. LSIc2n is seen only locally 
by the application running on the S.

The LSI value is always NATted when a packet leaves/arrives. For applications 
that use the IP address in the application data, the NATting functions should 
also modify the application data. This makes the implementation more 
complicated. 

If the LSI is generated with another procedure, than "24 lowest bits of HIT", 
the S cannot detect the collision until the connection attempt comes in. 

> method of resolving LSI conflicts in the long run is

The NAT function described above is not nice and better proposals are welcome.

/petri