idnits 2.17.1 draft-ietf-behave-p2p-state-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1416. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 35 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-06 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-04 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-02 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-15 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-05 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended status: INFORMATIONAL 3 Internet Draft P. Srisuresh 4 Expires: May 18, 2008 Kazeon Systems 5 B. Ford 6 M.I.T. 7 D. Kegel 8 kegel.com 9 November 19, 2007 11 State of Peer-to-Peer(P2P) Communication 12 Across Network Address Translators(NATs) 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This memo documents the various methods known to be in use by 41 applications to establish direct communication in the presence 42 of Network Address Translators (NATs) at the current time. Although 43 this memo is intended to be mainly descriptive, the Security 44 Considerations section makes some purely advisory recommendations 45 about how to deal with security vulnerabilities the applications 46 could inadvertently create when using the methods described. This 47 memo covers NAT traversal approaches used by both TCP and UDP 48 based applications. This memo is not an endorsement of the methods 49 described, but merely an attempt to capture them in a document. 51 Table of Contents 53 1. Introduction and Scope ....................................... 54 2. Terminology and Conventions Used ............................. 55 2.1. Endpoint ................................................ 56 2.2. Endpoint Mapping ........................................ 57 2.3. Endpoint-Independent Mapping ............................ 58 2.4. Endpoint-Dependent Mapping .............................. 59 2.5. Endpoint-Independent Filtering .......................... 60 2.6. Endpoint-Dependent Filtering ............................ 61 2.7. P2P Application ......................................... 62 2.8. NAT-friendly P2P Application ............................ 63 2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .............. 64 2.10. Hairpinning ............................................ 65 3. Techniques Used by P2P Applications to Traverse NATs ......... 66 3.1. Relaying ................................................ 67 3.2. Connection Reversal ..................................... 68 3.3. UDP Hole Punching ....................................... 69 3.3.1. Peers Behind Different NATs ...................... 70 3.3.2. Peers Behind Same NAT ............................ 71 3.3.3. Peers Separated by Multiple NATs ................. 72 3.4. TCP Hole Punching ....................................... 73 3.5. UDP Port Number Prediction .............................. 74 3.6. TCP Port Number Prediction .............................. 75 4. Recent Work on NAT Traversal ................................. 76 5. Summary of Observations ...................................... 77 5.1. TCP/UDP Hole Punching ................................... 78 5.2. NATs Employing Endpoint-Dependent Mapping ............... 79 5.3. Peer Discovery .......................................... 80 5.4. Hairpinning ............................................. 81 6. Security Considerations ...................................... 82 6.1. Lack of Authentication Can Cause Connection Hijacking ... 83 6.2. Denial-of-service Attacks ............................... 84 6.3. Man-in-the-middle Attacks ............................... 85 6.4. Security Impact From EIM-NAT Devices .................... 86 7. IANA Considerations .......................................... 87 8. Acknowledgments .............................................. 88 9. Normative References ......................................... 89 10. Informative References ....................................... 91 [RFC Editor: Please add page numbers after you finish reformatting.] 92 1. Introduction and Scope 94 Present day Internet has seen ubiquitous deployment of network 95 address translators (NATs). There are a variety of NAT devices and 96 a variety of network topologies utilizing NAT devices in 97 deployments. The asymmetric addressing and connectivity regimes 98 established by these NAT devices has created unique problems for 99 peer-to-peer (P2P) applications and protocols, such as 100 teleconferencing and multiplayer on-line gaming. These issues are 101 likely to persist even into the IPv6 world and in deployments 102 using [NAT-PT]. This is because, even the IPv6 world may include 103 firewalls, which employ similar filtering behavior of NATs but 104 without the address translation [V6-CPE-SEC]. The filtering 105 behavior interferes with the functioning of P2P applications. 106 For this reason, IPv6 applications that use the techniques descried 107 in this document for NAT traversal may also work with some firewalls 108 that have filtering behavior similar to NATs. 110 Currently deployed NAT devices are designed primarily around the 111 client/server paradigm, in which relatively anonymous client machines 112 inside a private network initiate connections to public servers with 113 stable IP addresses and DNS names. NAT devices encountered enroute 114 provide dynamic address assignment for the client machines. The 115 illusion of anonymity (private IP addresses) and inaccessibility of 116 the internal hosts behind a NAT device is not a problem for 117 applications such as web browsers, which only need to initiate 118 outgoing connections. This illusion of anonymity and inaccessibility 119 is sometimes perceived as a privacy benefit. As noted in section 120 2.2 of [RFC3041], this perceived privacy may be illusory in 121 majority of cases utilizing Small-Office-Home-Office (SOHO) NATs. 123 In the peer-to-peer paradigm, Internet hosts that would normally be 124 considered "clients" not only initiate sessions to peer nodes, but 125 also accept sessions initiated by peer nodes. The initiator and the 126 responder might lie behind different NAT devices with neither 127 endpoint having a permanent IP address or other form of public 128 network presence. A common on-line gaming architecture, for example, 129 involves all participating application hosts contacting a 130 publicly addressable rendezvous server for registering themselves 131 and discovering peer hosts. Subsequent to the communication with 132 rendezvous server, the hosts establish direct connections with each 133 other for fast and efficient propagation of updates during game play. 134 Similarly, a file sharing application might contact a well-known 135 rendezvous server for resource discovery or searching, but establish 136 direct connections with peer hosts for data transfer. NAT devices 137 create problems for peer-to-peer connections because hosts behind a 138 NAT device normally have no permanently visible public ports on the 139 Internet to which incoming TCP or UDP connections from other peers 140 can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue. 142 NAT traversal strategies that involve explicit signaling between 143 applications and NAT devices, namely [NAT-PMP], [NSIS-NSLP], 144 [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this 145 document. These techniques, if available, are a complement to the 146 techniques described in the document. [UNSAF] is in scope. 148 In this document, we summarize the currently known methods by which 149 applications work around the presence of NAT devices, without 150 directly altering the NAT devices. The techniques described predate 151 BEHAVE documents ([BEH-UDP], [BEH-TCP] and [BEH-ICMP]). The scope 152 of the document is restricted to describing currently known 153 techniques used to establish 2-way communication between endpoints 154 of an application. Discussion of timeouts, RST processing, 155 keepalives and so forth that concern a running session are outside 156 the scope of this document. The scope is also restricted to 157 describing techniques for TCP and UDP based applications. It is not 158 the objective of this document to provide solutions to NAT traversal 159 problem for applications in general [BEH-APP] or to a specific 160 class of applications [ICE]. 162 2. Terminology and Conventions Used 164 In this document, the IP addresses 192.0.2.1, 192.0.2.128, and 165 192.0.2.254 are used as example public IP addresses [RFC3330]. 166 Although these addresses are all from the same /24 network, this 167 is a limitation of the example addresses available in [RFC3330]. 168 In practice, these addresses would be on different networks. As 169 for the notation for ports usage, all clients use ports in the 170 range of 1-2000 and servers use ports in the range of 171 20000-21000. NAT devices use ports 30000 and above for endpoint 172 mapping. 174 Readers are urged to refer [NAT-TERM] for information on NAT 175 taxonomy and terminology. Unless prefixed with a NAT type or 176 explicitly stated otherwise, the term NAT, used throughout the 177 document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT 178 has two variations, namely, Basic NAT and Network Address Port 179 Translator (NAPT). Of these, NAPT is by far the most commonly 180 deployed NAT device. NAPT allows multiple private hosts to share a 181 single public IP address simultaneously. 183 An issue of relevance to P2P applications is how the NAT behaves 184 when an internal host initiates multiple simultaneous sessions from 185 a single endpoint (private IP, private port) to multiple distinct 186 endpoints on the external network. 188 [STUN] further classifies NAT implementations using the terms 189 "Full Cone", "Restricted Cone", "Port Restricted Cone" and 190 "Symmetric". Unfortunately, this terminology has been the source of 191 much confusion. For this reason, this draft adapts terminology from 192 [BEH-UDP] to distinguish between NAT implementations. 194 Listed below are terms used throughout the document. 196 2.1. Endpoint 198 An endpoint is a session specific tuple on an end host. An endpoint 199 may be represented differently for each IP protocol. For example, 200 a UDP or TCP session endpoint is represented as a tuple of 201 (IP address, UDP/TCP port). 203 2.2. Endpoint Mapping 205 When a host in a private realm initiates an outgoing session to a 206 host in the public realm through a NAT device, the NAT device 207 assigns a public endpoint to translate the private endpoint so 208 that subsequent response packets from the external host can be 209 received by the NAT, translated, and forwarded to the private 210 endpoint. The assignment by the NAT device to translate a private 211 endpoint to a public endpoint and vice versa is called the 212 Endpoint Mapping. NAT uses the Endpoint Mapping to perform 213 translation for the duration of the session. 215 2.3. Endpoint-Independent Mapping 217 "Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows. 218 The NAT reuses the port mapping for subsequent packets sent 219 from the same internal IP address and port (X:x) to any 220 external IP address and port. 222 2.4. Endpoint-Dependent Mapping 224 "Endpoint-Dependent Mapping" refers to the combination of 225 "Address-Dependent Mapping" and "Address and Port-Dependent Mapping" 226 as defined in [BEH-UDP]. 228 "Address-Dependent Mapping" is defined in [BEH-UDP] as follows. 229 The NAT reuses the port mapping for subsequent packets sent 230 from the same internal IP address and port (X:x) to the same 231 external IP address, regardless of the external port. 233 "Address and Port-Dependent Mapping" is defined in [BEH-UDP] as 234 follows. 236 The NAT reuses the port mapping for subsequent packets sent 237 from the same internal IP address and port (X:x) to the same 238 external IP address and port while the mapping is still active. 240 2.5. Endpoint-Independent Filtering 242 "Endpoint-Independent Filtering" is defined in [BEH-UDP] as follows. 243 The NAT filters out only packets not destined to the internal 244 address and port X:x, regardless of the external IP address and 245 port source (Z:z). The NAT forwards any packets destined to 246 X:x. In other words, sending packets from the internal side of 247 the NAT to any external IP address is sufficient to allow any 248 packets back to the internal endpoint. 250 A NAT device employing the combination of "Endpoint-Independent 251 Mapping" and "Endpoint-Independent Filtering" will accept incoming 252 traffic to a mapped public port from ANY external endpoint on the 253 public network. 255 2.6. Endpoint-Dependent Filtering 257 "Endpoint-Dependent Filtering" refers to the combination of "Address- 258 Dependent Filtering" and "Address and Port-Dependent Filtering" as 259 defined in [BEH-UDP]. 261 "Address-Dependent Filtering" is defined in [BEH-UDP] as follows. 262 The NAT filters out packets not destined to the internal 263 address X:x. Additionally, the NAT will filter out packets 264 from Y:y destined for the internal endpoint X:x if X:x has not 265 sent packets to Y:any previously (independently of the port 266 used by Y). In other words, for receiving packets from a 267 specific external endpoint, it is necessary for the internal 268 endpoint to send packets first to that specific external 269 endpoint's IP address. 271 "Address and Port-Dependent Filtering" is defined in [BEH-UDP] as 272 follows. 273 The NAT filters out packets not destined for the internal address 274 X:x. Additionally, the NAT will filter out packets from Y:y 275 destined for the internal endpoint X:x if X:x has not sent 276 packets to Y:y previously. In other words, for receiving packets 277 from a specific external endpoint, it is necessary for the 278 internal endpoint to send packets first to that external 279 endpoint's IP address and port. 281 A NAT device employing "Endpoint-Dependent Filtering" will accept 282 incoming traffic to a mapped public port from only a restricted set 283 of external endpoints on the public network. 285 2.7. P2P Application 287 A P2P application is an application that uses the same endpoint to 288 initiate outgoing sessions to peering hosts as well as accept 289 incoming sessions from peering hosts. A P2P application may use 290 multiple endpoints for peer-to-peer communication. 292 2.8. NAT-friendly P2P Application 294 NAT-friendly P2P application is a P2P application that is designed 295 to work effectively even as peering nodes are located in distinct 296 IP address realms, connected by one or more NATs. 298 One common way P2P applications establish peering sessions and 299 remain NAT-friendly is by using a publicly addressable rendezvous 300 server for registration and peer discovery purposes. 302 2.9. Endpoint-Independent Mapping NAT (EIM-NAT) 304 Endpoint-Independent Mapping NAT (EIM-NAT, for short) is a NAT 305 device employing Endpoint-Independent Mapping. An EIM-NAT can have 306 any type of filtering behavior. BEHAVE compliant NAT devices are 307 good examples of EIM-NAT devices. A NAT device employing 308 Address-Dependent Mapping is an example of a NAT device that is not 309 EIM-NAT. 311 2.10. Hairpinning 313 Hairpinning is defined in [BEH-UDP] as follows. 314 If two hosts (called X1 and X2) are behind the same NAT and 315 exchanging traffic, the NAT may allocate an address on the 316 outside of the NAT for X2, called X2':x2'. If X1 sends 317 traffic to X2':x2', it goes to the NAT, which must relay 318 the traffic from X1 to X2. This is referred to as 319 hairpinning. 321 Not all currently deployed NATs support hairpinning. 323 3. Techniques Used by P2P Applications to Traverse NATs 325 This section reviews in detail the currently known techniques for 326 implementing peer-to-peer communication over existing NAT devices, 327 from the perspective of the application or protocol designer. 329 3.1. Relaying 330 The most reliable, but least efficient method of implementing peer- 331 to-peer communication in the presence of a NAT device is to make the 332 peer-to-peer communication look to the network like client/server 333 communication through relaying. Consider the scenario in figure 1. 334 Two client hosts A and B, have each initiated TCP or UDP 335 connections to a well-known rendezvous server S. The Rendezvous 336 Server S has a publicly addressable IP address and is used for the 337 purposes of registration, discovery and relay. Hosts behind NAT 338 register with the server. Peer hosts can discover hosts behind NATs 339 and relay all end-to-end messages using the server. The clients 340 reside on separate private networks, and their respective NAT 341 devices prevent either client from directly initiating a connection 342 to the other. 344 Registry, Discovery 345 combined with Relay 346 Server S 347 192.0.2.128:20001 348 | 349 +----------------------------+----------------------------+ 350 | ^ Registry/ ^ ^ Registry/ ^ | 351 | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | 352 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 353 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 354 | | 355 +--------------+ +--------------+ 356 | 192.0.2.1 | | 192.0.2.254 | 357 | | | | 358 | NAT A | | NAT B | 359 +--------------+ +--------------+ 360 | | 361 | ^ Registry/ ^ ^ Registry/ ^ | 362 | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | 363 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 364 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 365 | | 366 | | 367 Client A Client B 368 10.0.0.1:1234 10.1.1.3:1234 370 Figure 1: Use of Relay Server to setup communication across end hosts 372 Instead of attempting a direct connection, the two clients can simply 373 use the server S to relay messages between them. For example, to 374 send a message to client B, client A simply sends the message to 375 server S along its already-established client/server connection, and 376 server S then sends the message on to client B using its existing 377 client/server connection with B. 379 This method has the advantage that it will always work as long as 380 both clients have connectivity to the server. The enroute NAT device 381 is not required to be EIM-NAT. The obvious disadvantages of 382 relaying are that it consumes the server's processing power and 383 network bandwidth, and communication latency between the peering 384 clients is likely to be increased even if the server has sufficient 385 I/O bandwidth and is located correctly topology wise. The TURN 386 protocol [TURN] defines a method of implementing application 387 agnostic, session oriented, packet relay in a relatively secure 388 fashion. 390 3.2. Connection Reversal 392 The following connection reversal technique for a direct 393 communication works only when one of the peers is behind a NAT 394 device and the other is not. For example, consider the scenario 395 in figure 2. Client A is behind a NAT, but client B has a publicly 396 addressable IP address. Rendezvous Server S has a publicly 397 addressable IP address and is used for the purposes of registration 398 and discovery. Hosts behind NAT register their endpoints with the 399 server. Peer hosts discover endpoints of hosts behind NAT using the 400 server. 402 Registry, Discovery 403 Server S 404 192.0.2.128:20001 405 | 406 +----------------------------+----------------------------+ 407 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 408 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 409 | | 192.0.2.1:62000 | | 192.0.2.254:1234 | | 410 | | 411 | ^ P2P Session (A-B) ^ | P2P Session (B-A) | | 412 | | 192.0.2.254:1234 | | 192.0.2.1:62000 | | 413 | | 192.0.2.1:62000 | v 192.0.2.254:1234 v | 414 | | 415 +--------------+ | 416 | 192.0.2.1 | | 417 | | | 418 | NAT A | | 419 +--------------+ | 420 | | 421 | ^ Registry Session(A-S) ^ | 422 | | 192.0.2.128:20001 | | 423 | | 10.0.0.1:1234 | | 424 | | 425 | ^ P2P Session (A-B) ^ | 426 | | 192.0.2.254:1234 | | 427 | | 10.0.0.1:1234 | | 428 | | 429 Private Client A Public Client B 430 10.0.0.1:1234 192.0.2.254:1234 432 Figure 2: Connection reversal using Rendezvous server 434 Client A has private IP address 10.0.0.1, and the application is 435 using TCP port 1234. This client has established a connection with 436 server S at public IP address 192.0.2.128 and port 20001. NAT A has 437 assigned TCP port 62000, at its own public IP address 192.0.2.1, 438 to serve as the temporary public endpoint address for A's session 439 with S; therefore, server S believes that client A is at IP address 440 192.0.2.1 using port 62000. Client B, however, has its own 441 permanent IP address, 192.0.2.254, and the application on B is 442 accepting TCP connections at port 1234. 444 Now suppose client B wishes to establish a direct communication 445 session with client A. B might first attempt to 446 contact client A either at the address client A believes itself to 447 have, namely 10.0.0.1:1234, or at the address of A as observed by 448 server S, namely 192.0.2.1:62000. In either case, the connection 449 will fail. In the first case, traffic directed to IP address 450 10.0.0.1 will simply be dropped by the network because 10.0.0.1 is 451 not a publicly routable IP address. In the second case, the TCP 452 SYN request from B will arrive at NAT A directed to port 62000, but 453 NAT A will reject the connection request because only outgoing 454 connections are allowed. 456 After attempting and failing to establish a direct connection to A, 457 client B can use server S to relay a request to client A to initiate 458 a "reversed" connection to client B. Client A, upon receiving this 459 relayed request through S, opens a TCP connection to client B at B's 460 public IP address and port number. NAT A allows the connection to 461 proceed because it is originating inside the firewall, and client B 462 can receive the connection because it is not behind a NAT device. 464 A variety of current peer-to-peer applications implement this 465 technique. Its main limitation, of course, is that it only works so 466 long as only one of the communicating peers is behind a NAT device. 467 If the NAT device is EIM-NAT, the public client can contact external 468 server S to determine the specific public endpoint from which to 469 expect Client-A originated connection and allow connections from 470 just those endpoints. If the NAT device is not EIM-NAT, the public 471 client cannot know the specific public endpoint from which to expect 472 Client-A originated connection. In the increasingly common case where 473 both peers can be behind NATs, the Connection Reversal method fails. 474 Connection Reversal is not a general solution to the peer-to-peer 475 connection problem. If neither a "forward" nor a "reverse" 476 connection can be established, applications often fall back to 477 another mechanism such as relaying. 479 3.3. UDP Hole Punching 481 UDP hole punching relies on the properties of EIM-NATs to allow 482 appropriately designed peer-to-peer applications to "punch holes" 483 through the NAT device(s) enroute and establish direct connectivity 484 with each other, even when both communicating hosts lie behind NAT 485 devices. When one of the hosts is behind a NAT that is not EIM-NAT, 486 the peering host cannot predictably know the mapped endpoint to 487 which to initiate connection. Further, the application on the host 488 behind non-EIM-NAT would be unable to reuse an already established 489 endpoint mapping for communication with different external 490 destinations and the hole-punching technique would fail. 492 This technique was mentioned briefly in section 5.1 of RFC 3027 493 [NAT-PROT], described in [KEGEL], and used in some recent 494 protocols [TEREDO, ICE]. Readers may refer Section 3.4 for details 495 on "TCP hole punching". 497 We will consider two specific scenarios, and how applications are 498 designed to handle both of them gracefully. In the first situation, 499 representing the common case, two clients desiring direct peer-to- 500 peer communication reside behind two different NATs. In the second, 501 the two clients actually reside behind the same NAT, but do not 502 necessarily know that they do. 504 3.3.1. Peers Behind Different NATs 506 Consider the scenario in figure 3. Clients A and B both have private 507 IP addresses and lie behind different NAT devices. Rendezvous Server 508 S has a publicly addressable IP address and is used for the purposes 509 of registration, discovery, and limited relay. Hosts behind NAT 510 register their public endpoints with the server. Peer hosts discover 511 the public endpoints of hosts behind NAT using the server. Unlike in 512 section 3.1, peer hosts use the server to relay just connection 513 initiation control messages, instead of end-to-end messages. 515 The peer-to-peer application running on clients A and B use UDP 516 port 1234. The rendezvous server S uses UDP port 20001. A and B have 517 each initiated UDP communication sessions with server S, causing 518 NAT A to assign its own public UDP port 62000 for A's session with 519 S, and causing NAT B to assign its port 31000 to B's session with S, 520 respectively. 522 Registry, Discovery, combined 523 with limited Relay 524 Server S 525 192.0.2.128:20001 526 | 527 +----------------------------+----------------------------+ 528 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 529 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 530 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 531 | | 532 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 533 | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | 534 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 535 | | 536 +--------------+ +--------------+ 537 | 192.0.2.1 | | 192.0.2.254 | 538 | | | | 539 | EIM-NAT A | | EIM-NAT B | 540 +--------------+ +--------------+ 541 | | 542 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 543 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 544 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 545 | | 546 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 547 | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | 548 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 549 | | 550 Client A Client B 551 10.0.0.1:1234 10.1.1.3:1234 553 Figure 3: UDP Hole Punching to setup direct connectivity 555 Now suppose that client A wants to establish a UDP communication 556 session directly with client B. If A simply starts sending UDP 557 messages to B's public endpoint 192.0.2.254:31000, then NAT B will 558 typically discard these incoming messages (unless it employs 559 Endpoint-Independent Filtering), because the source address and port 560 number does not match those of S, with which the original outgoing 561 session was established. Similarly, if B simply starts sending UDP 562 messages to A's public endpoint, then NAT A will typically discard 563 these messages. 565 Suppose A starts sending UDP messages to B's public endpoint, and 566 simultaneously relays a request through server S to B, asking B 567 to start sending UDP messages to A's public endpoint. A's outgoing 568 messages directed to B's public endpoint (192.0.2.254:31000) cause 569 EIM-NAT A to open up a new communication session between A's private 570 endpoint and B's public endpoint. At the same time, B's messages to 571 A's public endpoint (192.0.2.1:62000) cause EIM-NAT B to open up a 572 new communication session between B's private endpoint and A's 573 public endpoint. Once the new UDP sessions have been opened up in 574 each direction, client A and B can communicate with each other 575 directly without further burden on the server S. Server S, which 576 helps with relaying connection initiation requests to peer nodes 577 behind NAT devices ends up like an "introduction" server to peer 578 hosts. 580 The UDP hole punching technique has several useful properties. Once 581 a direct peer-to-peer UDP connection has been established between two 582 clients behind NAT devices, either party on that connection can in 583 turn take over the role of "introducer" and help the other party 584 establish peer-to-peer connections with additional peers, minimizing 585 the load on the initial introduction server S. The application does 586 not need to attempt to detect the kind of NAT device it is behind, 587 since the procedure above will establish peer-to-peer communication 588 channels equally well if either or both clients do not happen to be 589 behind a NAT device. The UDP hole punching technique even works 590 automatically with multiple NATs, where one or both clients are 591 removed from the public Internet via two or more levels of address 592 translation. 594 3.3.2. Peers Behind Same NAT 596 Now consider the scenario in which the two clients (probably 597 unknowingly) happen to reside behind the same EIM-NAT, and are 598 therefore located in the same private IP address space, as in 599 figure 4. A well-known Rendezvous Server S has a publicly addressable 600 IP address and is used for the purposes of registration, discovery, 601 and limited relay. Hosts behind NAT register with the server. Peer 602 hosts discover hosts behind NAT using the server and relay messages 603 using the server. Unlike in section 3.1, peer hosts use the server 604 to relay just control messages, instead of all end-to-end messages. 606 Client A has established a UDP session with server S, to which the 607 common EIM-NAT has assigned public port number 62000. Client B has 608 similarly established a session with S, to which the EIM-NAT has 609 assigned public port number 62001. 611 Registry, Discovery, combined 612 with limited Relay 613 Server S 614 192.0.2.128:20001 615 | 616 ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ 617 | 192.0.2.128:20001 | | | 192.0.2.128:20001 | 618 | 192.0.2.1:62000 | | | 192.0.2.1:62001 | 619 | 620 +--------------+ 621 | 192.0.2.1 | 622 | | 623 | EIM-NAT | 624 +--------------+ 625 | 626 +-----------------------------+----------------------------+ 627 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 628 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 629 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 630 | | 631 | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ | 632 | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | 633 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 634 | | 635 | ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ | 636 | | 10.1.1.3:1234 | | 10.0.0.1:1234 | | 637 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 638 | | 639 Client A Client B 640 10.0.0.1:1234 10.1.1.3:1234 642 Figure 4: Use local & public endpoints to communicate with peers 644 Suppose that A and B use the UDP hole punching technique as outlined 645 above to establish a communication channel using server S as an 646 introducer. Then A and B will learn each other's public endpoints 647 as observed by server S, and start sending each other messages at 648 those public endpoints. The two clients will be able to communicate 649 with each other this way as long as the NAT allows hosts on the 650 internal network to open translated UDP sessions with other internal 651 hosts and not just with external hosts. This situation is referred as 652 "Hairpinning", because packets arriving at the NAT from the private 653 network are translated and then looped back to the private network 654 rather than being passed through to the public network. 656 For example, consider P2P session-try1 above. When A sends a UDP 657 packet to B's public endpoint, the packet initially has a source 658 endpoint of 10.0.0.1:1234 and a destination endpoint of 659 192.0.2.1:62001. The NAT receives this packet, translates it to have 660 a source endpoint of 192.0.2.1:62000 and a destination endpoint of 661 10.1.1.3:1234, and then forwards it on to B. 663 Even if the NAT device supports hairpinning, this translation and 664 forwarding step is clearly unnecessary in this situation, and 665 adds latency to the dialog between A and B, besides burdening the 666 NAT. The solution to this problem is straightforward and is 667 described as follows. 669 When A and B initially exchange address information through the 670 Rendezvous server S, they include their own IP addresses and port 671 numbers as "observed" by themselves, as well as their public 672 endpoints as observed by S. The clients then simultaneously start 673 sending packets to each other at each of the alternative 674 addresses they know about, and use the first address that leads 675 to successful communication. If the two clients are behind the 676 same NAT, as is the case in figure 4 above, then the packets 677 directed to their private endpoints (as attempted using P2P 678 session-try2) are likely to arrive first, resulting in a direct 679 communication channel not involving the NAT. If the two clients are 680 behind different NATs, then the packets directed to their private 681 endpoints will fail to reach each other at all, but the clients 682 will hopefully establish connectivity using their respective 683 public endpoints. It is important that these packets be 684 authenticated in some way, however, since in the case of different 685 NATs it is entirely possible for A's messages directed at B's 686 private endpoint to reach some other, unrelated node on A's private 687 network, or vice versa. 689 [ICE] protocol employs this technique effectively, in that multiple 690 candidate endpoints (both private and public) are communicated 691 between peering end hosts during offer/answer exchange. Endpoints 692 that offer the most efficient end-to-end connection(s) are selected 693 eventually for end-to-end data transfer. 695 3.3.3. Peers Separated by Multiple NATs 697 In some topologies involving multiple NAT devices, it is not 698 possible for two clients to establish an "optimal" P2P route 699 between them without specific knowledge of the topology. 700 Consider for example the scenario in figure 5. 702 Registry, Discovery, combined 703 with limited Relay 704 Server S 705 192.0.2.128:20001 706 | 707 ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ 708 | 192.0.2.128:20001 | | | 192.0.2.128:20001 | 709 | 192.0.2.1:62000 | | | 192.0.2.1:62001 | 710 | 711 +--------------+ 712 | 192.0.2.1 | 713 | | 714 | EIM-NAT X | 715 | (Supporting | 716 | Hairpinning) | 717 +--------------+ 718 | 719 +----------------------------+----------------------------+ 720 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 721 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 722 | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | 723 | | 724 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 725 | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | 726 | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | 727 | | 728 +--------------+ +--------------+ 729 | 192.168.1.1 | | 192.168.1.2 | 730 | | | | 731 | EIM-NAT A | | EIM-NAT B | 732 +--------------+ +--------------+ 733 | | 734 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 735 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 736 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 737 | | 738 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 739 | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | 740 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 741 | | 742 Client A Client B 743 10.0.0.1:1234 10.1.1.3:1234 745 Figure 5: Use of Hairpinning in setting up direct communication 747 Suppose NAT X is an EIM-NAT deployed by a large internet service 748 provider (ISP) to multiplex many customers onto a few public IP 749 addresses, and NATs A and B are small consumer NAT gateways deployed 750 independently by two of the ISP's customers to multiplex their 751 private home networks onto their respective ISP-provided IP 752 addresses. Only server S and NAT X have globally routable IP 753 addresses; the "public" IP addresses used by NAT A and NAT B are 754 actually private to the ISP's addressing realm, while client A's 755 and B's addresses in turn are private to the addressing realms of 756 NAT A and B, respectively. Just as in previous section, Server S 757 is used for the purposes of registration, discovery and limited 758 relay. Peer hosts use the server to relay connection initiation 759 control messages, instead of all end-to-end messages. 761 Now suppose clients A and B attempt to establish a direct peer-to- 762 peer UDP connection. The optimal method would be for client A to 763 send messages to client B's public address at NAT B, 764 192.168.1.2:31000 in the ISP's addressing realm, and for client B 765 to send messages to A's public address at NAT B, namely 766 192.168.1.1:30000. Unfortunately, A and B have no way to learn 767 these addresses, because server S only sees the "global" public 768 endpoints of the clients, 192.0.2.1:62000 and 192.0.2.1:62001. 769 Even if A and B had some way to learn these addresses, there is 770 still no guarantee that they would be usable because the address 771 assignments in the ISP's private addressing realm might conflict 772 with unrelated address assignments in the clients' private realms. 773 The clients therefore have no choice but to use their global public 774 endpoints as seen by S for their P2P communication, and rely on 775 NAT X to provide hairpinning. 777 3.4. TCP Hole Punching 779 In this section, we will discuss the "TCP hole punching" technique 780 used for establishing direct TCP connection between a pair of nodes 781 that are both behind EIM-NAT devices. Just as with UDP hole punching, 782 TCP hole punching relies on the properties of EIM-NATs to allow 783 appropriately designed peer-to-peer applications to "punch holes" 784 through the NAT device and establish direct connectivity with each 785 other, even when both communicating hosts lie behind NAT devices. 786 This technique is also known sometimes as "Simultaneous TCP open". 788 Most TCP sessions start with one endpoint sending a SYN packet, to 789 which the other party responds with a SYN-ACK packet. It is 790 permissible, however, for two endpoints to start a TCP session by 791 simultaneously sending each other SYN packets, to which each party 792 subsequently responds with a separate ACK. This procedure is known 793 as "Simultaneous TCP Open" technique and may be found in figure 6 794 of the original TCP specification ([TCP]). However, "Simultaneous 795 TCP Open" is not implemented correctly on many systems, including 796 NAT devices. 798 If a NAT device receives a TCP SYN packet from outside the private 799 network attempting to initiate an incoming TCP connection, the 800 NAT device will normally reject the connection attempt by either 801 dropping the SYN packet or sending back a TCP RST (connection reset) 802 packet. In the case of SYN timeout or connection reset, the 803 application endpoint will continue to resend a SYN packet, until 804 the peer does the same from its end. 806 Let us consider the case where a NAT device supports "Simultaneous 807 TCP Open" sessions. When a SYN packet arrives with source and 808 destination endpoints that correspond to a TCP session that the NAT 809 device believes is already active, then the NAT device would allow 810 the packet to pass through. In particular, if the NAT device has just 811 recently seen and transmitted an outgoing SYN packet with the same 812 address and port numbers, then it will consider the session active 813 and allow the incoming SYN through. If clients A and B can each 814 initiate an outgoing TCP connection with the other client timed so 815 that each client's outgoing SYN passes through its local NAT device 816 before either SYN reaches the opposite NAT device, then a working 817 peer-to-peer TCP connection will result. 819 This technique may not always work reliably for the following 820 reason(s). If either node's SYN packet arrives at the remote NAT 821 device too quickly (before the peering node had a chance to send the 822 SYN packet), then the remote NAT device may either drop the SYN 823 packet or reject the SYN with a RST packet. This could cause the 824 local NAT device in turn to close the new NAT-session immediately or 825 initiate end-of-session timeout (refer section 2.6 of [NAT-TERM]) so 826 as to close the NAT-session at the end of the timeout. Even as both 827 peering nodes simultaneously initiate continued SYN retransmission 828 attempts, some remote NAT devices might not let the incoming SYNs 829 through if the NAT session is in end-of-session timeout state. This 830 in turn would prevent the TCP connection from being established. 832 In reality, the majority of the NAT devices (more than 50%) 833 support Endpoint-Independent Mapping and do not send ICMP errors or 834 RSTs in response to unsolicited incoming SYNs. As a result, 835 Simultaneous TCP Open technique does work across NAT devices in 836 the majority of TCP connection attempts ([P2P-NAT], [TCP-CHARACT]). 838 3.5. UDP Port Number Prediction 840 A variant of the UDP hole punching technique exists that allows 841 peer-to-peer UDP sessions to be created in the presence of some 842 NATs implementing Endpoint-Dependent Mapping. This method is 843 sometimes called the "N+1" technique [BIDIR] and is explored in 844 detail by Takeda [SYM-STUN]. The method works by analyzing the 845 behavior of the NAT and attempting to predict the public port 846 numbers it will assign to future sessions. The public ports 847 assigned are often predictable because most NATs assign mapping 848 ports in sequence. 850 Consider the scenario in figure 6. Two clients, A and B, each behind 851 a separate NAT, have established separate UDP connections with 852 rendezvous server S. Rendezvous server S has a publicly addressable 853 IP address and is used for the purposes of registration and 854 discovery. Hosts behind NAT register their endpoints with the 855 server. Peer hosts discover endpoints of the hosts behind NAT using 856 the server. 858 Registry and Discovery 859 Server S 860 192.0.2.128:20001 861 | 862 | 863 +----------------------------+----------------------------+ 864 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 865 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 866 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 867 | | 868 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 869 | | 192.0.2.254:31001 | | 192.0.2.1:62001 | | 870 | | 192.0.2.1:62001 | | 192.0.2.254:31001 | | 871 | | 872 +---------------------+ +--------------------+ 873 | 192.0.2.1 | | 192.0.2.254 | 874 | | | | 875 | NAT A | | NAT B | 876 | (Endpoint-Dependent | | (Endpoint-Dependent| 877 | Mapping) | | Mapping) | 878 +---------------------+ +--------------------+ 879 | | 880 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 881 | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | 882 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 883 | | 884 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 885 | | 192.0.2.254:31001 | | 192.0.2.1:62001 | | 886 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 887 | | 888 Client A Client B 889 10.0.0.1:1234 10.1.1.3:1234 891 Figure 6: UDP Port Prediction to setup direct connectivity 892 NAT A has assigned its UDP port 62000 to the communication 893 session between A and S, and NAT B has assigned its port 31000 to 894 the session between B and S. By communicating with server S, A 895 and B learn each other's public endpoints as observed by S. Client A 896 now starts sending UDP messages to port 31001 at address 192.0.2.254 897 (note the port number increment), and client B simultaneously starts 898 sending messages to port 62001 at address 192.0.2.1. If NATs A and B 899 assign port numbers to new sessions sequentially, and if not much 900 time has passed since the A-S and B-S sessions were initiated, then 901 a working bi-directional communication channel between A and B 902 should result. A's messages to B cause NAT A to open up a new 903 session, to which NAT A will (hopefully) assign public port number 904 62001, because 62001 is next in sequence after the port number 905 62000 it previously assigned to the session between A and S. 906 Similarly, B's messages to A will cause NAT B to open a new 907 session, to which it will (hopefully) assign port number 31001. 908 If both clients have correctly guessed the port numbers each NAT 909 assigns to the new sessions, then a bi-directional UDP 910 communication channel will have been established. 912 Clearly, there are many things that can cause this trick to fail. 913 If the predicted port number at either NAT already happens to be in 914 use by an unrelated session, then the NAT will skip over that port 915 number and the connection attempt will fail. If either NAT sometimes 916 or always chooses port numbers non-sequentially, then the trick will 917 fail. If a different client behind NAT A (or B respectively) opens 918 up a new outgoing UDP connection to any external destination after A 919 (B) establishes its connection with S but before sending its first 920 message to B (A), then the unrelated client will inadvertently 921 "steal" the desired port number. This trick is therefore much less 922 likely to work when either NAT involved is under load. 924 Since in practice an application implementing this trick would still 925 need to work even when one of the NATs employ Endpoint-Independent 926 Mapping, the application would need to detect beforehand what kind 927 of NAT is involved on either end and modify its behavior 928 accordingly, increasing the complexity of the algorithm and the 929 general brittleness of the network. Finally, port number prediction 930 has little chance of working if either client is behind two or more 931 levels of NAT and the NAT(s) closest to the client employ 932 Endpoint-Dependent Mapping. 934 3.6. TCP Port Number Prediction 936 This is a variant of the "TCP Hole Punching" technique to setup 937 direct peer-to-peer TCP sessions across NATs employing 938 Address-Dependent Mapping. 940 Unfortunately, this trick may be even more fragile and timing- 941 sensitive than the UDP port number prediction trick described 942 earlier. First, predicting the public port a NAT would assign 943 could be wrong. In addition, if either client's SYN arrives at 944 the opposite NAT device too quickly, then the remote NAT device 945 may reject the SYN with a RST packet, causing the local NAT 946 device in turn to close the new session and make future SYN 947 retransmission attempts using the same port numbers futile. 949 4. Recent Work on NAT Traversal 951 [P2P-NAT] has a detailed discussion on the UDP and TCP hole punching 952 techniques for NAT traversal. [P2P-NAT] also lists empirical results 953 from running [NAT-CHECK] test program across a number of commercial 954 NAT devices. The results indicate that UDP hole punching works 955 widely on more than 80% of the NAT devices, whereas TCP hole 956 punching works on just over 60% of the NAT devices tested. The 957 results also indicate that TCP or UDP hairpinning is not yet widely 958 available on the commercial NAT devices, as less than 25% of 959 the devices passed the tests ([NAT-CHECK]) for Hairpinning. Readers 960 may also refer [JENN-RESULT] and [SAIK-RESULT] for empirical test 961 results in classifying publicly available NAT devices. [JENN-RESULT] 962 provides results of NAT classification using tests spanning across 963 different IP protocols. [SAIK-RESULT] focuses exclusively on 964 classifying NAT devices by the TCP behavioral characteristics. 966 [TCP-CHARACT] and [NAT-BLASTER] focus on TCP hole punching, exploring 967 and comparing several alternative approaches. [NAT-BLASTER] takes an 968 analytical approach, analyzing different cases of observed NAT 969 behavior and ways applications might address them. [TCP-CHARACT] 970 adopts a more empirical approach, measuring the commonality of 971 different types of NAT behavior relevant to TCP hole punching. This 972 work finds that using more sophisticated techniques than those used 973 in [P2P-NAT], up to 88% of currently deployed NATs can support TCP 974 hole punching. 976 [TEREDO] is a NAT traversal service that uses relay technology to 977 connect IPv4 nodes behind NAT devices to IPv6 nodes, external to 978 the NAT devices. [TEREDO] provides for peer communication across 979 NAT devices by tunneling packets over UDP, across the NAT device(s) 980 to a relay node. Teredo relays act as Rendezvous servers to relay 981 traffic from private IPv4 nodes to the nodes in the external realm 982 and vice versa. 984 [ICE] is a NAT traversal protocol for setting up media sessions 985 between peer nodes for a class of multi-media applications. [ICE] 986 requires peering nodes to run STUN protocol ([STUN]) on the same 987 port number used to terminate media session(s). Applications that 988 use signaling protocols such as SIP ([SIP]) may embed the NAT 989 traversal attributes for the media session within the signaling 990 sessions and use the offer/answer type of exchange between peer 991 nodes to set up end-to-end media session(s)b across NAT devices. 992 [ICE-TCP] is an extension of ICE for TCP based media sessions. 994 A number of online gaming and media-over-IP applications, including 995 Instant Messaging application use the techniques described in the 996 document for peer-to-peer connection establishment. Some 997 applications may use multiple distinct rendezvous servers for 998 registration, discovery and relay functions for load balancing, 999 among other reasons. For example, a well-known media over IP 1000 application "Skype" uses a central public server for login 1001 and different public servers for end-to-end relay function. 1003 5. Summary of Observations 1005 5.1. TCP/UDP Hole Punching 1007 TCP/UDP hole punching appears to be the most efficient existing 1008 method of establishing direct TCP/UDP peer-to-peer communication 1009 between two nodes that are both behind NATs. This technique has 1010 been used with a wide variety of existing NATs. However, 1011 applications may need to prepare to fall back to simple relaying 1012 when direct communication cannot be established. 1014 The TCP/UDP hole punching technique has a caveat in that it works 1015 only when the traversing NAT is EIM-NAT. When the NAT device 1016 enroute is not EIM-NAT, the application is unable to reuse an 1017 already established endpoint mapping for communication with 1018 different external destinations and the technique would fail. 1019 However, many of the NAT devices deployed in the Internet are 1020 EIM-NAT devices. That makes TCP/UDP hole punching technique 1021 broadly applicable [P2P-NAT]. Nevertheless a substantial fraction 1022 of deployed NATs do employ Endpoint-Dependent Mapping and do not 1023 support TCP/UDP hole punching technique. 1025 5.2. NATs Employing Endpoint-Dependent Mapping 1027 NATs Employing Endpoint-Dependent Mapping weren't a problem with 1028 client-server applications such as web browsers, which only need to 1029 initiate outgoing connections. However, in the recent times, P2P 1030 applications such as Instant Messaging and Voice-over-IP 1031 applications have been in wide use. NATs employing 1032 Endpoint-Dependent mapping are not suitable for P2P applications as 1033 techniques such as TCP/UDP hole punching will not work across these 1034 NAT devices. 1036 5.3. Peer Discovery 1038 Application peers may be present within the same NAT domain or 1039 outside NAT domain. In order for all peers (those within or 1040 outside NAT domain) to discover application endpoint, an 1041 application may choose to register its private endpoints in 1042 addition to public endpoints with rendezvous server. 1044 5.4. Hairpinning 1046 Support for hairpinning is highly beneficial to allow hosts behind 1047 EIM-NAT to communicate with other hosts behind the same NAT 1048 device through their public, possibly translated endpoints. Support 1049 for hairpinning is particularly useful in the case of large-capacity 1050 NATs deployed as the first level of a multi-level NAT scenario. As 1051 described in section 3.3.3, hosts behind the same first-level NAT 1052 but different second-level NATs do not have a way to communicate 1053 with each other using TCP/UDP hole punching techniques, unless the 1054 first-level NAT also supports hairpinning. This would be the case 1055 even when all NAT devices in a deployment preserve endpoint 1056 identities. 1058 6. Security Considerations 1060 This document does not inherently create new security issues. 1061 Nevertheless, security risks may be present in the techniques 1062 described. This section describes security risks the applications 1063 could inadvertently create in attempting to support direct 1064 communication across NAT devices. 1066 6.1. Lack of Authentication Can Cause Connection Hijacking 1068 Applications must use appropriate authentication mechanisms to 1069 protect their connections from accidental confusion with other 1070 connections as well as from malicious connection hijacking or 1071 denial-of-service attacks. Applications effectively must interact 1072 with multiple distinct IP address domains, but are not generally 1073 aware of the exact topology or administrative policies defining 1074 these address domains. While attempting to establish connections 1075 via TCP/UDP hole punching, applications send packets that may 1076 frequently arrive at an entirely different host than the intended 1077 one. 1079 For example, many consumer-level NAT devices provide DHCP 1080 services that are configured by default to hand out site-local 1081 IP addresses in a particular address range. Say, a particular 1082 consumer NAT device, by default, hands out IP addresses starting 1083 with 192.168.1.100. Most private home networks using that NAT 1084 device will have a host with that IP address, and many of these 1085 networks will probably have a host at address 192.168.1.101 as 1086 well. If host A at address 192.168.1.101 on one private network 1087 attempts to establish a connection by UDP hole punching with 1088 host B at 192.168.1.100 on a different private network, then as 1089 part of this process host A will send discovery packets to 1090 address 192.168.1.100 on its local network, and host B will send 1091 discovery packets to address 192.168.1.101 on its network. Clearly, 1092 these discovery packets will not reach the intended machine since 1093 the two hosts are on different private networks, but they are very 1094 likely to reach SOME machine on these respective networks at the 1095 standard UDP port numbers used by this application, potentially 1096 causing confusion, especially if the application is also running 1097 on those other machines and does not properly authenticate its 1098 messages. 1100 This risk due to aliasing is therefore present even without a 1101 malicious attacker. If one endpoint, say host A, is actually 1102 malicious, then without proper authentication the attacker could 1103 cause host B to connect and interact in unintended ways with 1104 another host on its private network having the same IP address 1105 as the attacker's (purported) private address. Since the two 1106 endpoint hosts A and B presumably discovered each other through 1107 a public rendezvous server S, providing registration, discovery 1108 and limited relay services; and neither S nor B has any means to 1109 verify A's reported private address, applications may be 1110 advised to assume that any IP address they find to be suspect 1111 until they successfully establish authenticated two-way 1112 communication. 1114 6.2. Denial-of-service Attacks 1116 Applications and the public servers that support them must 1117 protect themselves against denial-of-service attacks, and ensure 1118 that they cannot be used by an attacker to mount denial-of-service 1119 attacks against other targets. To protect themselves, applications 1120 and servers must avoid taking any action requiring significant 1121 local processing or storage resources until authenticated two-way 1122 communication is established. To avoid being used as a tool for 1123 denial-of-service attacks, applications and servers must minimize 1124 the amount and rate of traffic they send to any newly-discovered 1125 IP address until after authenticated two-way communication is 1126 established with the intended target. 1128 For example, applications that register with a public rendezvous 1129 server can claim to have any private IP address, or perhaps multiple 1130 IP addresses. A well-connected host or group of hosts that can 1131 collectively attract a substantial volume of connection attempts 1132 (e.g., by offering to serve popular content) could mount a 1133 denial-of-service attack on a target host C simply by including C's 1134 IP address in their own list of IP addresses they register with the 1135 rendezvous server. There is no way the rendezvous server can verify 1136 the IP addresses, since they could well be legitimate private 1137 network addresses useful to other hosts for establishing 1138 network-local communication. The application protocol must 1139 therefore be designed to size- and rate-limit traffic to unverified 1140 IP addresses in order to avoid the potential damage such a 1141 concentration effect could cause. 1143 6.3. Man-in-the-middle Attacks 1145 Any network device on the path between a client and a public 1146 rendezvous server can mount a variety of man-in-the-middle 1147 attacks by pretending to be a NAT. For example, suppose 1148 host A attempts to register with rendezvous server S, but a 1149 network-snooping attacker is able to observe this registration 1150 request. The attacker could then flood server S with requests 1151 that are identical to the client's original request except with 1152 a modified source IP address, such as the IP address of the 1153 attacker itself. If the attacker can convince the server to 1154 register the client using the attacker's IP address, then the 1155 attacker can make itself an active component on the path of all 1156 future traffic from the server AND other hosts to the 1157 original client, even if the attacker was originally only able 1158 to snoop the path from the client to the server. 1160 The client cannot protect itself from this attack by 1161 authenticating its source IP address to the rendezvous server, 1162 because in order to be NAT-friendly the application must allow 1163 intervening NATs to change the source address silently. This 1164 appears to be an inherent security weakness of the NAT paradigm. 1165 The only defense against such an attack is for the client to 1166 authenticate and potentially encrypt the actual content of its 1167 communication using appropriate higher-level identities, so that 1168 the interposed attacker is not able to take advantage of its 1169 position. Even if all application-level communication is 1170 authenticated and encrypted, however, this attack could still be 1171 used as a traffic analysis tool for observing who the client is 1172 communicating with. 1174 6.4. Security Impact From EIM-NAT Devices 1176 Designing NAT devices to preserve endpoint identities does not 1177 weaken the security provided by the NAT device. For example, a 1178 NAT device employing Endpoint-Independent Mapping and 1179 Endpoint-Dependent Filtering is no more "promiscuous" than a NAT 1180 device employing Endpoint-Dependent Mapping and Endpoint-Dependent 1181 Filtering. Filtering incoming traffic aggressively using 1182 Endpoint-Dependent Filtering, while employing Endpoint-Independent 1183 Mapping allows a NAT device to be friendly to application without 1184 compromising the principle of rejecting unsolicited incoming 1185 traffic. 1187 Endpoint-Independent Mapping could arguably increase the 1188 predictability of traffic emerging from the NAT device, by revealing 1189 the relationships between different TCP/UDP sessions and hence about 1190 the behavior of applications running within the enclave. This 1191 predictability could conceivably be useful to an attacker in 1192 exploiting other network or application level vulnerabilities. 1193 If the security requirements of a particular deployment scenario 1194 are so critical that such subtle information channels are of 1195 concern, then perhaps the NAT device was not to have been 1196 configured to allow unrestricted outgoing TCP/UDP traffic in the 1197 first place. A NAT device configured to allow communication 1198 originating from specific applications at specific ports, or 1199 via tightly-controlled application-level gateways may accomplish 1200 the security requirements of such deployment scenarios. 1202 7. IANA Considerations 1204 There are no IANA considerations. 1206 8. Acknowledgments 1208 The authors wish to thank Henrik Bergstrom, David Anderson, 1209 Christian Huitema, Dan Wing, Eric Rescorla and other BEHAVE work 1210 group members for their valuable feedback on early versions of 1211 the document. The authors also wish to thank Francois Audet, 1212 Kaushik Biswas, Spencer Dawkins, Bruce Lowekamp and Brian Stucker 1213 for agreeing to be technical reviewers for the document. 1215 9. Normative References 1217 [NAT-TERM] Srisuresh, P., and Holdrege, M., "IP Network Address 1218 Translator (NAT) Terminology and Considerations", 1219 RFC 2663, August 1999. 1221 [NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network 1222 Address Translator (Traditional NAT)", RFC 3022, 1223 January 2001. 1225 [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements 1226 for Unicast UDP", RFC 4787, January 2007. 1228 10. Informative References 1230 [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application 1231 Design Guidelines for Traversal through Network 1232 Address Translators", draft-ford-behave-app-05.txt 1233 (Work In Progress), March 2007. 1235 [BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and Guha, S., 1236 "NAT Behavioral Requirements for ICMP protocol", 1237 draft-ietf-behave-nat-icmp-06.txt (work in progress), 1238 June 2007. 1240 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 1241 Srisuresh, P., "NAT Behavioral Requirements for TCP", 1242 draft-ietf-behave-tcp-07.txt (Work In Progress), 1243 April 2007. 1245 [BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working 1246 Committee, "Bidirectional Peer-to-Peer Communication with 1247 Interposing Firewalls and NATs", August 2001. 1248 http://www.peer-to-peerwg.org/tech/nat/ 1250 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 1251 (ICE): A Methodology for Network Address Translator (NAT) 1252 Traversal for Offer/Answer Protocols", 1253 draft-ietf-mmusic-ice-19.txt (work in Progress), 1254 October 2007. 1256 [ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive 1257 Connectivity Establishment (ICE)", 1258 draft-ietf-mmusic-ice-tcp-04.txt (work in Progress), 1259 July 2007. 1261 [JENN-RESULT] Jennings, C., "NAT Classification Test Results", 1262 draft-jennings-behave-test-results-04 (Work in Progress), 1263 July 2007. 1265 [KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July 1999. 1266 http://www.alumni.caltech.edu/~dank/peer-nat.html 1268 [MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and 1269 Rayhan, A., "Middlebox communication architecture and 1270 framework", RFC 3303, August 2002. 1272 [NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly 1273 Application Design Guidelines", RFC 3235, January 2002. 1275 [NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A., 1276 "Establishing TCP Connections Between Hosts Behind 1277 NATs", ACM SIGCOMM ASIA Workshop, April 2005. 1279 [NAT-CHECK] Ford, B., "NAT check Program" available online as 1280 http://midcom-p2p.sourceforge.net, February 2005. 1282 [NAT-PMP] Cheshire, S., Krochmal, M., and Sekar, K., "NAT Port 1283 Mapping Protocol (NAT-PMP)", 1284 draft-cheshire-nat-pmp-02.txt (Work In Progress), 1285 October 2006. 1287 [NAT-PROT] Holdrege, M., and Srisuresh, P., "Protocol Complications 1288 with the IP Network Address Translator", RFC 3027, 1289 January 2001. 1291 [NAT-PT] Tsirtsis, G. and Srisuresh, P., "Network Address 1292 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1293 February 2000. 1295 [NSIS-NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and Davies, 1296 E., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1297 draft-ietf-nsis-nslp-natfw-15.txt (Work In Progress), 1298 July 2007. 1300 [P2P-NAT] Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer 1301 Communication Across Network Address Translators", 1302 Proceedings of the USENIX Annual Technical Conference 1303 (Anaheim, CA), April 2005. 1305 [RFC3041] Narten, T., and Draves, R., "Privacy Extensions for 1306 Stateless Address Autoconfiguration in IPv6". 1307 RFC 3041, January, 2001. 1309 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 1310 2002. 1312 [RSIP] Borella, M., Lo, J., Grabelsky, D., and Montenegro, G., 1313 "Realm Specific IP: Framework", RFC 3102, October 2001. 1315 [SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as 1316 https://www.guha.cc/saikat/stunt-results.php. 1318 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1319 A., Peterson, J., Sparks, R., Handley, M., and E. 1320 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1321 June 2002. 1323 [SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R.,Koblas, D., and 1324 Jones, L., "SOCKS Protocol Version 5", RFC 1928, 1325 March 1996. 1327 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and Mahy, R., 1328 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1329 Through Network Address Translators (NATs)", RFC 3489, 1330 March 2003. 1332 [SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", 1333 draft-takeda-symmetric-nat-traversal-00 (Work In 1334 Progress), June 2003. 1336 [TCP] Postel, J., "Transmission Control Protocol (TCP) 1337 Specification", STD 7, RFC 793, September 1981. 1339 [TCP-CHARACT] Guha, S., and Francis, P., "Characterization and 1340 Measurement of TCP Traversal through NATs and Firewalls", 1341 Proceedings of Internet Measurement Conference (IMC), 1342 Berkeley, CA, Oct 2005, pp. 199-211. 1344 [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1345 Network Address Translations (NATs)", RFC 4380, 1346 February 2006. 1348 [TURN] Rosenberg, J., Mahy, R., and Huitema, C., 1349 "Traversal Using Relay NAT (TURN)", 1350 draft-ietf-behave-turn-05.txt (Work In Progress), 1351 November 2007. 1353 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 1354 Self-Address Fixing (UNSAF) Across Network Address 1355 Translation", RFC 3424, November 2002. 1357 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1358 Device Control Protocol V 1.0", November 2001. 1359 http://www.upnp.org/standardizeddcps/igd.asp 1361 [V6-CPE-SEC] Woodyatt, J., "Recommended Simple Security Capabilities 1362 in Customer Premises Equipment for Providing Residential 1363 IPv6 Internet Service", 1364 draft-ietf-v6ops-cpe-simple-security-00.txt (Work in 1365 Progress), June 2007. 1367 Authors' Addresses 1369 Pyda Srisuresh 1370 Kazeon Systems, Inc. 1371 1161 San Antonio Rd. 1372 Mountain View, CA 94043 1373 U.S.A. 1374 Phone: (408)836-4773 1375 E-mail: srisuresh@yahoo.com 1377 Bryan Ford 1378 Laboratory for Computer Science 1379 Massachusetts Institute of Technology 1380 77 Massachusetts Ave. 1381 Cambridge, MA 02139 1382 Phone: (617) 253-5261 1383 E-mail: baford@mit.edu 1384 Web: http://www.brynosaurus.com/ 1386 Dan Kegel 1387 Kegel.com 1388 901 S. Sycamore Ave. 1389 Los Angeles, CA 90036 1390 Phone: 323 931-6717 1391 Email: dank06@kegel.com 1392 Web: http://www.kegel.com/ 1394 Intellectual Property Statement 1396 The IETF takes no position regarding the validity or scope of any 1397 Intellectual Property Rights or other rights that might be claimed to 1398 pertain to the implementation or use of the technology described in 1399 this document or the extent to which any license under such rights 1400 might or might not be available; nor does it represent that it has 1401 made any independent effort to identify any such rights. Information 1402 on the procedures with respect to rights in RFC documents can be 1403 found in BCP 78 and BCP 79. 1405 Copies of IPR disclosures made to the IETF Secretariat and any 1406 assurances of licenses to be made available, or the result of an 1407 attempt made to obtain a general license or permission for the use of 1408 such proprietary rights by implementers or users of this 1409 specification can be obtained from the IETF on-line IPR repository at 1410 http://www.ietf.org/ipr. 1412 The IETF invites any interested party to bring to its attention any 1413 copyrights, patents or patent applications, or other proprietary 1414 rights that may cover technology that may be required to implement 1415 this standard. Please address the information to the IETF at 1416 ietf-ipr@ietf.org. 1418 Copyright Statement 1420 Copyright (C) The IETF Trust (2007). 1422 This document is subject to the rights, licenses and restrictions 1423 contained in BCP 78, and except as set forth therein, the authors 1424 retain all their rights. 1426 This document and the information contained herein are provided on an 1427 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1428 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1429 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1430 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1431 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1432 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1434 Acknowledgment 1436 Funding for the RFC Editor function is currently provided by the 1437 IETF Trust.