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