Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Apr 2007 13:38:50 +0300

Hi,

at last, we had some people review the draft. There were a set of 
comments on the list that need to be addressed. When can we expect a 
revised document addressing those comments?

Additionally, I found a few nits:

The acronym "HIP" needs to be expanded in the title of the draft.

In the abstract:
OLD:
The Host Identity Protocol and architecture (HIP) proposes

NEW:
The Host Identity Protocol (HIP) and architecture proposes

There are a few acronyms (e.g., DHT) that need to be expanded on their 
first use. Others (e.g., API) are probably well known and do not need to 
be expanded.

The Terminology section should include the acronyms of the terms that 
are defined there (i.e., HIT, LSI).

The draft does not have the mandatory IANA Considerations section. It 
should.

References should be divided into Normative and Informative. 
Alternatively, given that this will be an informational draft, the 
References Section could be renamed as Informative References.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Folks,
> 
> during the month this WGLC has lasted, we have not received a single 
> comment on the document, even though I sent a reminder half-way through 
> the WGLC. It seems that the WG is not interested in completing the items 
> we added to our charter after requesting the publication of our original 
> chartered items.
> 
> I would like to get at least two volunteers for each of our new charter 
> items to perform dedicated reviews. This will ensure that we make some 
> progress in our charter.
> 
> Please, if you would like to volunteer to perform a dedicated (thorough) 
> review of one (or more) of our chartered items, send an email to the 
> chairs.
> 
> Thanks,
> 
> Gonzalo
> HIP co-chair
> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> note that we are already half-way through this WGLC and we have not 
>> received any comments (yet). I would like to encourage people to be 
>> active in this WGLC.
>>
>> Thanks,
>>
>> Gonzalo
>>
>> Gonzalo Camarillo wrote:
>>> Folks,
>>>
>>> we would like to working group last call the following draft:
>>> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt
>>>
>>> This WGLC will end on March 1st. This should give people enough time to
>>> read the draft and send their comments to the list and the authors.
>>>
>>> As the first WGLC comment, the draft should have a null IANA
>>> considerations section.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>> HIP co-chair

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 2 Apr 2007 14:01:14 -0700

Gonzalo,

I will publish an -01 version this week, if there are no further
comments.  Below is how I propose to address the remaining comments that
have come in the past two weeks.

Also, here is one section of text that needs to be updated with the
publication of ORCHID; I'll clean it up:

"  Depending on how HITs are ultimately defined, it may be hard for a
   system to distinguish between a HIT and a routable IPv6 address.
   Elsewhere it has been proposed [7] that HITs be precluded from using
   highest-ordered bits that correspond to IPv6 addresses, so that at
   least in the near term, a system could differentiate between a HIT
   and an IPv6 address by inspection."

Let me first address the localhost comments by Miika and Shinta:

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 12:01 AM
> To: Henderson, Thomas R
> Cc: Pekka Nikander; HIP
> Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt
> 
> On Wed, 14 Mar 2007, Henderson, Thomas R wrote:
> 
> > I propose: "This method will not necessarily reveal to the user of
> > the legacy application that HIP is being used."
> 
> Ok.
> 
> >>> 3.2.  Using DNS
> >>
> >> getaddrinfo DNS resolver is defined in rfc3493 and says that
> >> NULL host
> >> name refers to the localhost. Is there any differences in local vs.
> >> remote host name resolution? Or in the use of local vs.
> >> remote host names?
> >
> > I am not sure what you would like to see stated.  If 
> nodename is null,
> > then you are connecting to yourself, and I suppose that a 
> system could
> > use HIP in a loopback fashion in that way, but I don't know the use
> > case.  I had in mind the non-null case-- do you think it needs to be
> > described to that detail?
> 
> Actually the section name is "Using DNS" and since the name 
> is obtained 
> locally, it is not relevant for the section. Resolution of 
> local HITs is 
> actually more related to my following comment. See below.
> 
> >> The draft does not mention explicitly the use ipv4 and 
> ipv6 wildcard
> >> addresses at the server side. Maybe something like this could
> >> be added?
> >>
> >>    The wildcard addresses accept both non-HIP and HIP based
> >> connections,
> >>    and especially the ipv6 wildcard can be used also for 
> ipv4 traffic
> >>    [RFC3493]. Depending on the implementation, sockets bound
> >> explicitly to
> >>    an locator may or may not accept HIP based communications
> >> as defined in
> >>    Section 3.1.
> >
> > I would be fine with adding that-- where do you think it belongs?
> 
> I would prefer a new section 3.4, or alternatively, to the 
> end of section 
> 3.1. I would like to propose some concrete text about local name 
> resolution also. My proposal is based on the observation that 
> all of the 
> current implementations are using some kind of a virtual 
> interface with 
> LSIs or HITs:
> 
>    When getaddrinfo [RFC3493] resolver is used for resolving local
>    addresses, it may also return HITs or LSIs. An application 
> that binds
>    to such an HIP-based identifier, may not be able to accept non-HIP
>    based communications. In addition, the system may have 
> several HITs.
>    Naturally, an application that binds to a single HIT cannot accept
>    connections that use the other HITs of the system.
> 
> -- 
> Miika Komu                                       
> http://www.iki.fi/miika/
>  
> -----Original Message-----
> From: Shinta Sugimoto [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 12:00 AM
> To: Henderson, Thomas R; Pekka Nikander
> Cc: [email-masked]
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt
> 
> Hello,
> 
> I read the draft-ietf-hip-applications-00.txt. Overall, I found the
> document easy to read (I mean its readability is high).
> The followings are my comments:
> 
> Substantial:
> 
> - I found that Section 3 was primarily focusing on behavior of client
> host which is in many cases HIP initiator.  I mean, Section 3 gives
> detail descriptions about how connect() system call is used by client
> and how remote host identifier is treated.  But there is no 
> description
> about treatment of local host identifier.  Some application may call
> bind() system call to bind a socket to a specific local address.
> So I think it is better to add some description in Section 3 
> how system
> can/should behave in terms of local address management so that legacy
> application can make use of HIP, IMHO.  I expect it is done in the
> same way as remote address management though.

I propose the following text to try to address the above concerns:

"3.4.  Local address management
   
   The previous sections focused mainly on client behavior (HIP
initiator).
   We must also consider the behavior for servers.  Typically, a server
   may bind to a wildcard IP address and well-known port.  In the case
   of HIP use with legacy server implementations, there are again a few
   options.  As in Section 3.1 above, the system may be configured
manually
   to always, optionally (depending on the client behavior), or never
use 
   HIP with a particular service, as a matter of policy, when the server
   specifies a wildcard (IP) address.

   When getaddrinfo [RFC3493] resolver is used for resolving local
   addresses, it may also return HITs or LSIs, if the system has
assigned
   HITs or LSIs to internal virtual interfaces (common in many HIP 
   implementations).  The application may use such identifiers as
   addresses in subsequent socket calls. 

   Some applications may call bind() to bind a socket to a specific
   local address.  If the local address specified is an IP address,
   again, the underlying system may be configured to still use HIP.  If
   the local address specified is a HIT (Section 3.3), the system should
   enforce that connections can only come to the specified HIT.  If a 
   system has many HITs, an application that binds to a single HIT
   cannot accept connections to the other HITs in the system.  It may
   be possible for a system to specify a special ORCHID value as a local
   HIT wildcard value, if such wildcarding among local HIs is desired.
   
   When a host has multiple HIs and the socket behavior does not
prescribe
   the use of any particular HI as a source identifier, it is a matter
   of local policy as to how to select a HI to serve as a source
identifier."

> 
> - Secondly, I have a question as follows, which is related to the
> above comment.  I assume that the source identifier would be selected
> by either:
> 1) source address selection performed by the kernel based on 
> RFC 3484, or
> 2) explicitly specified by bind()
> In the case of 1), is there any requirements/recommendation 
> from HIP to
> RFC 3484 with regard to the treatment of HIT?  In particular, if we
> have ORCHID, how does it influence RFC 3484?

That topic seems to me to be outside of the scope of this draft, and
probably needs to go into a future multihoming document.  

> Editorial:
> 
> - Section 3.3, there is a redundant "and" in the first sentence.
> 

OK

> -----Original Message-----
> From: Alberto Garcia [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 7:05 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt
> 
> Hello again Tom,
> 
> I'm glad that you're interested in my comments. So now I'd 
> like to discuss some
> of your responses:
> 
> > > 3) In general, there is some ambiguity in the usage of the
> > > terms host identity,
> > > host identifier and host identity tag.
> > I do not think there is ambiguity here, but perhaps 
> inconsistency in use of
> > acronym?  I am not sure all of these need to be compacted, 
> since it seems to
> > read better to me to spell out "host identities" sometimes.
> 
> I think I didn't explain it correctly. Actually "ambiguity" 
> was not the right
> word to use here. What I meant is that in 
> http://www.ietf.org/rfc/rfc4423.txt ,
> page 5, it is defined:
> "Host Identity: An abstract concept assigned to a 'computing 
> platform'.  See
> 'Host Identifier', below."
> "Host Identifier: A public key used as a name for a Host Identity."
> In my opinion we should avoid using Host Identity for 
> something else than the
> host itself, since it is "an abstract concept". Then I 
> suggest to use the term
> Host Identifier or HI -previously defined in section 2-  when 
> talking about
> mapping IP addresses into HI, and things related to DNS.

I see your point, and will clean it up with respect to host identifier
terminology.

> 
> > > 5)In "3.2.  Using DNS":
> > > It seems strange the repetition of the same title just three
> > > paragraphs before.
> > > I could suggest "3.2. Returning HIs directly from the name
> > > resolution process",
> > > or something similar.
> >
> > How about "Using DNS names in applications" to parallel 3.1's title?
> 
> How about in 3.1:  "Using DNS to map IPs to HIs"?
> As you know, the difference between 3.1 and 3.2 is that:
> - in 3.1: domain name -> IP address -> HI
> - in 3.2: domain name -> HI
> Symbol -> means mapping. I think this difference should be 
> clearly stated in the
> section titles.

OK, I will change 3.1 to "Using DNS to map IPs to HIs" and 3.2 to "Using
DNS to map domain names to HIs"

> 
> > > [...] to return a Local Scope Identifier (LSI) or Host
> > > Identity Tag (HIT) rather
> > > than an IP [...]
> > > s/Local Scope Identifier (LSI) or Host Identity Tag (HIT)/LSI
> > > or HIT    -- as
> > > they are defined in section 2.
> >
> > At this point in the text, LSI acronym has not yet been 
> used.  I agree that
> > HIT doesn't need to be spelled out here.
> 
> Actually LSI can be defined in section 2: "Local Scope 
> Identifier (LSI): A 32-
> or 128-bit quantity locally [...]".

OK

> 
> > > [...] It may be possible for an LSI or HIT to be routable or
> > > resolvable, but
> > > such a case may not have the level of security in the binding
> > > to host identity
> > > that a HIT has with the host identity. [...]
> > > This sentence is somehow confusing, please consider rewriting it.
> >
> > How about changing this paragraph:
> >
> > "   It may be possible for an LSI or HIT to be routable or 
> resolvable,
> >    but such a case may not have the level of security in 
> the binding to
> >    host identity that a HIT has with the host identity.  
> For example, a
> >    special IP address that has some location invariance is the
> >    identifier-address discussed in [6].  In general, LSIs and HITs
> >    considered to date for HIP have been non-routable."
> >
> > to this:
> >
> > "  It may be possible for an LSI or HIT to be routable or 
> resolvable,
> >    either directly or on an overlay.  For example, a
> >    special IP address that has some location invariance is the
> >    identifier-address discussed in [6].  A term other than 
> LSI may be
> >    needed for these routable identifiers, since they would
> >    no longer be locally scoped.  When using DNS, returning 
> a routable
> >    identifier would avoid the aforementioned problems with 
> referrals.
> >    However, the cost of routability may be that the hash binding
> >    between the routable identifier and the host identity would be
> >    weakened, since more bits may be allocated to the hierarchy."
> 
> Yes, much clearer now. BTW, here, the term "host identity" is 
> applicable in my
> opinion.

OK, agree.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 3:39 AM
> To: HIP
> Cc: Pekka Nikander; Henderson, Thomas R; David Ward
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt
> 
> 

OK

> The Host Identity Protocol (HIP) and architecture proposes

OK

> first use. Others (e.g., API) are probably well known and do 

OK, will do a check.

> are defined there (i.e., HIT, LSI).

OK.

> The draft does not have the mandatory IANA Considerations section. It 

OK.  Will add a new section that states "This document has no actions
for IANA."

> References Section could be renamed as Informative References.

Will rename to Informative References.

Thanks to all who provided comments,

Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 05 Apr 2007 14:11:12 +0900

Hi Thoams,

Please find my response inline.

On Mon, 2 Apr 2007 14:01:14 -0700

> Let me first address the localhost comments by Miika and Shinta:
[snip]

>    of local policy as to how to select a HI to serve as a source

Ok, I think the above texts are fine and useful for users (application
programmers).

Ok.

> > - Section 3.3, there is a redundant "and" in the first sentence.

I personally see no more issues in the draft. Thanks for the clarification.

[rest of the original email was snipped]

Regards,
Shinta