BEHAVE B. Ford Internet-Draft M.I.T. Expires: April 23, 2006 P. Srisuresh Consultant D. Kegel kegel.com October 2005 Application Design Guidelines for Traversal through Network Address Translators 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 document defines best current practices by which application designers can create applications that communicate reliably and efficiently in the presence of Network Address Translators (NAT), particularly when the application has a need for "peer-to-peer"- style (P2P) communication patterns in addition to traditional client/server-style communication. There is no single NAT traversal algorithm that will make a P2P application reliably work over all deployed NATs. The guidelines described in this document allow a P2P Ford, Srisuresh, Kegel [Page 1] Internet-Draft Application design guidelines October 2005 application to work reliably over a majority of existing NATs, as well as all future NATs that conform to the behave requirements specified in companion documents. The NAT traversal techniques described here do not require the use of special proxy or relay protocols, do not require specific knowledge about the network topology or the number and type of NATs in the path, and do not require any modifications to IP or transport-layer protocols on the end hosts. Table of Contents 1. Introduction and Scope........................................ 1.1. BEHAVE-compliant versus Legacy NATs ..................... 2. General NAT Traversal Concepts ............................... 2.1. NAT Functions Influencing Traversal Logic ............... 2.2. Communication Between Peers Behind Distinct NATs ........ 2.3. Short-Circuiting Sessions on Private Networks ........... 2.4. Authenticating Peer-to-Peer Connections ................. 2.5. NAT Behavior Detection .................................. 3. NAT Traversal for UDP ........................................ 3.1. UDP Idle Timeouts ....................................... 4. NAT Traversal for TCP ........................................ 4.1. Ensuring Robustness .................................... 5. Summary of Requirements ...................................... 6. Security Considerations ...................................... 6.1. Denial-of-service attacks ............................... 6.2. Man-in-the-middle attacks ............................... 7. Normative references ......................................... 8. Informative references ....................................... 1. Introduction and Scope The present-day Internet has seen the ubiquitous deployment of network address translators (NAT), driven by a variety of practical challenges such as security and the ongoing depletion of the IPv4 address space. The asymmetric addressing and connectivity regimes established by NATs, however, cause problems for many applications, particularly those such as teleconferencing [SIP, H.323] and multiplayer on-line gaming systems. Such application protocols require "peer-to-peer" communication directly between arbitrary hosts, and not just traditional "client/server" communication between an arbitrary "client" host and a "well-known" server with a global IP address and DNS name. RFC 3235 [NAT-APPL] already proposes some NAT- friendly design guidelines for applications, but merely recommends against using peer-to-peer communication without providing a workable solution to this problem. Ford, Srisuresh, Kegel [Page 2] Internet-Draft Application design guidelines October 2005 Given the increasing demand for applications that require P2P communication, in conjunction with the ubiquity of NATs, applications are increasingly implementing and deploying various workarounds to this problem. Most of these workarounds take the form of a NAT traversal or "hole punching" algorithm, by which two "peers" lying behind one or more NATs cooperate with a well-known "rendezvous server" to set up a direct peer-to-peer communication path between them. The rendezvous server is crucial to the initial path setup but does not take part in the subsequent peer-to-peer data stream. There are many different NAT traversal algorithms already in use and currently being explored. However, due to the lack of standardization for NAT behavior up to this point, none of these algorithms can be guaranteed to work reliably over all currently deployed NATs. Further, without standardization of NAT traversal algorithms there is a strong danger that the proliferation of traversal algorithms may further compound the reliability and predictability problems that NAT created in the first place. This document focuses exclusively on NAT traversal techniques that do not require the application to communicate explicitly with the NATs in the path. Protocols that allow applications to obtain external communication endpoints through explicit interaction with NATs in the path are outside the scope of this document. Several such protocols exist and are documented elsewhere [SOCKS, RSIP, MIDCOM, UPNP], but so far none of these protocols have become widely accepted. This document defines a set of best current practices for implementing NAT traversal in applications. The specific recommendations are described at length in the sections below and later summarized concisely in Section 5. 1.1. BEHAVE-compliant versus Legacy NATs The NAT traversal practices set forth here are relatively simple to implement and are guaranteed to work reliably across all BEHAVE-compliant NATs, BEHAVE-compliant NATs are those NAT devices that conform to the behavioral requirements set out in the companion documents [BEH-TCP, BEH-UDP, BEH-ICMP]. These techniques are also known to work in practice with a wide variety of existing NATs in the most common interconnection scenarios, even when those NATs are only partially BEHAVE-compliant. To be considered a "BEHAVE-compliant application", an application MUST be designed to operate reliably when all NATs in its communication paths are BEHAVE-compliant. It is also RECOMMENDED that new applications assume that all NATs in the path are BEHAVE-compliant, since non-BEHAVE-compliant NATs are expected Ford, Srisuresh, Kegel [Page 3] Internet-Draft Application design guidelines October 2005 to be deprecated quickly. Adding complexity to applications for the purpose of handling legacy NATs risks introducing additional unpredictability into the network. This document does not specifically prohibit applications from implementing more elaborate NAT traversal algorithms that may function over a wider variety of non-BEHAVE-compliant, "legacy" NATs. Some known techniques for operating over such poorly-behaved NATs are outlined briefly in the companion document [BEH-STATE], and are described more thoroughly in [NUTSS, P2PNAT, NATBLAST, NATTRAV]. Applications implementing fancier protocols such as these, however, MUST ensure that their traversal algorithms operate just as efficiently as the ones specified here over BEHAVE-compliant NATs, and do not create new security vulnerabilities or unnecessarily burden network components in the path. REQ-1 Applications MUST be designed to operate reliably over BEHAVE- compliant NATs. New applications are RECOMMENDED to assume that all NATs in the path are BEHAVE-compliant. 2. General NAT Traversal Concepts This section describes requirements and techniques for NAT traversal that are independent of transport protocol; subsequent sections will specifically address NAT traversal for the UDP and TCP transport protocols. For more detailed background information on current practices in use by existing applications, please refer to the companion document [BEH-STATE]. 2.1. NAT Functions Influencing Traversal Logic Commonly-deployed NATs integrate two distinct logical functions, each of which interferes with peer-to-peer communication in a different way and thus requires NAT traversal support in applications. Address Translation: A NAT modifies the IP-level and often the transport-level header information in packets flowing across the boundary, in order to enable many "private" hosts behind the NAT to share the use of a smaller number of public IP addresses (often just one). Hosts behind the NAT therefore usually have no unique, permanently usable address on the public Internet, but instead can only communicate through temporary public endpoints that the NAT assigns them dynamically as a result of communication attempts initiated by hosts on the private network. Ford, Srisuresh, Kegel [Page 4] Internet-Draft Application design guidelines October 2005 When two hosts reside on two different private networks behind distinct NATs, neither of them has a permanent address that the other can reach at any time, so in order to establish peer-to-peer connections the hosts must rely on the temporary public endpoints their NATs assign them as a result of prior outgoing client/server-style communication sessions. Discovering, exchanging, and using these temporary public endpoints generally requires that the two hosts first collaborate through a well-known server on the public Internet that both hosts can reach, as described below. Filtering of Unsolicited Traffic: The filtering function in a Traditional NAT device restricts communication between a private internal network and the public Internet by dropping incoming sessions that are deemed "unsolicited". All packets arriving from the public Internet are dropped unless they are part of an existing communication session that was previously initiated by a host on the private network. When two hosts reside on two different private networks behind distinct NATs, an attempt by either host to initiate a peer-to- peer connection to the other will usually fail, even if the connection attempt is directed to the correct temporary public endpoint assigned by the opposite host's NAT, because the opposite host's NATs will interpret this attempt as unsolicited incoming traffic and reject it. NAT traversal in this case requires the two hosts to cooperate, typically by communicating initially through a well-known server on the public Internet that they can both reach, so as to make their peer-to-peer connection appear to each host's NAT as if it was initiated from within that host's own private network. The cooperation of two hosts to create a peer-to-peer connection across NATs does not constitute a violation of the filtering policy imposed by the NAT. Network firewall functionality in general is outside the scope of this document, and this document does not condone any attempts by application developers to subvert security policies that may be imposed by NATs or firewalls. 2.2. Communication Between Peers Behind Distinct NATs Although the details of NAT traversal vary from one transport protocol to another depending on how NATs recognize and handle sessions for that transport, the basic approach to NAT traversal is transport-independent. We merely assume for now that each transport Ford, Srisuresh, Kegel [Page 5] Internet-Draft Application design guidelines October 2005 uses session endpoints consisting of an (IP address, port number) pair to identify and differentiate communication sessions, and that each communication session is uniquely identified by its two endpoints. We focus here specifically on the one NAT traversal algorithm recommended here for new applications. Suppose client hosts A and B both have private IP addresses and lie behind different NATs, as shown below. Server S 18.181.0.31:1234 | +----------------------------+----------------------------+ | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 138.76.29.7:31000 | | 155.99.25.11:62000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | +------------------+ +------------------+ | 155.99.25.11 | | 138.76.29.7 | | | | | | BEHAVE-compliant | | BEHAVE-compliant | | NAT A | | NAT B | +------------------+ +------------------+ | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | | 138.76.29.7:31000 | | 155.99.25.11:62000 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234 Figure 1: Simultaneous outgoing sessions to accomplish direct-P2P A peer-to-peer application running on clients A and B, and also on a well-known rendezvous server S, each use port number 1234 at their own IP address to form their primary local communication endpoint. A and B have each initiated communication sessions from their local endpoint server S's endpoint. As a result of A's outgoing connection Ford, Srisuresh, Kegel [Page 6] Internet-Draft Application design guidelines October 2005 attempt to S, NAT A has dynamically assigned port 62000 at its own public IP address, 155.99.25.11, to A's session with S, so that S sees this session as having been initiated from the endpoint 155.99.25.11:62000, rather than from A's original private endpoint of 10.0.0.1:1234. Similarly, B's outgoing connection to S causes NAT B to assign port 31000 at its own IP address to B's session with S, thus forming B's public endpoint of 138.76.29.7:31000. Now suppose that host A wants to establish a communication session directly with host B. If A just naively initiates a new communication session to the endpoint B believes itself to be using, namely 10.1.1.3:1234, then A's connection attempt will either reach the wrong host - a different host on A's own private network that happens to have the private IP address 10.1.1.3 - or it will reach no host at all, because B's private IP address 10.1.1.3 is not routable over the Internet. Even if A learns B's temporary public endpoint, 138.76.29.7:31000, from server S, and attempts to initiate a communication session to that destination endpoint, NAT B may reject this attempt because the IP packet's source and destination endpoints do not match those of an existing session previously initiated from within the private network. The destination endpoint of A's connection attempt to B matches the source endpoint of B's existing session with S, but the source endpoint of A's connection attempt is of course different. Similarly, if B makes a unilateral connection attempt to A's public endpoint, NAT A may similarly reject B's attempt. As it turns out, this difficulty could arise even if NAT-A and NAT-B are replaced by firewalls with the standard filtering policy of rejecting unsolicited incoming communication attempts. In order to operate reliably across NATs and firewalls that reject unsolicited incoming communication, the client hosts A and B collaborate with an external server S to learn each other's public AND private endpoints, and then each of the two client hosts initiate "approximately simultaneous" connection attempts from their existing primary local endpoints (the same local endpoints they used previously for the connection to S), and directed at all of the known endpoints (public and private) for the other host. In the scenario illustrated above, A's connection attempt to B's public endpoint is interpreted by NAT A as a legitimate, outgoing session whose private source endpoint (10.0.0.1:1234) is the same as that of A's existing session with S, but whose public destination endpoint (138.76.29.7:31000) is different. If NAT A is BEHAVE-compliant, it will translate A's private source endpoint for this new session in the same way that it did for A's existing session with S, so that the new session appears on the public Internet to be a session between A's public endpoint, 155.99.25.11:62000, and B's public endpoint, Ford, Srisuresh, Kegel [Page 7] Internet-Draft Application design guidelines October 2005 138.76.29.7:31000. In similar fashion, B's "approximately simultaneous" connection attempt from its private endpoint, 10.1.1.3:1234, to A's public endpoint, 155.99.25.11:62000, results in NAT B opening a new translation session that reuses the existing public endpoint for B, 138.76.29.7:31000, which NAT B previously assigned to B's session with S. NAT B is now set up to allow communication between A's public endpoint and B's private endpoint, and on the public Internet this session has the endpoints 155.99.25.11:62000 and 138.76.29.7:31000, the same as the endpoints of the session that A initiated above toward B's public endpoint. Both NATs are thus set up to permit communication between these two public endpoints, translating and forwarding the traffic comprising this session to the respective client hosts on the private networks as appropriate. This traversal technique relies on certain aspects of NAT behavior described fully in the companion documents [BEH-GEN, BEH-TCP, BEH- UDP]. The technique also relies on the transport protocol allowing a connection to be initiated actively by two endpoints, rather than asymmetrically in traditional client/server fashion. Fortunately both of the two ubiquitous transports, TCP and UDP, allow symmetric connection initiation in this way. REQ-2 Application hosts wishing to establish peer-to-peer communication MUST support NAT traversal by implementing the "approximately simultaneous connection attempts" technique described above with the help of a mutually accessible registry or "rendezvous server" in the external network. 2.3. Short-Circuiting Sessions on Private Networks Although the network topology illustrated in the figure above is typical of the situation seen by P2P applications, it is by no means the only possible scenario. Only one of the client hosts may be behind, or one or more of the clients may be located behind two or more levels of NATs, any number of which may be shared between the two clients. The general NAT traversal algorithm described above will work reliably in all of the common topological scenarios provided that the NATs involved are BEHAVE-compliant. One other particularly common scenario is worth special consideration however. In the situation illustrated below the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address space. Ford, Srisuresh, Kegel [Page 8] Internet-Draft Application design guidelines October 2005 Server S 18.181.0.31:1234 | ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ | 18.181.0.31:1234 | | | 18.181.0.31:1234 | | 155.99.25.11:62000 | | | 155.99.25.11:62001 | | +------------------+ | 155.99.25.11 | | | | Behave-Compliant | | NAT | +------------------+ | +-----------------------------+----------------------------+ | | | | | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1 (B-A)^ | | | 10.1.1.3:1234 | | 10.0.0.1:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A)^ | | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234 Figure 2: Register private identity & NAT identity with Relay server In this scenario, client A has established a session with well-known server S as before, 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. Suppose that A and B use the NAT traversal technique outlined above to establish a communication channel using server S as an introducer. If A and B only attempt simultaneous connections to each other's public endpoints, 155.99.25.11:62001 and 155.99.25.11:62000 respectively, then their connection attempts will succeed only if the NAT supports hairpin translation, as described in [BEH-STATE, BEH-TOP]. Although hairpin translation is required for a NAT to be considered fully BEHAVE-compliant, this feature is not yet widely supported by Ford, Srisuresh, Kegel [Page 9] Internet-Draft Application design guidelines October 2005 commonly deployed NATs at the time of this writing. Additionally, the resulting connection between A and B will be sub-optimal in this case because all traffic will unnecessarily pass through and be translated by the NAT, whereas the two endpoint hosts are perfectly capable of communicating directly on their common IP network without the NAT intervention. To address this problem, it is recommended that P2P applications make simultaneous connection attempts both to the private endpoints and the public endpoints of the desired peer, and use whichever connection succeeds first in establishing bi-directional communication between the correct peers. If the two client hosts happen to be located in the same private network, their connection attempt using each others' private endpoints is likely to succeed first because it follows a shorter network path not involving the NAT. If the NAT does not support hairpin translation, the connection attempts using the hosts' private endpoints will be the only one to succeed. REQ-3 Applications implementing NAT traversal MUST exchange their local IP addresses and transport-level port numbers as known to themselves, in addition to the global IP address and port number tuples they register with the rendezvous server. Further, peering applications MUST make "approximately simultaneous" connection attempts to each other using both private and external communication endpoints. In addition, applications SHOULD exchange and make connection attempts to multiple endpoint addresses for each peer, in case the hosts have multiple IP addresses or are registered with multiple rendezvous servers at different locations in the network topology. 2.4. Authenticating Peer-to-Peer Connections It is extremely important not only for security but also for general robustness that applications implementing a NAT traversal protocol authenticate any peer-to-peer connections they establish, using some higher-level application-specific notion of host or user identity. To operate reliably and securely, applications MUST consider any IP addresses and port numbers they use for communication with other hosts to be merely "locators" for hosts, serving as hints indicating how the desired host might be reached, and not as a reliable "identifier" for the target host or user. Applications MUST NOT in particular merely assume that the first communication attempt that establishes transport-level connectivity and elicits a response from a particular target endpoint (IP address and port number) necessarily represents a connection to the desired Ford, Srisuresh, Kegel [Page 10] Internet-Draft Application design guidelines October 2005 host. Consider the following topological scenario, for example, which is in fact extremely common in today's Internet. Server S 18.181.0.31:1234 | +----------------------------+----------------------------+ | | | | +------------------+ +------------------+ | 155.99.25.11 | | 138.76.29.7 | | | | | | BEHAVE-compliant | | BEHAVE-compliant | | NAT A | | NAT B | +------------------+ +------------------+ | | -------+----+-----------+ | | | | Client X Client A Client B 10.1.1.10:1234 10.0.0.11:1234 10.1.1.10:1234 Figure 3: Clients behind different NATs can bear same local endpoint In this scenario, suppose that NAT A and NAT B are both "off-the- shelf" consumer NAT routers from the same vendor, which the vendor has configured by default to act as DHCP servers that hand out private IP addresses starting at 10.1.1.10. (Most users of such devices know little or nothing about IP addresses, and therefore are very unlikely to reconfigure their NATs any more than is necessary to get them to connect to the Internet.) As before, Client A wishes to establish a peer-to-peer connection with Client B with the help of Server S. Client A happened to receive private IP address 10.1.1.11 on NAT A's private network, after Client X had already been assigned private IP address 10.1.1.10. Client B happens to be the only host on NAT B's private network, and thus received the first available private IP address, 10.1.1.10. Client X happens to be running the same P2P application as is running on clients A and B, and thus has port 1234 allocated and ready to initiate and accept peer-to-peer connections. Suppose Client A follows the NAT traversal approach described above to establish a peer-to-peer session with Client B. As per the suggested protocol, A and B each make approximately simultaneous connection attempts both to each other's public and private endpoints. B's connection attempt to A's private endpoint, 10.1.1.11:1234, will of course fail because there is no host 10.1.1.11 on NAT B's private network and that IP address is not globally routable. A's connection attempt to B's public endpoint and Ford, Srisuresh, Kegel [Page 11] Internet-Draft Application design guidelines October 2005 B's connection attempt to A's public endpoint will eventually succeed in establishing the desired peer-to-peer connection if the two NATs are BEHAVE-compliant. However, A's connection attempt to B's private endpoint, 10.1.1.10:1234, will succeed at the transport layer but connect to the wrong host: namely client X, the host on NAT A's private network that happens to have the same private IP address as B does on NAT B's network. Furthermore, this bogus connection to client X is likely to succeed much more quickly than the actually desired connection to client B, because X is on the same private network as A. If the application running on client A does not properly authenticate its peer-to-peer connections using some higher- level notion of identity that is independent of IP address, then client A is likely to assume that its transport-level connection to X is the desired peer-to-peer connection, cancel its attempt to connect to B's public endpoint, and subsequently become very confused when the peer it connected to fails to behave like client B. Given the prevalence of NAT routers that are pre-configured by their vendors to hand out private IP addresses via DHCP in more-or-less deterministic fashion from a standard private IP address block, different hosts on different private networks are very likely to have the same private IP addresses, making the above scenario extremely likely for P2P applications to encounter. P2P applications therefore MUST authenticate their transport-layer connections before assuming they have successfully connected to the desired host. Strong cryptographic authentication using standard algorithms is of course preferred. REQ-4 Applications making peer-to-peer connections MUST authenticate each other using some higher-level application-specific notion of identity, before concluding that a successfully-established transport-level connection has actually reached the intended host. 2.5. NAT Behavior Detection In many existing NAT traversal protocols for both TCP and UDP, each client attempts to determine experimentally certain properties of any NATs it is located behind before attempting to establish peer-to-peer connections with other clients. For example, even when a NAT does not re-use the same public endpoint for all sessions involving a given private endpoint as required for BEHAVE compliance, it is sometimes possible to predict which port the NAT will assign to a new session. Extensive testing of various existing NATs, however, has revealed that there is no truly robust way a client can predict how a legacy NAT will behave in the future based on such experimental tests. Some Ford, Srisuresh, Kegel [Page 12] Internet-Draft Application design guidelines October 2005 legacy NATs behave differently depending on the local port number the application is using on the client, and can even switch behaviors dynamically depending on unpredictable timing and network conditions. Therefore, while applications MAY use such experimental tests in an attempt to make peer-to-peer connections work across a wider variety of legacy NATs, they MUST ensure that such methods do not interfere with the performance or reliability of the application over BEHAVE- compliant NATs. REQ-5 Applications SHOULD NOT attempt to predict the future behavior of NATs in the path through empirical tests. If they do, applications MUST ensure that any such tests do not delay or otherwise impede the efficiency of NAT traversal over BEHAVE- compliant NATs. 3. NAT Traversal for UDP NAT traversal for UDP, also commonly known as UDP "hole punching", was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and first publicly documented informally on the Internet [KEGEL]. Because of UDP's simplicity and its connectionless nature, NAT traversal for UDP is somewhat simpler, more widely understood, and hence more universally supported by NATs and applications than is NAT traversal for TCP, though the principles are the same for both transports. NAT traversal for UDP has been used in several recent experimental Internet protocols [TEREDO, ICE] along with various proprietary or non-standardized protocols. The NAT traversal approach recommended in this document is also described informally in [P2PNAT], and other variations of hole punching are explored more thoroughly in other recent research papers [NUTSS, NATBLASTER, NATTRAV]. To set up a peer-to-peer UDP session between two clients A and B, we assume that the clients have each bound to a particular primary local UDP port, and that the clients have each initiated a UDP session from this primary local port to a well-known rendezvous server S, as described earlier. Each client then learns the other's public and private UDP endpoints from the server S, and simply begins sending UDP datagrams, from their respective primary local ports (the same ports they used to contact S), to all of the other client's known endpoints. If one or both of the clients is behind a BEHAVE- compliant NAT, the outgoing datagrams from each client will "open a hole" through a firewall or establish a translation session through the NAT, causing the NAT to forward subsequent incoming datagrams from the opposite client as desired. 3.1. UDP Idle Timeouts Ford, Srisuresh, Kegel [Page 13] Internet-Draft Application design guidelines October 2005 Because of its inherently connectionless nature, NATs have no fully reliable way to determine when a UDP communication session crossing the NAT has terminated, other than simply by assuming the session is over if it observes a sufficiently long idle period. Applications whose UDP communication sessions may experience long idle periods must therefore account for this idle timeout. As specified in [BEH-UDP], any BEHAVE-compliant NAT is required to have an idle timeout of at least two minutes, but idle timeouts as small as 30 seconds have been observed in existing NATs. Additionally, BEHAVE-compliant NATs are only required to reset the idle timer on the observance of outgoing traffic leaving the private network; the NAT may ignore incoming traffic for this purpose, in order to prevent external hosts from being able to hold UDP sessions open unilaterally and thus consume NAT resources indefinitely. BEHAVE-compliant NATs are required to support Address Restricted Cone NAT Behavior, which essentially resets the idle timer for ALL sessions for a particular binding (i.e., involving a particular private port) whenever outbound traffic is seen from that private port on ANY such session. However, there are many existing NATs which exhibit Port Restricted Cone NAT behavior. Cone NAT devices maintain UDP idle timers independently on each session. A NAT's UDP idle timeouts affects P2P applications implementing NAT traversal in two main ways: Rendezvous Server Registration Sessions: Client hosts implementing UDP hole punching typically register with one or more well-known rendezvous servers, S in the above scenarios, and expect to be notified by S when a second client wishes to open a peer-to-peer connection to the first. However, if a NAT's UDP idle timer times out while the first client is waiting for incoming connections, then the client will not receive the notification from S of the second client's desire to connect. The client therefore MUST send periodic outbound "keep-alive" packets to the rendezvous server(s) in order to ensure that the registration session remains open while the application is active. If a UDP application merely desires to be compatible with BEHAVE- compliant NATs, then its outbound keep-alive packets need not elicit a response from the server unless the application is concerned about detecting if the server disappears. Also, if a UDP application maintains active registration sessions with more than one well-known rendezvous server simultaneously, then it is sufficient for the application to send outbound keep-alive packets on only one of these registration sessions as long as all of them Ford, Srisuresh, Kegel [Page 14] Internet-Draft Application design guidelines October 2005 were initiated from the same local UDP port. If the application desires to function reliably over a broader range of existing NATs, however, then it may wish to send periodic outbound keep-alives to each of the rendezvous servers it is registered with, and ensure that these keep-alives elicit responses from those servers. This behavior increases compatibility at the expense of consuming additional network bandwidth. REQ-6 Applications wishing to accept connections from other peers after registering via UDP with one or more rendezvous servers MUST send periodic outgoing UDP "keep-alive" packets to at least one rendezvous server, at least once within the BEHAVE-compliant NAT UDP timeout (2 minutes). Peer-to-Peer Sessions: Once two client hosts have used a rendezvous server to set up a peer-to-peer UDP communication session between them, this peer-to- peer session is similarly vulnerable to being closed by any of the NATs along the path if it goes idle for too long. If the application is only concerned about compatibility with BEHAVE- compliant NATs and already sends regular outbound keep-alives to a registration server as described above, then those keep-alives are sufficient to maintain the peer-to-peer sessions the application has opened, as long as those peer-to-peer sessions involve the same local UDP endpoint. If an application desires to be more broadly compatible with existing NATs such as Port Restricted Cone NATs, and has only a few peer-to-peer sessions active at once, then the application may use keep-alives for each of the active peering sessions to keep the sessions open. If an application has many idle peer-to-peer sessions at once, however, then it is recommended that the application NOT use keep-alives on peer-to- peer sessions, but instead simply be prepared to re-establish peer-to-peer sessions as needed after an idle period, by simply re-running the NAT traversal protocol via the original rendezvous server. REQ-7 Applications whose peer-to-peer UDP sessions may go idle for more than the BEHAVE-compliant NAT UDP timeout (2 minutes) at a time, SHOULD re-run the original NAT traversal protocol in an attempt to re-establish the peer-to-peer session, if they detect that connectivity has been lost. 4. NAT Traversal for TCP Ford, Srisuresh, Kegel [Page 15] Internet-Draft Application design guidelines October 2005 NAT traversal for TCP, or "TCP hole punching," is not yet as well- understood or widely supported as is UDP hole punching. Nevertheless, the general technique described in section 2 above works for TCP as well as UDP, as long as any NATs in the path are well-behaved. The recommended NAT traversal algorithm for TCP, described here, makes use of the symmetric TCP connection initiation feature of TCP as specified in RFC 793 [TCP] and RFC 1122 [REQ-COMM]. This algorithm is guaranteed to work reliably as long as all NATs in the path are BEHAVE-compliant [BEH-TCP], and as long as the end-hosts correctly implement the TCP protocol. Other more complex TCP hole punching algorithms have been developed and explored elsewhere [NUTSS, NATBLAST, NATTRAV]. These algorithms use various tricks to work around the nonstandard behaviors of many existing NATs, and/or to work around bugs in the TCP implementations of certain existing operating systems. Applications MAY implement more complex algorithms such as these in order to achieve broader compatibility with existing NATs and hosts, but applications MUST ensure that any such alternative algorithm still works reliably and efficiently over BEHAVE-compliant NATs without substantially burdening the network and any NATs on the path. To prepare for TCP NAT traversal, a P2P client application first binds to an arbitrary local port, which becomes the application's primary local port, and then uses that port both to listen for incoming peer-to-peer connections, and to initiate outgoing connections to rendezvous servers and other peers. Because standard sockets APIs usually associate TCP sockets with individual TCP sessions rather than with a local port as with UDP, the application must typically open multiple TCP sockets - one listen socket and one or more connect-sockets - and explicitly bind them to the same local port, using a special socket option usually named SO_REUSEADDR or SO_REUSEPORT. Once the TCP application has bound to its primary local port, started listening on it, and opened connections to one or more rendezvous servers, it can initiate or accept peer-to-peer connections as follows. If two clients, A and B, wish to establish a peer-to-peer connection with the help of a common rendezvous server S, they first exchange their public and private TCP endpoints through S as described earlier in section 2. Each client then simultaneously attempts to initiate outgoing TCP connections from its primary local port to each of the opposite client's known TCP endpoints (public and private). As long as any NATs in the path are well-behaved, each client's outgoing TCP connection attempt will open firewall and/or translation sessions through any NATs it is located behind, eventually resulting in a working bi-directional TCP connection Ford, Srisuresh, Kegel [Page 16] Internet-Draft Application design guidelines October 2005 through all intervening NATs on the path, in the same way as for UDP. Because of timing dependencies and differences in TCP implementations, applications may observe slightly different (but functionally equivalent) results when a P2P connection is successfully established using this method. If client B is not actually located behind a firewall or NAT, for example, and client A's first attempt to connect directly to B reaches B before its peer- to-peer connection request relayed through S reaches B, then B will accept A's connection via its outstanding listen socket, in traditional client/server fashion. Even if A's connection request (SYN packet) to B crosses B's corresponding request to A, resulting in a TCP simultaneous open at the protocol level, some end-host operating systems may still "deliver" the resulting connection to the application via the application's outstanding listen socket for its primary local port, rather than via the socket by which the application explicitly initiated a connection to the opposite client. The application must be prepared to handle all such possible cases gracefully. REQ-8 Application hosts implementing peer-to-peer communication via TCP SHOULD simultaneously listen for incoming peer-to-peer connections and open connections to rendezvous servers and other peers from the same primary port. REQ-9 Applications SHOULD establish peer-to-peer TCP connections by making "approximately simultaneous" connection attempts from each peer to all of the known endpoint addresses (both original and translated) for the opposite peer's primary port. Applications MAY alternatively establish peer-to-peer TCP connections via other, asymmetric methods if one or both endpoint hosts does not correctly support simultaneous TCP open. 4.1. Ensuring Robustness Some existing NATs actively reject an apparently-unsolicited incoming TCP connection by sending back TCP RST or ICMP error packets to the connection initiator, rather than simply by dropping the incoming SYN. This behavior can cause one of the clients to observe bogus timing-dependent connection failures. While this NAT behavior is deprecated and not allowed for BEHAVE-compliant NATs, P2P applications can fairly easily make themselves robust against this behavior. If a client's attempt to initiate a peer-to-peer connection fails with a "Connection Refused" or "Network Unreachable" or similar network-related error before some application-defined peer-to-peer connection timeout has expired, the application SHOULD simply retry the same outgoing connection attempt. The application Ford, Srisuresh, Kegel [Page 17] Internet-Draft Application design guidelines October 2005 MUST ensure that at least one second has passed between each such retry, however, in order to avoid accidentally flooding the network with SYNs if the cause of the error is close to the client and is thus reported very quickly after each attempt. REQ-10 Applications SHOULD re-try peer-to-peer TCP connection attempts that fail due to network conditions other than timeout, but MUST NOT re-try connecting to a given peer more than once per second. 5. Summary of Requirements An application that supports all of the mandatory requirements of this specification (the "MUST" requirements), is "compliant with this specification" or "BEHAVE-compliant". An application that supports all of the mandatory and optional recommendations of this specification (including the "SHOULD" or "RECOMMENDED" ones) is "fully compliant with all the mandatory and recommended requirements of this specification." REQ-1 Applications MUST be designed to operate reliably over BEHAVE- compliant NATs. New applications are RECOMMENDED to assume that all NATs in the path are BEHAVE-compliant. REQ-2 Application hosts wishing to establish peer-to-peer communication with the help of a mutually accessible registry or "rendezvous server", MUST support traversal of NATs that may be in the paths of one or both hosts, by implementing the "approximately simultaneous connection attempts" technique described above. REQ-3 Applications implementing NAT traversal MUST exchange both their IP addresses and transport-level port numbers as known to themselves, and their IP addresses and port numbers as known to the common rendezvous server, and make "approximately simultaneous" connection attempts to each other using both sets of communication endpoints. Applications SHOULD additionally be able to exchange and make connection attempts to more than two endpoints for each peer, in case the hosts have multiple IP addresses or are registered with multiple rendezvous servers at different locations in the network topology. REQ-4 Applications making peer-to-peer connections MUST authenticate each other using some higher-level application-specific notion of identity, before concluding that a successfully-established transport-level connection has actually reached the intended host. Ford, Srisuresh, Kegel [Page 18] Internet-Draft Application design guidelines October 2005 REQ-5 Applications SHOULD NOT attempt to predict the future behavior of NATs in the path through empirical tests. If they do, applications MUST ensure that any such tests do not delay or otherwise impede the efficiency of NAT traversal over BEHAVE- compliant NATs. REQ-6 Applications wishing to accept connections from other peers after registering via UDP with one or more rendezvous servers MUST send periodic outgoing UDP "keep-alive" packets to at least one rendezvous server, at least once within the BEHAVE-compliant NAT UDP timeout (2 minutes). REQ-7 Applications whose peer-to-peer UDP sessions may go idle for more than the BEHAVE-compliant NAT UDP timeout (2 minutes) at a time, SHOULD re-run the original NAT traversal protocol in an attempt to re-establish the peer-to-peer session, if they detect that connectivity has been lost. REQ-8 Application hosts implementing peer-to-peer communication via TCP SHOULD simultaneously listen for incoming peer-to-peer connections and open connections to rendezvous servers and other peers from the same primary port. REQ-9 Applications SHOULD establish peer-to-peer TCP connections by making "approximately simultaneous" connection attempts from each peer to all of the known endpoint addresses (both original and translated) for the opposite peer's primary port. Applications MAY alternatively establish peer-to-peer TCP connections via other, asymmetric methods if one or both endpoint hosts does not correctly support simultaneous TCP open. REQ-10 Applications SHOULD re-try peer-to-peer TCP connection attempts that fail due to network conditions other than timeout, but MUST NOT re-try connecting to a given peer more than once per second. 6. Security Considerations This document does not inherently create new security issues. This section describes security risks the applications could inadvertently create in attempting to support P2P communication across NAT devices. 6.1. Denial-of-service attacks P2P applications and the public registry servers that support them Ford, Srisuresh, Kegel [Page 19] Internet-Draft Application design guidelines October 2005 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 registry servers must avoid taking any action requiring significant local processing or storage resources until authenticated two-way communication is established. To avoid being used as a tool for denial-of-service attacks, P2P applications and servers must minimize the amount and rate of traffic they send to any newly-discovered IP address until after authenticated two-way communication is established with the intended target. For example, P2P applications that register with a public rendezvous server can claim to have any private IP address, or perhaps multiple IP addresses. A well-connected host or group of hosts that can collectively attract a substantial volume of P2P connection attempts (e.g., by offering to serve popular content) could mount a 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.2. Man-in-the-middle attacks Any network device on the path between a P2P client and a rendezvous server can mount a variety of man-in-the-middle attacks by pretending to be a NAT. For example, suppose host A attempts to register with rendezvous server S, but a network-snooping attacker is able to observe this registration request. The attacker could then flood server S with requests that are identical to the client's original request except with a modified source IP address, such as the IP address of the attacker itself. If the attacker can convince the server to register the client using the attacker's IP address, then the attacker can make itself an active component on the path of all future traffic from the server AND other P2P hosts to the original client, even if the attacker was originally only able to snoop the path from the client to the server. The client cannot protect itself from this attack by authenticating its source IP address to the rendezvous server, because in order to be NAT-friendly the application must allow intervening NATs to change the source address silently. This Ford, Srisuresh, Kegel [Page 20] Internet-Draft Application design guidelines October 2005 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. 7. Normative References [BEH-ICMP] P. Srisuresh, B. Ford, and S. Sivakumar, "NAT Behavioral Requirements for ICMP", draft-srisuresh-behave-nat-icmp-00.txt (Work In Progress), October 2005. [BEH-TCP] P.Srisuresh, S. Sivakumar, K. Biswas, and B. Ford, "NAT Behavioral Requirements for TCP", draft-sivakumar-behave-nat-tcp-req-02.txt (Work In Progress), October 2005. [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp-04.txt (Work In Progress), September 2005. [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. http://www.alumni.caltech.edu/~dank/peer-nat.html [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. 8. Informative References [BEH-STATE] P. Srisuresh, B. Ford, and D. Kegel, "State of Peer-to-Peer (P2P) communication across Network Address Translators (NATs)", draft-srisuresh-behave-p2p-state-01.txt (Work In Progress), October 2005. [BEH-TOP] B. Ford and P. Srisuresh, "Topological Complications from Network Address Translation", draft-ford-behave-top-00.txt (Work In Progress), February 2005. [H.323] "Packet-based Multimedia Communications Systems", ITU-T Recommendation H.323, July 2003. Ford, Srisuresh, Kegel [Page 21] Internet-Draft Application design guidelines October 2005 [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-06.txt (work in Progress), October 2005. [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [NATBLAST] Andrew Biggadike and Daniel Ferullo and Geoffrey Wilson and Adrian Perrig, "NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs", ACM SIGCOMM Asia Workshop, April 2005. [NUTSS] Saikat Guha and Yutaka Takeday and Paul Francis, "NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity", SIGCOMM 2004 Workshops, August 2004. [NATTRAV] Jeffrey L. Eppinger, "TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem", Carnegie Mellon Tech Report CMU-ISRI-05-104, January 2005. [P2PNAT] Bryan Ford, Pyda Srisuresh, and Dan Kegel, "Peer-to-Peer Communication Across Network Address Translators", USENIX Annual Technical Conference, April 2005. [REQ-COMM] R. Braden, Editor, "Requirements for Internet Hosts - Communication Layers", RFC 1122, October 1989. [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", draft-ietf-ngtrans-shipworm-08.txt (Work In Progress), September 2002. Ford, Srisuresh, Kegel [Page 22] Internet-Draft Application design guidelines October 2005 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. http://www.upnp.org/standardizeddcps/igd.asp Author's Address Bryan Ford Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 U.S.A. Phone: (617) 253-5261 E-mail: baford@mit.edu Web: http://www.brynosaurus.com/ Pyda Srisuresh Consultant 20072 Pacifica Dr. Cupertino, CA 95014 U.S.A. Phone: (408)836-4773 E-mail: srisuresh@yahoo.com Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 Phone: (323) 931-6717 E-mail: dank@kegel.com Web: http://www.kegel.com/ Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED Ford, Srisuresh, Kegel [Page 23] Internet-Draft Application design guidelines October 2005 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ford, Srisuresh, Kegel [Page 24]