Subject: [Hipsec] another review of draft-ietf-hip-native-api-02.txt

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 17 Sep 2007 09:17:40 -0700

Hi Miika,

Here are a few high-level comments, some of which have been touched upon
by other reviewers.

My inclination would be to first describe what an API looks like that
modifies or extends the IPv6 API for HIP support only, and then later
consider whether and how it can be generalized to support other non-HIP
usage.  The reason is that if you try to do the general solution first,
you may lose or obscure getting the HIP-specific concerns right.  

In a similar vein, I would like to see stated up front what are the
functional requirements or assumptions of this API.  In particular,
before we get to syntactical issues, it should be more clear what name
or names (HIT, ORCHID, LSI, HI, RVS) the application is expected to deal
with, and what are the expected semantics of the API calls.  As an
example, is the system expected to be able to handle the case when no
locator information is available in the connect call, or when there are
multiple locators, etc.?  

We should also state what are the assumptions on policy that an
application may want to control.  This seems to me to be underdeveloped
in the current draft; section 4.1 goes into some of this but I think
there are going to be more policy issues that need to be exposed.  For
example, another possible option is to tell the system whether to
enforce the usage of HIP or whether to allow non-HIP communications if
the peer doesn't support HIP.  

Multihoming is also underdeveloped; I realize that there is a separate
shim6 multihoming API document which you are trying to leverage, but
again there probably are some dependencies to explore because that other
API draft, for instance, presumes that REAP is implemented, which is not
officially part of HIP.  

We should also clarify more explicitly the assumptions and requirements
of how the resolver interacts differently with the system (for instance,
in Figure 2, the resolver/SHIM interaction steps d and e implies certain
assumptions on the sequence of events on how the pieces of the system
obtain binding information).  

- Tom

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 16:11:07 +0300 (EEST)

On Mon, 17 Sep 2007, Henderson, Thomas R wrote:

Hi Tom,

> you may lose or obscure getting the HIP-specific concerns right.

Right.

> locator information is available in the connect call, or when there are

HITs and Orchids are already discussed in the draft. I don't see any 
reason to introduce the LSIs because the endpoint descriptor concept was 
also removed. HIs don't fit into socket address structures, so they should 
be polled using separate functions calls such as defined in the BTNS 
draft. I think the RVS vs. end-host locator type should be exposed to the 
application.

I think we need an error value when there is no locator information (or an 
extra lookup returned nothing). With multiple locators, it is up to the 
system on whether sequentialize or parallelize I1 packets, but I think 
that is mostly an implementation issue, not an API issue. That is, unless 
we want to provide extra socket options for the application to set this 
explicitly.

> the peer doesn't support HIP.

The list is ordered so that HITs are in front of the list and routable 
addresses after it. The application either goes through the list 
sequentially (based on timeouts) or launches a parallel connections. In 
the latter case, it is up to the application to choose the fastest 
(usually non-SHIM) vs. securest (HIP) connection.

Perhaps we should add some text regarding to this, but I am not sure yet 
what is the clearest way to do this (logic diagram, text or code 
examples). Contributions are welcome :)

> API draft, for instance, presumes that REAP is implemented, which is not 

I think this is covered pretty much in the SHIM6 draft as you mentioned. 
The REAP related socket options should return an error when the protocol 
does not implement the corresponding feature. I think this could be added 
to the SHIM6 API draft directly.

> obtain binding information).

This was also mentioned by Jan. The e. and d. arrows should not be in the 
draft as it is currently defined. However, I am looking for more feedback 
on the "mapping side effect" before I update the figure.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 Sep 2007 10:15:30 -0700

Miika,
One other comment is that it seems to me that we ought to distinguish
between address family (namespace) and level in the stack where the
function is applied (SHIM).  The shim6 multihoming API draft uses
SOL_SHIM but this is defined for the "level" field in the setsockopt and
not the address family.  So I don't think it would misalign things to
use AF_HOST with SOL_SHIM, rather than AF_SHIM with SOL_SHIM.

Two possible names to call this are AF_HOST or AF_ORCHID.  I don't have
a strong preference but would probably lean towards AF_HOST, because I
am not sure whether ORCHIDs are thought to be part of AF_INET6 already,
and because there has seemed to be some kind of experimental time limit
on the use of the ORCHID prefix.  

Tom