[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-behave-p2p-state

Internet Draft                                              P. Srisuresh
Expires: March 27, 2007                                       Consultant
                                                                 B. Ford
                                                                  M.I.T.
                                                                D. Kegel
                                                               kegel.com
                                                      September 27, 2006


                State of Peer-to-Peer(P2P) Communication
                Across Network Address Translators(NATs)
                <draft-srisuresh-behave-p2p-state-04.txt>


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   This memo documents the various methods known to be in use by
   peer-to-peer (P2P) applications for communication in the presence
   of Network Address Translators (NATs) at the current time. This
   memo covers NAT traversal approaches used by both TCP and UDP
   based applications. This memo is not an endorsement of the methods
   described, but merely an attempt to capture them in a document.


Table of Contents



Srisuresh, Ford & Kegel                                         [Page 1]


Internet-Draft   State of P2P Communication Across NATs   September 2006



   1.  Introduction .................................................
   2.  Terminology ..................................................
       2.1. Endpoint ................................................
       2.2. Endpoint Mapping ........................................
       2.3. Endpoint Independent Mapping ............................
       2.4. Endpoint Dependent Mapping ..............................
       2.5. Endpoint Independent Filtering ..........................
       2.6. Endpoint Dependent Filtering ............................
       2.7. P2P Application .........................................
       2.8. NAT-friendly P2P application ............................
       2.9. P2P-friendly NAT ........................................
       2.10. Hairpin translation ....................................
   3.  Techniques used by NAT-friendly P2P applications .............
       3.1. Relaying ................................................
       3.2. Connection reversal .....................................
       3.3. UDP Hole Punching .......................................
            3.3.1. Peers behind different NATs ......................
            3.3.2. Peers behind the same NAT ........................
            3.3.3. Peers separated by multiple NATs .................
            3.3.4. Where UDP hole punching fails ....................
       3.4. Simultaneous TCP Open ...................................
       3.5. UDP port number prediction ..............................
       3.6. TCP port number prediction ..............................
   4. Recent Work on P2P NAT Traversal ..............................
   5.  Summary of observations ......................................
       5.1. TCP/UDP hole punching ...................................
       5.2. Symmetric NATs are not P2P friendly .....................
       5.3. Peer discovery ..........................................
       5.4. Hairpin translation .....................................
   6.  Security considerations ......................................
       6.1. Lack of Authentication can cause connection hijacking ...
       6.2. Denial-of-service attacks ...............................
       6.3. Man-in-the-middle attacks ...............................
       6.4. Security impact from a P2P-friendly NAT device ..........
   7.  IANA Considerations ..........................................
   8.  Acknowledgments ..............................................
   9.  Normative References .........................................
   10. Informative References .......................................


1. Introduction

   Present day Internet has seen ubiquitous deployment of network
   address translators (NATs). There are a variety of NAT devices and
   a variety of network topologies utilizing NAT devices in
   deployments. The asymmetric addressing and connectivity regimes
   established by these NAT devices has created unique problems for



Srisuresh, Ford & Kegel                                         [Page 2]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   peer-to-peer (P2P) applications and protocols, such as
   teleconferencing and multiplayer on-line gaming. These issues are
   likely to persist even into the IPv6 world, where a NAT may be used
   as an IPv4 compatibility mechanism [NAT-PT].

   Currently deployed NAT devices are designed primarily around the
   client/server paradigm, in which relatively anonymous client machines
   inside a private network initiate connections to public servers with
   stable IP addresses and DNS names. NAT devices encountered enroute
   provide dynamic address assignment for the client machines. The
   anonymity and inaccessibility of the internal hosts behind a NAT
   device is not a problem for applications such as web browsers, which
   only need to initiate outgoing connections. This inaccessibility is
   sometimes perceived as a privacy benefit.

   In the peer-to-peer paradigm, Internet hosts that would normally be
   considered "clients" not only initiate sessions to peer nodes, but
   also accept sessions initiated by peer nodes. The initiator and the
   responder might lie behind different NAT devices with neither
   endpoint having a permanent IP address or other form of public
   network presence. A common on-line gaming architecture, for example,
   involves all participating application hosts contacting a
   well-known server for initialization and administration purposes.
   Subsequent to this, the hosts establish direct connections with each
   other for fast and efficient propagation of updates during game play.
   Similarly, a file sharing application might contact a well-known
   server for resource discovery or searching, but establish direct
   connections with peer hosts for data transfer. NAT devices create
   problems for peer-to-peer connections because hosts behind a
   NAT device normally have no permanently visible public ports on the
   Internet to which incoming TCP or UDP connections from other peers
   can be directed.  RFC 3235 [NAT-APPL] briefly addresses this issue.

   Unless prefixed with a NAT type or explicitly stated otherwise, the
   term NAT, used throughout the document, refers to Traditional
   NAT as described in [NAT-TRAD]. Traditional NATs include the
   popular NAPT devices which use a single public IP address to
   translate multiple private IP addresses.

   NAT traversal strategies that involve explicit signaling between
   applications and  NAT devices, namely [NAT-PMP], [NSIS-NSLP],
   [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this
   document. [UNSAF] is in scope.

   In this document, we summarize the currently known methods by which
   P2P applications work around the presence of NAT devices, without
   directly altering the NAT devices. The traversal techniques
   discussed are limited to TCP and UDP based applications. It is not



Srisuresh, Ford & Kegel                                         [Page 3]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   the objective of this document to provide solutions to NAT traversal
   problem for P2P applications in general [BEH-APP] or to a specific
   class of applications [ICE].

2. Terminology

   Readers are urged to refer [NAT-TERM] for information on NAT
   taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most
   common type of NAT device deployed. Traditional NAT has two main
   variations - Basic NAT and Network Address Port Translator (NAPT).
   Of these, NAPT is by far the most commonly deployed NAT device. NAPT
   allows multiple internal hosts to share a single public IP address
   simultaneously. When an internal host opens an outgoing TCP or UDP
   session through a NAPT, the NAPT assigns the session a public IP
   address and port number so that subsequent response packets from
   the external endpoint can be received by the NAPT, translated, and
   forwarded to the internal host. Unless specified otherwise, the
   term NAT in this document simply refers to Traditional NAT.

   An issue of relevance to P2P applications is how the NAT behaves
   when an internal host initiates multiple simultaneous sessions from
   a single endpoint (private IP, private port) to multiple distinct
   endpoints on the external network.

   [STUN] further classifies NAT implementations using the terms
   "Full Cone", "Restricted Cone", "Port Restricted Cone" and
   "Symmetric". Unfortunately, this terminology has been the source of
   much confusion. For this reason, this draft adapts terminology from
   [BEH-UDP] to distinguish between NAT implementations.

   Listed below are terms used throughout the document.

2.1. Endpoint

   An endpoint is a session specific tuple on an end host. An endpoint
   may be represented differently for each IP protocol. For example,
   a TCP session endpoint is represented as a tuple of (IP Address,
   TCP port), and a UDP session endpoint is represented as a tuple
   of (IP Address, UDP Port).

2.2. Endpoint Mapping

   When a host in a private realm initiates an outgoing session to a
   host in the public realm through a NAT device, the NAT device
   assigns an external endpoint to translate the private endpoint so
   that subsequent response packets from the external host can be
   received by the NAT, translated, and forwarded to the private
   endpoint. The assignment by the NAT device to translate a private



Srisuresh, Ford & Kegel                                         [Page 4]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   endpoint to an external endpoint and vice versa is called the
   Endpoint Mapping. NAT uses the Endpoint Mapping to perform
   translation for the duration of the session.

2.3. Endpoint Independent Mapping

   This term is adapted from [BEH-UDP]. Endpoint Independent Mapping
   is shared by all variations of Cone NAT devices ([STUN]). NAT
   devices that perform Endpoint Independent Mapping reuse the
   Endpoint Mapping assigned to a private host endpoint for all
   sessions initiated by the private host from the same endpoint,
   while the Endpoint Mapping is alive.

   For example, suppose Client A in figure 1 initiates two simultaneous
   outgoing sessions through a NAT device employing Endpoint Independent
   Mapping, from the same internal endpoint (10.0.0.1:1234) to two
   different external servers, S1 and S2. The NAT device assigns just
   one public endpoint 155.99.25.11:62000 to both these sessions,
   ensuring that the "identity" of the client's endpoint is maintained
   across address translation. Since Basic NAT devices do not modify
   port numbers as packets traverse the device, Basic NAT device can be
   viewed as a degenerate form of a NAT device performing Endpoint
   Independent Mapping.




























Srisuresh, Ford & Kegel                                         [Page 5]


Internet-Draft   State of P2P Communication Across NATs   September 2006



           Server S1                                     Server S2
        18.181.0.31:1235                              138.76.29.7:1235
               |                                             |
               |                                             |
               +----------------------+----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          | 155.99.25.11:62000 |      |      | 155.99.25.11:62000 |
                                      |
                           +----------------------+
                           |    155.99.25.11      |
                           |                      |
                           | NAT Device employing |
                           | Endpoint Independent |
                           | Mapping              |
                           +----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          |   10.0.0.1:1234    |      |      |   10.0.0.1:1234    |
                                      |
                                   Client A
                                10.0.0.1:1234

      Figure 1: Endpoint Independent Mapping - NAT Translation


2.4. Endpoint Dependent Mapping

   This term refers to "Address Dependent Mapping" and/or "Address and
   Port Dependent Mapping" defined in [BEH-UDP]. Symmetric NAT devices
   ([STUN]) are a good example of NAT devices performing Endpoint
   Dependent Mapping. A NAT device that performs Endpoint Dependent
   Mapping does not reuse the same Endpoint Mapping for all sessions
   initiated by the private host from the same endpoint. The NAT
   device may assign a new Endpoint Mapping to each new session
   traversing the NAT device.

   For example, suppose Client A in figure 2 initiates two outgoing
   sessions from the same endpoint, one with S1 and another with S2.
   The same client endpoint is connecting to the two external servers
   S1 and S2. When the first session to server S1 traverses the NAT
   device employing Endpoint Dependent Mapping, the NAT device assigns
   port 62000 to translate the client endpoint. When the second
   session from the same client endpoint to server S2 traverses the
   NAT device, the NAT device assigns a different port 62001 to



Srisuresh, Ford & Kegel                                         [Page 6]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   translate the same client endpoint. As a result, server S1 sees the
   client endpoint as 155.99.25.11:62000, whereas server S2 sees the
   same client endpoint differently as 155.99.25.11:62001. The
   NAT device, however, is able to differentiate between the two
   sessions for translation purposes because the external endpoints
   involved in the two sessions (those of S1 and S2) differ, even as
   the endpoint identity of the client application is lost across the
   address translation boundary.


           Server S1                                     Server S2
        18.181.0.31:1235                              138.76.29.7:1235
               |                                             |
               |                                             |
               +----------------------+----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          | 155.99.25.11:62000 |      |      | 155.99.25.11:62001 |
                                      |
                           +----------------------+
                           |    155.99.25.11      |
                           |                      |
                           | NAT Device employing |
                           | Endpoint Dependent   |
                           | Mapping              |
                           +----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          |   10.0.0.1:1234    |      |      |   10.0.0.1:1234    |
                                      |
                                   Client A
                                10.0.0.1:1234


       Figure 2: Endpoint Dependent Mapping - NAT Translation


2.5. Endpoint Independent Filtering

   This term is adapted from [BEH-UDP]. Essentially, a NAT device
   employing Endpoint Independent Mapping is further classified
   according to how liberally the NAT accepts incoming traffic
   directed to an already-established public endpoint. Endpoint
   Independent Filtering is the most liberal form of filtering
   incoming traffic on a NAT device.




Srisuresh, Ford & Kegel                                         [Page 7]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Subsequent to establishing Endpoint Independent Mapping at the
   start of an outgoing session, a NAT device employing Endpoint
   Independent Filtering will accept incoming traffic to the
   corresponding public port from ANY external endpoint on the
   public network. A NAT device employing Endpoint Independent
   Filtering is also sometimes referred to as "Promiscuous NAT" or
   "Full Cone NAT" [STUN].

2.6. Endpoint Dependent Filtering

   This is same as "Address and Port Dependent Mapping" defined in
   [BEH-UDP]. Endpoint Dependent Filtering is the least liberal form
   of filtering incoming traffic on a NAT device.

   Subsequent to establishing Endpoint Mapping at the start of an
   outgoing session, a NAT device employing Endpoint Dependent
   Filtering will accept incoming traffic to the corresponding public
   port from only those external endpoints to which the internal host
   has previously sent one or more outgoing packets. I.e., only
   those incoming packets that belong to the sessions initiated
   by the private host are permitted on the inbound.

2.7. P2P Application

   A P2P application is an application that uses the same endpoint to
   initiate outgoing sessions to peering hosts as well as accept
   incoming sessions from peering hosts.

2.8. NAT-friendly P2P application

   NAT-friendly P2P application is a P2P application that is designed
   to work effectively even as peering nodes are located in distinct
   IP address realms, connected by one or more NATs.

   A NAT-friendly P2P application registers with a public registration
   server and subsequently uses either the private endpoint, or public
   endpoint, or both to establish peering sessions.

2.9. P2P-friendly NAT

   A P2P-friendly NAT is a NAT device that maintains the endpoint
   identity of a P2P host application when the P2P application
   initiates a session. P2P-friendly NAT devices permit traversal of
   P2P applications traffic across themselves. NAT devices employing
   Address Independent Mapping are examples of P2P-friendly NAT
   devices. A NAT device employing Address Dependent Mapping is an
   example of a NAT device that is not P2P friendly.




Srisuresh, Ford & Kegel                                         [Page 8]


Internet-Draft   State of P2P Communication Across NATs   September 2006


2.10. Hairpin translation

   When a host in the private domain of a NAT device attempts to
   connect with another host behind the same NAT device using the
   public address of the host, a NAT device supporting hairpin
   translation performs the equivalent of Twice NAT ([NAT-TERM])
   translation on the packet as follows. The originating host's private
   endpoint is translated into its assigned public endpoint, and the
   target host's public endpoint is translated into its private
   endpoint, before the packet is forwarded to the target host. We
   refer the above translation as "Hairpin translation". Not all
   currently deployed NATs support hairpin translation, although it is
   mandated by [BEH-UDP].


3. Techniques used by P2P applications to traverse NATs

   This section reviews in detail the currently known techniques for
   implementing peer-to-peer communication over existing NAT devices,
   from the perspective of the application or protocol designer.
   Readers will note that the applications assume a NAT device
   employing Endpoint Independent Mapping and Endpoint Dependent
   Filtering in majority of the cases below.

3.1. Relaying

   The most reliable, but least efficient method of implementing peer-
   to-peer communication in the presence of a NAT device is to make the
   peer-to-peer communication look to the network like client/server
   communication through relaying.  For example, suppose two client
   hosts A and B, in figure 3, have each initiated TCP or UDP
   connections to a well-known server S, which has a permanent IP
   address.  The clients reside on separate private networks, and
   their respective NAT devices prevent either client from directly
   initiating a connection to the other.
















Srisuresh, Ford & Kegel                                         [Page 9]


Internet-Draft   State of P2P Communication Across NATs   September 2006


                               Registry cum Relay
                                  Server S
                              18.181.0.31:1234
                                     |
        +----------------------------+----------------------------+
        |                                                         |
        | ^ Registry/              ^   ^ Registry/              ^ |
        | | Relay-Req Session(A-S) |   | Relay-Req Session(B-S) | |
        | |  18.181.0.31:1234      |   |  18.181.0.31:1234      | |
        | | 155.99.25.11:62000     |   |  138.76.29.7:31000     | |
        |                                                         |
      +--------------+                                 +--------------+
      | 155.99.25.11 |                                 | 138.76.29.7  |
      |              |                                 |              |
      |    NAT A     |                                 |    NAT B     |
      +--------------+                                 +--------------+
        |                                                         |
        | ^ Registry/              ^   ^ Registry/              ^ |
        | | Relay-Req Session(A-S) |   | Relay-Req Session(B-S) | |
        | |  18.181.0.31:1234      |   |  18.181.0.31:1234      | |
        | |     10.0.0.1:1234      |   |     10.1.1.3:1234      | |
        |                                                         |
        |                                                         |
     Client A                                                 Client B
     10.0.0.1:1234                                        10.1.1.3:1234

   Figure 3: Use of Registry/Relay Server to emulate direct-P2P

   Instead of attempting a direct connection, the two clients can simply
   use the server S to relay messages between them.  For example, to
   send a message to client B, client A simply sends the message to
   server S along its already-established client/server connection, and
   server S then sends the message on to client B using its existing
   client/server connection with B.

   This method has the advantage that it will always work as long as
   both clients have connectivity to the server. The enroute NAT device
   is not assumed to be P2P friendly. The obvious disadvantages of
   relaying are that it consumes the server's processing power and
   network bandwidth, and communication latency between the peering
   clients is likely to be increased even if the server is
   well-connected. The TURN protocol [TURN] defines a method of
   implementing relaying in a relatively secure fashion.

3.2. Connection reversal

   The following connection reversal technique for a direct P2P
   communication works only when one of the clients (i.e., peers) is



Srisuresh, Ford & Kegel                                        [Page 10]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   behind a NAT device and the other is not. For example, suppose
   client A is behind a NAT but client B has a globally routable IP
   address, as in figure 4.


                                 Server S
                              18.181.0.31:1234
                                     |
        +----------------------------+----------------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | | 155.99.25.11:62000    |     |  138.76.29.7:1234     | |
        |                                                         |
        | ^ P2P Session (A-B)     ^     |  P2P Session (B-A)    | |
        | |  138.76.29.7:1234     |     |  155.99.25.11:62000   | |
        | | 155.99.25.11:62000    |     v  138.76.29.7:31000    v |
        |                                                         |
      +--------------+                                            |
      | 155.99.25.11 |                                            |
      |              |                                            |
      | P2P-friendly |                                            |
      |    NAT A     |                                            |
      +--------------+                                            |
        |                                                         |
        | ^ Registry Session(A-S) ^                               |
        | |  18.181.0.31:1234     |                               |
        | |     10.0.0.1:1234     |                               |
        |                                                         |
        | ^ P2P Session (A-B)     ^                               |
        | |  138.76.29.7:1234     |                               |
        | |     10.0.0.1:1234     |                               |
        |                                                         |
     Private Client A                                 Public Client B
     10.0.0.1:1234                                    138.76.29.7:1234

   Figure 4: Connection reversal to accomplish Direct-P2P

   Client A has private IP address 10.0.0.1, and the application is
   using TCP port 1234.  This client has established a connection with
   server S at public IP address 18.181.0.31 and port 1235.  NAT A has
   assigned TCP port 62000, at its own public IP address 155.99.25.11,
   to serve as the temporary public endpoint address for A's session
   with S: therefore, server S believes that client A is at IP address
   155.99.25.11 using port 62000.  Client B, however, has its own
   permanent IP address, 138.76.29.7, and the peer-to-peer application
   on B is accepting TCP connections at port 1234.




Srisuresh, Ford & Kegel                                        [Page 11]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Now suppose client B would like to initiate a peer-to-peer
   communication session with client A.  B might first attempt to
   contact client A either at the address client A believes itself to
   have, namely 10.0.0.1:1234, or at the address of A as observed by
   server S, namely 155.99.25.11:62000.  In either case, however, the
   connection will fail.  In the first case, traffic directed to IP
   address 10.0.0.1 will simply be dropped by the network because
   10.0.0.1 is not a publicly routable IP address. In the second case,
   the TCP SYN request from B will arrive at NAT A directed to port
   62000, but NAT A will reject the connection request because only
   outgoing connections are allowed.

   After attempting and failing to establish a direct connection to A,
   client B can use server S to relay a request to client A to initiate
   a "reversed" connection to client B.  Client A, upon receiving this
   relayed request through S, opens a TCP connection to client B at B's
   public IP address and port number.  NAT A allows the connection to
   proceed because it is originating inside the firewall, and client B
   can receive the connection because it is not behind a NAT device.

   A variety of current peer-to-peer applications implement this
   technique. Its main limitation, of course, is that it only works so
   long as only one of the communicating peers is behind a NAT and the
   NAT is P2P-friendly, employing Address Independent Mapping. In the
   increasingly common case where both peers can be behind NATs, the
   method fails. Because connection reversal is not a general solution
   to the problem, it is NOT recommended as a primary strategy.
   NAT-friendly P2P applications may choose to attempt connection
   reversal, but should be able to fall back automatically to another
   mechanism such as relaying if neither a "forward" nor a "reverse"
   connection can be established.

3.3. UDP hole punching

   UDP hole punching relies on the properties of common firewalls and
   NATs employing Address Independent Mapping to allow appropriately
   designed peer-to-peer applications to "punch holes" through the NAT
   device and establish direct connectivity with each other, even when
   both communicating hosts lie behind NAT devices. This technique was
   mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], described
   in [KEGEL], and used in some recent protocols [TEREDO, ICE]. This
   technique has been used primarily with UDP applications, but not as
   reliably with TCP applications. Readers may refer Section 3.4 for
   details on "Simultaneous TCP open", also known sometimes as "TCP
   hole punching".

   We will consider two specific scenarios, and how applications are
   designed to handle both of them gracefully.  In the first situation,



Srisuresh, Ford & Kegel                                        [Page 12]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   representing the common case, two clients desiring direct peer-to-
   peer communication reside behind two different NATs.  In the second,
   the two clients actually reside behind the same NAT, but do not
   necessarily know that they do.

3.3.1. Peers behind different NATs

   Suppose clients A and B both have private IP addresses and lie behind
   different network address translators as in figure 5.  The
   peer-to-peer application running on clients A and B and on server S
   each use UDP port 1234. A and B have each initiated UDP communication
   sessions with server S, causing NAT A to assign its own public UDP
   port 62000 for A's session with S, and causing NAT B to assign its
   port 31000 to B's session with S, respectively.

                                 Server S
                              18.181.0.31:1234
                                     |
        +----------------------------+----------------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | | 155.99.25.11:62000    |     |  138.76.29.7:31000    | |
        |                                                         |
        | ^ P2P Session (A-B)     ^     ^  P2P Session (B-A)    ^ |
        | |  138.76.29.7:31000    |     |  155.99.25.11:62000   | |
        | | 155.99.25.11:62000    |     |  138.76.29.7:31000    | |
        |                                                         |
      +--------------+                                 +--------------+
      | 155.99.25.11 |                                 | 138.76.29.7  |
      |              |                                 |              |
      | P2P-friendly |                                 | P2P-friendly |
      |    NAT A     |                                 |    NAT B     |
      +--------------+                                 +--------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | |     10.0.0.1:1234     |     |     10.1.1.3:1234     | |
        |                                                         |
        | ^ P2P Session (A-B)     ^     ^  P2P Session (B-A)    ^ |
        | |  138.76.29.7:31000    |     |  155.99.25.11:62000   | |
        | |     10.0.0.1:1234     |     |      10.1.1.3:1234    | |
        |                                                         |
     Client A                                                 Client B
     10.0.0.1:1234                                        10.1.1.3:1234

   Figure 5: Simultaneous Hole Punching to accomplish Direct-P2P




Srisuresh, Ford & Kegel                                        [Page 13]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Now suppose that client A wants to establish a UDP communication
   session directly with client B.  If A simply starts sending UDP
   messages to B's public address, 138.76.29.7:31000, then NAT B will
   typically discard these incoming messages (unless it employs
   Endpoint Independent Filtering), because the source address and port
   number does not match those of S, with which the original outgoing
   session was established. Similarly, if B simply starts sending UDP
   messages to A's public address and port number, then NAT A will
   typically discard these messages.

   Suppose A starts sending UDP messages to B's public address, however,
   and simultaneously relays a request through server S to B, asking B
   to start sending UDP messages to A's public address.  A's outgoing
   messages directed to B's public address (138.76.29.7:31000) cause NAT
   A to open up a new communication session between A's private address
   and B's public address.  At the same time, B's messages to A's public
   address (155.99.25.11:62000) cause NAT B to open up a new
   communication session between B's private address and A's public
   address.  Once the new UDP sessions have been opened up in each
   direction, client A and B can communicate with each other directly
   without further burden on the "introduction" server S.

   The UDP hole punching technique has several useful properties. Once
   a direct peer-to-peer UDP connection has been established between two
   clients behind NAT devices, either party on that connection can in
   turn take over the role of "introducer" and help the other party
   establish peer-to-peer connections with additional peers, minimizing
   the load on the initial introduction server S.  The application does
   not need to attempt to detect the kind of NAT device it is behind,
   if any [STUN], since the procedure above will establish peer-to-peer
   communication channels equally well if either or both clients do not
   happen to be behind a NAT device. The UDP hole punching technique
   even works automatically with multiple NATs, where one or both
   clients are removed from the public Internet via two or more levels
   of address translation.

3.3.2. Peers behind the same NAT

   Now consider the scenario in which the two clients (probably
   unknowingly) happen to reside behind the same NAT, and are therefore
   located in the same private IP address space, as in figure 6.
   Client A has established a UDP session with server S, to which the
   common NAT has assigned public port number 62000. Client B has
   similarly established a session with S, to which the NAT has
   assigned public port number 62001.






Srisuresh, Ford & Kegel                                        [Page 14]


Internet-Draft   State of P2P Communication Across NATs   September 2006


                                Server S
                            18.181.0.31:1234
                                    |
         ^ Registry Session(A-S) ^  | ^ Registry Session(B-S) ^
         |  18.181.0.31:1234     |  | |  18.181.0.31:1234     |
         | 155.99.25.11:62000    |  | |  155.99.25.11:62001   |
                                    |
                             +--------------+
                             | 155.99.25.11 |
                             |              |
                             | P2P-friendly |
                             |    NAT       |
                             +--------------+
                                    |
      +-----------------------------+----------------------------+
      |                                                          |
      |                                                          |
      | ^ Registry Session(A-S) ^      ^ Registry Session(B-S) ^ |
      | |  18.181.0.31:1234     |      |  18.181.0.31:1234     | |
      | |     10.0.0.1:1234     |      |     10.1.1.3:1234     | |
      |                                                          |
      | ^ P2P Session-try1(A-B) ^      ^ P2P Session-try1(B-A) ^ |
      | |     10.1.1.3:1234     |      |     10.0.0.1:1234     | |
      | |     10.0.0.1:1234     |      |     10.1.1.3:1234     | |
      |                                                          |
      | ^ P2P Session-try2(A-B) ^      ^ P2P Session-try2(B-A) ^ |
      | | 155.99.25.11:62001    |      |  155.99.25.11:62000   | |
      | |     10.0.0.1:1234     |      |      10.1.1.3:1234    | |
      |                                                          |
   Client A                                                   Client B
   10.0.0.1:1234                                         10.1.1.3:1234

   Figure 6: Use local & public identities to communicate with peers.

   Suppose that A and B use the UDP hole punching technique as outlined
   above to establish a communication channel using server S as an
   introducer.  Then A and B will learn each other's public IP addresses
   and port numbers as observed by server S, and start sending each
   other messages at those public addresses.  The two clients will be
   able to communicate with each other this way as long as the NAT
   allows hosts on the internal network to open translated UDP sessions
   with other internal hosts and not just with external hosts. We refer
   to this situation as "Hairpin translation," because packets arriving
   at the NAT from the private network are translated and then looped
   back to the private network rather than being passed through to the
   public network.  For example, when A sends a UDP packet to B's public
   address, the packet initially has a source IP address and port number
   of 10.0.0.1:124 and a destination of 155.99.25.11:62001.  The NAT



Srisuresh, Ford & Kegel                                        [Page 15]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   receives this packet, translates it to have a source of
   155.99.25.11:62000 (A's public address) and a destination of
   10.1.1.3:1234, and then forwards it on to B.  Even if hairpin
   translation is supported by the NAT, this translation and forwarding
   step is obviously unnecessary in this situation, and is likely to add
   latency to the dialog between A and B as well as burdening the NAT.

   The solution to this problem is straightforward, however.  When A and
   B initially exchange address information through server S, they
   should include their own IP addresses and port numbers as "observed"
   by themselves, as well as their addresses as observed by S.  The
   clients then simultaneously start sending packets to each other at
   each of the alternative addresses they know about, and use the first
   address that leads to successful communication.  If the two clients
   are behind the same NAT, then the packets directed to their private
   addresses are likely to arrive first, resulting in a direct
   communication channel not involving the NAT.  If the two clients are
   behind different NATs, then the packets directed to their private
   addresses will fail to reach each other at all, but the clients will
   hopefully establish connectivity using their respective public
   addresses.  It is important that these packets be authenticated in
   some way, however, since in the case of different NATs it is entirely
   possible for A's messages directed at B's private address to reach
   some other, unrelated node on A's private network, or vice versa.

3.3.3. Peers separated by multiple NATs

   In some topologies involving multiple NAT devices, it is not
   possible for two clients to establish an "optimal" P2P route between
   them without specific knowledge of the topology.  Consider for
   example the situation, depicted in figure 7.




















Srisuresh, Ford & Kegel                                        [Page 16]


Internet-Draft   State of P2P Communication Across NATs   September 2006


                                Server S
                            18.181.0.31:1234
                                   |
         ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
         |  18.181.0.31:1234     | | |  18.181.0.31:1234     |
         | 155.99.25.11:62000    | | | 155.99.25.11:62001    |
                                   |
                            +--------------+
                            | 155.99.25.11 |
                            |              |
                            | P2P-friendly |
                            |    NAT X     |
                            | (Supporting  |
                            | Hairpin      |
                            | Translation) |
                            +--------------+
                                   |
      +----------------------------+----------------------------+
      |                                                         |
      | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
      | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
      | |  192.168.1.1:30000    |     |  192.168.1.2:31000    | |
      |                                                         |
      | ^ P2P Session (A-B)     ^     ^ P2P Session (B-A)     ^ |
      | |  155.99.25.11:62001   |     |   155.99.25.11:62000  | |
      | |   192.168.1.1:30000   |     |    192.168.1.2:31000  | |
      |                                                         |
   +--------------+                                  +--------------+
   | 192.168.1.1  |                                  | 192.168.1.2  |
   |              |                                  |              |
   | P2P-friendly |                                  | P2P-friendly |
   |    NAT A     |                                  |    NAT B     |
   +--------------+                                  +--------------+
       |                                                        |
       | ^ Registry Session(A-S) ^    ^ Registry Session(B-S) ^ |
       | |  18.181.0.31:1234     |    |  18.181.0.31:1234     | |
       | |     10.0.0.1:1234     |    |     10.1.1.3:1234     | |
       |                                                        |
       | ^ P2P Session (A-B)     ^    ^  P2P Session (B-A)    ^ |
       | |  155.99.25.11:62001   |    |  155.99.25.11:62000   | |
       | |      10.0.0.1:1234    |    |      10.1.1.3:1234    | |
       |                                                        |
   Client A                                                  Client B
   10.0.0.1:1234                                        10.1.1.3:1234

   Figure 7: Hairpin translation support in NAT to facilitate Direct-P2P

   Suppose NAT X is a NAT device performing Address Independent Mapping



Srisuresh, Ford & Kegel                                        [Page 17]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   and deployed by a large internet service provider (ISP) to multiplex
   many customers onto a few public IP addresses, and NATs A and B are
   small consumer NAT gateways deployed independently by two of the
   ISP's customers to multiplex their private home networks onto their
   respective ISP-provided IP addresses. Only server S and NAT X have
   globally routable IP addresses; the "public" IP addresses used by
   NAT A and NAT B are actually private to the ISP's addressing realm,
   while client A's and B's addresses in turn are private to the
   addressing realms of NAT A and B, respectively.  Each client
   initiates an outgoing connection to server S as before, causing NATs
   A and B each to create a single public/private translation, and
   causing NAT X to establish a public/private translation for each
   session.

   Now suppose clients A and B attempt to establish a direct peer-to-
   peer UDP connection.  The optimal method would be for client A to
   send messages to client B's public address at NAT B,
   192.168.1.2:31000 in the ISP's addressing realm, and for client B to
   send messages to A's public address at NAT B, namely
   192.168.1.1:30000.  Unfortunately, A and B have no way to learn these
   addresses, because server S only sees the "global" public addresses
   of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.  Even if A
   and B had some way to learn these addresses, there is still no
   guarantee that they would be usable because the address assignments
   in the ISP's private addressing realm might conflict with unrelated
   address assignments in the clients' private realms.  The clients
   therefore have no choice but to use their global public addresses as
   seen by S for their P2P communication, and rely on NAT X to provide
   hairpin translation.

3.3.4. Where UDP hole punching fails

   The UDP hole punching technique has a caveat in that it works only
   if the traversing NAT is a P2P-friendly NAT. When a NAT device
   employing Endpoint Dependent Mapping is enroute, P2P application is
   unable to reuse an already established endpoint mapping
   for communication with different external destinations and the
   technique would fail. However, many of the NAT devices deployed in
   the Internet do employ Address Independent Mapping. That makes the
   UDP hole punching technique broadly applicable [P2P-NAT].
   Nevertheless a substantial fraction of deployed NATs do employ
   Endpoint Dependent Mapping and do not support the UDP hole punching
   technique.

3.4. Simultaneous TCP Open

   Simultaneous TCP open (also known sometimes as TCP hole punching)
   is a technique used in some cases to establish direct peer-to-peer



Srisuresh, Ford & Kegel                                        [Page 18]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   TCP connections between a pair of nodes that are both behind
   P2P-friendly NAT devices that implement Endpoint Independent Mapping
   for their TCP traffic. Most TCP sessions start with one endpoint
   sending a SYN packet, to which the other party responds with a
   SYN-ACK packet. It is permissible, however, for two endpoints to
   start a TCP session by simultaneously sending each other SYN
   packets, to which each party subsequently responds with a separate
   ACK. This procedure is known as "Simultaneous TCP Open" technique
   and may be found in figure 8 of the original TCP specification
   ([TCP]). However, "Simultaneous TCP Open" is not implemented
   correctly on many systems, including NAT devices.

   If a NAT device receives a TCP SYN packet from outside the private
   network attempting to initiate an incoming TCP connection, the
   NAT device will normally reject the connection attempt by either
   dropping the SYN packet or sending back a TCP RST (connection reset)
   packet. In the case of SYN timeout or connection reset, the P2P
   endpoint will continue to resend a SYN packet, until the peer does
   the same from its end.

   When a SYN packet arrives with source and destination addresses and
   port numbers that correspond to a TCP session that the NAT device
   believes is already active, then the NAT device will allow the
   packet to pass through. In particular, if the NAT device has just
   recently seen and transmitted an outgoing SYN packet with the same
   addresses and port numbers, then it will consider the session
   active and allow the incoming SYN through. If clients A and B can
   each initiate an outgoing TCP connection with the other client
   timed so that each client's outgoing SYN passes through its local
   NAT device before either SYN reaches the opposite NAT device, then
   a working peer-to-peer TCP connection will result.

   This technique may not always work reliably for the following
   reason(s). If either node's SYN packet arrives at the remote NAT
   device too quickly (before the peering node had a chance to send the
   SYN packet), then the remote NAT device may either drop the SYN
   packet or reject the SYN with a RST packet. This could cause the
   local NAT device in turn to close the new NAT-session immediately or
   initiate end-of-session timeout (refer section 2.6 of [NAT-TERM]) so
   as to close the NAT-session at the end of the timeout. Even as both
   peering nodes simultaneously initiate continued SYN retransmission
   attempts, some remote NAT devices might not let the incoming SYNs
   through if the NAT session is in end-of-session timeout state. This
   in turn would prevent the TCP connection from being established.

   In reality, the majority of the NAT devices (more than 50%) do
   support Endpoint Independent Mapping and do not send ICMP errors or
   RSTs in response to unsolicited incoming SYNs. As a result,



Srisuresh, Ford & Kegel                                        [Page 19]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Simultaneous TCP Open technique does work across NAT devices in
   the majority of TCP connection attempts ([P2P-NAT], [TCP-CHARACT]).


3.5. UDP port number prediction

   A variant of the UDP hole punching technique exists that allows
   peer-to-peer UDP sessions to be created in the presence of some
   NATs implementing Endpoint Dependent Mapping. This method is
   sometimes called the "N+1" technique [BIDIR] and is explored in
   detail by Takeda [SYM-STUN]. The method works by analyzing the
   behavior of the NAT and attempting to predict the public port
   numbers it will assign to future sessions. Consider again the
   situation in which two clients, A and B, each behind a separate NAT,
   have each established UDP connections with a permanently addressable
   server S, as depicted in figure 8.


                                 Server S
                              18.181.0.31:1234
                                     |
        +----------------------------+----------------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | | 155.99.25.11:62000    |     |  138.76.29.7:31000    | |
        |                                                         |
        |                                                         |
   +---------------------+                       +--------------------+
   | 155.99.25.11        |                       |        138.76.29.7 |
   |                     |                       |                    |
   |    NAT A            |                       |        NAT B       |
   | (Endpoint Dependent |                       | (Endpoint Dependent|
   |  Mapping)           |                       |  Mapping)          |
   +---------------------+                       +--------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | |     10.0.0.1:1234     |     |     10.1.1.3:1234     | |
        |                                                         |
     Client A                                                 Client B
     10.0.0.1:1234                                       10.1.1.3:1234

   Figure 8: Port Prediction on NATs employing Address Dependent Mapping

   NAT A has assigned its own UDP port 62000 to the communication
   session between A and S, and NAT B has assigned its port 31000 to
   the session between B and S. By communicating through server S, A



Srisuresh, Ford & Kegel                                        [Page 20]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   and B learn each other's public IP addresses and port numbers as
   observed by S. Client A now starts sending UDP messages to port
   31001 at address 138.76.29.7 (note the port number increment), and
   client B simultaneously starts sending messages to port 62001 at
   address 155.99.25.11. If NATs A and B assign port numbers to new
   sessions sequentially, and if not much time has passed since the
   A-S and B-S sessions were initiated, then a working bi-directional
   communication channel between A and B should result. A's messages
   to B cause NAT A to open up a new session, to which NAT A will
   (hopefully) assign public port number 62001, because 62001 is next
   in sequence after the port number 62000 it previously assigned to
   the session between A and S. Similarly, B's messages to A will
   cause NAT B to open a new session, to which it will (hopefully)
   assign port number 31001. If both clients have correctly guessed
   the port numbers each NAT assigns to the new sessions, then a
   bi-directional UDP communication channel will have been
   established as shown in figure 9.


































Srisuresh, Ford & Kegel                                        [Page 21]


Internet-Draft   State of P2P Communication Across NATs   September 2006


                                 Server S
                              18.181.0.31:1234
                                     |
                                     |
        +----------------------------+----------------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | | 155.99.25.11:62000    |     |  138.76.29.7:31000    | |
        |                                                         |
        | ^ P2P Session (A-B)     ^     ^  P2P Session (B-A)    ^ |
        | |  138.76.29.7:31001    |     |  155.99.25.11:62001   | |
        | | 155.99.25.11:62001    |     |  138.76.29.7:31001    | |
        |                                                         |
   +---------------------+                       +--------------------+
   | 155.99.25.11        |                       |        138.76.29.7 |
   |                     |                       |                    |
   |    NAT A            |                       |        NAT B       |
   | (Endpoint Dependent |                       | (Endpoint Dependent|
   |  Mapping)           |                       |  Mapping)          |
   +---------------------+                       +--------------------+
        |                                                         |
        | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
        | |  18.181.0.31:1234     |     |  18.181.0.31:1234     | |
        | |     10.0.0.1:1234     |     |     10.1.1.3:1234     | |
        |                                                         |
        | ^ P2P Session (A-B)     ^     ^  P2P Session (B-A)    ^ |
        | |  138.76.29.7:31001    |     |  155.99.25.11:62001   | |
        | |     10.0.0.1:1234     |     |      10.1.1.3:1234    | |
        |                                                         |
     Client A                                                 Client B
     10.0.0.1:1234                                        10.1.1.3:1234


   Figure 9: Use of Port Prediction for Direct-P2P

   Clearly, there are many things that can cause this trick to fail.
   If the predicted port number at either NAT already happens to be in
   use by an unrelated session, then the NAT will skip over that port
   number and the connection attempt will fail.  If either NAT sometimes
   or always chooses port numbers non-sequentially, then the trick will
   fail.  If a different client behind NAT A (or B respectively) opens
   up a new outgoing UDP connection to any external destination after A
   (B) establishes its connection with S but before sending its first
   message to B (A), then the unrelated client will inadvertently
   "steal" the desired port number.  This trick is therefore much less
   likely to work when either NAT involved is under load.




Srisuresh, Ford & Kegel                                        [Page 22]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Since in practice a P2P application implementing this trick would
   still need to work even when one of the NATs employ Endpoint
   Independent Mapping, the application would need to detect beforehand
   what kind of NAT is involved on either end and modify its behavior
   accordingly, increasing the complexity of the algorithm and the
   general brittleness of the network. Finally, port number prediction
   has no chance of working if either client is behind two or more
   levels of NAT and the NAT(s) closest to the client employ Endpoint
   Dependent Mapping. For all of these reasons, it is NOT recommended
   that new applications implement this trick. This technique is
   mentioned here only for historical and informational purposes.

3.6. TCP port number prediction

   This is a variant of the "Simultaneous TCP open" technique that
   allows peer-to-peer TCP sessions to be created in the presence of
   some NATs employing Address Dependent Mapping.

   Unfortunately, this trick may be even more fragile and timing-
   sensitive than the UDP port number prediction trick described
   earlier. First, even as both NAT devices implement Endpoint
   Independent Mapping on the TCP traffic, all the same things can go
   wrong with each side's attempt to predict the public port numbers
   that the respective NATs will assign to the new sessions can
   happen with TCP port prediction as well. In addition, if either
   client's SYN arrives at the opposite NAT device too quickly, then
   the remote NAT device may reject the SYN with a RST packet,
   causing the local NAT device in turn to close the new session
   and make future SYN retransmission attempts using the same port
   numbers futile. For this reason, this trick is mentioned here
   only for historical reasons. It is NOT recommended for use by
   applications.


4. Recent Work on P2P NAT Traversal

   [P2P-NAT] has a detailed discussion on the UDP and TCP hole punching
   techniques for NAT traversal. [P2P-NAT] also lists empirical results
   from running [NAT-CHECK] test program across a number of commercial
   NAT devices. The results indicate that UDP hole punching is widely
   supported on more than 80% of the NAT devices, whereas TCP hole
   punching is supported on just over 60% of the NAT devices tested.
   The results also indicate that TCP or UDP hairpinning is not yet
   widely available on the commercial NAT devices, as less than 25% of
   the devices passed the tests ([NAT-CHECK]) for Hairpinning.

   [TCP-CHARACT] and [NAT-BLASTER] focus on TCP hole punching, exploring
   and comparing several alternative approaches. [NAT-BLASTER] takes an



Srisuresh, Ford & Kegel                                        [Page 23]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   analytical approach, analyzing different cases of observed NAT
   behavior and ways applications might address them. [TCP-CHARACT]
   adopts a more empirical approach, measuring the commonality of
   different types of NAT behavior relevant to TCP hole punching. This
   work finds that using more sophisticated techniques than those used
   in [P2P-NAT], up to 88% of currently deployed NATs can support TCP
   hole punching.

   [TEREDO] is a NAT traversal service that uses relay technology to
   connect IPv4 nodes behind NAT devices to IPv6 nodes, external to
   the NAT devices. [TEREDO] provides for peer communication across
   NAT devices by tunneling packets over UDP, across the NAT device(s)
   to a relay node. Teredo relays act as Rendezvous servers to relay
   traffic from private IPv4 nodes to the nodes in the external realm
   and vice versa.

   [ICE] is a NAT traversal protocol for setting up media sessions
   between peer nodes for a class of multi-media applications. [ICE]
   requires peering nodes to run STUN protocol ([STUN]) on the same
   port number used to terminate media session(s). Applications that
   use signaling protocols such as SIP ([SIP]) may embed the NAT
   traversal attributes for the media session within the signaling
   sessions and use the offer/answer type of exchange between peer
   nodes to set up end-to-end media session(s)b across NAT devices.
   [ICE-TCP] is an extension of ICE for TCP based media sessions.


5. Summary of observations

5.1. TCP/UDP hole punching

   TCP/UDP hole punching is the most efficient existing method of
   establishing direct TCP/UDP peer-to-peer communication between two
   nodes that are both behind NATs. This technique has been used with a
   wide variety of existing NATs. However, applications should be
   prepared to fall back to simple relaying when direct communication
   cannot be established.

5.2. NATs Employing Endpoint Dependent Mapping are not P2P friendly

   Symmetric NATs gained popularity with client-server applications
   such as web browsers, which only need to initiate outgoing
   connections. However, in the recent times, P2P applications such as
   Instant messaging and audio conferencing have been in wide use.
   Symmetric NATs do not support Endpoint Independent Mapping and are
   not suitable for P2P applications.

5.3. Peer discovery



Srisuresh, Ford & Kegel                                        [Page 24]


Internet-Draft   State of P2P Communication Across NATs   September 2006



   Applications should not assume all its peers to be outside its NAT
   boundary. As such, an application should register all its private IP
   addresses with the external server, so it can connect to some of its
   peers within the NAT boundary without having to traverse the NAT
   device.

5.4. Hairpin translation

   Hairpin translation support is highly beneficial to allow hosts
   behind a p2p-friendly NAT to communicate with other hosts behind
   the same NAT device through their public, possibly translated
   endpoints. Support for hairpin translation is particularly useful in
   the case of large-capacity NATs deployed as the first level of a
   multi-level NAT scenario. As described in section 3.3.3, hosts
   behind the same first-level NAT but different second-level NATs do
   not have a way to communicate with each other using TCP/UDP hole
   punching techniques, unless the first-level NAT also supports
   hairpin translation. This would be the case even when all NAT
   devices in the deployment preserve endpoint identities,


6. Security considerations

   This document does not inherently create new security issues.
   Nevertheless, security risks may be present in the techniques
   described. This section describes security risks the applications
   could inadvertently create in attempting to support P2P
   communication across NAT devices. Also described are implications
   for the security policies of P2P-friendly NAT devices.

6.1. Lack of Authentication can cause connection hijacking

   NAT-friendly P2P applications must use appropriate authentication
   mechanisms to protect their P2P connections from accidental
   confusion with other P2P connections as well as from malicious
   connection hijacking or denial-of-service attacks. NAT-friendly
   P2P applications effectively must interact with multiple distinct
   IP address domains, but are not generally aware of the exact topology
   or administrative policies defining these address domains. While
   attempting to establish P2P connections via TCP/UDP hole punching,
   applications send packets that may frequently arrive at an entirely
   different host than the intended one.

   For example, many consumer-level NAT devices provide DHCP
   services that are configured by default to hand out site-local
   IP addresses in a particular address range. Say, a particular
   consumer NAT device, by default, hands out IP addresses starting



Srisuresh, Ford & Kegel                                        [Page 25]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   with 192.168.1.100. Most private home networks using that NAT
   device will have a host with that IP address, and many of these
   networks will probably have a host at address 192.168.1.101 as
   well. If host A at address 192.168.1.101 on one private network
   attempts to establish a connection by UDP hole punching with
   host B at 192.168.1.100 on a different private network, then as
   part of this process host A will send discovery packets to
   address 192.168.1.100 on its local network, and host B will send
   discovery packets to address 192.168.1.101 on its network. Clearly,
   these discovery packets will not reach the intended machine since
   the two hosts are on different private networks, but they are very
   likely to reach SOME machine on these respective networks at the
   standard UDP port numbers used by this application, potentially
   causing confusion, especially if the application is also running
   on those other machines and does not properly authenticate its
   messages.

   This risk due to aliasing is therefore present even without a
   malicious attacker. If one endpoint, say host A, is actually
   malicious, then without proper authentication the attacker could
   cause host B to connect and interact in unintended ways with
   another host on its private network having the same IP address
   as the attacker's (purported) private address. Since the two
   endpoint hosts A and B presumably discovered each other through
   a public server S, and neither S nor B has any means to verify
   A's reported private address, all P2P applications must assume
   that any IP address they find to be suspect until they successfully
   establish authenticated two-way communication.

6.2. Denial-of-service attacks

   P2P applications and the public servers that support them must
   protect themselves against denial-of-service attacks, and ensure
   that they cannot be used by an attacker to mount denial-of-service
   attacks against other targets. To protect themselves, P2P
   applications and servers must avoid taking any action requiring
   significant local processing or storage resources until
   authenticated two-way communication is established. To avoid being
   used as a tool for denial-of-service attacks, P2P applications and
   servers must minimize the amount and rate of traffic they send to
   any newly-discovered IP address until after authenticated two-way
   communication is established with the intended target.

   For example, P2P applications that register with a public rendezvous
   server can claim to have any private IP address, or perhaps multiple
   IP addresses. A well-connected host or group of hosts that can
   collectively attract a substantial volume of P2P connection attempts
   (e.g., by offering to serve popular content) could mount a



Srisuresh, Ford & Kegel                                        [Page 26]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   denial-of-service attack on a target host C simply by including C's
   IP address in their own list of IP addresses they register with the
   rendezvous server. There is no way the rendezvous server can verify
   the IP addresses, since they could well be legitimate private
   network addresses useful to other hosts for establishing
   network-local communication. The P2P application protocol must
   therefore be designed to size- and rate-limit traffic to unverified
   IP addresses in order to avoid the potential damage such a
   concentration effect could cause.

6.3. Man-in-the-middle attacks

   Any network device on the path between a P2P client and a
   rendezvous server can mount a variety of man-in-the-middle
   attacks by pretending to be a NAT.  For example, suppose
   host A attempts to register with rendezvous server S, but a
   network-snooping attacker is able to observe this registration
   request. The attacker could then flood server S with requests
   that are identical to the client's original request except with
   a modified source IP address, such as the IP address of the
   attacker itself.  If the attacker can convince the server to
   register the client using the attacker's IP address, then the
   attacker can make itself an active component on the path of all
   future traffic from the server AND other P2P hosts to the
   original client, even if the attacker was originally only able
   to snoop the path from the client to the server.

   The client cannot protect itself from this attack by
   authenticating its source IP address to the rendezvous server,
   because in order to be NAT-friendly the application must allow
   intervening NATs to change the source address silently.  This
   appears to be an inherent security weakness of the NAT paradigm.
   The only defense against such an attack is for the client to
   authenticate and potentially encrypt the actual content of its
   communication using appropriate higher-level identities, so that
   the interposed attacker is not able to take advantage of its
   position.  Even if all application-level communication is
   authenticated and encrypted, however, this attack could still be
   used as a traffic analysis tool for observing who the client is
   communicating with.

6.4. Security impact from a P2P-friendly NAT device

   Designing NAT devices to preserve endpoint identities does not
   weaken the security provided by the NAT device. For example, a
   NAT device employing Endpoint Independent Mapping and Endpoint
   Dependent Filtering is no more "promiscuous" than a NAT device
   employing Endpoint Dependent Mapping and Endpoint Dependent



Srisuresh, Ford & Kegel                                        [Page 27]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   Filtering. Filtering incoming traffic aggressively using Endpoint
   Dependent Filtering, while employing Endpoint Independent Mapping
   allows a NAT device to be P2P friendly without compromising the
   principle of rejecting unsolicited incoming traffic.

   Endpoint Independent Mapping could arguably increase the
   predictability of traffic emerging from the NAT device, by revealing
   the relationships between different TCP/UDP sessions and hence about
   the behavior of applications running within the enclave. This
   predictability could conceivably be useful to an attacker in
   exploiting other network or application level vulnerabilities.
   If the security requirements of a particular deployment scenario
   are so critical that such subtle information channels are of
   concern, however, then the NAT device almost certainly should not be
   configured to allow unrestricted outgoing TCP/UDP traffic in the
   first place. Such a NAT device should only allow communication
   originating from specific applications at specific ports, or
   via tightly-controlled application-level gateways.  In this
   situation there is no hope of generic, transparent peer-to-peer
   connectivity across the NAT device (or transparent client/server
   connectivity for that matter); the NAT device must either
   implement appropriate application-specific behavior or disallow
   communication entirely.


7.  IANA Considerations

   There are no IANA considerations.


8. Acknowledgments

   The authors wish to thank Henrik, Dave, Christian Huitema and Dan
   Wing for their valuable feedback.


9. Normative References

[NAT-TERM]    Srisuresh, P., and Holdrege, M., "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

[NAT-TRAD]    Srisuresh, P., and Egevang, K., "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

[BEH-UDP]     F. Audet and C. Jennings, "NAT Behavioral Requirements
              for Unicast UDP", draft-ietf-behave-nat-udp-04.txt (Work



Srisuresh, Ford & Kegel                                        [Page 28]


Internet-Draft   State of P2P Communication Across NATs   September 2006


              In Progress), September 2005.


10. Informative References

[BEH-APP]     Ford, B., Srisuresh, P., and Kegel, D., "Application
              Design Guidelines for Traversal through Network Address
              Translators", draft-ford-behave-app-02.txt (Work In
              Progress), March 2006.

[BIDIR]       Peer-to-Peer Working Group, NAT/Firewall Working
              Committee, "Bidirectional Peer-to-Peer Communication with
              Interposing Firewalls and NATs", August 2001.
              http://www.peer-to-peerwg.org/tech/nat/

[ICE]         Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Methodology for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-09 (work in Progress), June 2006.

[ICE-TCP]     Rosenberg, J., "TCP Candidates with Interactive
              Connectivity Establishment (ICE)",
              draft-ietf-mmusic-ice-tcp-01.txt (work in Progress),
              June 2006.

[KEGEL]       Kegel, D., "NAT and Peer-to-Peer Networking", July 1999.
              http://www.alumni.caltech.edu/~dank/peer-nat.html

[MIDCOM]      Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and
              Rayhan, A., "Middlebox communication architecture and
              framework", RFC 3303, August 2002.

[NAT-APPL]    Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235, January 2002.

[NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A.,
              "Establishing TCP Connections Between Hosts Behind
              NATs", ACM SIGCOMM ASIA Workshop, April 2005.

[NAT-CHECK]   Ford, B., "NAT check Program" available online as
              http://midcom-p2p.sourceforge.net, February 2005.

[NAT-PMP]     Cheshire, S., Krochmal, M., and Sekar, K., "NAT Port
              Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-00.txt (Work In Progress),
              June 2005.

[NAT-PROT]    Holdrege, M., and Srisuresh, P., "Protocol Complications



Srisuresh, Ford & Kegel                                        [Page 29]


Internet-Draft   State of P2P Communication Across NATs   September 2006


              with the IP Network Address Translator", RFC 3027,
              January 2001.

[NAT-PT]      Tsirtsis, G. and Srisuresh, P., "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

[NSIS-NSLP]   Stiemerling, M., Tschofenig, H., Aoun, C., and Davies,
              E., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
              draft-ietf-nsis-nslp-natfw-11.txt (Work In Progress),
              April 2006.

[P2P-NAT]     Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer
              Communication Across Network Address Translators",
              Proceedings of the USENIX Annual Technical Conference
              (Anaheim, CA), April 2005.

[RSIP]        Borella, M., Lo, J., Grabelsky, D., and Montenegro, G.,
              "Realm Specific IP: Framework", RFC 3102, October 2001.

[SIP]         Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

[SOCKS]       Leech, M., Ganis, M., Lee, Y., Kuris, R.,Koblas, D., and
              Jones, L., "SOCKS Protocol Version 5", RFC 1928,
              March 1996.

[STUN]        Rosenberg, J., Weinberger, J., Huitema, C., and Mahy, R.,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

[SYM-STUN]    Takeda, Y., "Symmetric NAT Traversal using STUN",
              draft-takeda-symmetric-nat-traversal-00 (Work In
              Progress), June 2003.

[TCP]         Postel, J., "Transmission Control Protocol (TCP)
              Specification", STD 7,  RFC 793, September 1981.

[TCP-CHARACT] Guha, S., and Francis, P., "Characterization and
              Measurement of TCP Traversal through NATs and Firewalls",
              Proceedings of Internet Measurement Conference (IMC),
              Berkeley, CA, Oct 2005, pp. 199-211.

[TEREDO]      Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,



Srisuresh, Ford & Kegel                                        [Page 30]


Internet-Draft   State of P2P Communication Across NATs   September 2006


              February 2006.

[TURN]        Rosenberg, J., Mahy, R., and Huitema, C.,
              "Traversal Using Relay NAT (TURN)",
              draft-rosenberg-midcom-turn-08.txt (Work In Progress),
              September 2005.

[UNSAF]       Daigle, L., and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

[UPNP]        UPnP Forum, "Internet Gateway Device (IGD) Standardized
              Device Control Protocol V 1.0", November 2001.
              http://www.upnp.org/standardizeddcps/igd.asp


Authors' Addresses

   Pyda Srisuresh
   Consultant
   20072 Pacifica Dr.
   Cupertino, CA 95014
   U.S.A.
   Phone: (408)836-4773
   E-mail: srisuresh@yahoo.com

   Bryan Ford
   Laboratory for Computer Science
   Massachusetts Institute of Technology
   77 Massachusetts Ave.
   Cambridge, MA 02139
   Phone: (617) 253-5261
   E-mail: baford@mit.edu
   Web: http://www.brynosaurus.com/

   Dan Kegel
   Kegel.com
   901 S. Sycamore Ave.
   Los Angeles, CA 90036
   Phone: 323 931-6717
   Email: dank@kegel.com
   Web: http://www.kegel.com/

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in



Srisuresh, Ford & Kegel                                        [Page 31]


Internet-Draft   State of P2P Communication Across NATs   September 2006


   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Srisuresh, Ford & Kegel                                        [Page 32]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/