Subject: [Hipsec] hip-nat-traversal-02-pre5

From: Miika Komu <[email-masked]>
Date: Tue, 29 May 2007 12:49:42 +0300 (EEST)

Hi folks,

here is a preversion of ICE-based NAT traversal draft:

http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre5.txt

I rewrote it practically from scratch, so the text is not very well 
polished yet (work in progress). Please send early comments already now 
to the mailing list.

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

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 May 2007 12:09:39 -0700

Thanks for the opportunity to review this document before publication.

Comments:

1. section 3:

   This section describes NAT traversal between two HIP end-hosts.  A
   successful NAT traversal requires at least the Responder to register
   to a relay server.  The base exchange is relayed through the relay
   server. 

In the introduction you described three cases -- where the initiator is
behind a NAT, where the terminator is behind a NAT, and where both are
behind (different) NATs.  In the second case, where the terminator
(HIP Responder, I presume?) is not behind a NAT but is on a public
network, is it true that it still needs to register to a relay server?

2. section 3:

   The end-hosts need a fixed transport layer port number to be able to
   communicate with each other.  The end-hosts MUST accept incoming HIP
   and ESP traffic arriving at UDP port 50500 (future extensions may use
   the same port number for TCP).  It is RECOMMENDED that an Initiator
   selects a random port number between 49152-65535 for initiating a
   base exchange even for registration.  However, the allocated port
   MUST be maintained until all of the corresponding Host Associations
   are closed.  Alternatively, a host MAY also use source port 50500 for
   initiating a base exchange.  The RECOMMENDED transport layer protocol
   is UDP.

>From this requirement, I can only assume that HIP doesn't communicate the
port number across th HIP rendezvous server.  Is my assumption corrrect?

3. section 3.1:

   When the ESP relay registration was successful, the relay server uses
   the source IP address and port (typically 50500) of the R2 to relay
   ESP traffic with the client.  This address-port pair of the relay is
   referred as "leased transport locator" in this document.

Please delete "(typically 50500)", because earlier text allows using 50500
as the source address or using the 49152-65535 range as the source address.

But more importantly, a NAT may be unable to retain whatever UDP port the 
host chose because another host is already using that same UDP port, or 
because the NAT doesn't like to retain source UDP ports.  So -- what is
the significance of this choice of ephemeral port?

4. Section 3.2:

   The relay MUST change the transport
   source and destination of the message to match the one the Responder
   used when registrating to the relay.

Does this mean the relay spoofs the IP address?  That is how I read it...
If you're referring to transport source and destination addresses inside of
HIP itself, the text needs to be clarified.  If you really do want the relay
to spoof IP addresses, I think the design is flawed.

5. Section 3.2:

   The base
   exchange was concluded by I2 and R2 messages over transport layer
   that contained RELAY_TO parameters. 

   After this, the state of the HIP
   associations is ESTABLISHED, but the hosts MUST NOT allow any ESP
   traffic until the connectivity tests described in the next section
   are performed successfully.

But the next section (3.3) describes cases where there aren't connectivity
tests, even if there was a RELAY_TO.  This needs to be cleaned up.  I
suggest moving the last two paragraphs of 3.2 into 3.3, and not described
ESTABLISHED as some-state-that-isn't-quite-like-ESTABLISHED.  I think you
need to transition to a different state (such as perhaps UNVERIFIED?), and
describe the rules for when you enter that state and when you can skip that
state and go directly to ESTABLISHED.

6.  Section 3.2:

I don't think the FROM_PEER is sufficient to identify peers.  Consider, for
example, that almost every consumer-grade NAT in the world uses 192.168.1.0
as its private (internal) network, and the first host is typically assigned
192.168.1.1, the second host .2, and so forth.  Two HIP hosts behind their
own NATs could easily have the same private IP address, and could be trying
to establish communication with each other.  In this case, FROM_PEER isn't
useful to distinguish connectivity checks from yourself versus from your
peer.  Rather than using IP address, ICE uses a USERNAME, half of which is
chosen by each peer, to provide this distinguisher.  I suggest using a
peer-selected value to identify each peer is superior to IP address as a
peer identifier.

7.  Section 3.3:

   If the FROM_PEER and TO_PEER do not
   match, the Responder is behind a "p2p-unfriendly" NAT
   [I-D.ietf-behave-p2p-state]. 

I believe there are two cases where you'll still encounter that situation,
even if you are behind 100% p2p-friendly NATs.

Case 1:  you're behind two p2p-friendly NATs ("nested NATs").

Case 2:  if you have a network topology like this, with 100% p2p-friendly
NATs, I believe they'll also not match:

         Rendezvous Server
       /                   \
      /                     \
     /                       \
  Intiator------------NAT----Router
                              |
                          Responder

That is, where a NAT is only on-path between the Initator and Responder, but
isn't on-path between Responder and its Rendezvous Server.  There could be a
different NAT that is on-path between the Responder and its Rendezvous
Server.  Such a situation can occur (and does occur) with NATs inside
enterprises.  This situation is why ICE has 'triggered checks':  for
situations where the ICE endpoint doesn't know its traffic will traverse a
NAT because the NAT isn't on-path with the ICE endpoint's STUN server.

I encourage you to not use IP addresses as identifiers, especially for NAT
traversal.

8.  The first paragraph of section 3.3 burdens public hosts with NAT
keepalives:

   They MUST NOT
   follow the extensions of this draft, except for the NAT keepalives
   described in a later section.

You don't need to create that burden:  only the hosts behind NATs need to be
burdened with keeping their NAT pinholes alive.

9.  The NAT keepalive section (section 3.6) needs to describe how often the
keepalives need to be sent.  As I mentioned above, you don't need to burden
everyone with NAT keepalives -- just the hosts that are behind NATs.

10.     Section 5, firewall traversal:

There is an odd statement about NAT traversal that is included in the
firewall traversal section:

   The NAT traversal mechanisms described in Section 3 require that the
   firewall - stateful or not - allow inbound UDP traffic to port 50500
   and allow outbound UDP traffic to arbitrary UDP ports.  If necessary
   for firewall traversal, ports reserved for IKE MAY be used for
   initiating new connections, but the implementation MUST be able to
   listen for UDP packets from port 50500.

This needs to be made clearer.  Here is an example of a topology that
wouldn't work if all the firewall did was the above paragraph:

         Rendezvous Server
                          \
                           \
                           Firewall
                              |
                             NAT
                              |
                          Responder

The Rendezvous server would listen for traffic on UDP/50500.  

---

Nits:

Nit 1:  Introduction:

  This document
   specifies how HIP can traverse through such NAT middleboxes which are
   neither HIP-aware or ESP-aware without manual configuration of the
   NAT devices.

You're using the term "NAT middlebox" and "NAT devices" in the same
sentence.   You should use one.  I also found the "without manual
configuration" awkward to read; inserting a comma might help separate
out the two awareness clauses.  Like this:

  ... neither HIP-aware or ESP aware, without manual ...
                                    ^

Nit 2:  The paragraph starting with:

  "The new namespace of HIP has some additional benefits."

seems to need a transitional phrase or something; it sort of sticks out
there by itself.  I think before that paragraph you need an introductory
paragraph describing the "HIP namespace".

Nit 3:

OLD:
The protocol extensions in this document make
NEW:
The HIP extensions in this document make
    ^^^

Nit 4:

OLD:
the behavior of the NAT devices to make NAT traversal to work even
NEW:
the behavior of the NAT devices so that NAT traversal will work even
                                ^^^^^^^               ^^^^

Nit 5:
Instead of repeating the procedure to choose the source port (50500 or in
that port range), how about describing it once in a tiny section and then
referring to that section everywhere in the document.  

It would be useful if the suggestion for 49152-65535 was clarified:  does
something break if I were to use 49151, for example?

(I found a discussion in section 5, "firewall traversal", which seemed to
describe why the selection of source port was useful.  This should be
consolidated into one place.)

Nit 6: Section 3.2:

   The source port is chosen randomly between the range
   49152-65535 and destination port is 50500.  The destination address
   is the relay address.  The source address is one of the addresses of
   the link, which are also referenced to as "unreflexive locators" in
   ^^^^^^^^
   this document.

"Links" don't have addresses; I think this should be 'one of the routable
addresses for the host' or something like that??  (I'm not sure)

Nit 7:  Section 3.3:

   In the case of direct path, the hosts
   prefer a path without transport layer encapsulation which means that
   the hosts have no legacy NAT between them.

This encapsulation has not previously been described in the document.  

Question:  is legacy NAT the only reason for UDP encapsulation?  I would
think a firewall that doesn't like the HIP protocol number might also be
another reason.  And perhaps also another case is an operating system that
doesn't understand HIP, where HIP is done entirely by the application?  I do
not know HIP well enough to answer these two questions.

Nit 8: Section 3.3:

   The
   Initiator MUST pace the NOTIFY messages sequentially 20 ms apart (as
   explained in [I-D.ietf-mmusic-ice]).  

FYI, this ICE pacing algorithm is going to be changed.  See Sally Floyd's 
response to my email about those upcoming changes at:
  http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00085.html

Nit 9: section 8:

   Thanks for Jonathan
   Rosenberg and the rest of the ICE WG folks for the excellent work on
                                 ^^^^^^
   ICE.

ICE is a product of the MMUSIC working group.

-d

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, May 29, 2007 2:50 AM
> To: [email-masked]
> Subject: [Hipsec] hip-nat-traversal-02-pre5
> 
> Hi folks,
>