Intended status: INFORMATIONAL Internet Draft P. Srisuresh Expires: August 19, 2007 Kazeon Systems B. Ford M.I.T. D. Kegel kegel.com February 19, 2007 State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) 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. Srisuresh, Ford & Kegel [Page 1] Internet-Draft State of P2P Communication Across NATs February 2007 Table of Contents 1. Introduction ................................................. 2. Terminology and Conventions Used ............................. 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 Srisuresh, Ford & Kegel [Page 2] Internet-Draft State of P2P Communication Across NATs February 2007 established by these NAT devices has created unique problems for 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 rendezvous server for registering themselves and discovering peer hosts. Subsequent to the communication with rendezvous server, 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 rendezvous 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 Srisuresh, Ford & Kegel [Page 3] Internet-Draft State of P2P Communication Across NATs February 2007 directly altering the NAT devices. The traversal techniques discussed are limited to TCP and UDP based applications. It is not 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 and Conventions Used In this document, the IP addresses 192.0.2.1, 192.0.2.128, and 192.0.2.254 are used as example IP addresses [RFC3330]. Although these addresses are all from the same /24 network, this is a limitation of the example addresses available in [RFC3330]. In practice, these addresses would be on different networks. 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). Srisuresh, Ford & Kegel [Page 4] Internet-Draft State of P2P Communication Across NATs February 2007 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 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 "Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows. The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. Endpoint-Independent Mapping is shared by all variations of Cone NAT devices ([STUN]). The following text provides an example of this. 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 192.0.2.1: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 February 2007 Server S1 Server S2 192.0.2.128:1235 192.0.2.254:1235 | | | | +----------------------+----------------------+ | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 192.0.2.128:1235 | | | 192.0.2.254:1235 | | 192.0.2.1:62000 | | | 192.0.2.1:62000 | | +----------------------+ | 192.0.2.1 | | | | NAT Device employing | | Endpoint-Independent | | Mapping | +----------------------+ | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 192.0.2.128:1235 | | | 192.0.2.254:1235 | | 10.0.0.1:1234 | | | 10.0.0.1:1234 | | Client A 10.0.0.1:1234 Figure 1: Translation performed by Endpoint-Independent Mapping NAT 2.4. Endpoint-Dependent Mapping "Endpoint-Dependent Mapping" refers to the combination of "Address-Dependent Mapping" and "Address and Port-Dependent Mapping" as defined in [BEH-UDP]. "Address-Dependent Mapping" is defined in [BEH-UDP] as follows. The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. "Address and Port-Dependent Mapping" is defined in [BEH-UDP] as follows. The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address and port while the mapping is still active. Symmetric NAT devices ([STUN]) are a good example of NAT devices performing Endpoint-Dependent Mapping. The following text provides an example of this. Srisuresh, Ford & Kegel [Page 6] Internet-Draft State of P2P Communication Across NATs February 2007 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 translate the same client endpoint. As a result, server S1 sees the client endpoint as 192.0.2.1:62000, whereas server S2 sees the same client endpoint differently as 192.0.2.1: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 192.0.2.128:1235 192.0.2.254:1235 | | | | +----------------------+----------------------+ | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 192.0.2.128:1235 | | | 192.0.2.254:1235 | | 192.0.2.1:62000 | | | 192.0.2.1:62001 | | +----------------------+ | 192.0.2.1 | | | | NAT Device employing | | Endpoint-Dependent | | Mapping | +----------------------+ | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 192.0.2.128:1235 | | | 192.0.2.254: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 Srisuresh, Ford & Kegel [Page 7] Internet-Draft State of P2P Communication Across NATs February 2007 "Endpoint-Independent Filtering" is defined in [BEH-UDP] as follows. The NAT filters out only packets not destined to the internal address and port X:x, regardless of the external IP address and port source (Z:z). The NAT forwards any packets destined to X:x. In other words, sending packets from the internal side of the NAT to any external IP address is sufficient to allow any packets back to the internal endpoint. A NAT device employing the combination of "Endpoint-Independent Mapping" and "Endpoint-Independent Filtering" will accept incoming traffic to a mapped public port from ANY external endpoint on the public network. Such a NAT device is also sometimes referred to as "Promiscuous NAT" or "Full Cone NAT" [STUN]. 2.6. Endpoint-Dependent Filtering "Endpoint-Dependent Filtering" is same as "Address and Port-Dependent Filtering" defined in [BEH-UDP]. "Address and Port-Dependent Filtering" is defined in [BEH-UDP] as follows. The NAT filters out packets not destined for the internal address X:x. Additionally, the NAT will filter out packets from Y:y destined for the internal endpoint X:x if X:x has not sent packets to Y:y previously. In other words, for receiving packets from a specific external endpoint, it is necessary for the internal endpoint to send packets first to that external endpoint's IP address and port. Endpoint-Dependent Filtering is the least liberal form of filtering incoming traffic on a NAT device. 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 well-known rendezvous server, used for node registration and peer node discovery purposes. Pursuant to registering with rendezvous server, a P2P-friendly application uses its private endpoint, public endpoint, or a combination thereof to establish peering sessions. Srisuresh, Ford & Kegel [Page 8] Internet-Draft State of P2P Communication Across NATs February 2007 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. 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. Consider the scenario in figure 3. Two client hosts A and B, have each initiated TCP or UDP connections to a well-known rendezvous server S. The Rendezvous Server S has a permanent IP address and is used for the purposes of registration, discovery and relay. Hosts behind NAT register with the server. Peer hosts can discover hosts behind NATs and relay all end-to-end messages using the server. The clients reside on separate private networks, and their respective NAT devices prevent either Srisuresh, Ford & Kegel [Page 9] Internet-Draft State of P2P Communication Across NATs February 2007 client from directly initiating a connection to the other. Registry, Discovery combined with Relay Server S 192.0.2.128:1234 | +----------------------------+----------------------------+ | ^ Registry/ ^ ^ Registry/ ^ | | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | +--------------+ +--------------+ | 192.0.2.1 | | 192.0.2.254 | | | | | | NAT A | | NAT B | +--------------+ +--------------+ | | | ^ Registry/ ^ ^ Registry/ ^ | | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | | | 192.0.2.128:1234 | | 192.0.2.128: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 and 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. Srisuresh, Ford & Kegel [Page 10] Internet-Draft State of P2P Communication Across NATs February 2007 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 behind a NAT device and the other is not. For example, consider the scenario in figure 4. Client A is behind a NAT, but client B has a permanent, globally routable IP address. A well-known Rendezvous Server S has a permanent, globally routable IP address and is used for the purposes of node registration and discovery. Hosts behind NAT register with the server. Peer hosts discover hosts behind NAT using the server. Registry, Discovery Server S 192.0.2.128:1234 | +----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.0.2.1:62000 | | 192.0.2.254:1234 | | | | | ^ P2P Session (A-B) ^ | P2P Session (B-A) | | | | 192.0.2.254:1234 | | 192.0.2.1:62000 | | | | 192.0.2.1:62000 | v 192.0.2.254:31000 v | | | +--------------+ | | 192.0.2.1 | | | | | | NAT A | | +--------------+ | | | | ^ Registry Session(A-S) ^ | | | 192.0.2.128:1234 | | | | 10.0.0.1:1234 | | | | | ^ P2P Session (A-B) ^ | | | 192.0.2.254:1234 | | | | 10.0.0.1:1234 | | | | Private Client A Public Client B 10.0.0.1:1234 192.0.2.254: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 Srisuresh, Ford & Kegel [Page 11] Internet-Draft State of P2P Communication Across NATs February 2007 server S at public IP address 192.0.2.128 and port 1235. NAT A has assigned TCP port 62000, at its own public IP address 192.0.2.1, 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 192.0.2.1 using port 62000. Client B, however, has its own permanent IP address, 192.0.2.254, and the peer-to-peer application on B is accepting TCP connections at port 1234. 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 192.0.2.1: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 device. If the NAT device employs Endpoint-Independent Mapping, the public Client can contact external server S to determine the specific public endpoint from which to expect Client-A originated connection. That would be P2P-friendly. However, if the NAT device employs Endpoint-Dependent Mapping, the public Client cannot know the specific public endpoint from which to expect Client-A originated connection. In the increasingly common case where both peers can be behind NATs, the Connection Reversal method fails. As such, Connection Reversal is not a general solution to the Peer-to-peer connection problem. Even if an application attempts connection reversal method, the application 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 Srisuresh, Ford & Kegel [Page 12] Internet-Draft State of P2P Communication Across NATs February 2007 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, 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 Consider the scenario in figure 5. Clients A and B both have private IP addresses and lie behind different network address translators. A well-known Rendezvous Server S has a permanent, globally routable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind NAT register with the server. Peer hosts discover hosts behind NAT using the server. Unlike in section 3.1, peer hosts use the server to relay just connection initiation control messages, instead of all end-to-end messages. 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. Srisuresh, Ford & Kegel [Page 13] Internet-Draft State of P2P Communication Across NATs February 2007 Registry, Discovery, combined with limited Relay Server S 192.0.2.128:1234 | +----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | +--------------+ +--------------+ | 192.0.2.1 | | 192.0.2.254 | | | | | | P2P-friendly | | P2P-friendly | | NAT A | | NAT B | +--------------+ +--------------+ | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.254:31000 | | 192.0.2.1: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 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, 192.0.2.254: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 Srisuresh, Ford & Kegel [Page 14] Internet-Draft State of P2P Communication Across NATs February 2007 messages directed to B's public address (192.0.2.254: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 (192.0.2.1: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 server S. Server S, which helps with relaying connection initiation requests to peer nodes behind NAT ends up like an "introduction" server to peer hosts. 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, as in [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. A well-known Rendezvous Server S has a permanent, globally routable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind NAT register with the server. Peer hosts discover hosts behind NAT using the server and relay messages using the server. Unlike in section 3.1, peer hosts use the server to relay just control messages, instead of all end-to-end messages. 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 15] Internet-Draft State of P2P Communication Across NATs February 2007 Registry, Discovery, combined with limited Relay Server S 192.0.2.128:1234 | ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ | 192.0.2.128:1234 | | | 192.0.2.128:1234 | | 192.0.2.1:62000 | | | 192.0.2.1:62001 | | +--------------+ | 192.0.2.1 | | | | P2P-friendly | | NAT | +--------------+ | +-----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128: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) ^ | | | 192.0.2.1:62001 | | 192.0.2.1: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 Srisuresh, Ford & Kegel [Page 16] Internet-Draft State of P2P Communication Across NATs February 2007 of 10.0.0.1:124 and a destination of 192.0.2.1:62001. The NAT receives this packet, translates it to have a source of 192.0.2.1: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 scenario in figure 7. Srisuresh, Ford & Kegel [Page 17] Internet-Draft State of P2P Communication Across NATs February 2007 Registry, Discovery, combined with limited Relay Server S 192.0.2.128:1234 | ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ | 192.0.2.128:1234 | | | 192.0.2.128:1234 | | 192.0.2.1:62000 | | | 192.0.2.1:62001 | | +--------------+ | 192.0.2.1 | | | | P2P-friendly | | NAT X | | (Supporting | | Hairpin | | Translation) | +--------------+ | +----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.1:62001 | | 192.0.2.1: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) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.1:62001 | | 192.0.2.1: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 Srisuresh, Ford & Kegel [Page 18] Internet-Draft State of P2P Communication Across NATs February 2007 Suppose NAT X is a NAT device performing Address-Independent Mapping 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. Just as in previous section, Server S is used for the purposes of registration, discovery and limited relay. Peer hosts use the server to relay connection initiation control messages, instead of all end-to-end messages. 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, 192.0.2.1:62000 and 192.0.2.1: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 Srisuresh, Ford & Kegel [Page 19] Internet-Draft State of P2P Communication Across NATs February 2007 Simultaneous TCP open (also known sometimes as TCP hole punching) is a technique used in some cases to establish direct peer-to-peer 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 Srisuresh, Ford & Kegel [Page 20] Internet-Draft State of P2P Communication Across NATs February 2007 support Endpoint-Independent Mapping and do not send ICMP errors or RSTs in response to unsolicited incoming SYNs. As a result, 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 the scenario in figure 8. Two clients, A and B, each behind a separate NAT, have established separate UDP connections with a rendezvous server S. Rendezvous server S has a permanent, globally routable IP address and is used for the purposes of registration and discovery. Hosts behind NAT register with the server. Peer hosts discover hosts behind NAT using the server. Registry and Discovery Server S 192.0.2.128:1234 | +----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | | | +---------------------+ +--------------------+ | 192.0.2.1 | | 192.0.2.254 | | | | | | NAT A | | NAT B | | (Endpoint-Dependent | | (Endpoint-Dependent| | Mapping) | | Mapping) | +---------------------+ +--------------------+ | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128: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 assuming Endpoint-Dependent Mapping NATs Srisuresh, Ford & Kegel [Page 21] Internet-Draft State of P2P Communication Across NATs February 2007 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 with server S, A 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 192.0.2.254 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 192.0.2.1. 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 22] Internet-Draft State of P2P Communication Across NATs February 2007 Registry and Discovery Server S 192.0.2.128:1234 | | +----------------------------+----------------------------+ | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.254:31001 | | 192.0.2.1:62001 | | | | 192.0.2.1:62001 | | 192.0.2.254:31001 | | | | +---------------------+ +--------------------+ | 192.0.2.1 | | 192.0.2.254 | | | | | | NAT A | | NAT B | | (Endpoint-Dependent | | (Endpoint-Dependent| | Mapping) | | Mapping) | +---------------------+ +--------------------+ | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 192.0.2.254:31001 | | 192.0.2.1: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 communication 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 23] Internet-Draft State of P2P Communication Across NATs February 2007 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. 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. This trick is mentioned here only for historical reasons. 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 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 Srisuresh, Ford & Kegel [Page 24] Internet-Draft State of P2P Communication Across NATs February 2007 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. A number of online gaming and media-over-IP applications, including Instant Messaging application use the techniques described in the document for peer-to-peer connection establishment. Some applications may use multiple distinct rendezvous servers for registration, discovery and relay functions for load balancing, among other reasons. For example, a well-known media over IP application "Skype" uses a central public server for registration and different public servers for end-to-end relay function. 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 NATs Employing Endpoint-Dependent Mapping gained popularity with client-server applications such as web browsers, which only need to initiate outgoing connections. However, in the recent times, P2P Srisuresh, Ford & Kegel [Page 25] Internet-Draft State of P2P Communication Across NATs February 2007 applications such as Instant messaging and audio conferencing have been in wide use. NATs Employing Endpoint-Dependent Mapping are not suitable for P2P applications. 5.3. Peer discovery An application should not assume all its peers to be outside NAT boundary. As such, an application should register all its private IP addresses with rendezvous server, so it can connect to some of its peers within the same NAT boundary without having to traverse the NAT device. The rendezvous server must be on node with permanent, globally routable IP address, and be able to provide registration, discovery, and limited relay services, so an application is able to discover peer hosts even as they are behind a 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 Srisuresh, Ford & Kegel [Page 26] Internet-Draft State of P2P Communication Across NATs February 2007 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 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 rendezvous server S, providing registration, discovery and limited relay services; 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 Srisuresh, Ford & Kegel [Page 27] Internet-Draft State of P2P Communication Across NATs February 2007 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 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 public 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 Srisuresh, Ford & Kegel [Page 28] Internet-Draft State of P2P Communication Across NATs February 2007 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 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 Srisuresh, Ford & Kegel [Page 29] Internet-Draft State of P2P Communication Across NATs February 2007 [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", RFC 4787, January 2007. 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-04.txt (Work In Progress), October 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-13.txt (work in Progress), January 2007. [ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-tcp-02.txt (work in Progress), October 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. Srisuresh, Ford & Kegel [Page 30] Internet-Draft State of P2P Communication Across NATs February 2007 [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 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-13.txt (Work In Progress), October 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. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [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", Srisuresh, Ford & Kegel [Page 31] Internet-Draft State of P2P Communication Across NATs February 2007 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, February 2006. [TURN] Rosenberg, J., Mahy, R., and Huitema, C., "Traversal Using Relay NAT (TURN)", draft-ietf-behave-turn-02.txt (Work In Progress), October 2006. [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 Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 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/ Srisuresh, Ford & Kegel [Page 32] Internet-Draft State of P2P Communication Across NATs February 2007 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 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 IETF Trust (2007). 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, THE IETF TRUST 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. Srisuresh, Ford & Kegel [Page 33] Internet-Draft State of P2P Communication Across NATs February 2007 Acknowledgment Funding for the RFC Editor function is currently provided by the IETF Trust. Srisuresh, Ford & Kegel [Page 34]