Subject: [Hipsec] I-D ACTION:draft-ietf-hip-nat-traversal-01.txt

From: [email-masked]
Date: Thu, 08 Mar 2007 15:50:03 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Host Identity Protocol Working Group of the IETF.

	Title		: HIP Extensions for the Traversal of Network Address Translators
	Author(s)	: V. Schmitt, et al.
	Filename	: draft-ietf-hip-nat-traversal-01.txt
	Pages		: 35
	Date		: 2007-3-8
	
This document specifies extensions to Host Identity Protocol (HIP) to
   support traversal of Network Address Translator (NAT) middleboxes.
   The traversal mechanism tunnels HIP control and data traffic over UDP
   and enables HIP initiators which MAY be behind NATs to contact HIP
   responders which MAY be behind another NAT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-hip-nat-traversal-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-hip-nat-traversal-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Tue, 13 Mar 2007 17:36:26 +0200 (EET)

On Thu, 8 Mar 2007, [email-masked] wrote:

Hi all,

> http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-01.txt

The authors have reviewed the draft by themselves and done some editorial 
corrections here and there. We have also a new fresh pair of eyeballs 
authoring the draft: on the courtesy of Vivien Schmitt, Simon Schuetz is 
continuing Vivien's work at NEC.

The new version of the draft has been thoroughly reviewed by Lauri 
Silvennoinen and Tobias Heer. They suggested several editorial 
improvements and also some other clarifications (first three are 
from Tobias and the remaining four from Lauri):

   * NAT keepalives were replaced with NOTIFY messages because no HMACs and
     signatures were used
   * The use of HMACs and signatures in the context of locator exclusion
     is now clarified. When a host is operating behind NAT, locators are
     excluded from messages BEFORE applying HMACs and signatures.
   * HIP checksum is excluded for two reasons when using UDP encapsulation.
     First, the HIP checksum cannot be applied as defined in the base
     draft as it includes also the outer IP addresses which will  be
     changed by the NAT. Since we are dealing with legacy  (HIP-unaware
     NATs), the NAT boxes won't change the HIP checksum and the HMACs and
     signatures would make it impossible anyway. Second, the HIP checksum
     would be redundant with the UDP checksum.
   * Some errors fixed in the details of some figures.
   * There were some errors in the discussion of hairpin translation and
     endpoint filtering but this is now corrected.
   * Clarifications to the use of VIA_RVS_NAT parameter.
   * Lauri validated the NAT traversal extensions for the base exchange
     (all four cases) by developing them to the HIPL implementation.

Pekka Nikander also pointed out that the current draft was implicitly 
assuming lowered privacy for the responder. Namely, the RVS reveals the 
address and port of the NAT of responder when the initiator is behind a 
NAT. As such, it may be more easier to DoS a responder. To avoid this, we 
could have relayed the whole base exchange through the RVS but we did not 
prefer it because it can be done more efficiently through other 
mechanisms, such as Hi3. Anyway, the privacy statement is now explicit in 
the draft.

Another issue has been the case where both hosts are behind NATs. The 
problem in this case is the UDP hole punching because it works only with 
NAT boxes that support endpoint independent mappings. If NATs do not 
support this, a TURN-like relay is needed for HIP control and data packet 
traversal. However, we did not define the TURN-like behaviour in this 
draft for the following reasons:

   1. A relay would have been less efficient in terms of slower connection
      initialization and data transfer (triangular routing). In addition,
      the base exchange could have been more prone to NAT timeout issues
      at the initiator side.
   2. A relay would have inflated the draft with full-relay RVS-NAT
      registration and relaying extensions (relaying the compelete base
      exchange and also ESP traffic). The current design follows more
      the existing RVS design which only relays I1 packets.
   3. It appears that 70 percent of the deployed NATs support endpoint
      independent mappings according to a recent study [GUHA]. A limiting
      factor is also that endpoint independent mappings are required only
      in the case where both the initiator and responder are behind NATs.
      In addition, we assume that NAT vendors start to follow the recently
      published RFC4787 which requires NATs to support endpoint independent
      mappings to avoid the inefficient full relays.

Even though the draft does not define the full relay mechanism, it 
suggests the initiator to switch to some external relay mechanism in the 
both-hosts-behind-nat scenario when the initiator does not get an R1 
during a time period. We preferred timeouts over switching to the full 
relay immediately in the both-hosts-behind-nat scenario for the reasons 
(1,2,3) mentioned above. In addition, I should mention that there does not 
seem to be a reliable way for the initiator to detect that also the 
responder is behind a NAT device supporting endpoint independent mapping.

We did also a small change in the design of the both-hosts-behind-nat 
scenario. When the initiator receives a FROM_NAT from a RVS, it sends now 
a NOTIFY to punch a hole into the NAT instead of an I1. The I1 will be 
delivered reliably through the RVS anyway, so there is not reason to do 
the hole punching with an I1.

The current multihoming text is quite short. We have been discussing with 
Marcelo Bagnulo to complete this work in a different document.

On the behalf of the NAT draft authors, I'd like to thank the reviewers. 
All further comments are welcome!

[GUHA] Guha et al, Characterization and measurement of tcp traversal
        through nats and firewalls, 2005

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