Subject: [Hipsec] Comments on draft-ietf-hip-nat-traversal-01.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 29 Mar 2007 15:38:08 +0300

Hi,

a few comments on the NAT Traversal draft.

The draft talks about detecting the presence of NATs and their type 
using STUN. There has been a lot of work on this area (see the ICE 
specification developed in the MMUSIC WG) and detecting NAT types does 
not seem very useful. It is typically better to just obtain a set of 
addresses where the endpoint may potentially be reached and send it 
(somehow) to the remote endpoint. The remote point does the same and, 
then, both endpoints probe addresses in pairs to see which one is best.

The idea is that the endpoints will use the address pair that works 
best, as opposed to using the address pair that looks better from the 
possibly mistaken information the endpoints can gather about the NAT 
topology between them.

One design decision we have to make is whether to use STUN to discover 
reflexive addresses and to perform connectivity checks or to define new 
HIP mechanisms. The advantage of using STUN would be that HIP endpoints 
would be able to use all the already deployed STUN servers. Of course, 
nothing prevents implementers from adding STUN support to their HIP RVSs.

Using STUN for that purpose would also make it easier to introduce 
traffic relays to cover cases where both endpoints are behind symmetric 
NATs. Note that TURN is now specified as a STUN usage (i.e., the STUN 
Relay Usage).

Some nits:

HIP should be expanded in the title of the draft.

The Introduction section should not have normative statements.

The last paragraph of the Introduction should be a section on its own 
called Terminology.

Cheers,

Gonzalo

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

---

From: Miika Komu <[email-masked]>
Date: Thu, 29 Mar 2007 23:59:14 +0300 (EEST)

On Thu, 29 Mar 2007, Gonzalo Camarillo wrote:

Hi,

thanks Gonzalo for your comments. We are definitely going to have a look 
at the ICE design for the next draft version. In fact, we already had some 
preliminary discussions with Philip in the IETF on integrating ICE with 
HIP. It also believe that something similar to ICE is better for 
multihomed/addressed hosts and integration with TURN-like traffic relays 
would be more seamless.

> The draft talks about detecting the presence of NATs and their type using 
> STUN. There has been a lot of work on this area (see the ICE specification 
> developed in the MMUSIC WG) and detecting NAT types does not seem very 
> useful. It is typically better to just obtain a set of addresses where the 
> endpoint may potentially be reached and send it (somehow) to the remote 
> endpoint. The remote point does the same and, then, both endpoints probe 
> addresses in pairs to see which one is best.
>
> The idea is that the endpoints will use the address pair that works best, as 
> opposed to using the address pair that looks better from the possibly 
> mistaken information the endpoints can gather about the NAT topology between 
> them.
>
> reflexive addresses and to perform connectivity checks or to define new HIP 
> mechanisms. The advantage of using STUN would be that HIP endpoints would be 
> able to use all the already deployed STUN servers. Of course, nothing 
> prevents implementers from adding STUN support to their HIP RVSs.
>
> Using STUN for that purpose would also make it easier to introduce traffic 
> relays to cover cases where both endpoints are behind symmetric NATs. Note 
> that TURN is now specified as a STUN usage (i.e., the STUN Relay Usage).
>
> Some nits:
>
> The last paragraph of the Introduction should be a section on its own called 
> Terminology.
>
>
> Cheers,
>
> Gonzalo
>

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

---

From: Miika Komu <[email-masked]>
Date: Fri, 30 Mar 2007 19:22:27 +0300 (EEST)

Hi all,

I have been having some discussions with Philip, Joakim, Jani and 
others on HIP NAT traversal. It is becoming difficult to track the people 
so I am opening the discussion here for further comments. For the cc:d 
people, I recommend subscribing to the list if you haven't already:

Thanks for Joakim for converting protocol mechanism and notes to 
electronic format, and especially for further improvement ideas and 
questions. Joakim's notes below:

HIP nat traversal thoughts

According to the current NAT traversal proposial, when both the
responder and initiator is behind NATs, a RVS is used for relaying
the I1 packet to the responder. The responder will then try to reply
with the R1 directly according to the following figure (taken from the
draft):

     +---+        +----+         +-------+            +----+        +---+
     |   +--(1)-->|    +---(2)-->+       |            |    |        |   |
     |   |        |    |         | RVS-R |            |    |        |   |
     |   |        |    |<--(3a)--+       +---(3b)---->|    |        |   |
     |   |        |    |         +-------+            |    |        |   |
     |   |<-(4a)--+ N  |                              | N  +--(4b)->|   |
     |   |        | A  |                              | A  |        |   |
     | I +--(5a)->| T  |                              | T  |<-(5b)--+ R |
     |   |        | -  |<-(6b)------------------(6a)->| -  |        |   |
     |   |<-(7b)--+ I  |                              | R  +--(7a)->|   |
     |   |        |    |                              |    |        |   |
     |   +--(8)-->|    +--------------(9)------------>|    +--(10)->|   |
     |   |        |    |                              |    |        |   |
     |   |<-(13)--+    |<-------------(12)------------+    |<-(11)--+   |
     +---+        +----+                              +----+        +---+

The problem with this design is that there is no guarantee that the R1
packet (or any subsequent, including the ESP data packets) will pass
through the two NATs.

As the base exchange is not that bandwidth-heavy, one solution would
be to adopt a SIP-like design where it is done completely through the
RVS.  During the base exchange, parameters would be negotiated
(exchanged) in an ICE-like manner to try to setup a direct connection
for the data traffic, if possible.  To ensure that a data connection
will be established, both I and R MAY configure a suitable proxy (TURN
or similar) for relaying the actual data traffic.

The base exchange would look something like this:

        50500         11111    50500   50500       44444          50500
     +---+        +----+         +-------+            +----+        +---+
     |   +--(1)-->|    +---(2)-->+ RVS-R |            |    |        |   |
     |   |        |    |         |       |            |    |        |   |
     |   |        |    |<--(3a)--+ [*E1] +---(3b)---->|    |        |   |
     |   |        |    |         |       |            |    |        |   |
     |   |<-(4a)--+ N  |         |       |            | N  +--(4b)->|   |
     |   |        | A  |         |       |            | A  |        |   |
     | I |<-(8)---+ T  |<--(7)---+       |<--(6)------| T  |<-(5)---+ R |
[*E2]   |        | -  |         |       |            | -  |        |   |
     |   +--(9)-->| I  +---(10)->|       |            | R  |        |   |
     |   |        |    |         |       |            |    |        |   |
     |   |        |    |         |       +---(11)---->|    +--(12)->|   |
     |   |        |    |         |       |            |    |        |   [*E3]
     |   |        |    |         |       |<--(14)-----+    |<-(13)--+   |
     |   |        |    |         |       |            |    |        |   |
     |   |<-(16)--+    |<--(15)--+       |            |    |        |   |
     |   |        |    |         +-------+            |    |        |   |
     |   |        |    |                              |    |        |   |
     +---+        +----+                              +----+        +---+

     1.   IP(IP-I, IP-RVS)       UDP(50500, 50500)  I1(HIT-I, HIT-R)
     2.   IP(IP-NAT-I, IP-RVS)   UDP(11111, 50500)  I1(HIT-I, HIT-R)

     3a.  IP(IP-RVS, IP-NAT-I)   UDP(50500, 11111)
             NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
     3b.  IP(IP-RVS, IP-NAT-R)   UDP(50500, 44444)
             I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC)

[*E1] The RVS might need to create a state for the I-R exchange to be
       able to forward subsequent packages (R1, I2 & R2). (what say
       you?)

     4a.  IP(IP-RVS-R, IP-I)     UDP(50500, 50500)
             NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
     4b.  IP(IP-RVS, IP-R)       UDP(50500, 50500)
             I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC)

     5.  IP(R, RVS-R) UDP(50500, 50500)
             R1(HIT-R, HIT-I)
     6.  IP(IP-NAT-R, RVS-R) UDP(44444, 50500)
             R1(HIT-R, HIT-I)
     7.  IP(RVS-R, IP-NAT-I) UDP(50500, 11111)
             R1(HIT-R, HIT-I)
     8.  IP(IP-NAT-I, I) UDP(11111, 50500)
             R1(HIT-R, HIT-I)

[*E2] I MAY configure an external TURN server to relay the data
       traffic between I and R. If so, it is done here.  The
       I-configured TURN server is further referenced to as IP-TURN-I,
       22222

     9.  IP(I, RVS-R) UDP(50500, 50500)
             I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222))
     10. IP(IP-NAT-I, RVS-R) UDP(11111, 50500)
             I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222))

     11. IP(RVS-R, IP-NAT-R) UDP(50500, 44444)
             I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222))
     12. IP(IP-NAT-R, R) UDP(44444, 50500)
             I2(HIT-I, HIT-R, VIA_RVS_NAT(IP-I, 50500), VIA_RVS_NAT(IP-TURN-I, 22222))

[*E3] R MAY configure an external TURN server to relay the data
       traffic between I and R. If so, it is done here.  The
       R-configured TURN server is further referenced to as IP-TURN-R,
       88888

     13. IP(R, RVS-R) UDP(50500, 50500)
             R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888))
     14. IP(IP-NAT-R, RVS-R) UDP(44444, 50500)
             R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888))

     15. IP(RVS-R, IP-NAT-I) UDP(50500, 11111)
             R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888))
     16. IP(IP-NAT-I, I) UDP(11111, 50500)
             R2(HIT-R, HIT-I, VIA_RVS_NAT(IP-R, 50500), VIA_RVS_NAT(IP-TURN-R, 88888))

After the base exchange, I and R will know each other's real IP, the
IP of the publicly accessible NAT they are behind and possiby a TURN
server configured to relay the data traffic.  No connection for the
traffic has however yet been established.

Both I and R will now perform an ICE-like ranking of the different
address pairs, and try each combination in hope of establishing a
connection.  This probing is done using HIP UPDATE packets.

E.g. from I's point of view, when both between separate symmetrical
NATs, forced to used TURN-I:

Ranking (dont know if this would actually be the ranking, but serves as example):
1  (IP-I, IP-R)
2  (IP-I, IP-NAT-R)
3  (IP-NAT-I, IP-R)
4  (IP-NAT-I, IP-NAT-R)
5  (IP-I, IP-TURN-I)
    (IP-I, IP-TURN-R)

        50500      11111  22221  22222 88888  88889  44444     50500
     +---+      +---+       +-----+       +-----+      +---+     +---+
     |   |      |   |       |TURN-|       |TURN-|      |   |     |   |
     | I |      | N |       |  I  |       |  R  |      | N |     | R |
     |   +-(1)->| A +---------------(1b)------------------------>|   |
     |   |      | T |       |     |       |     |      | T |     |   |
     |   +-(2)->| - |---------------(2b)-------------->| - |     |   |
     |   |      | I |       |     |       |     |      | R |     |   |
     |   +-(3)->|   +---------------(3b)------------------------>|   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   +-(4)->|   |---------------(4b)-------------->|   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   +-(5)->|   |-(5b)->|     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |<-(7)-+   |<-(6)--+     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   +-(8)->|   +-(8b)->|     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |<------(9)------->|     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |

     1.  IP(IP-I, IP-R) UDP(50500, 50500)
             UPDATE(ESP_INFO, LOCATOR(IP-I, 50500))
     1b. IP(IP-NAT-I, IP-R) UDP(11111, 50500)
             UPDATE(ESP_INFO, LOCATOR(IP-I, 50500))

     2.  IP(IP-I, IP-NAT-R) UDP(50500, 44444)
             UPDATE(ESP_INFO, LOCATOR(IP-I, 50500))
     2b. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444)
             UPDATE(ESP_INFO, LOCATOR(IP-I, 50500))

     3.  IP(IP-I, IP-R) UDP(50500, 50500)
             UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111))
     3b. IP(IP-NAT-I, IP-R) UDP(11111, 50500)
             UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111))

     4.  IP(IP-I, IP-NAT-R) UDP(50500, 44444)
             UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111))
     4b. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444)
             UPDATE(ESP_INFO, LOCATOR(IP-NAT-I, 11111))

     5.  IP(IP-I, IP-TURN-I) UDP(50500, 22221)
             UPDATE(ESP_INFO, LOCATOR(IP-TURN-I, 22222))
     5b. IP(IP-NAT-I, IP-TURN-I) UDP(11111, 22221)
             UPDATE(ESP_INFO, LOCATOR(IP-TURN-I, 22222))

     6. UPDATE(ESP_INFO, ACK, ECHO_REQUEST)
     8. UPDATE(ACK, ECHO_RESPONSE)

     9. ESP data

Open issues:

  - In what order are the addresses tried?

    Perhaps reverse compared to ICE - from the least-optimal (last) to
    most-optimal (first).  In practice this would mean the TURN-server
    based (if such exist) first, which would establish *some* sort of
    connection quickly.  After that, the NAT-based would be tried,
    following by the real IPs (in case I & R are in the same subnet.

  - What is the suitable parameter for providing the TURN servers' info
    (where VIA_RVS_NAT was used in the example)?

  - Is there any race-condition problems when both are trying the
    alternatives.  Maybe the initiator should only try to establish the
    connections or something similar?  ICE might provide something for
    this.

  - Can all be tried at once to try to speed up the process. The first
    that gets through would be used until another one is responded to
    which is ranked better than the one currently used.

  - Should the RVS-R be automatically used as the first proxy used for
    starting the data traffic?  As Miika noted, this could be
    controlled using HIT acl's at the RVS combined with some policies.

  - Can the RVS-R automatically / transparently add a proxy server
    (TURN or similar) to the *2- packets of the base exchange?

--
ascii template for further drawings:

        50500      11111  22221  22222 88888  88889  44444     50500
     +---+      +---+       +-----+       +-----+      +---+     +---+
     |   |      |   |       |TURN-|       |TURN-|      |   |     |   |
     | I |      | N |       |  I  |       |  R  |      | N |     | R |
     |   |      | A |       |     |       |     |      | A |     |   |
     |   |      | T |       |     |       |     |      | T |     |   |
     |   |      | - |       |     |       |     |      | - |     |   |
     |   |      | I |       |     |       |     |      | R |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |
     |   |      |   |       |     |       |     |      |   |     |   |

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 30 Mar 2007 22:13:44 +0300

Hi,

> I have been having some discussions with Philip, Joakim, Jani and others 
> on HIP NAT traversal. It is becoming difficult to track the people so I 
> am opening the discussion here for further comments. For the cc:d 

as you know, messages sent to ietf lists that have too many people in 
their To or CC fields are manually moderated. Therefore, I would 
strongly recommend to keep those fields short. If folks want to follow 
HIP-related discussions, they should subscribe to the list, as Miika 
suggests above.

Cheers,

Gonzalo