Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]]

From: Miika Komu <[email-masked]>
Date: Tue, 24 Apr 2007 23:36:58 +0300 (EEST)

On Tue, 24 Apr 2007, Henderson, Thomas R wrote:

(cc:d hipsec because this might be of interest also to other people)

> I am a bit confused as to shim6 role and whatever happened to
> draft-sugimoto-multihome-shim-api-00.  Is the HIP API work supposed to
> cover shim6, or not?  If not, should it be coordinated with how shim6
> does their API?

HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't currently see 
any compatibility issues between any of the drafts. The work has been 
distributed roughly in the following way:

* native api
   * opportunistic mode
   * some socket options
* shim6 api
   * multihoming
   * locator handling
* btns api
   * channel bindings, connection latching
   * tuning some of ipsec security parameters

IMHO, the BTNS stuff is meaningful for HIP mostly in the context of 
opportunistic mode. We have a pile of improvements for the next version of 
the BTNS draft from Nicolas Williams that we haven't had time to work on 
yet.

http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-02.txt
http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt

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

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

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 26 Apr 2007 14:24:26 +1200

I've not yet had a detailed look at the APIs themselves, but I have a  
comment on the overall structure of this set of documents.  Nowhere  
do I see a recommendation as to what constitutes a useful referral  
for applications in HIP, SHIM6 or BTNS.  That's really an  
architectural consideration, but it should be expressed in the API as  
well, at least insofar as there needs to be a well defined way to get  
from a valid referral to a running connection.  The API certainly has  
means to construct connections given several kinds of referral.

Andrew

On 25/04/2007, at 8:36 AM, Miika Komu wrote:

> HIP API does not cover SHIM6 APIs (or BTNS APIs) and I don't  
> currently see any compatibility issues between any of the drafts.  
> The work has been distributed roughly in the following way:
>
> * native api
>   * opportunistic mode
>   * some socket options
> * shim6 api
>   * multihoming
>   * locator handling
> * btns api
> opportunistic mode. We have a pile of improvements for the next  
> version of the BTNS draft from Nicolas Williams that we haven't had  
> time to work on yet.
>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 26 Apr 2007 12:15:31 +0300

Good point about referrals.

I think we need another document.

As far as I can see, the basic message is easy: use the full public  
key for referrals.  Amend it with locators if you know fresh and good  
ones, but they are only taken as hints.

--Pekka

On 26 Apr 2007, at 05:24, Andrew McGregor wrote:

> I've not yet had a detailed look at the APIs themselves, but I have  
> a comment on the overall structure of this set of documents.   
> Nowhere do I see a recommendation as to what constitutes a useful  
> referral for applications in HIP, SHIM6 or BTNS.  That's really an  
> architectural consideration, but it should be expressed in the API  
> as well, at least insofar as there needs to be a well defined way  
> to get from a valid referral to a running connection.  The API  
> certainly has means to construct connections given several kinds of  
> referral.
>
> Andrew
>
>> IMHO, the BTNS stuff is meaningful for HIP mostly in the context  
>> of opportunistic mode. We have a pile of improvements for the next  
>> version of the BTNS draft from Nicolas Williams that we haven't  
>> had time to work on yet.
>>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 26 Apr 2007 11:14:34 -0700

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 1:37 PM
> To: Henderson, Thomas R
> Cc: Ahrenholz, Jeffrey M; [email-masked]
> Subject: RE: [Fwd: [Fwd: [Hipsec] NAT Traversal and Native HIP API]]
> 
> currently see 
> any compatibility issues between any of the drafts. 

I didn't draw the same conclusion.  The shim6 API draft talks 
about HIP, the HIP API draft talks about shims.  They don't seem 
to be consistent either; the shim6 draft talks about EIDs, ULIDs, 
and HITs, while the HIP draft talks about endpoint descriptors 
(EDs).  Even the document titles seem to be very close:
"Native API for SHIM Layer Protocols" and "Socket API for 
Multihoming Shim".  Maybe the socket options are split out
between the two drafts, but there seems to me to be a clear
relationship.

Some comments on the HIP API draft:

I do not think that the concept of Endpoint Descriptor as the
primary application-level name for endpoints is fully worked out.
In particular, I question the overall design of using a 
locally-scoped name as the primary name at the native API.  One
criticism of HIP is that it does not properly support application
referrals when LSIs are used.  ED could be subject to the
same criticism.  It seems somewhat a step backward to me that
we would try to define this new HIP namespace to allow hosts
to be named explicitly, then to avoid using such names at
native APIs.  
 
I understand the goal stated in the draft that users do not want 
to have to handle 128-bit flat identifiers, but the role of 
aliases for these identifiers needs to be carefully thought out.  
I am not sure that abstracting these names at the socket API is 
critical because humans are not interacting with the system at 
that level.  There may need to be some other resolution mechanism 
considered.

For instance, I can imagine that I might want to assign a 
name such as "my work laptop" to a host and have that mapped 
locally to a lower-level identifier somewhere locally on my system, 
but resolving that might not be the job of the socket API but
rather something like the resolver.

I think there are a few steps that are needed:

1) definition of a new address family (AF_HOST) that allows
for the application to signal to the system that the quantity
being passed at the application is a host identifier.  Ideally,
this should explicitly allow users to specify hosts by HIT and
to allow IP addresses to be optionally (additionally) passed
as hints.  Wildcard values should also be supported.

(I don't know about Pekka's suggestion to pass the full HI; I'm
not sure why that is needed)

2) there should be a set of flags and policy attributes (sec 3.2.4) 
that should be settable via the equivalent of setsockopt().  I am 
not sure about all of the list of options in Table 2, though.  For 
instance, setting the ESP transform is not something that is done 
at the sockets API but at other APIs like PFKEY.

After reaching the above two milestones, an application that is 
HIP aware could cleanly use the sockets API with HITs.  The next 
step might be to consider how to generalize it to allow for LSIs
(endpoint descriptors) and for advanced functionality like allowing 
an application to register its own application-specific host 
identity for use on the socket, but the use cases should be clearly 
described and agreed before venturing down that path, and consideration 
made as to whether sockets API or another API is the right choice.

Tom

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 27 Apr 2007 13:47:10 +1200

> between the two drafts, but there seems to me to be a clear

I agree about the consistency: there should be one set of  
terminology.  As it is, these documents would make very confusing  
manual entries for the APIs.

> rather something like the resolver.

I rather agree; and additionally, it seems to require greater  
refactoring of an application to make it support EDs rather than go  
with the existing design of passing around struct hostent *s...  
especially if the application already supports IPv6, because adding a  
third address family is much easier than adding the second.

> not sure why that is needed)

At this level I think the API should require at least one locator in  
a connect(), because the 'how do you look up a HIT' question is still  
unresolved; I think it should be done within the resolver, not below  
the sockets API.

> at the sockets API but at other APIs like PFKEY.

But setting a TLS crypto option is done using a library-specific  
handle that eventually points at a socket.  I think setting transform  
options is better done with setsockopt(), simply because otherwise  
the application has to do a whole lot more work to get a handle in  
another API for something it already has a pointer to, namely the  
socket.

> made as to whether sockets API or another API is the right choice.

Can't we just assign application specific identities with bind()?   
That would seem most in line with the existing API.  So to make a  
connection using an app specific identity, you make a socket, bind it  
to the app identity, resolve the peer, and call connect with the  
results.

Andrew

---

From: Miika Komu <[email-masked]>
Date: Fri, 27 Apr 2007 15:23:45 +0300 (EEST)

On Thu, 26 Apr 2007, Henderson, Thomas R wrote:

Thanks Thomas, some comments below,

> between the two drafts, but there seems to me to be a clear

Ok, I think we need a terminology section in the drafts at the minimum.

> to be named explicitly, then to avoid using such names at

If you are suggesting HIs and HITs as referrals, they have their own 
problems because the locator is needed as hint. The API does not give
false feelings about referrals because the EDs don't even look like 
addresses. The application can figure with getlocaledinfo and 
getpeeredinfo that what is the best type of referral for its use; an 
IP address (for legacy apps and for opportunistic connections), HI or HIT.

Thomas, you did mention anything about the opportunistic mode in your 
comments which was the main motivator for the ED in the draft. I believe 
the draft addresses this problem in a clean way with the EDs as discussed 
in sections 1, 2.4 and 3.1.

> that level.  There may need to be some other resolution mechanism

The ED concept is engineering choice and it not really related to 
usability. It is related to code developers (as means for avoiding hard 
coded applications), but not to the actual end-users.

The draft considers that what happens when people decide to transition 
from 128 bit HITs to 256 bit HITs in the future? I am not sure that it is 
good idea to hardcode this to the API (recall the SHA1 collision 
problems).

> as hints.  Wildcard values should also be supported.

Please see above my comments regarding to the use of HITs.

The draft already contains PF_SHIM (never mind about the difference 
between AF and PF, it has been already broken). Wildcard values are 
supported as described in section 3.1. "Automatic" HIT + IP mappings are 
supported by the resolver and can be manually configured as show in 
section 3.2.1.

> not sure why that is needed)

Application can query for full local or peer HIs using the functions in 
section 3.2.3.

> at the sockets API but at other APIs like PFKEY.

The ESP transforms belong to the BTNS API draft. The BTNS security 
options won't be settable with setsockopt() but rather "wrapper 
functions for setsockopt".

> made as to whether sockets API or another API is the right choice.

I don't see how burdening a HIP aware application with LSIs, HIT128, 
HIT256 and HIs is going to make it modular. I think a single "blob" 
identifier would make things easier. Think about forwards compatibility 
with other protocols supporting identity locator split (see 
SHIM_AF_FAMILY in section 3.2.4).

The application specific identifiers are already handled in section 3.2.2.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 27 Apr 2007 15:07:08 -0700

Miika, some follow-up inline:

> addresses. 

Neither do ORCHIDs to a HIP-aware app.

> The application can figure with getlocaledinfo and 

Can't you simply connect(*, locator) where * is a wildcard value for the
HIT?

> good idea to hardcode this to the API (recall the SHA1 collision 

(see my last comment below)

> Application can query for full local or peer HIs using the 

again, I am not sure of the utility, since a HIT uniquely refers to a
HI, and the base exchange provides the HI.

> The application specific identifiers are already handled in 

I think if we go down this path, we need to consider more broadly than
HIP what are the implications of making applications work on the basis
of LSIs.  Maybe the application community can be consulted.

Tom

---

From: Miika Komu <[email-masked]>
Date: Sun, 29 Apr 2007 17:18:18 +0300 (EEST)

On Fri, 27 Apr 2007, Henderson, Thomas R wrote:

Hi Thomas,

> Neither do ORCHIDs to a HIP-aware app.

Agree.

>> comments which was the main motivator for the ED in the draft. I 
>> believe the draft addresses this problem in a clean way with the EDs as 
>> discussed in sections 1, 2.4 and 3.1.
>

Unfortunately no, because the standard connect system call inputs only a 
single socket address structure. Creating a new connect2 call (and sendv, 
sendto, sendmsg) is not good for backwards compatibility. Also, I don't 
think that using a socket address structure that contains both the 
identifier and the locator is a good solution either because the locator 
can get depracated quite soon.

The draft specifies the opportunistic style connect() in section 3.1 with 
SHIM_ED_ANY (it can be used also by clients, not only by servers, will be 
fixed in the next version). The same flag can already be set in the 
resolution step with AI_ED_ANY when the application does not want to tweak 
with connect() (please see the fourth bullet).

>> supported as described in section 3.1. "Automatic" HIT + IP mappings 
>> are supported by the resolver and can be manually configured as show in 
>> section 3.2.1.
>>

Let's think about it this way: do you think that there is absolutely no 
need for a HIP-aware application to know the whole HI?

> of LSIs.  Maybe the application community can be consulted.

Are you suggesting a cross-area review from applications area?

---

From: Miika Komu <[email-masked]>
Date: Sun, 29 Apr 2007 18:13:59 +0300 (EEST)

On Fri, 27 Apr 2007, Andrew McGregor wrote:

> I agree about the consistency: there should be one set of terminology. 
> As it is, these documents would make very confusing manual entries for 
> the APIs.

Ok.

> I rather agree; and additionally, it seems to require greater refactoring of 
> an application to make it support EDs rather than go with the existing design 
> of passing around struct hostent *s... especially if the application already 
> supports IPv6, because adding a third address family is much easier than 
> adding the second.

In contrast to draft-00 version, I tried to minimize the cost of 
converting an IPv6 application to use the SHIM extensions. For example, a 
client application simply needs to add a AI_ED flag to getaddrinfo() in 
order to resolve endpoint descriptors.

> At this level I think the API should require at least one locator in a 
> connect(), because the 'how do you look up a HIT' question is still 
> unresolved; I think it should be done within the resolver, not below the 
> sockets API.

I don't see a clear way of passing a locator in the existing connect() 
call as discussed in the previous email, but I agree that the HIT-lookup 
is a task for resolver.

> But setting a TLS crypto option is done using a library-specific handle that 
> eventually points at a socket.  I think setting transform options is better 
> done with setsockopt(), simply because otherwise the application has to do a 
> whole lot more work to get a handle in another API for something it already 
> has a pointer to, namely the socket.

I will remove the this part from the next version of the draft as a better 
place for it is the BTNS draft.

> Can't we just assign application specific identities with bind()?  That would 
> seem most in line with the existing API.  So to make a connection using an 
> app specific identity, you make a socket, bind it to the app identity, 
> resolve the peer, and call connect with the results.

I am not sure if bind() is the right place to do this. Socket address 
structures are constrained by size and passing private keys inside socket 
address structures does not work when private keys are large. The draft 
specifies in section 3.2.2 to first associate the private key with an ED 
using a function call and then to pass the ED to bind().

I think ED concept would be useful also with smart cards that do not 
pass the whole private key but just sign or verify data. The ED could be 
used to enforce access control mechanism in such a system. However, I 
think this is out of scope for the draft.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 29 Apr 2007 16:09:27 -0700

> From: Miika Komu [mailto:[email-masked]] 
(snip)
> with connect() (please see the fourth bullet).

I think that there may be other more explicit options available to solve
this problem that do not require going with an abstract ED just to fit
it into the size of a sockaddr.  

For instance, there could locally be defined some kind of ORCHID
wildcard that fits into the sockaddr_in6, and it could be preceded by
setsockopt(LOCATOR) of some sort.

> need for a HIP-aware application to know the whole HI?

Regardless of whether the HIP aware application needs to know the HI, it
is not clear to me why the HI must be passed to the system instead of
just the HIT.

> Are you suggesting a cross-area review from applications area?

One possible first step might be to raise the question on the
applications area mailing list about the possible benefits and costs of
making the long-term HIP API based on locally-scoped handles to
addresses/identities.

Tom

---

From: Miika Komu <[email-masked]>
Date: Mon, 30 Apr 2007 11:30:26 +0300 (EEST)

> setsockopt(LOCATOR) of some sort.

Yes, this is possible. I'd also allow this behaviour from the resolver.

This kind of identifier cannot be used as a referral anymore, hence it is 
a locally scoped identifier within the host. Seems like a shift towards 
the LSI/ED approach. (We need an additional function call to query for the 
actual channel bindings when connect() returns.)

I think it would be easier (KISS!) to have only single kind of identifiers 
in the native APIs: either referral-capable or locally-scoped identifiers. 
Mixing referrals and LSIs/EDs in the API will be confusing for the 
developer. Since the referral case simply does not work with opportunistic 
mode, I'd exclude referrals out and stick to the local scope.

If you agree on the locally scope identifiers, the next thing is the 
format of the locally scoped identifiers: do the identifiers need to look 
like IP addresses or not? Locally scoped IP-address-like identifiers 
present bogus information to the application, or at least I don't see any 
benefit from such a information to HIP-aware applications. It could 
even lead to security problems when a misguided developer starts to 
use them in access control lists.

Ok.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 30 Apr 2007 05:58:29 -0700

> Sent: Monday, April 30, 2007 1:30 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: comments on native HIP API draft
> 

I think there is a difference here-- it is not an identifier, it is
explicitly a wildcard.  The locator could be used in a referral.

The main issue here seems to be whether we want to move to a long-term
API based on LSIs.  I think you identified a potential benefit: that it
would make the API future-proof against changes to the HIT size.
Similarly, one might argue that the IPv6 transition would have been a
lot easier for applications if the concept of endpoint descriptor were
already available for the past twenty years; IPv6 could have been hidden
in the system.  This latter observation makes me wonder whether there
have been such considerations previously in the applications area.  

Therefore, it seems like asking a question like the following would be
helpful: "We are contemplating a level of indirection in naming hosts to
future-proof the HIP API.  One could conceive that such a level of
indirection could be used more generally outside of HIP, to enable
applications to be more compatible across IP versions, for instance.
What are the benefits and costs that you see about migrating the basic
socket API calls towards end-system handles rather than explicit
end-system addresses?"

Tom