Subject: [Hipsec-rg] [hipl-users] HIPL release version 1.0.0 (fwd)
From: miika at iki.fi (Miika Komu)
Date: Wed, 31 May 2006 19:42:30 +0300 (EEST)

FYI.

---------- Forwarded message ----------
Date: Wed, 31 May 2006 19:25:21 +0300
From: Diego Beltrami <Diego.Beltrami at hiit.fi>
Reply-To: hipl-users at freelists.org
To: hipl-announce at freelists.org
Cc: hipl-users at freelists.org
Subject: [hipl-users] HIPL release version 1.0.0

Folks,

I would like to proudly announce the availability of the official release 
of HIPL.

InfraHIP HIPL source and binary release for Debian/Ubuntu/Fedora are available
at the following link:

     http://hipl.hiit.fi/hipl/release/1.0.0

Release Notes can be found at:
     http://hipl.hiit.fi/hipl/release/1.0.0/RELEASE-NOTES-1.0.0

The version number has been increased from 0.x to 1.x in order to 
underline the main difference with respect to the previous release: hipl 
has moved to the userspace.

Furthermore, I would experimental HIPL binaries from MerCoNe project for 
ARM-Linux based PDAs:

    http://infrahip.hiit.fi/MERCoNe/

A big "Thank You" to *everyone* who put a great effort in order to achieve 
this great result!

On behalf of the InfraHIP group,

--
Diego

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Mon, 22 May 2006 12:00:40 +0300
Subject: [Hipsec-rg] Meeting on IETF66 at Montreal
Message-ID: <[email-masked]>

This is tentative information, we'll have a HIP RG meeting in Montreal
on Friday afternoon. I'm attending and Tom probably not. If you have
suggestions for agenda items please send them to me.

Andrei

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 19 May 2006 09:35:52 -0700
Subject: [Hipsec-rg] new release of OpenHIP
Message-ID: <[email-masked]>

FYI, we've released a new version of OpenHIP this week (0.3.3),
available under GNU GPLv2 license at http://www.openhip.org.

This version has the following features:

- first support for OS X (IPv4 user mode only)

- patch for bind-9 to support HIP resource records
 - available in our CVS tree under BSD license
 - also, a utility for generating the resource records
 - also, client support for draft-ietf-hip-dns

- updates to implementation to correspond to the following drafts:
draft-ietf-hip-base-05.txt
draft-ietf-hip-esp-02.txt
draft-ietf-hip-mm-03.txt

- continued support for 
draft-nikander-hiprg-hi3-00.txt
draft-ahrenholz-hiprg-dht-00.txt
draft-ietf-hip-registration-00.txt
draft-ietf-hip-rvs-00.txt

- continued support for Windows XP and Linux versions (bug fixes and
draft alignment)

- Ethereal-0.99.0 patch corresponding to the most recent published
drafts

- Updated Linux kernel patch (2.6.13.5) for kernel-mode Linux

Our high-level development schedule is posted at:
http://www.openhip.org/develop.html.

In particular, we are planning to add UDP encapsulation/NAT traversal
patch and IPv6 user-mode support in the next release (July), and
continued work on installation and usability features.

Jeff Ahrenholz (draft alignment, testing, DNS, mobility, Windows, Linux)
and Jeff Meegan (OS X support, mobility) have done the bulk of the work
on this release.  

Tom

From: miika at iki.fi (Miika Komu)
Date: Wed, 17 May 2006 00:41:13 +0300 (EEST)
Subject: [Hipsec-rg] additional text to HIP legacy apps draft
Message-ID: <[email-masked]>

Earlier I left the topic "RE: feedback from draft-hip-applications-02" 
dangling on hipsec-rg list. Let me now return to that topic by providing
some more concrete text to the draft. Sorry for crossposting both to WG 
and RG lists, but the draft is now an official WG item.

Comments are welcome, as always. Thomas, feel free modify and adapt the 
text to the draft.

3.2.  Using DNS

..

New paragraph: "Return HIP HITs instead of IP addresses":

For legacy applications that are not hard coded using IPv4 addresses, it 
is also possible to return HITs in resolver calls. An advantage of 
returning a HIT in comparison to returning an LSI is that a HIT is not 
only a locally created identifier but rather has a global meaning. The 
drawbacks are mostly related to referrals which are discussed in detail in 
section <3.4>. Additionally, the resolver implementation has to be careful 
to return the HITs only when the application requests AF_ANY or AF_INET6 
type of addresses. A HIP enabled resolver is expected to return first the 
HITs and only after that a list of IPv6 addresses, unless the AI_HIP flag 
is set, as descibed in more detail in section <3.5>.

Suggest adding new section 3.4: Referral issues

A referral is the case when three or more instances of an application 
interacts and the first instance communicates with the second instance, 
and then communicates with the third instances and wishes to tell the 
third instance how to contact the second instance [B]. In order to 
maximize backwards compatibility with legacy applications, it is important 
to consider the type of referrals that applications use. However, 
maximizing backwards compatibility may have some negative impacts that 
need to be considered. In this section, we consider four types of 
referrals: end-point identifiers (HITs), end-point locators (IP addresses) 
and middlebox locators (rendezvous).

Using HITs as referrals may not work with legacy hosts that are not HIP 
capable as the HITs are not routable. Having routable HITs requires 
additional infrastructure, such as overlays [C]. In addition, resolving 
HITs to IP addresses in HIP aware applications requires also extra 
infrastructure such as DHTs because HITs contain no hierarchical 
information, which is really required by DNS. A benefit of using HITs at 
the application layer is that they have a longer expected lifetime than IP 
addresses in mobile environments. However, there may be middleboxes, such 
as NATs between the end-points. As a HIT denotes an end-point rather than 
"middle-point", HITs might be more useful than locators with NATted 
environments, especially when end-points are mobile and when both 
communicating end-points are behind NATs.

On the other hand, the use of end-point IP addresses as referrals has the 
quite the opposite benefits and drawbacks to HITs. One benefit of using 
end-point IP addresses as referrals is that they are backwards compatible 
even with legacy hosts that are not HIP capable. In addition, they do not 
require any new infrastructure. As a drawback, the expected lifetime of IP 
addresses in mobile environments is lower than HITs. Another drawback is 
that it may be more difficult to disambiquite whether a given IP address 
belongs to the end-point host or e.g. a NAT middle-box.

Using rendezvous IP addresses as referrals does not work with legacy hosts 
that are not HIP capable. In addition, the rendezvous servers themselves 
are required as an additional infrastructure. As a benefit, the expected 
lifetime of this type of referrals is also longer than for end-point 
addresses in mobile environments. As a second benefit, this case might be 
useful for establishing opportunistic HIP connection between HIP capable 
hosts assuming that the rendezvous server has a sufficient supply of 
locators (one dedicated locator per one responder). When a single 
rendezvous address is dedicated for a single responder, using rendezvous 
addresses as referrals may be less ambigious than when using end-point 
addresses, but more ambiguous than when using HITs.

New section "3.5 Enforcing the use of HIP in legacy applications"

In general, legacy applications are expected to be HIP unaware. In 
practice, this means that the source code of the actual application 
remains unmodified. However, there might be cases when the use of HIP is 
being enforced by either very minimal changes to the application source 
code or to the underlying, dynamically loadable resolver libraries. The
motivation for doing this is to force the application to establish 
connections using HIP, or to not to establish them at all [A].

When the application source code can be modified, AI_HIP flag can set to 
getaddrinfo() resolver call. This way, the application either gets 
LSIs/HITs or nothing at all. Alternatively, the resolver library can be 
configured to force the resolver to enforce system specific behaviour when 
the source code of the application cannot be modified. In this case, the 
resolver can return either LSIs/HITs or nothing at all.

[A] Applying a cryptographic namespace to applications
http://portal.acm.org/ft_gateway.cfm?id=1080786&type=pdf&coll=portal&dl=ACM&CFID=76024067&CFTOKEN=9663775
[B] http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
[C] http://www.ambient-networks.org/docs/Host_Identity_Indirection_Infrastructure_Hi3.pdf

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

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Mon, 15 May 2006 09:45:25 +0200
Subject: [Hipsec-rg] New version of draft-irtf-hiprg-nat-02.txt
Message-ID: <[email-masked]>

Hi all,

The draft "NAT and Firewall Traversal Issues of Host Identity  
Protocol (HIP) Communication" is now available in an updated version.  
Draft -02 contains all changes that have been requested by the final  
reviewers (as indicated in the respective emails).

The draft is already available here:

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-irtf-hiprg- 
nat-02.txt

A HTML-diff to -01 is available here:

http://www.stiemerling.org/ietf/hiprg/draft-irtf-hiprg-nat-02- 
from-1.diff.html

Regards,

    Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 14:27:58 +0200
Subject: [Hipsec-rg] draft-irtf-hiprg-nat-01.txt review
In-Reply-To: <p06230907c072c836b0b4@[18.26.0.27]>
References: <p06230907c072c836b0b4@[18.26.0.27]>
Message-ID: <[email-masked]>

Hi Karen,

Many thanks for reviewing the draft! More inline.

Am 24.04.2006 um 20:43 schrieb Karen R. Sollins:

> In general I find draft-irtf-hiprg-nat-01.txt to be ready to  
> publish with a few additional and reiterated small points or nits.   
> I think it does a nice job of identifying and considering the  
> issues, and should be valuable.
>
> First, I also found that it didn't quite stand on its own because  
> it uses so many acronyms that are not even spelled out.  Perhaps at  
> the first usage of each acronym, it should be written out fully,  
> with the acronym in parentheses (to hint to the reader that  
> henceforth the acronym will be used).

I have added to all non-obvious acronyms a full text explanation.

>
> In addition to the nits reported by others, here is my further list:
>
> *  p. 4, 2nd line: "refer to" should be "reference"

Fixed.

>
> * p. 4, 4th line: "It also does not..." - eliminate "also" to read  
> "It does not".. (since this is the first negative about what the  
> doc does NOT do).

Fixed.

>
> * p. 5, first line - last word is missing.  The sentence ends it  
> "before", but doesn't tell me before what - perhaps what is meant  
> is "before transmission"?

Removed the "before", was a left over.

>
> * p. 5, Sect. 2.2, last sentence, 2nd paragraph: The sentence  
> reads, "They may be addressed in the BEHAVE working group or in  
> [RFC3489]." This suggests a future action, but one can't plan to do  
> something in the future within an already existing RFC, so the  
> sentence needs to say something slightly different about what might  
> happen and what has already happened.

By the current state in the BEHAVE working group the sentence reads:
They are addressed in the BEHAVE working group or in [RFC3489].

Because the BEHAVE working group is working on NAT implementation  
issues.

>
> * Finally, is there an issue with the fact that several of the key  
> references (2 normative and 1 informative) are currently only  
> Internet Drafts?

Yes, there is an issue which cannot be solved by now. All the  
references that are Internet drafts are really needed. However, one  
of  them is already in the RFC editor queue (draft-ietf-hip- 
arch-03.txt) and the others are expected to enter the RFC editor  
queue soon.

Thanks,

   Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 14:07:15 +0200
Subject: [Hipsec-rg] review of draft-ietf-hiprg-nat-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Mark,

Many thanks for reviewing the draft! More inline.

Am 21.04.2006 um 21:26 schrieb Mark Allman:

>
> I found this document to be pretty reasonable and have no problem with
> it being published.  I have a few nits; none of which are a big deal.
>
> allman
>
>
>
> 2.1:
>
>   + "it uses an IP payload" --> "it uses the IP payload"

Fixed.

>
> 2.1.1:
>
>   + "suggests to encapsulate" --> "suggests encapsulating"

Fixed.

>
> 3.1.2:
>
>   + "issue Section 2.1.1 applies" --> "issue applies"
>
>   + "configurations Section 3.1 that" --> "configurations that"
>
>   (Both of these look like they are trying to refer back to particular
>   previous discussions, but its a very odd construct to just plop
>   "Section X" in the middle of a sentence that then makes no sense.  I
>   suggest using a parenthetical at the end of the sentence or some  
> other
>   method.)

Fixed. Was indeed a very odd construction.

>
> 8:
>
>   + The term "pinhole" is first used here.  Maybe it should be
>     introduced earlier?  (Or, defined right here?)

Fixed. No it reads:

    Opening pinholes in firewalls (i.e., loading firewall rules allowing
    packets to traverse) and creating NAT bindings are highly security-
    [...]

>
> Meta:
>
>   + My biggest issue with the draft was with the use of undefined
>     acronyms ("HIT", "SPI", "SPINAT", "NSLP", etc.).  Some of these I
>     knew and some of them I had to go off and figure out.  I suggest
>     spelling them out and if their purpose is not clear from said
>     spelling out then please give a sentence of explanation.

Ok, I will go through the draft and fix this.

Thanks,

   Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 13:52:37 +0200
Subject: [Hipsec-rg] [IRSG] review of document draft-irtf-hiprg-nat-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

Many thanks to Kevin for his review. More inline.

Am 06.04.2006 um 16:18 schrieb Henderson, Thomas R:

> Below is Kevin Fall's review of draft-irtf-hiprg-nat-01.  We're
> expecting two other reviews in the coming weeks.
>
> The next steps are to assemble a RG response to these comments, and  
> then
> share that response (and proposed changes) to the IRSG.  We would like
> to get the IRSG to declare 'ready to publish' as defined by the  
> process
> in:
> http://www.ietf.org/internet-drafts/draft-irtf-rfcs-00.txt
> I'm serving the role of shepherd of this document (see the expired
> draft:
> http://psg.com/~mrw/PROTO-Team/shepherding-draft.txt).  We'll discuss
> proposed changes on the RG list.  This process is similar but not
> identical to IESG review.
>
> Tom
>
> -----Original Message-----
> From: Fall, Kevin [mailto:kevin.fall at intel.com]
> Sent: Thursday, March 30, 2006 9:50 AM
> To: Internet Research Steering Group
> Subject: [IRSG] review of document draft-irtf-hiprg-nat-01
>
>
> I read this document yesterday along with the earlier document
> draft-ietf-hip-arch-03.  At a high-level, although I have no  
> substantive
> objection to the IRTF document, I have a concern with the IETF  
> document
> and therefore the HIP effort more generally.
>
> Here's some more constructive comments for the IRTF doc:
>
> draft-irtf-hiprg-nat-01 is only about traversing firewalls and  
> NATs, yet
> its title is 'middlebox traversal'.  I believe the title should be
> narrowed to reflect its contents, or the content expanded to  
> reflect the
> title.

You are right in the sense that the document is solely handling
NAT and firewall middleboxes. Changed, unless somebody out
of the HIPRG has a major concern about it.

>
> In the abstract I'm not sure its fair to say it 'fundamentally'  
> changes
> the way in which two Internet hosts communicate.  Indeed, in the
> proposal as is, IP addresses are still being used to do the actual  
> data
> routing.  In addition, the phrase "two Internet hosts" gives me  
> concern

Right, IP addresses are still being used but both "use internally"  
the host
IDs. However, I still see the issue of this sentence being a very strong
argument, even though HIP is changing a lot. So, I have stripped out
the 'fundamentally' and it now reads:

   The Host Identity Protocol (HIP) changes the way in which two  
Internet
   hosts communicate. One key advantage over other schemes is that HIP
   does not require modifications to the traditional network-layer  
functionality
   of the Internet, i.e., its routers.

> that multicast is really completely not addressed.  This comes up  
> again
> on page 2 where it says HIP "assumes simple Internet paths, where
> routers forward globally routable IP packets..."  I might says  
> "globally
> routable unicast IP packets".  This problem isn't one directly related
> to the IRTF draft, however, and really is more a common on the IETF
> document.  I will say a little on it later.

Yes, indeed multicast is not handled, but this due to the nature of HIP.

>
> The discussion of NATP points out that the IPv4 HIP base exchange
> doesn't contain port numbers.  Is this fundamental?  Could the HIP
> exchange be carried, e.g. over UDP.  I think something to this  
> effect is
> mentioned later in section 6, but not in exactly that form.

The specification of HIP is using plain IP payload and the encapsulation
in UDP has been ruled out in the first place. However, there is now
a proposal to run the HIP base exchange over UDP, as a result of this
IRTF traversal issue draft.

>
> I am curious also about whether the TCP alternate checksum (RFC1146)
> when the TCP pseudoheader cksum computation is changed to work on  
> HITs.
> Again, this may be a comment on the IETF doc rather than this IRTF  
> doc.

This is a comment towards the IETF document rather than this IRTF  
document.

>
> Section 3 typo "This type of middlebox" -> "These types of  
> middleboxes"
> Also, "forward or discard them" -> "forward, discard, or process  
> them in
> some special way".

Fixed.

>
> Section 4 it says the section identifies possible changes to HIP that
> attempt to improve middlebox traversal, but it is only really for
> firewall and NAT traversal... see comment above.

Fixed to NAT and firewall.

>
> Paragraph #3 of section 4 starting with "When contacting peers"  
> needs to
> be re-written (overloading of pronouns).

Change to:

    HIP nodes located behind a NAT must notify their communication peers
    about the contact information.  The contact information is the NAT's
    public IP address and a specific UDP port number.  This measure
    enables the peers to send return traffic to HIP nodes behind the  
NAT.
    This would require a new HIP mechanisms.

>
> Paragraph #4 of section 4 mentions the rendezvous problem.  This is  
> not
> a HIP-only problem, which should be noted, possibly with appropriate
> refs.  I3 and Keshav's TCA (http://citeseer.ist.psu.edu/724596.html)
> come to mind, for example.

I do not know whether those references are appropriate, since the
rendezvous problem is as old as the usage of NAT. However,
they could show the relationship to other architectures. But I do not
see this draft as the place for this, since we do not go into detail
on the rendezvous point.

Thank you for the review!

   Martin for the authors

>
> Section 8 refers to "pinholes" which could use a sentence of  
> definition
> here.
>
> -- comments on the IETF document draft-ietf-hip-arch --
>
> HIP seems to be looking at an important problem area and it seems  
> to be
> viable at least for the scenarios studied (TCP and UDP transport).  In
> reading this document, I wasn't really sure it works in cases where
> these aren't the transports.  I think about ICMP, for example, as well
> as multicast.  Perhaps its not in HIP's scope to look at these things,
> but if that's the case then does it really make sense to re-tool  
> the end
> host implementations for just these protocols?  Maybe it does, but  
> this
> issue doesn't seem to be discussed in the architecture document.
>
> - Kevin
>

From: miika at iki.fi (Miika Komu)
Date: Wed, 31 May 2006 19:42:30 +0300 (EEST)
Subject: [Hipsec-rg] [hipl-users] HIPL release version 1.0.0 (fwd)
Message-ID: <[email-masked]>

FYI.

---------- Forwarded message ----------
Date: Wed, 31 May 2006 19:25:21 +0300
From: Diego Beltrami <Diego.Beltrami at hiit.fi>
Reply-To: hipl-users at freelists.org
To: hipl-announce at freelists.org
Cc: hipl-users at freelists.org
Subject: [hipl-users] HIPL release version 1.0.0

Folks,

I would like to proudly announce the availability of the official release 
of HIPL.

InfraHIP HIPL source and binary release for Debian/Ubuntu/Fedora are available
at the following link:

     http://hipl.hiit.fi/hipl/release/1.0.0

Release Notes can be found at:
     http://hipl.hiit.fi/hipl/release/1.0.0/RELEASE-NOTES-1.0.0

The version number has been increased from 0.x to 1.x in order to 
underline the main difference with respect to the previous release: hipl 
has moved to the userspace.

Furthermore, I would experimental HIPL binaries from MerCoNe project for 
ARM-Linux based PDAs:

    http://infrahip.hiit.fi/MERCoNe/

A big "Thank You" to *everyone* who put a great effort in order to achieve 
this great result!

On behalf of the InfraHIP group,

--
Diego

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Mon, 22 May 2006 12:00:40 +0300
Subject: [Hipsec-rg] Meeting on IETF66 at Montreal
Message-ID: <[email-masked]>

This is tentative information, we'll have a HIP RG meeting in Montreal
on Friday afternoon. I'm attending and Tom probably not. If you have
suggestions for agenda items please send them to me.

Andrei

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 19 May 2006 09:35:52 -0700
Subject: [Hipsec-rg] new release of OpenHIP
Message-ID: <[email-masked]>

FYI, we've released a new version of OpenHIP this week (0.3.3),
available under GNU GPLv2 license at http://www.openhip.org.

This version has the following features:

- first support for OS X (IPv4 user mode only)

- patch for bind-9 to support HIP resource records
 - available in our CVS tree under BSD license
 - also, a utility for generating the resource records
 - also, client support for draft-ietf-hip-dns

- updates to implementation to correspond to the following drafts:
draft-ietf-hip-base-05.txt
draft-ietf-hip-esp-02.txt
draft-ietf-hip-mm-03.txt

- continued support for 
draft-nikander-hiprg-hi3-00.txt
draft-ahrenholz-hiprg-dht-00.txt
draft-ietf-hip-registration-00.txt
draft-ietf-hip-rvs-00.txt

- continued support for Windows XP and Linux versions (bug fixes and
draft alignment)

- Ethereal-0.99.0 patch corresponding to the most recent published
drafts

- Updated Linux kernel patch (2.6.13.5) for kernel-mode Linux

Our high-level development schedule is posted at:
http://www.openhip.org/develop.html.

In particular, we are planning to add UDP encapsulation/NAT traversal
patch and IPv6 user-mode support in the next release (July), and
continued work on installation and usability features.

Jeff Ahrenholz (draft alignment, testing, DNS, mobility, Windows, Linux)
and Jeff Meegan (OS X support, mobility) have done the bulk of the work
on this release.  

Tom

From: miika at iki.fi (Miika Komu)
Date: Wed, 17 May 2006 00:41:13 +0300 (EEST)
Subject: [Hipsec-rg] additional text to HIP legacy apps draft
Message-ID: <[email-masked]>

Earlier I left the topic "RE: feedback from draft-hip-applications-02" 
dangling on hipsec-rg list. Let me now return to that topic by providing
some more concrete text to the draft. Sorry for crossposting both to WG 
and RG lists, but the draft is now an official WG item.

Comments are welcome, as always. Thomas, feel free modify and adapt the 
text to the draft.

3.2.  Using DNS

..

New paragraph: "Return HIP HITs instead of IP addresses":

For legacy applications that are not hard coded using IPv4 addresses, it 
is also possible to return HITs in resolver calls. An advantage of 
returning a HIT in comparison to returning an LSI is that a HIT is not 
only a locally created identifier but rather has a global meaning. The 
drawbacks are mostly related to referrals which are discussed in detail in 
section <3.4>. Additionally, the resolver implementation has to be careful 
to return the HITs only when the application requests AF_ANY or AF_INET6 
type of addresses. A HIP enabled resolver is expected to return first the 
HITs and only after that a list of IPv6 addresses, unless the AI_HIP flag 
is set, as descibed in more detail in section <3.5>.

Suggest adding new section 3.4: Referral issues

A referral is the case when three or more instances of an application 
interacts and the first instance communicates with the second instance, 
and then communicates with the third instances and wishes to tell the 
third instance how to contact the second instance [B]. In order to 
maximize backwards compatibility with legacy applications, it is important 
to consider the type of referrals that applications use. However, 
maximizing backwards compatibility may have some negative impacts that 
need to be considered. In this section, we consider four types of 
referrals: end-point identifiers (HITs), end-point locators (IP addresses) 
and middlebox locators (rendezvous).

Using HITs as referrals may not work with legacy hosts that are not HIP 
capable as the HITs are not routable. Having routable HITs requires 
additional infrastructure, such as overlays [C]. In addition, resolving 
HITs to IP addresses in HIP aware applications requires also extra 
infrastructure such as DHTs because HITs contain no hierarchical 
information, which is really required by DNS. A benefit of using HITs at 
the application layer is that they have a longer expected lifetime than IP 
addresses in mobile environments. However, there may be middleboxes, such 
as NATs between the end-points. As a HIT denotes an end-point rather than 
"middle-point", HITs might be more useful than locators with NATted 
environments, especially when end-points are mobile and when both 
communicating end-points are behind NATs.

On the other hand, the use of end-point IP addresses as referrals has the 
quite the opposite benefits and drawbacks to HITs. One benefit of using 
end-point IP addresses as referrals is that they are backwards compatible 
even with legacy hosts that are not HIP capable. In addition, they do not 
require any new infrastructure. As a drawback, the expected lifetime of IP 
addresses in mobile environments is lower than HITs. Another drawback is 
that it may be more difficult to disambiquite whether a given IP address 
belongs to the end-point host or e.g. a NAT middle-box.

Using rendezvous IP addresses as referrals does not work with legacy hosts 
that are not HIP capable. In addition, the rendezvous servers themselves 
are required as an additional infrastructure. As a benefit, the expected 
lifetime of this type of referrals is also longer than for end-point 
addresses in mobile environments. As a second benefit, this case might be 
useful for establishing opportunistic HIP connection between HIP capable 
hosts assuming that the rendezvous server has a sufficient supply of 
locators (one dedicated locator per one responder). When a single 
rendezvous address is dedicated for a single responder, using rendezvous 
addresses as referrals may be less ambigious than when using end-point 
addresses, but more ambiguous than when using HITs.

New section "3.5 Enforcing the use of HIP in legacy applications"

In general, legacy applications are expected to be HIP unaware. In 
practice, this means that the source code of the actual application 
remains unmodified. However, there might be cases when the use of HIP is 
being enforced by either very minimal changes to the application source 
code or to the underlying, dynamically loadable resolver libraries. The
motivation for doing this is to force the application to establish 
connections using HIP, or to not to establish them at all [A].

When the application source code can be modified, AI_HIP flag can set to 
getaddrinfo() resolver call. This way, the application either gets 
LSIs/HITs or nothing at all. Alternatively, the resolver library can be 
configured to force the resolver to enforce system specific behaviour when 
the source code of the application cannot be modified. In this case, the 
resolver can return either LSIs/HITs or nothing at all.

[A] Applying a cryptographic namespace to applications
http://portal.acm.org/ft_gateway.cfm?id=1080786&type=pdf&coll=portal&dl=ACM&CFID=76024067&CFTOKEN=9663775
[B] http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
[C] http://www.ambient-networks.org/docs/Host_Identity_Indirection_Infrastructure_Hi3.pdf

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

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Mon, 15 May 2006 09:45:25 +0200
Subject: [Hipsec-rg] New version of draft-irtf-hiprg-nat-02.txt
Message-ID: <[email-masked]>

Hi all,

The draft "NAT and Firewall Traversal Issues of Host Identity  
Protocol (HIP) Communication" is now available in an updated version.  
Draft -02 contains all changes that have been requested by the final  
reviewers (as indicated in the respective emails).

The draft is already available here:

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-irtf-hiprg- 
nat-02.txt

A HTML-diff to -01 is available here:

http://www.stiemerling.org/ietf/hiprg/draft-irtf-hiprg-nat-02- 
from-1.diff.html

Regards,

    Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 14:27:58 +0200
Subject: [Hipsec-rg] draft-irtf-hiprg-nat-01.txt review
In-Reply-To: <p06230907c072c836b0b4@[18.26.0.27]>
References: <p06230907c072c836b0b4@[18.26.0.27]>
Message-ID: <[email-masked]>

Hi Karen,

Many thanks for reviewing the draft! More inline.

Am 24.04.2006 um 20:43 schrieb Karen R. Sollins:

> In general I find draft-irtf-hiprg-nat-01.txt to be ready to  
> publish with a few additional and reiterated small points or nits.   
> I think it does a nice job of identifying and considering the  
> issues, and should be valuable.
>
> First, I also found that it didn't quite stand on its own because  
> it uses so many acronyms that are not even spelled out.  Perhaps at  
> the first usage of each acronym, it should be written out fully,  
> with the acronym in parentheses (to hint to the reader that  
> henceforth the acronym will be used).

I have added to all non-obvious acronyms a full text explanation.

>
> In addition to the nits reported by others, here is my further list:
>
> *  p. 4, 2nd line: "refer to" should be "reference"

Fixed.

>
> * p. 4, 4th line: "It also does not..." - eliminate "also" to read  
> "It does not".. (since this is the first negative about what the  
> doc does NOT do).

Fixed.

>
> * p. 5, first line - last word is missing.  The sentence ends it  
> "before", but doesn't tell me before what - perhaps what is meant  
> is "before transmission"?

Removed the "before", was a left over.

>
> * p. 5, Sect. 2.2, last sentence, 2nd paragraph: The sentence  
> reads, "They may be addressed in the BEHAVE working group or in  
> [RFC3489]." This suggests a future action, but one can't plan to do  
> something in the future within an already existing RFC, so the  
> sentence needs to say something slightly different about what might  
> happen and what has already happened.

By the current state in the BEHAVE working group the sentence reads:
They are addressed in the BEHAVE working group or in [RFC3489].

Because the BEHAVE working group is working on NAT implementation  
issues.

>
> * Finally, is there an issue with the fact that several of the key  
> references (2 normative and 1 informative) are currently only  
> Internet Drafts?

Yes, there is an issue which cannot be solved by now. All the  
references that are Internet drafts are really needed. However, one  
of  them is already in the RFC editor queue (draft-ietf-hip- 
arch-03.txt) and the others are expected to enter the RFC editor  
queue soon.

Thanks,

   Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 14:07:15 +0200
Subject: [Hipsec-rg] review of draft-ietf-hiprg-nat-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Mark,

Many thanks for reviewing the draft! More inline.

Am 21.04.2006 um 21:26 schrieb Mark Allman:

>
> I found this document to be pretty reasonable and have no problem with
> it being published.  I have a few nits; none of which are a big deal.
>
> allman
>
>
>
> 2.1:
>
>   + "it uses an IP payload" --> "it uses the IP payload"

Fixed.

>
> 2.1.1:
>
>   + "suggests to encapsulate" --> "suggests encapsulating"

Fixed.

>
> 3.1.2:
>
>   + "issue Section 2.1.1 applies" --> "issue applies"
>
>   + "configurations Section 3.1 that" --> "configurations that"
>
>   (Both of these look like they are trying to refer back to particular
>   previous discussions, but its a very odd construct to just plop
>   "Section X" in the middle of a sentence that then makes no sense.  I
>   suggest using a parenthetical at the end of the sentence or some  
> other
>   method.)

Fixed. Was indeed a very odd construction.

>
> 8:
>
>   + The term "pinhole" is first used here.  Maybe it should be
>     introduced earlier?  (Or, defined right here?)

Fixed. No it reads:

    Opening pinholes in firewalls (i.e., loading firewall rules allowing
    packets to traverse) and creating NAT bindings are highly security-
    [...]

>
> Meta:
>
>   + My biggest issue with the draft was with the use of undefined
>     acronyms ("HIT", "SPI", "SPINAT", "NSLP", etc.).  Some of these I
>     knew and some of them I had to go off and figure out.  I suggest
>     spelling them out and if their purpose is not clear from said
>     spelling out then please give a sentence of explanation.

Ok, I will go through the draft and fix this.

Thanks,

   Martin

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 10 May 2006 13:52:37 +0200
Subject: [Hipsec-rg] [IRSG] review of document draft-irtf-hiprg-nat-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

Many thanks to Kevin for his review. More inline.

Am 06.04.2006 um 16:18 schrieb Henderson, Thomas R:

> Below is Kevin Fall's review of draft-irtf-hiprg-nat-01.  We're
> expecting two other reviews in the coming weeks.
>
> The next steps are to assemble a RG response to these comments, and  
> then
> share that response (and proposed changes) to the IRSG.  We would like
> to get the IRSG to declare 'ready to publish' as defined by the  
> process
> in:
> http://www.ietf.org/internet-drafts/draft-irtf-rfcs-00.txt
> I'm serving the role of shepherd of this document (see the expired
> draft:
> http://psg.com/~mrw/PROTO-Team/shepherding-draft.txt).  We'll discuss
> proposed changes on the RG list.  This process is similar but not
> identical to IESG review.
>
> Tom
>
> -----Original Message-----
> From: Fall, Kevin [mailto:kevin.fall at intel.com]
> Sent: Thursday, March 30, 2006 9:50 AM
> To: Internet Research Steering Group
> Subject: [IRSG] review of document draft-irtf-hiprg-nat-01
>
>
> I read this document yesterday along with the earlier document
> draft-ietf-hip-arch-03.  At a high-level, although I have no  
> substantive
> objection to the IRTF document, I have a concern with the IETF  
> document
> and therefore the HIP effort more generally.
>
> Here's some more constructive comments for the IRTF doc:
>
> draft-irtf-hiprg-nat-01 is only about traversing firewalls and  
> NATs, yet
> its title is 'middlebox traversal'.  I believe the title should be
> narrowed to reflect its contents, or the content expanded to  
> reflect the
> title.

You are right in the sense that the document is solely handling
NAT and firewall middleboxes. Changed, unless somebody out
of the HIPRG has a major concern about it.

>
> In the abstract I'm not sure its fair to say it 'fundamentally'  
> changes
> the way in which two Internet hosts communicate.  Indeed, in the
> proposal as is, IP addresses are still being used to do the actual  
> data
> routing.  In addition, the phrase "two Internet hosts" gives me  
> concern

Right, IP addresses are still being used but both "use internally"  
the host
IDs. However, I still see the issue of this sentence being a very strong
argument, even though HIP is changing a lot. So, I have stripped out
the 'fundamentally' and it now reads:

   The Host Identity Protocol (HIP) changes the way in which two  
Internet
   hosts communicate. One key advantage over other schemes is that HIP
   does not require modifications to the traditional network-layer  
functionality
   of the Internet, i.e., its routers.

> that multicast is really completely not addressed.  This comes up  
> again
> on page 2 where it says HIP "assumes simple Internet paths, where
> routers forward globally routable IP packets..."  I might says  
> "globally
> routable unicast IP packets".  This problem isn't one directly related
> to the IRTF draft, however, and really is more a common on the IETF
> document.  I will say a little on it later.

Yes, indeed multicast is not handled, but this due to the nature of HIP.

>
> The discussion of NATP points out that the IPv4 HIP base exchange
> doesn't contain port numbers.  Is this fundamental?  Could the HIP
> exchange be carried, e.g. over UDP.  I think something to this  
> effect is
> mentioned later in section 6, but not in exactly that form.

The specification of HIP is using plain IP payload and the encapsulation
in UDP has been ruled out in the first place. However, there is now
a proposal to run the HIP base exchange over UDP, as a result of this
IRTF traversal issue draft.

>
> I am curious also about whether the TCP alternate checksum (RFC1146)
> when the TCP pseudoheader cksum computation is changed to work on  
> HITs.
> Again, this may be a comment on the IETF doc rather than this IRTF  
> doc.

This is a comment towards the IETF document rather than this IRTF  
document.

>
> Section 3 typo "This type of middlebox" -> "These types of  
> middleboxes"
> Also, "forward or discard them" -> "forward, discard, or process  
> them in
> some special way".

Fixed.

>
> Section 4 it says the section identifies possible changes to HIP that
> attempt to improve middlebox traversal, but it is only really for
> firewall and NAT traversal... see comment above.

Fixed to NAT and firewall.

>
> Paragraph #3 of section 4 starting with "When contacting peers"  
> needs to
> be re-written (overloading of pronouns).

Change to:

    HIP nodes located behind a NAT must notify their communication peers
    about the contact information.  The contact information is the NAT's
    public IP address and a specific UDP port number.  This measure
    enables the peers to send return traffic to HIP nodes behind the  
NAT.
    This would require a new HIP mechanisms.

>
> Paragraph #4 of section 4 mentions the rendezvous problem.  This is  
> not
> a HIP-only problem, which should be noted, possibly with appropriate
> refs.  I3 and Keshav's TCA (http://citeseer.ist.psu.edu/724596.html)
> come to mind, for example.

I do not know whether those references are appropriate, since the
rendezvous problem is as old as the usage of NAT. However,
they could show the relationship to other architectures. But I do not
see this draft as the place for this, since we do not go into detail
on the rendezvous point.

Thank you for the review!

   Martin for the authors

>
> Section 8 refers to "pinholes" which could use a sentence of  
> definition
> here.
>
> -- comments on the IETF document draft-ietf-hip-arch --
>
> HIP seems to be looking at an important problem area and it seems  
> to be
> viable at least for the scenarios studied (TCP and UDP transport).  In
> reading this document, I wasn't really sure it works in cases where
> these aren't the transports.  I think about ICMP, for example, as well
> as multicast.  Perhaps its not in HIP's scope to look at these things,
> but if that's the case then does it really make sense to re-tool  
> the end
> host implementations for just these protocols?  Maybe it does, but  
> this
> issue doesn't seem to be discussed in the architecture document.
>
> - Kevin
>