Subject: [Hipsec] WGLC: draft-ietf-hip-native-api-06

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 24 Jun 2009 19:50:28 +0300

Folks,

we would like to start the WGLC on the following draft:

http://tools.ietf.org/html/draft-ietf-hip-native-api-06

Some time ago, we decided to wait with this WGLC until the NAT traversal 
draft was more mature. The WGLC on the NAT traversal draft ends on 
Sunday. We chose to make both WGLCs overlap a bit just in case somebody 
wants to review both drafts at the same time.

This WGLC will end on July 12th.

Cheers,

Gonzalo
HIP co-chair

---

From: Ari Keranen <[email-masked]>
Date: Tue, 30 Jun 2009 14:22:00 +0300

> http://tools.ietf.org/html/draft-ietf-hip-native-api-06

Here are some comments on the HIP native API draft. Indented text is 
copy-pasted from the draft.

The draft does not seem to take NAT traversal into account. For NAT 
traversal purposes an application that is not using a resolver should be 
able to get the local UDP port used by the HIP daemon for receiving 
incoming HIP messages. Also the application should be able create a 
HIT-to-locator mapping that includes a (possibly non-standard) UDP port 
number for a peer. Probably this is more of an issue for the shim6 API 
draft, though.

Also, I think it would be worthwhile to clarify in section 3.2 what 
socket options exactly are used for setting new HIT-to-locator mappings 
when no (DNS) resolver is used. Maybe add a reference to section 4.6.

In section 4.1. Socket Family and Address Structure Extensions:

    The
    HIP_HIT_ANY equals to HIP_HIT_ANY_PUB or HIP_HIT_ANY_TMP.

Do you mean here that
HIP_HIT_ANY = HIP_HIT_ANY_PUB | HIP_HIT_ANY_TMP
or that the implementation is free to set HIP_HIP_ANY to any one of the 
two? I'd guess you mean the binary/logical or, but it wasn't clear while 
reading this the first time.

4.2. Extensions to Resolver Data Structures:

    The simultaneous use of both HIP_PREFER_ORCHID and
    HIP_PREFER_PASSIVE_* flags produces a single sockaddr_hip structure
    containing a wildcard address that the application can use either for
    incoming (node argument is NULL in getaddrinfo) or outgoing
    communications (node argument is non-NULL).

I think you should introduce the HIP_PREFER_PASSIVE_* flags before this. 
Actually, I couldn't find any explanation of their semantics in the 
whole document.

4.6. Explicit Handling of Locators:

    An application that initiates a connection using a connection
    oriented socket to a particular host at a known address or set of
    addresses can invoke SHIM_LOCLIST_PEER socket option.

What about UDP (non-connection oriented) sockets? I hope you can also 
use the LOCLIST option with them.

4.5. Source HIT Selection by the System:

                  | Public DSA      | 130        | 7     |
                  | Public RSA      | 140        | 8     |
                  | [RFC3484] rules | 50-100     | 7     |

Are the labels for Public DSA and RFC 3484 rules intentionally the same?

Editorial nits/comments:

The table of contents is partially double-spaced but all the other HIP 
RFCs have fully single-spaced TOCs, so it would make sense to use only 
single spacing here too.

4.1. Socket Family and Address Structure Extensions:

    The port number ship_port is two
    octets in network byte order. and the ship_hit is 16 octets in

A period in the middle of a sentence.

4.4. Validating HITs:

          short sockaddr_is_srcaddr(struct sockaddr *srcaddr
                                    uint64_t flags);

Missing comma between the arguments.

4.6. Explicit Handling of Locators:

The description for SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND in Figure 
6 implies that the options have only "set" semantics while they seem to 
also work with "get". Also, I'd call that a "table" instead of "figure".

    [...] uses the first address (if multiple are provided, or else the
    application can override this by setting SHIM_LOC_PEER_PREF to one of
    the addresses in SHIM_LOCLIST_PEER.

Missing closing parenthesis.

Cheers,
Ari

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 30 Jun 2009 12:11:02 -0700

Here are additional comments on the native API draft, mostly editorial
nits.

You might reference ORCHIDs earlier on (maybe second or third paragraph
of introduction) as the first time they appear in this draft is section
4.2. Should the resolver function be dealing with sockaddr_orchid
instead of sockaddr_hip? The naming is a little strange to have the
HIP_PREFER_ORCHID flag return sockaddr_hip. (See also a note below about
typedef orchid_t ...)

Abstract, Page 2
current sockets API for the Host Identity Protocol
                        ^^^
Section 1., Page 4
are of an experimental nature  *or* are experimental in nature
       ^^                             ^^(deleted of) ^^
Section 3.1 Page 5
(parenthesis might make these steps more clear in the text)
calls the resolver in step (a) to resolve an FQDN in step (b).
                           ^ ^                    ^^      ^ ^
and a set of locators in step (c).
                      ^^      ^ ^
Section 3.1 Page 5
caches the HIT to locator mapping with the HIP module
                                  ^^^^
Figure 1 Page 5
I'm not sure you need the double text <HITS+locators = HITs+locs>
Maybe just <HITs+locs> or <HITs+locs.> would suffice?

Section 3.2 Page 5-6
suggest replacing:
  The resolver associates implicitly the HIT with the locator(s)
  by e.g. communicating the HIT-to-IP mapping to the HIP daemon. 
with this:
  The resolver may implicitly associate the HIT with its 
  locator(s) by communicating the HIT-to-IP mapping to the
  HIP daemon.

Page 3 says:
"This document specifies extensions to [RFC3493] to define a new
 socket address family, AF_HIP.  The macro AF_HIP is used as an alias
 for PF_HIP in this document because the distinction between AF and PF
 has been lost in practice."
but then Section 4.1 Page 6, 2nd paragraph talks about using PF_HIP
"The use of the PF_HIP constant" ...

In Figure 2 on Page 6, there is typedef struct in6_addr hip_hit_t. It
may be worthwhile to reference the RFC 4843 ORCHIDs so that the HIT is
defined as an ORCHID such as: typedef struct in6_addr orchid_t; typedef
orchid_t hip_hit_t;

Section 4.1 Page 7
identifiers refer to the use of anonymous identifiers
                             ^^
Section 4.1 Page 8
it should be noted that different
             ^^^^^ (replaced noticed)
Section 4.2 Page 8
to be used by applications to query
                         ^
The application must set both the
^^^
The application denotes its preference
^^^
Section 4.2 Page 10
cache the locator mappings with the HIP module
                           ^^^^
it should be noted that the application
             ^^^^^
Section 4.5 Page 11
When an application using a AF_HIP-based
     ^^
Section 4.5 Page 12
When the system provides multiple keys of the same type
     ^^^                                  ^^^
Section 4.5 Page 12
calls and in the ancillary data of datagram packets
                 ^^^^^^^^^
Section 9 Page 15
Jan Melen appears to have provided twice the feedback :)

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 30 Jun 2009 13:44:37 -0700

> -----Original Message-----
> From: Ari Keranen [mailto:[email-masked]] 
> Sent: Tuesday, June 30, 2009 4:22 AM
> To: HIP
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-06
> 
> Gonzalo Camarillo wrote:

I'm concerned that you have hit upon a real problem here.  The shim6
draft or protocol framework do not seem to have any concept of NAT
traversal support.  I do not think this is a simple patch for the shim6
document; for instance, is shim6 WG willing to rewrite Figure 1 of
http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-
08.txt
to show the shim6 layer sitting on top of UDP?  The concept of a locator
in shim6 is an IPv6 address, not a transport address.

One possibility would be to remove the explicit locator-related messages
in the native HIP API document (leaving them for further study), but
that would also strip out the support for outbound opportunistic mode.

The other options seem to be to ask the shim6-api draft authors, and WG,
to support NAT traversal, or to just write a HIP-specific API for these
aspects.  In either case, I think we (HIP WG) should decide what we want
this API to be.

> Are the labels for Public DSA and RFC 3484 rules 

They shouldn't be the same, but more broadly, I think this section may
need some more work.  According to RFC 3484, the precedence value is
used for sorting destination addresses, and the label for selecting
source addresses, but the text here implies that precedence is used for
source address selection.  It is not clear how RFC3484 rules relate to
HITs, or whether they are referring to possible use of IP addresses.  

Tom