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

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 11 Mar 2007 21:11:07 +0200

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

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

---

From: Andrei Gurtov <[email-masked]>
Date: Mon, 12 Mar 2007 16:43:02 +0200

Hi,

I've read this draft and think that it addresses an important issue, is
well-written and ready for publication.

Andrei

Gonzalo Camarillo wrote:
> 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,
>>

---

From: Julien Laganier <[email-masked]>
Date: Mon, 12 Mar 2007 16:10:15 +0100

On Wednesday 31 January 2007 12:25, Gonzalo Camarillo 
wrote:
> draft-ietf-hip-applications-00.txt

Folks,

I reviewed this document, and thought it is well 
written and ready for publication. I'd however like to 
suggest a couple of minor edits below:

1. Introduction

[...]

   Fully deployed, the HIP architecture will permit
   applications to explicitly request the system to
   connect to another named host by expressing a
   location-independent name of the host when the 
   system call to connect is performed. 

Shouldn't we substitute "connect" with "send a packet" 
in the above text portion, and throughout the rest of 
the document? After all, IP provides a datagram 
oriented communication paradigm.

[...]

   When HITs are used (rather than IP addresses) as 
   peer names at the system API, they can provide a
   type of "channel binding" (Section 1.1.6 of [2]) in
   that the ESP association formed by HIP is
   cryptographically bound to the name (HIT) invoked by 
   the calling application.

s/system API/system API level/ ?

[...]

2.  Terminology

   Host Identity Tag: A 128-bit quantity formed by the
   hash of a Host Identity.  More details are available
   in [1].

s/formed by the/composed with the/ ?

[...]

3.  Approaches for supporting legacy applications

[...]

   While the text below concentrates on the use of the 
   connect system call, the same argument can also be
   applied to datagram-based system calls.

s/can also be applied to/is also valid for/

I hope those helps. Best,

--julien

---

From: Miika Komu <[email-masked]>
Date: Tue, 13 Mar 2007 18:48:10 +0200 (EET)

> > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt

I have already reviewed the draft once but some minor comments below. I 
think the draft is mature to proceed forward. Alberto Garcia will give an 
extra review during this week.

> 3.1.  Using IP addresses in applications

Maybe you could explicitly mention in the section that this method
does not show the channel bindings to the user of the legacy application.

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

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

The latest version of the NAT draft was reviewed by two people as I 
mentioned in my previous email to this list. I hope to get an extra review 
of the draft during this week from Julien Laganier.

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 14 Mar 2007 09:25:29 +0100

Hi Gonzalo,

Sorry for not sending some comments on the HIP NAT traversal draft  
during the WGLC. There have been some other issue keeping me away  
from the draft.

As first conclusion: I see the technical issues in HIP NAT draft as  
stable but some minor things and editorial things need to be fixed.

The authors are going to meet at the IETF meeting and discuss the draft.

Thanks,

   Martin

Am 11.03.2007 um 20:11 schrieb Gonzalo Camarillo:

> 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.
>
> charter items to perform dedicated reviews. This will ensure that  
> we make some progress in our charter.
>
>> 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,
>>>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 14 Mar 2007 15:11:12 -0700

Miika,  

Thank you for reviewing this draft.  Some responses inline.

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 9:48 AM
> To: Gonzalo Camarillo
> Cc: Pekka Nikander; HIP
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-applications-00.txt
> 

I propose: "This method will not necessarily reveal to the user of
the legacy application that HIP is being used." 
> remote host name resolution? Or in the use of local vs. 

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?

>    an locator may or may not accept HIP based communications 

I would be fine with adding that-- where do you think it belongs?

Tom

---

From: Miika Komu <[email-masked]>
Date: Thu, 15 Mar 2007 09:01:22 +0200 (EET)

> the legacy application that HIP is being used."

Ok.

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

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

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 16 Mar 2007 15:59:56 +0900

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.

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

Editorial:

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

Regards,
Shinta

On Sun, 11 Mar 2007 21:11:07 +0200