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

From: [email-masked]
Date: Thu, 23 Jun 2016 07:12:32 -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-12.txt
	Pages           : 44
	Date            : 2016-06-23

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12

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

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: Thu, 23 Jun 2016 17:29:58 +0300

Hi,

high-level changes are as follows:

   * The new draft version follows the ice-bis version, so I removed 
aggressive nomination
   * Clarifications in the subsections in section 4.12. Relaying 
Considerations
   * Fixed some nits

Open questions:

   * What should do with compatibility with RFC 6078 (HICCUPS)
   * Connectivity tests should be skipped unless ESP_TRANSFORM is 
negotiated?
   * Steps 5-6 could be skipped in the handoff sequence? See fig. 6.
   * 4.12.3.  Handling Conflicting SPI Values
     * Should the Responder send a notify on SPI collision?
     * Removed text about registering with multiple addresses because I 
think this does not work with HIP (or at least, requires multihoming)
   * Lower the connectivity test pacing value from 20 ms to 2 ms (as in 
the ice-bis specs) in section 4.4?

On 06/23/2016 05:12 PM, [email-masked] wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Jeff Ahrenholz <[email-masked]>
Date: Thu, 23 Jun 2016 21:49:01 +0000

Hi Miika,
I was reviewing this section...

>think this does not work with HIP (or at least, requires multihoming)

When there is a SPI collision, it does seem that we would want a new type of NOTIFY to be sent.

Otherwise it seems the Initiator will be stuck in the state I2-SENT, retransmitting the I2 until going back to the failure state, when it can retry the BEX from the beginning again.

Maybe it needs to be an ICMP message (and not NOTIFY) since there is not yet an association between the two peers (RFC 7401 section 4.3).

-Jeff

---

From: Jeff Ahrenholz <[email-masked]>
Date: Fri, 24 Jun 2016 15:23:06 +0000

Hi Miika,
First of all, nice work with all of your changes! 
This is a big draft but seems much clearer without the RFC 5770 delta.

Here’s some further comments on your questions...

>   * What should do with compatibility with RFC 6078 (HICCUPS)

I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wait until if/when 6078 is updated for HIPv2.)

>    * Connectivity tests should be skipped unless ESP_TRANSFORM is

Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way comms between peers.
For example, when performing a registration procedure with a relay server.

>   * Steps 5-6 could be skipped in the handoff sequence? See fig. 6.

If steps 5-6 are skipped, then we would have no SEQ in step 3?
And the subsequent connectivity checks would suffice for these steps?

Below are a few editorial nits...

-Jeff

page 2
s/checks keepalives, and data relaying./check keepalives and data relaying./g

page 7
s/IPsec [RFC3948] Finally/IPsec [RFC3948]. Finally/

page 15
s/NATs drop messages messages/NATs drop messages/

page 18
s/the the recipient/the recipient/

page 22
s/interact handover/interact with handover/

page 27
s/MUST not/MUST NOT/

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jun 2016 11:12:50 +0300

Hi Jeff,

> Maybe it needs to be an ICMP message (and not NOTIFY) since there is not yet an association between the two peers (RFC 7401 section 4.3).

good catch, no host association -> ICMP should be used.

The SPI collision issue seems to be a bit more generic, possibly 
influencing also RFC7402. Or is it actually a real issue? From the nat 
draft:

"In first case, the SPI collision problem occurs when two Initiators
run a base exchange to the same Responder (i.e. registered host), and
both the Initiators claim the same inbound SPI."

Is it actually a problem for the Responder that two different Initiators 
happen to claim different SPIs? The Initiators have different IP 
addresses (or at least UDP ports if they are behind the same NAT).

It is a problem for the data relay, so the text says:

"Upon receiving an I2 with a colliding SPI, the Responder MUST not 
include the relayed address in the R2 message because the data relay 
would not be able demultiplex the related ESP packet to the correct 
Initiator."

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jun 2016 19:06:57 +0300

Hi Jeff,

> I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wait until if/when 6078 is updated for HIPv2.)

ok.

> For example, when performing a registration procedure with a relay server.

The direct path could be, of course, used for exchange HIP messages 
directly (including hiccups v2). Does this make sense?

If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP are 
both negotiated? Or should we just be proactive and state that upon 
receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not 
going to employ any ESP_TRANSFORM.

> If steps 5-6 are skipped, then we would have no SEQ in step 3?

Yes.

> And the subsequent connectivity checks would suffice for these steps?

Connectivity tests implement the return routability checks. Currently, 
the NAT mobility triggering mechanism mimics the tree-way procedure in here:

https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12#section-3.2.1

I thought that would nice for implementers but strictly speaking steps 
5-6 could skipped since the connectivity checks actually implement the 
return routability checks.

I can change this if you agree?

> s/interact handover/interact with handover/

Thanks, I have fixed the nits and they will be included in the next version.

---

From: Jeff Ahrenholz <[email-masked]>
Date: Thu, 30 Jun 2016 16:08:11 +0000

Miika,

> On 6/30/16, 1:12 AM, "Miika Komu" <[email-masked]> wrote:
>

You’re right, it seems like it is not a problem for the Responder since there are different IP/ports.

> would not be able demultiplex the related ESP packet to the correct 

Does this mean the Responder should not even send the R2 message upon collision?

The draft also says this:

 “The described
   collision scenario can be avoided if the Responder delivers a new
   relayed address candidate upon SPI collisions.  Each relayed address
   has a separate UDP port reserved to it, so the relay can demultiplex
   properly conflicting SPIs of the Initiators based on the SPI and port
   number towards the correct Responder.”

What if the Responder sends the R2 message (established state)  and then immediately follows with an UPDATE packet to initiate a rekey?
The rekey would cause both sides to select new SPI values.

Not sure what happens if you send the R2 without the relayed address -- proper state not created on the Initiator?

-Jeff

---

From: Jeff Ahrenholz <[email-masked]>
Date: Thu, 30 Jun 2016 16:33:22 +0000

> directly (including hiccups v2). Does this make sense?

yes, makes sense

> going to employ any ESP_TRANSFORM.

This proposed sentence seems like a good revision.

> I can change this if you agree?

Yes, I agree they can be skipped. 
The connectivity checks are more UPDATE packets, and fewer update round-trips seems like faster mobility handover.

-Jeff