diff options
Diffstat (limited to 'doc/rfc/rfc5128.txt')
| -rw-r--r-- | doc/rfc/rfc5128.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc5128.txt b/doc/rfc/rfc5128.txt new file mode 100644 index 0000000..7f7df45 --- /dev/null +++ b/doc/rfc/rfc5128.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group P. Srisuresh +Request for Comments: 5128 Kazeon Systems +Category: Informational B. Ford + M.I.T. + D. Kegel + kegel.com + March 2008 + + + State of Peer-to-Peer (P2P) Communication across + Network Address Translators (NATs) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This memo documents the various methods known to be in use by + applications to establish direct communication in the presence of + Network Address Translators (NATs) at the current time. Although + this memo is intended to be mainly descriptive, the Security + Considerations section makes some purely advisory recommendations + about how to deal with security vulnerabilities the applications + could inadvertently create when using the methods described. 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, et al. Informational [Page 1] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +Table of Contents + + 1. Introduction and Scope ..........................................3 + 2. Terminology and Conventions Used ................................4 + 2.1. Endpoint ...................................................5 + 2.2. Endpoint Mapping ...........................................5 + 2.3. Endpoint-Independent Mapping ...............................5 + 2.4. Endpoint-Dependent Mapping .................................5 + 2.5. Endpoint-Independent Filtering .............................6 + 2.6. Endpoint-Dependent Filtering ...............................6 + 2.7. P2P Application ............................................7 + 2.8. NAT-Friendly P2P Application ...............................7 + 2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .................7 + 2.10. Hairpinning ...............................................7 + 3. Techniques Used by P2P Applications to Traverse NATs ............7 + 3.1. Relaying ...................................................8 + 3.2. Connection Reversal ........................................9 + 3.3. UDP Hole Punching .........................................11 + 3.3.1. Peers behind Different NATs ........................12 + 3.3.2. Peers behind the Same NAT ..........................14 + 3.3.3. Peers Separated by Multiple NATs ...................16 + 3.4. TCP Hole Punching .........................................18 + 3.5. UDP Port Number Prediction ................................19 + 3.6. TCP Port Number Prediction ................................21 + 4. Recent Work on NAT Traversal ...................................22 + 5. Summary of Observations ........................................23 + 5.1. TCP/UDP Hole Punching .....................................23 + 5.2. NATs Employing Endpoint-Dependent Mapping .................23 + 5.3. Peer Discovery ............................................24 + 5.4. Hairpinning ...............................................24 + 6. Security Considerations ........................................24 + 6.1. Lack of Authentication Can Cause Connection Hijacking .....24 + 6.2. Denial-of-Service Attacks .................................25 + 6.3. Man-in-the-Middle Attacks .................................26 + 6.4. Security Impact from EIM-NAT Devices ......................26 + 7. Acknowledgments ................................................27 + 8. References .....................................................27 + 8.1. Normative References ......................................27 + 8.2. Informative References ....................................27 + + + + + + + + + + + + +Srisuresh, et al. Informational [Page 2] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +1. Introduction and Scope + + The 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 have created unique problems for peer-to-peer (P2P) + applications and protocols, such as teleconferencing and multiplayer + online gaming. These issues are likely to persist even into the IPv6 + world. During the transition to IPv6, some form of NAT may be + required to enable IPv4-only nodes to communicate with IPv6-only + nodes [NAT-PT], although the appropriate protocols and guidelines for + this use of NAT are still unresolved [NAT-PT-HIST]. Even a future + "pure IPv6 world" may still include firewalls, which employ similar + filtering behavior of NATs but without the address translation + [V6-CPE-SEC]. The filtering behavior interferes with the functioning + of P2P applications. For this reason, IPv6 applications that use the + techniques described in this document for NAT traversal may also work + with some firewalls that have filtering behavior similar to NATs. + + 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 en route + provide dynamic address assignment for the client machines. The + illusion of anonymity (private IP addresses) 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 illusion of anonymity and inaccessibility + is sometimes perceived as a privacy benefit. As noted in Section 2.2 + of [RFC4941], this perceived privacy may be illusory in a majority of + cases utilizing Small-Office-Home-Office (SOHO) NATs. + + 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 online gaming architecture, for example, + involves all participating application hosts contacting a publicly + addressable rendezvous server for registering themselves and + discovering peer hosts. Subsequent to the communication with the + 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 + + + +Srisuresh, et al. Informational [Page 3] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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. + + 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. + These techniques, if available, are a complement to the techniques + described in the document. [UNSAF] is in scope. + + In this document, we summarize the currently known methods by which + applications work around the presence of NAT devices, without + directly altering the NAT devices. The techniques described predate + BEHAVE documents ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]). The scope + of the document is restricted to describing currently known + techniques used to establish 2-way communication between endpoints of + an application. Discussion of timeouts, RST processing, keepalives, + and so forth that concern a running session are outside the scope of + this document. The scope is also restricted to describing techniques + for TCP- and UDP-based applications. It is not the objective of this + document to provide solutions to NAT traversal problems for + 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 public 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. As for the + notation for ports usage, all clients use ports in the range of + 1-2000 and servers use ports in the range of 20000-21000. NAT + devices use ports 30000 and above for endpoint mapping. + + Readers are urged to refer to [NAT-TERM] for information on NAT + taxonomy and terminology. Unless prefixed with a NAT type or + explicitly stated otherwise, the term NAT, used throughout this + document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has + two variations, namely, Basic NAT and Network Address Port Translator + (NAPT). Of these, NAPT is by far the most commonly deployed NAT + device. NAPT allows multiple private hosts to share a single public + IP address simultaneously. + + 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. + + + +Srisuresh, et al. Informational [Page 4] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + [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 document adapts terminology from + [BEH-UDP] to distinguish between NAT implementations. + + Listed below are terms used throughout this 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 + UDP or TCP session endpoint is represented as a tuple of (IP address, + UDP/TCP 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 + a public 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 a + public endpoint and vice versa is called Endpoint Mapping. NAT uses + 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. + +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 + + 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. + + + + + +Srisuresh, et al. Informational [Page 5] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Address and Port-Dependent Mapping + + 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. + +2.5. Endpoint-Independent Filtering + + "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. + +2.6. Endpoint-Dependent Filtering + + "Endpoint-Dependent Filtering" refers to the combination of "Address- + Dependent Filtering" and "Address and Port-Dependent Filtering" as + defined in [BEH-UDP]. + + Address-Dependent Filtering + + The NAT filters out packets not destined to 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:any previously (independently of the port used by + Y). In other words, for receiving packets from a specific + external endpoint, it is necessary for the internal endpoint to + send packets first to that specific external endpoint's IP + address. + + Address and Port-Dependent Filtering + + 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. + + + +Srisuresh, et al. Informational [Page 6] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + A NAT device employing "Endpoint-Dependent Filtering" will accept + incoming traffic to a mapped public port from only a restricted set + of external endpoints on the public network. + +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. A P2P application may use + multiple endpoints for peer-to-peer communication. + +2.8. NAT-Friendly P2P Application + + A 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. + + One common way P2P applications establish peering sessions and remain + NAT-friendly is by using a publicly addressable rendezvous server for + registration and peer discovery purposes. + +2.9. Endpoint-Independent Mapping NAT (EIM-NAT) + + An Endpoint-Independent Mapping NAT (EIM-NAT, for short) is a NAT + device employing Endpoint-Independent Mapping. An EIM-NAT can have + any type of filtering behavior. BEHAVE-compliant NAT devices are + good examples of EIM-NAT devices. A NAT device employing Address- + Dependent Mapping is an example of a NAT device that is not EIM-NAT. + +2.10. Hairpinning + + Hairpinning is defined in [BEH-UDP] as follows: + + If two hosts (called X1 and X2) are behind the same NAT and + exchanging traffic, the NAT may allocate an address on the + outside of the NAT for X2, called X2':x2'. If X1 sends traffic + to X2':x2', it goes to the NAT, which must relay the traffic + from X1 to X2. This is referred to as hairpinning. + + Not all currently deployed NATs support hairpinning. + +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. + + + + + +Srisuresh, et al. Informational [Page 7] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +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 1. + 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 + publicly addressable 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 + client from directly initiating a connection to the other. + + Registry, Discovery + Combined with Relay + Server S + 192.0.2.128:20001 + | + +----------------------------+----------------------------+ + | ^ Registry/ ^ ^ Registry/ ^ | + | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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:20001 | | 192.0.2.128:20001 | | + | | 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 1: Use of a Relay Server to communicate with peers + + 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. + + + +Srisuresh, et al. Informational [Page 8] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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 required to be EIM-NAT. 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 has sufficient I/O + bandwidth and is located correctly topology-wise. The TURN protocol + [TURN] defines a method of implementing application agnostic, + session-oriented, packet relay in a relatively secure fashion. + +3.2. Connection Reversal + + The following connection reversal technique for a direct + communication works only when one of the peers is behind a NAT device + and the other is not. For example, consider the scenario in figure + 2. Client A is behind a NAT, but client B has a publicly addressable + IP address. Rendezvous Server S has a publicly addressable IP + address and is used for the purposes of registration and discovery. + Hosts behind a NAT register their endpoints with the server. Peer + hosts discover endpoints of hosts behind a NAT using the server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Srisuresh, et al. Informational [Page 9] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Registry and Discovery + Server S + 192.0.2.128:20001 + | + +----------------------------+----------------------------+ + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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:1234 v | + | | + +--------------+ | + | 192.0.2.1 | | + | | | + | NAT A | | + +--------------+ | + | | + | ^ Registry Session(A-S) ^ | + | | 192.0.2.128:20001 | | + | | 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 2: Connection reversal using Rendezvous server + + 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 192.0.2.128 and port 20001. 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 application on B is accepting TCP + connections at port 1234. + + Now suppose client B wishes to establish a direct 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, the connection will fail. + In the first case, traffic directed to IP address 10.0.0.1 will + + + +Srisuresh, et al. Informational [Page 10] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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 is EIM-NAT, the public client can contact external + server S to determine the specific public endpoint from which to + expect Client-A-originated connection and allow connections from just + those endpoints. If the NAT device is EIM-NAT, the public client can + contact the external server S to determine the specific public + endpoint from which to expect connections originated by client A, and + allow connections from just that endpoint. If the NAT device is not + EIM-NAT, the public client cannot know the specific public endpoint + from which to expect connections originated by client A. In the + increasingly common case where both peers can be behind NATs, the + Connection Reversal method fails. Connection Reversal is not a + general solution to the peer-to-peer connection problem. If neither + a "forward" nor a "reverse" connection can be established, + applications often fall back to another mechanism such as relaying. + +3.3. UDP Hole Punching + + UDP hole punching relies on the properties of EIM-NATs to allow + appropriately designed peer-to-peer applications to "punch holes" + through the NAT device(s) enroute and establish direct connectivity + with each other, even when both communicating hosts lie behind NAT + devices. When one of the hosts is behind a NAT that is not EIM-NAT, + the peering host cannot predictably know the mapped endpoint to which + to initiate a connection. Further, the application on the host + behind non-EIM-NAT would be unable to reuse an already established + endpoint mapping for communication with different external + destinations, and the hole punching technique would fail. + + This technique was mentioned briefly in Section 5.1 of RFC 3027 + [NAT-PROT], first described in [KEGEL], and used in some recent + protocols [TEREDO, ICE]. Readers may refer to Section 3.4 for + details on "TCP hole punching". + + + +Srisuresh, et al. Informational [Page 11] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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 3. Clients A and B both have private + IP addresses and lie behind different NAT devices. Rendezvous Server + S has a publicly addressable IP address and is used for the purposes + of registration, discovery, and limited relay. Hosts behind a NAT + register their public endpoints with the server. Peer hosts discover + the public endpoints of hosts behind a NAT using the server. Unlike + in Section 3.1, peer hosts use the server to relay just connection + initiation control messages, instead of end-to-end messages. + + The peer-to-peer application running on clients A and B use UDP port + 1234. The rendezvous server S uses UDP port 20001. 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, et al. Informational [Page 12] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Registry and Discovery Combined + with Limited Relay + Server S + 192.0.2.128:20001 + | + +----------------------------+----------------------------+ + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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 | + | | | | + | EIM-NAT A | | EIM-NAT B | + +--------------+ +--------------+ + | | + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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 3: UDP Hole Punching to set up direct connectivity + + 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 endpoint 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 do 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 endpoint, then NAT A will typically discard + these messages. + + Suppose A starts sending UDP messages to B's public endpoint, and + simultaneously relays a request through server S to B, asking B to + start sending UDP messages to A's public endpoint. A's outgoing + messages directed to B's public endpoint (192.0.2.254:31000) cause + EIM-NAT A to open up a new communication session between A's private + + + +Srisuresh, et al. Informational [Page 13] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + endpoint and B's public endpoint. At the same time, B's messages to + A's public endpoint (192.0.2.1:62000) cause EIM-NAT B to open up a + new communication session between B's private endpoint and A's public + endpoint. Once the new UDP sessions have been opened up in each + direction, clients 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 + devices, 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, + 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 + distant 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 EIM-NAT, and are + therefore located in the same private IP address space, as in figure + 4. A well-known Rendezvous Server S has a publicly addressable IP + address and is used for the purposes of registration, discovery, and + limited relay. Hosts behind the NAT register with the server. Peer + hosts discover hosts behind the 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 EIM-NAT has assigned public port number 62000. Client B has + similarly established a session with S, to which the EIM-NAT has + assigned public port number 62001. + + + + + + + + + + + +Srisuresh, et al. Informational [Page 14] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Registry and Discovery Combined + with Limited Relay + Server S + 192.0.2.128:20001 + | + ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ + | 192.0.2.128:20001 | | | 192.0.2.128:20001 | + | 192.0.2.1:62000 | | | 192.0.2.1:62001 | + | + +--------------+ + | 192.0.2.1 | + | | + | EIM-NAT | + +--------------+ + | + +-----------------------------+----------------------------+ + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | + | | + | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ | + | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | + | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | + | | + | ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ | + | | 10.1.1.3:1234 | | 10.0.0.1: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 4: Use of local and public endpoints 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 endpoints as + observed by server S, and start sending each other messages at those + public endpoints. 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. This situation is referred to as + "Hairpinning", 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, consider P2P session-try1 above. When A sends a UDP + packet to B's public endpoint, the packet initially has a source + endpoint of 10.0.0.1:1234 and a destination endpoint of + + + +Srisuresh, et al. Informational [Page 15] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 192.0.2.1:62001. The NAT receives this packet, translates it to have + a source endpoint of 192.0.2.1:62000 and a destination endpoint of + 10.1.1.3:1234, and then forwards it on to B. + + Even if the NAT device supports hairpinning, this translation and + forwarding step is clearly unnecessary in this situation, and adds + latency to the dialog between A and B, besides burdening the NAT. + The solution to this problem is straightforward and is described as + follows. + + When A and B initially exchange address information through the + Rendezvous server S, they include their own IP addresses and port + numbers as "observed" by themselves, as well as their public + endpoints 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, as is the + case in figure 4 above, then the packets directed to their private + endpoints (as attempted using P2P session-try2) 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 endpoints will fail to reach each other at + all, but the clients will hopefully establish connectivity using + their respective public endpoints. 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 endpoint to reach some other, unrelated node on A's + private network, or vice versa. + + The [ICE] protocol employs this technique effectively, in that + multiple candidate endpoints (both private and public) are + communicated between peering end hosts during an offer/answer + exchange. Endpoints that offer the most efficient end-to-end + connection(s) are selected eventually for end-to-end data transfer. + +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 5. + + + + + + + + + + +Srisuresh, et al. Informational [Page 16] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Registry and Discovery Combined + with Limited Relay + Server S + 192.0.2.128:20001 + | + ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ + | 192.0.2.128:20001 | | | 192.0.2.128:20001 | + | 192.0.2.1:62000 | | | 192.0.2.1:62001 | + | + +--------------+ + | 192.0.2.1 | + | | + | EIM-NAT X | + | (Supporting | + | Hairpinning) | + +--------------+ + | + +----------------------------+----------------------------+ + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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 | + | | | | + | EIM-NAT A | | EIM-NAT B | + +--------------+ +--------------+ + | | + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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 5: Use of Hairpinning in setting up direct communication + + Suppose NAT X is an EIM-NAT 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 + + + +Srisuresh, et al. Informational [Page 17] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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 NATs A + and B, respectively. Just as in the 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 endpoints + 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 endpoints as seen by S + for their P2P communication, and rely on NAT X to provide + hairpinning. + +3.4. TCP Hole Punching + + In this section, we will discuss the "TCP hole punching" technique + used for establishing direct TCP connection between a pair of nodes + that are both behind EIM-NAT devices. Just as with UDP hole + punching, TCP hole punching relies on the properties of EIM-NATs 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 is also known sometimes as "Simultaneous TCP + Open". + + 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 6 of + the original TCP specification ([TCP]). However, "Simultaneous TCP + Open" is not implemented correctly on many systems, including NAT + devices. + + + +Srisuresh, et al. Informational [Page 18] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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 application + endpoint will continue to resend a SYN packet, until the peer does + the same from its end. + + Let us consider the case where a NAT device supports "Simultaneous + TCP Open" sessions. When a SYN packet arrives with source and + destination endpoints that correspond to a TCP session that the NAT + device believes is already active, then the NAT device would 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 address 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 to 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 an end-of-session + timeout state. This in turn would prevent the TCP connection from + being established. + + In reality, the majority of NAT devices (more than 50%) support + Endpoint-Independent Mapping and do not send ICMP errors or RSTs in + response to unsolicited incoming SYNs. As a result, the 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 + + + +Srisuresh, et al. Informational [Page 19] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + NAT and attempting to predict the public port numbers it will assign + to future sessions. The public ports assigned are often predictable + because most NATs assign mapping ports in sequence. + + Consider the scenario in figure 6. Two clients, A and B, each behind + a separate NAT, have established separate UDP connections with + rendezvous server S. Rendezvous server S has a publicly addressable + IP address and is used for the purposes of registration and + discovery. Hosts behind a NAT register their endpoints with the + server. Peer hosts discover endpoints of the hosts behind NAT using + the server. + + Registry and Discovery + Server S + 192.0.2.128:20001 + | + | + +----------------------------+----------------------------+ + | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | + | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | + | | 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:20001 | | 192.0.2.128:20001 | | + | | 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 6: UDP Port Prediction to set up direct connectivity + + + + + +Srisuresh, et al. Informational [Page 20] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + NAT A has assigned its 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 endpoints 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 + bidirectional 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 + bidirectional UDP communication channel will have been established. + + 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. + + Since in practice an application implementing this trick would still + need to work even when one of the NATs employs 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 + little chance of working if either client is behind two or more + levels of NAT and the NAT(s) closest to the client employs Endpoint- + Dependent Mapping. + +3.6. TCP Port Number Prediction + + This is a variant of the "TCP Hole Punching" technique to set up + direct peer-to-peer TCP sessions across NATs employing Address- + Dependent Mapping. + + + + + +Srisuresh, et al. Informational [Page 21] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + Unfortunately, this trick may be even more fragile and timing- + sensitive than the UDP port number prediction trick described + earlier. First, predicting the public port a NAT would assign could + be wrong. 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. + +4. Recent Work on 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 a test program [NAT-CHECK] across a number of commercial + NAT devices. The results indicate that UDP hole punching works + widely on more than 80% of the NAT devices, whereas TCP hole punching + works on just over 60% of the NAT devices tested. The results also + indicate that TCP or UDP hairpinning is not yet widely available on + commercial NAT devices, as less than 25% of the devices passed the + tests ([NAT-CHECK]) for Hairpinning. Readers may also refer to + [JENN-RESULT] and [SAIK-RESULT] for empirical test results in + classifying publicly available NAT devices. [JENN-RESULT] provides + results of NAT classification using tests spanning across different + IP protocols. [SAIK-RESULT] focuses exclusively on classifying NAT + devices by the TCP behavioral characteristics. + + [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 + 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 the Simple Traversal of the UDP + Protocol through NAT (STUN) protocol [STUN] on the same port number + + + +Srisuresh, et al. Informational [Page 22] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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) 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 applications, 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, the well-known media-over-IP + application "Skype" uses a central public server for login and + different public servers for end-to-end relay function. + +5. Summary of Observations + +5.1. TCP/UDP Hole Punching + + TCP/UDP hole punching appears to be 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 may + need to prepare to fall back to simple relaying when direct + communication cannot be established. + + The TCP/UDP hole punching technique has a caveat in that it works + only when the traversing NAT is EIM-NAT. When the NAT device enroute + is not EIM-NAT, the 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 are EIM-NAT devices. That + makes the TCP/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 TCP/UDP hole + punching technique. + +5.2. NATs Employing Endpoint-Dependent Mapping + + NATs Employing Endpoint-Dependent Mapping weren't a problem with + client-server applications such as Web browsers, which only need to + initiate outgoing connections. However, in recent times, P2P + applications such as Instant Messaging and Voice-over-IP have been in + wide use. NATs employing Endpoint-Dependent Mapping are not suitable + for P2P applications as techniques such as TCP/UDP hole punching will + not work across these NAT devices. + + + + +Srisuresh, et al. Informational [Page 23] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +5.3. Peer Discovery + + Application peers may be present within the same NAT domain or + external to the NAT domain. In order for all peers (those within or + external to the NAT domain) to discover the application endpoint, an + application may choose to register its private endpoints in addition + to public endpoints with the rendezvous server. + +5.4. Hairpinning + + Support for hairpinning is highly beneficial to allow hosts behind + EIM-NAT to communicate with other hosts behind the same NAT device + through their public, possibly translated, endpoints. Support for + hairpinning 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 hairpinning. This would be the case even + when all NAT devices in a 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 direct + communication across NAT devices. + +6.1. Lack of Authentication Can Cause Connection Hijacking + + Applications must use appropriate authentication mechanisms to + protect their connections from accidental confusion with other + connections as well as from malicious connection hijacking or + denial-of-service attacks. 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 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 Dynamic Host + Configuration Protocol (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 + + + +Srisuresh, et al. Informational [Page 24] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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, applications may be advised to assume that any IP + address they find to be suspect until they successfully establish + authenticated two-way communication. + +6.2. Denial-of-Service Attacks + + 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, 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, 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, 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 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 its own list of IP addresses it registers with the + rendezvous server. There is no way the rendezvous server can verify + + + +Srisuresh, et al. Informational [Page 25] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + the IP addresses, since they could well be legitimate private network + addresses useful to other hosts for establishing network-local + communication. The 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 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 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 EIM-NAT Devices + + 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 friendly to applications without compromising the + principle of rejecting unsolicited incoming traffic. + + + + +Srisuresh, et al. Informational [Page 26] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + 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, then + perhaps the NAT device was not to have been configured to allow + unrestricted outgoing TCP/UDP traffic in the first place. A NAT + device configured to allow communication originating from specific + applications at specific ports, or via tightly controlled + application-level gateways, may accomplish the security requirements + of such deployment scenarios. + +7. Acknowledgments + + The authors wish to thank Henrik Bergstrom, David Anderson, Christian + Huitema, Dan Wing, Eric Rescorla, and other BEHAVE work group members + for their valuable feedback on early versions of this document. The + authors also wish to thank Francois Audet, Kaushik Biswas, Spencer + Dawkins, Bruce Lowekamp, and Brian Stucker for agreeing to be + technical reviewers for this document. + +8. References + +8.1. Normative References + + [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", RFC + 2663, August 1999. + + [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, January 2007. + +8.2. Informative References + + [BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application + Design Guidelines for Traversal through Network Address + Translators", Work in Progress, March 2007. + + + + + + +Srisuresh, et al. Informational [Page 27] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + [BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, + "NAT Behavioral Requirements for ICMP protocol", Work + in Progress, February 2008. + + [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. + Srisuresh, "NAT Behavioral Requirements for TCP", Work + in Progress, April 2007. + + [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", Work in + Progress, October 2007. + + [ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive + Connectivity Establishment (ICE)", Work in Progress, + July 2007. + + [JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work + in Progress, July 2007. + + [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 A. Rayhan, "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 K. Sekar, "NAT Port + Mapping Protocol (NAT-PMP)", Work in Progress, October + 2006. + + + + + + +Srisuresh, et al. Informational [Page 28] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + [NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications + with the IP Network Address Translator", RFC 3027, + January 2001. + + [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + [NAT-PT-HIST] Aoun, C. and E. Davies, "Reasons to Move the Network + Address Translator - Protocol Translator (NAT-PT) to + Historic Status", RFC 4966, July 2007. + + [NSIS-NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E. + Davies, "NAT/Firewall NSIS Signaling Layer Protocol + (NSLP)", Work in Progress, July 2007. + + [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. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, + "Realm Specific IP: Framework", RFC 3102, October 2001. + + [SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as + https://www.guha.cc/saikat/stunt-results.php. + + [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 L. Jones, "SOCKS Protocol Version 5", RFC 1928, + March 1996. + + [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. + Mahy, "STUN - Simple Traversal of User Datagram + Protocol (UDP) Through Network Address Translators + (NATs)", RFC 3489, March 2003. + + + + +Srisuresh, et al. Informational [Page 29] + +RFC 5128 State of P2P Communication across NATs March 2008 + + + [SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work + in Progress, June 2003. + + [TCP] Postel, J., "Transmission Control Protocol", 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, October 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 P. Matthews, "Traversal + Using Relays around NAT (TURN): Relay Extensions to + Session Traversal Utilities for NAT (STUN)", Work in + Progress, January 2008. + + [UNSAF] Daigle, L., Ed., 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 + + [V6-CPE-SEC] Woodyatt, J., "Recommended Simple Security Capabilities + in Customer Premises Equipment for Providing + Residential IPv6 Internet Service", Work in Progress, + June 2007. + + + + + + + + + + + + + + + + + + +Srisuresh, et al. Informational [Page 30] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +Authors' Addresses + + Pyda Srisuresh + Kazeon Systems, Inc. + 1161 San Antonio Rd. + Mountain View, CA 94043 + USA + + Phone: (408)836-4773 + EMail: srisuresh@yahoo.com + + + Bryan Ford + Laboratory for Computer Science + Massachusetts Institute of Technology + 77 Massachusetts Ave. + Cambridge, MA 02139 + USA + + Phone: (617) 253-5261 + EMail: baford@mit.edu + Web: http://www.brynosaurus.com/ + + + Dan Kegel + Kegel.com + 901 S. Sycamore Ave. + Los Angeles, CA 90036 + USA + + Phone: 323 931-6717 + EMail: dank@kegel.com + Web: http://www.kegel.com/ + + + + + + + + + + + + + + + + + + +Srisuresh, et al. Informational [Page 31] + +RFC 5128 State of P2P Communication across NATs March 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Srisuresh, et al. Informational [Page 32] + |