Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt

From: [email-masked]
Date: Tue, 25 Apr 2017 04:05:33 -0700

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

        Title           : Native NAT Traversal Mode for the Host Identity Protocol
        Authors         : Ari Keranen
                          Jan Melén
                          Miika Komu
	Filename        : draft-ietf-hip-native-nat-traversal-20.txt
	Pages           : 56
	Date            : 2017-04-25

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2017 14:47:25 +0300

Hi,

this version addresses Christer's earliers comments and fixes some other 
issues I discovered while reviewing the draft. I'll send a summary of 
the comments a bit later.

On 04/25/2017 02:05 PM, [email-masked] wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2017 22:44:51 +0300

Hi,

so in addition to Christer's comments...

https://mailarchive.ietf.org/arch/msg/hipsec/iPSdqgR6e2lK7LZqUfCBnkLxZn8
https://mailarchive.ietf.org/arch/msg/hipsec/LLsY1BqJdmc5foSk9QhYzUWRDvE

...I took the liberty of improving the draft editorially while reviewing 
it (+ one paragraph was removed):

1. Introduction
* Added a note that legacy ICE-HIP refers to HIPv1 and this is one 
refers HIPv2 explicitly

2. Terminology:
* HIP connectivity checks, Controlling host, Controlled host (minor 
editorial improvements)

3. Overview:
* Data Relay Server is not mandatory
* What the Data Relay Server actually does (translates source address)
* Strictly speaking only Responder requires the Data Relay Server

4.2. Transport Address Candidate Gathering at the Relay Client

* CANDIDATE_DISCOVERY parameter requires multihoming capabilities which 
is out of scope, so I removed it

4.5.  Base Exchange via Control Relay Server
* "It is RECOMMENDED to use the same Control Relay Server throughout the 
lifetime of the host association that was used for forwarding the base 
exchange if the	Responder includes it in the locator parameter of the R2 
message."

4.6.1.  Connectivity Check Procedure

* Added this section: "It should be noted that in the case both 
Initiator and Responder both advertising their own relayed address 
candidates [..]" to clarify what happens in this case of both ends 
advertise their own TURN servers and that asymmetric paths are possible

4.12.3.  Handling Conflicting SPI Values

* Editorial fixes to make the two cases more understandable

If you want to see the diff in detail, please check from here: