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

[Shinta Sugimoto <[e-mail]>]

Hi Thomas, all,

Excuse me for jumping in the discussion, but please find my comments 
inline.  I am co-authoring the multihome shim API draft.

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Ari Keranen [mailto:[e-mail]] 
>> Sent: Tuesday, June 30, 2009 4:22 AM
>> To: HIP
>> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-06
>>
>> Gonzalo Camarillo wrote:
>>> we would like to start the WGLC on the following draft:
>>>
>>> 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.
> 
> 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.

well, I don't think this is a very big change for SHIM6 actually.
In theory, SHIM6 can support IPv4 locator as well.  And such an
idea was brought up and discussed in the SHIM6 WG in the past.
For instance, Section 1.3 of draft-nordmark-shim6-esd-01.txt
discusses the issue of IPv4 locator.  In my understanding,
SHIM6 is very much dependent on IPv6 with regard to the
security mechanism to protect identity ownwership (i.e., CGA/HBA).
However, there is not much dependency on IPv6 with regard to
locators because validity check of claimed locator is done by
the return routability test.

Although Figure 1 in the multihome draft shows that the
multihome shim layer is a sub-layer inside the IP layer,
this does not necessarily mean that UDP encap interface cannot
be handled as a locator.  I think this is common to HIP as
well (HIP lays between transport layer and IP layer, from
an architectural p.o.v., if I understand it correctly,
but it supports handling UDP encap interface as a locator).

> 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.

As a co-author of the multihome shim API document, I am willing
to improve the draft to support NAT Traversal.  It is not only
useful for HIP but also for SHIM6 (in the future) as mentioned
above.  Does this sound reasonable?

With regard to the data structure for storing IPv4 address and
a pair of UDP port numbers, let me come up with proposal later.
I need to discuss with co-authors of the multihome shim API draft.


Regards,
Shinta

> 
>>
>> 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?
>>
> 
> 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
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>