Subject: RE: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 Dec 2007 10:48:16 -0800

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 1:22 PM
> To: HIP
> Subject: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt
> 
> Folks,
> 
> I would like to WGLC the following draft:
> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt
> 
> This WGLC will end on December 19th.
> 
> Send your comments to the author and this list.
> 
> Thanks,
> 
> Gonzalo
> HIP co-chair
> 

Miika,
Here are some more comments.  In summary, I'd like to see more work on
this draft on some points below.

Overall
========

I still don't think the document gives enough guidance to the
implementor about where various aspects of HIP-related API are defined
(there are two other API documents in shim6 and BTNS WGs).
Specifically, the shim6 API draft specifies new socket options
applicable to shim6 and HIP, but some of them are not applicable when
using PF_HIP.  I would like to see more clearly stated which shim6
options from Table 1 of the shim6 document are applicable/invalid when
using PF_HIP.

So I would like to see more explicit guidance of the form; e.g.:
- this document specifies extensions to RFC3493 and 3542 to define a new
socket address family and describe how the socket calls in those RFCs
are adapted or extended as a result
- socket options for use with PF_HIP/PF_INET6 sockets are defined in the
[shim6-api], and section X.X of this document clarifies which options
are applicable to PF_HIP sockets.
- this document relates to the RFC5014 as follows...
- APIs to manipulate IPsec bindings are defined in [btns-api]...

Andrew also pointed out the need to align with or extend RFC5014 (source
address selection).

The introduction should clearly state a design assumption:
"This API allows a HIP-aware application to use the sockets API
independent of any handling of IP addresses, but also allows an
application to use HIP names in conjunction with IP addresses if so
desired.  As a result, this API implies that the system may need to
resolve HIP names to IP addresses, and describes how a system resolver
might be able to cache such bindings during the name resolution
process."

In section 4.1:
"The HIT value is an IPv6 address and it is stored in network byte
order."  I disagree, and I think other reviewers will too.  HITs are not
IPv6 addresses.

In section 4.3 (page 8) the document starts talking about ORCHIDs, in a
manner that suggests at first glance that they are distinct from HITs.
I think I understand what you are trying to do here, but I am not sure
it is the right way.  If I understand correctly, you are allowing to
bind sockets to wildcarded HIT macros, but then allowing the system to
accept the communications even if it is not a HIT but is instead an IPv6
address, unless it sets a flag to "ONLY_ORCHID" in the ship_flags
(although it is unclear which socket call requires this flag to be set).

My opinion is that more work needs to be done on this part of the API.
I think you want to allow an application to set some wildcards in the
socket calls and possibly permit the socket to open if the peer does not
support HIP but is reachable via IPv6.  I think there will need to be
some care taken to not violate semantics since we are mixing address
families at this point.

Regarding the last paragraph of section 4.1, some systems support
accept_filters that allow the system to do the access controls-- do we
want to specify the same here?

In section 4.2 (resolver extensions), the description implies that a
resolver will have to do two queries (nodename to HITs and nodename to
IP addresses), and concatenate the results in the rres field, before
returning from getaddrinfo().  Shouldn't the application instead issue
two getaddrinfo's for each of the different queries?

Section 4.3 first paragraph could perhaps be developed further.  Maybe
it warrants another major section in the document.  Also, I did not
quite understand the placement of the second paragraph in this section.
It seems like this guidance (what error to return if the HIT cannot be
resolved) is more appropriate somewhere in Section 4.1.

Editorial
==========

The last sentence of the abstract has some missing words.

Generally, Terminology section follows the Introduction.  

It seemed to me that the third paragraph of the Introduction might be
the one that you want to lead with.

I do not think that "HIP Layer" row needs to be in Table 2.  To me, this
is akin to saying that there is an "ARP Layer" between Network and Link
layer, and that is not how ARP is commonly depicted in the stack.

I was surprised that there was no reference to the HIP DNS draft since
this is heavily based on HIP DNS resolution.

In the paragraph after figure 2:
s/published or not, but that/published or not, but note that/

I thought that we agreed to delete the "IPV6_ADDR" portion from the
macro HIP_IS_IPV6_ADDR_ANON_HIT?

For document title, I would suggest changing from:
Native Application Programming Interfaces (APIs) for Host Identity
Protocol (HIP)
to 
Basic Socket Interface Extensions for Host Identity Protocol (HIP)
which would align the title with RFC 3493.

Lingering comment from my previous post
=========

> >>     Both of these two approaches may be more prone to errors
> >> than the use
> >>     resolver with host names.  Hence, HIP-aware applications should
> >>     prefer to use the resolver with host names.
> >
> > Can you specify which errors the resolver-less approach is 
> more prone
> > to?
> 
> The main concern is wow to map a HIT to an IP address in the 
> current state 
> of HIP deployment in DNS. Do you suggest to move the last two 
> sentences?

I just want to understand what the assumed error risk is.  You seem to
be saying that indirecting through the DNS is less error prone than
directly providing the HIT to IP address binding at the API.  Is that
because you are assuming that handling HITs is an error prone operation
(as compared with DNS names) for either applications or users?  

I think it should either be more specified to state what the presumed
error is, or else remove the last two sentences.

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