idnits 2.17.1 draft-srisuresh-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 71 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 42 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TEREDO' is mentioned on line 467, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') ** Obsolete normative reference: RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) == Outdated reference: A later version (-05) exists of draft-ford-behave-app-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-08 == 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-11 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Srisuresh 3 Expires: December 2, 2006 Consultant 4 B. Ford 5 M.I.T. 6 D. Kegel 7 kegel.com 8 June, 2006 10 State of Peer-to-Peer(P2P) Communication 11 Across Network Address Translators(NATs) 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This memo documents the various methods known to be in use by the 40 peer-to-peer (P2P) applications for communication in the presence 41 of Network Address Translators (NATs) at the current time. This 42 memo covers NAT traversal approaches used by both TCP and UDP 43 based applications. This memo is not an endorsement of the methods 44 described, but merely an attempt to capture them in a document. 46 Table of Contents 47 1. Introduction ................................................. 48 2. Terminology .................................................. 49 3. Techniques used by NAT-friendly P2P applications ............. 50 3.1. Relaying ................................................ 51 3.2. Connection reversal ..................................... 52 3.3. UDP Hole Punching ....................................... 53 3.3.1. Peers behind different NATs ...................... 54 3.3.2. Peers behind the same NAT ........................ 55 3.3.3. Peers separated by multiple NATs ................. 56 3.3.4. Where UDP hole punching fails .................... 57 3.4. Simultaneous TCP Open ................................... 58 3.5. UDP port number prediction .............................. 59 3.6. TCP port number prediction .............................. 60 4. Summary of observations ...................................... 61 4.1. TCP/UDP hole punching ................................... 62 4.2. Symmetric NATs are not P2P friendly ..................... 63 4.3. Peer discovery .......................................... 64 4.4. Hairpin translation ..................................... 65 5. Security considerations ...................................... 66 5.1. Lack of Authentication can cause connection hijacking ... 67 5.2. Denial-of-service attacks ............................... 68 5.3. Man-in-the-middle attacks ............................... 69 5.4. Security impact from a P2P-friendly NAT device .......... 70 6. IANA Considerations .......................................... 71 7. Acknowledgments .............................................. 72 8. Normative References ......................................... 73 9. Informative References ....................................... 74 10. Authors' addresses ........................................... 76 1. Introduction 78 Present day Internet has seen ubiquitous deployment of network 79 address translators (NATs). There are a variety of NAT devices and 80 a variety of network topologies utilizing the NAT devices in the 81 deployments. The asymmetric addressing and connectivity regimes 82 established by the NAT devices has created unique problems for 83 peer-to-peer (P2P) applications and protocols, such as 84 teleconferencing and multiplayer on-line gaming. These issues are 85 likely to persist even into the IPv6 world, where a NAT may be used 86 as an IPv4 compatibility mechanism [NAT-PT]. 88 Currently deployed NAT devices are designed primarily around the 89 client/server paradigm, in which relatively anonymous client machines 90 inside a private network initiate connections to public servers with 91 stable IP addresses and DNS names. NAT devices encountered enroute 92 provide dynamic address assignment for the client machines. The 93 anonymity and inaccessibility of the internal hosts behind a NAT 94 device is not a problem for applications such as web browsers, which 95 only need to initiate outgoing connections. This inaccessibility is 96 sometimes perceived as a privacy benefit. 98 In the peer-to-peer paradigm, Internet hosts that would normally be 99 considered "clients" would not only initiate sessions to peer 100 nodes, but also accept sessions initiated by peer nodes. The 101 initiator and the responder might lie behind different NAT devices 102 with neither endpoint having a permanent IP address or other form of 103 public network presence. A common on-line gaming architecture, for 104 example, involves all participating application hosts to contact a 105 well-known server for initialization and administration purposes. 106 Subsequent to this, the hosts establish direct connections with each 107 other for fast and efficient propagation of updates during game play. 108 Similarly, a file sharing application might contact a well-known 109 server for resource discovery or searching, but establish direct 110 connections with peer hosts for data transfer. NAT devices create 111 problems for peer-to-peer connections because hosts behind a 112 NAT device normally have no permanently visible public ports on the 113 Internet to which incoming TCP or UDP connections from other peers 114 can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue. 116 NAT traversal strategies that involve explicit signaling between 117 applications and NAT devices, namely [NAT-PMP], [NSIS-NSLP], 118 [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this 119 document. [UNSAF] is in scope. 121 In this document, we summarize the currently known methods by which 122 P2P applications work around the presence of NAT devices, without 123 directly altering the NAT devices. It is not the objective of this 124 document to provide solutions to NAT traversal problem for P2P 125 applications in general [BEH-APP] or to a specific class of 126 applications as in [ICE]. 128 2. Terminology 130 Readers are urged to refer [NAT-TERM] for information on NAT 131 taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most 132 common type of NAT device deployed. Traditional NAT has two main 133 variations - Basic NAT and Network Address Port Translator (NAPT). 134 Of these, NAPT is by far the most commonly deployed NAT device. NAPT 135 allows multiple internal hosts to share a single public IP address 136 simultaneously. When an internal host opens an outgoing TCP or UDP 137 session through a NAPT, the NAPT assigns the session a public IP 138 address and port number so that subsequent response packets from 139 the external endpoint can be received by the NAPT, translated, and 140 forwarded to the internal host. An issue of relevance to P2P 141 applications is how the NAT behaves when an internal host 142 initiates multiple simultaneous sessions from a single endpoint 143 (private IP, private port) to multiple distinct endpoints on the 144 external network. 146 Additional terms that further classify NAPT implementation are 147 defined in [STUN] and are summarized below. 149 Cone NAT 150 The fundamental property of Cone NAT is that it reuses Port 151 Binding assigned to a private host endpoint (identified by 152 the combination of private IP address and protocol specific 153 port number) for all sessions initiated by the private host 154 from the same endpoint, while the port binding is alive. Cone 155 NAT creates port binding between a (private IP, private port) 156 tuple and a (public IP, public port) tuple for translation 157 purposes. 159 For example, suppose Client A in figure 1 initiates two 160 simultaneous outgoing sessions through a cone NAT, from the same 161 internal endpoint (10.0.0.1:1234) to two different external 162 servers, S1 and S2. The cone NAT assigns just one public endpoint 163 155.99.25.11:62000 to both these sessions, ensuring that the 164 "identity" of the client's endpoint is maintained across address 165 translation. Since Basic-NAT devices do not modify port numbers 166 as packets traverse the device, Basic-NAT device can be viewed 167 as a degenerate form of Cone NAT. 169 Server S1 Server S2 170 18.181.0.31:1235 138.76.29.7:1235 171 | | 172 | | 173 +----------------------+----------------------+ 174 | 175 ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ 176 | 18.181.0.31:1235 | | | 138.76.29.7:1235 | 177 | 155.99.25.11:62000 | | | 155.99.25.11:62000 | 178 | 179 +--------------+ 180 | 155.99.25.11 | 181 | | 182 | Any type of | 183 | Cone NAT | 184 +--------------+ 185 | 186 ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ 187 | 18.181.0.31:1235 | | | 138.76.29.7:1235 | 188 | 10.0.0.1:1234 | | | 10.0.0.1:1234 | 189 | 190 Client A 191 10.0.0.1:1234 193 Figure 1: Cone NAT - Port Binding used for endpoint translation 195 Symmetric NAT 196 A symmetric NAT, in contrast, does not use Port Bindings. 197 A Symmetric NAT assigns a new public port to each new session 198 traversing the NAT device. For example, suppose Client A in 199 figure 2 initiates two outgoing sessions from the same endpoint, 200 one with S1 and another with S2. The same client endpoint is 201 connecting to the two external servers S1 and S2. When the first 202 session to server S1 traverses the symmetric NAT, the symmetric 203 NAT assigns port 62000 to translate the client end-point. When 204 the second session from the same client end-point to server S2 205 traverses the symmetric NAT, the symmetric NAT will assign a 206 different port 62001 to translate the same client end-point. As 207 a result, server S1 sees the client endpoint as 208 155.99.25.11:62000, whereas server S2 sees the same client 209 endpoint differently as 155.99.25.11:62001. The symmetric NAT, 210 however, is able to differentiate between the two sessions for 211 translation purposes because the external endpoints involved in 212 the two sessions (those of S1 and S2) differ, even as the 213 endpoint identity of the client application is lost across the 214 address translation boundary. 216 Server S1 Server S2 217 18.181.0.31:1235 138.76.29.7:1235 218 | | 219 | | 220 +----------------------+----------------------+ 221 | 222 ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ 223 | 18.181.0.31:1235 | | | 138.76.29.7:1235 | 224 | 155.99.25.11:62000 | | | 155.99.25.11:62001 | 225 | 226 +---------------+ 227 | 155.99.25.11 | 228 | | 229 | Symmetric NAT | 230 +---------------+ 231 | 232 ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ 233 | 18.181.0.31:1235 | | | 138.76.29.7:1235 | 234 | 10.0.0.1:1234 | | | 10.0.0.1:1234 | 235 | 236 Client A 237 10.0.0.1:1234 239 Figure 2: Symmetric NAT - Port Binding not used 241 Cone NAT is further classified according to how liberally the NAT 242 accepts incoming traffic directed to an already-established (public 243 IP, public port) tuple. The following Cone NAT variations are 244 defined in [STUN], but restated here for additional explanation. 245 This classification generally applies only to UDP traffic as 246 described below. 248 Full Cone NAT 249 Subsequent to establishing Port Binding at the start of an 250 outgoing UDP session, a full cone NAT will accept incoming 251 UDP traffic to the corresponding public port from ANY 252 external endpoint on the public network. Full cone NAT is 253 also sometimes referred as "Promiscuous NAT". 255 Address-Restricted Cone NAT 256 Subsequent to establishing Port Binding at the start of an 257 outgoing UDP session, Address-Restricted Cone NAT will accept 258 incoming UDP traffic to the corresponding public port from 259 only those external endpoints whose IP address match the 260 address of a node to which the internal host has previously 261 sent one or more outgoing packets. 263 Port-Restricted Cone NAT 264 Subsequent to establishing Port Binding at the start of an 265 outgoing TCP/UDP session, Port-Restricted Cone NAT will 266 accept incoming traffic to the corresponding public port from 267 only those external endpoints to which the internal host has 268 previously sent one or more outgoing packets. I.e., only 269 those incoming packets that belong to the sessions initiated 270 by the private host are permitted on the inbound. 272 Finally, we define the following new terms for classifying 273 P2P-relevant behavior across NAT devices. 275 P2P Application 276 P2P application is an application that uses the same 277 endpoint to initiate outgoing sessions to peering hosts 278 as well as accept incoming sessions from peering hosts. 280 NAT-friendly P2P application 281 NAT-friendly P2P application is a P2P application that is 282 designed to work effectively even as peering nodes are 283 located in distinct IP address realms, connected by one or 284 more NATs. 286 A NAT-friendly P2P application registers with a public 287 registration server and subsequently uses either the 288 private endpoint, or public endpoint, or both of its peers 289 to establish peering sessions. 291 P2P-friendly NAT 292 P2P-friendly NAT is a NAT device that maintains endpoint 293 identity of a P2P host application when the P2P application 294 initiates a session. P2P-friendly NAT devices permit 295 traversal of P2P applications traffic across itself. All 296 variations of Cone NAT are good examples of P2P-friendly 297 NAT devices. All Cone NAT variations maintain Address/Port 298 Bindings for TCP and UDP endpoints. Symmetric NAT is a 299 good example of a NAT device that is not P2P friendly. 301 Hairpin translation 302 When a host in the private domain of a NAT device attempts to 303 connect with another host behind the same NAT device using 304 the public address of the host, the NAT device performs the 305 equivalent of Twice NAT translation on the packet as 306 follows. The originating host's private endpoint is translated 307 into its assigned public endpoint, and the target host's public 308 endpoint is translated into its private endpoint, before 309 the packet is forwarded to the target host. We refer the above 310 translation as "Hairpin translation". 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. The 317 readers will note that the applications assume an 318 Address/Port-Restricted Cone NAT in majority of the cases below. 320 3.1. Relaying 322 The most reliable, but least efficient method of implementing peer- 323 to-peer communication in the presence of a NAT device is to make the 324 peer-to-peer communication look to the network like client/server 325 communication through relaying. For example, suppose two client 326 hosts A and B, in figure 3, have each initiated TCP or UDP 327 connections to a well-known server S, which has a permanent IP 328 address. The clients reside on separate private networks, and 329 their respective NAT devices prevent either client from directly 330 initiating a connection to the other. 332 Registry cum Relay 333 Server S 334 18.181.0.31:1234 335 | 336 +----------------------------+----------------------------+ 337 | | 338 | ^ Registry/ ^ ^ Registry/ ^ | 339 | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | 340 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 341 | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | 342 | | 343 +--------------+ +--------------+ 344 | 155.99.25.11 | | 138.76.29.7 | 345 | | | | 346 | Symmetric or | | Symmetric or | 347 | P2P-friendly | | P2P-friendly | 348 | NAT A | | NAT B | 349 +--------------+ +--------------+ 350 | | 351 | ^ Registry/ ^ ^ Registry/ ^ | 352 | | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | | 353 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 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 3: Use of Registry/Relay Server to emulate direct-P2P 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 assumed to be P2P friendly. Its obvious disadvantages are that 372 it consumes the server's processing power and network bandwidth, and 373 communication latency between the peering clients is likely to be 374 increased even if the server is well-connected. The TURN protocol 375 [TURN] defines a method of implementing relaying in a relatively 376 secure fashion. 378 3.2. Connection reversal 379 The following connection reversal technique for a direct P2P 380 communication works only when one of the clients (i.e., peers) is 381 behind a NAT device. For example, suppose client A is behind a NAT 382 but client B has a globally routable IP address, as in figure 4. 384 Server S 385 18.181.0.31:1234 386 | 387 +----------------------------+----------------------------+ 388 | | 389 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 390 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 391 | | 155.99.25.11:62000 | | 138.76.29.7:1234 | | 392 | | 393 | ^ P2P Session (A-B) ^ | P2P Session (B-A) | | 394 | | 138.76.29.7:1234 | | 155.99.25.11:62000 | | 395 | | 155.99.25.11:62000 | v 138.76.29.7:31000 v | 396 | | 397 +--------------+ | 398 | 155.99.25.11 | | 399 | | | 400 | P2P-friendly | | 401 | NAT A | | 402 +--------------+ | 403 | | 404 | ^ Registry Session(A-S) ^ | 405 | | 18.181.0.31:1234 | | 406 | | 10.0.0.1:1234 | | 407 | | 408 | ^ P2P Session (A-B) ^ | 409 | | 138.76.29.7:1234 | | 410 | | 10.0.0.1:1234 | | 411 | | 412 Private Client A Public Client B 413 10.0.0.1:1234 138.76.29.7:1234 415 Figure 4: Connection reversal to accomplish Direct-P2P 417 Client A has private IP address 10.0.0.1, and the application is 418 using TCP port 1234. This client has established a connection with 419 server S at public IP address 18.181.0.31 and port 1235. NAT A has 420 assigned TCP port 62000, at its own public IP address 155.99.25.11, 421 to serve as the temporary public endpoint address for A's session 422 with S: therefore, server S believes that client A is at IP address 423 155.99.25.11 using port 62000. Client B, however, has its own 424 permanent IP address, 138.76.29.7, and the peer-to-peer application 425 on B is accepting TCP connections at port 1234. 427 Now suppose client B would like to initiate a peer-to-peer 428 communication session with client A. B might first attempt to 429 contact client A either at the address client A believes itself to 430 have, namely 10.0.0.1:1234, or at the address of A as observed by 431 server S, namely 155.99.25.11:62000. In either case, however, the 432 connection will fail. In the first case, traffic directed to IP 433 address 10.0.0.1 will simply be dropped by the network because 434 10.0.0.1 is not a publicly routable IP address. In the second case, 435 the TCP SYN request from B will arrive at NAT A directed to port 436 62000, but NAT A will reject the connection request because only 437 outgoing connections are allowed. 439 After attempting and failing to establish a direct connection to A, 440 client B can use server S to relay a request to client A to initiate 441 a "reversed" connection to client B. Client A, upon receiving this 442 relayed request through S, opens a TCP connection to client B at B's 443 public IP address and port number. NAT A allows the connection to 444 proceed because it is originating inside the firewall, and client B 445 can receive the connection because it is not behind a NAT device. 447 A variety of current peer-to-peer applications implement this 448 technique. Its main limitation, of course, is that it only works so 449 long as only one of the communicating peers is behind a NAT and the 450 NAT is P2P-friendly, such as a Cone NAT. In the increasingly common 451 case where both peers can be behind NATs, the method fails. Because 452 connection reversal is not a general solution to the problem, it is 453 NOT recommended as a primary strategy. NAT-friendly P2P 454 applications may choose to attempt connection reversal, but should 455 be able to fall back automatically to another mechanism such as 456 relaying if neither a "forward" nor a "reverse" connection can be 457 established. 459 3.3. UDP hole punching 461 UDP hole punching relies on the properties of common firewalls and 462 cone NATs to allow appropriately designed peer-to-peer applications 463 to "punch holes" through the NAT device and establish direct 464 connectivity with each other, even when both communicating hosts 465 lie behind NAT devices. This technique was mentioned briefly in 466 section 5.1 of RFC 3027 [NAT-PROT], described in [KEGEL], and used 467 in some recent protocols [TEREDO, ICE]. This technique has been 468 used primarily with UDP applications, but not as reliably with TCP 469 applications. Readers may refer Section 3.4 for details on 470 "Simultaneous TCP open", also known sometimes as "TCP hole 471 punching". 473 We will consider two specific scenarios, and how applications are 474 designed to handle both of them gracefully. In the first situation, 475 representing the common case, two clients desiring direct peer-to- 476 peer communication reside behind two different NATs. In the second, 477 the two clients actually reside behind the same NAT, but do not 478 necessarily know that they do. 480 3.3.1. Peers behind different NATs 482 Suppose clients A and B both have private IP addresses and lie behind 483 different network address translators as in figure 5. The 484 peer-to-peer application running on clients A and B and on server S 485 each use UDP port 1234. A and B have each initiated UDP communication 486 sessions with server S, causing NAT A to assign its own public UDP 487 port 62000 for A's session with S, and causing NAT B to assign its 488 port 31000 to B's session with S, respectively. 490 Server S 491 18.181.0.31:1234 492 | 493 +----------------------------+----------------------------+ 494 | | 495 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 496 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 497 | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | 498 | | 499 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 500 | | 138.76.29.7:31000 | | 155.99.25.11:62000 | | 501 | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | 502 | | 503 +--------------+ +--------------+ 504 | 155.99.25.11 | | 138.76.29.7 | 505 | | | | 506 | P2P-friendly | | P2P-friendly | 507 | NAT A | | NAT B | 508 +--------------+ +--------------+ 509 | | 510 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 511 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 512 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 513 | | 514 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 515 | | 138.76.29.7:31000 | | 155.99.25.11:62000 | | 516 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 517 | | 518 Client A Client B 519 10.0.0.1:1234 10.1.1.3:1234 521 Figure 5: Simultaneous Hole Punching to accomplish Direct-P2P 523 Now suppose that client A wants to establish a UDP communication 524 session directly with client B. If A simply starts sending UDP 525 messages to B's public address, 138.76.29.7:31000, then NAT B will 526 typically discard these incoming messages (unless it is a full cone 527 NAT), because the source address and port number does not match those 528 of S, with which the original outgoing session was established. 529 Similarly, if B simply starts sending UDP messages to A's public 530 address and port number, then NAT A will typically discard these 531 messages. 533 Suppose A starts sending UDP messages to B's public address, however, 534 and simultaneously relays a request through server S to B, asking B 535 to start sending UDP messages to A's public address. A's outgoing 536 messages directed to B's public address (138.76.29.7:31000) cause NAT 537 A to open up a new communication session between A's private address 538 and B's public address. At the same time, B's messages to A's public 539 address (155.99.25.11:62000) cause NAT B to open up a new 540 communication session between B's private address and A's public 541 address. Once the new UDP sessions have been opened up in each 542 direction, client A and B can communicate with each other directly 543 without further burden on the "introduction" server S. 545 The UDP hole punching technique has several useful properties. Once 546 a direct peer-to-peer UDP connection has been established between two 547 clients behind NAT devices, either party on that connection can in 548 turn take over the role of "introducer" and help the other party 549 establish peer-to-peer connections with additional peers, minimizing 550 the load on the initial introduction server S. The application does 551 not need to attempt to detect the kind of NAT device it is behind, 552 if any [STUN], since the procedure above will establish peer-to-peer 553 communication channels equally well if either or both clients do not 554 happen to be behind a NAT device. The UDP hole punching technique 555 even works automatically with multiple NATs, where one or both 556 clients are removed from the public Internet via two or more levels 557 of address translation. 559 3.3.2. Peers behind the same NAT 561 Now consider the scenario in which the two clients (probably 562 unknowingly) happen to reside behind the same NAT, and are therefore 563 located in the same private IP address space, as in figure 6. 564 Client A has established a UDP session with server S, to which the 565 common NAT has assigned public port number 62000. Client B has 566 similarly established a session with S, to which the NAT has 567 assigned public port number 62001. 569 Server S 570 18.181.0.31:1234 571 | 572 ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ 573 | 18.181.0.31:1234 | | | 18.181.0.31:1234 | 574 | 155.99.25.11:62000 | | | 155.99.25.11:62001 | 575 | 576 +--------------+ 577 | 155.99.25.11 | 578 | | 579 | P2P-friendly | 580 | NAT | 581 +--------------+ 582 | 583 +-----------------------------+----------------------------+ 584 | | 585 | | 586 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 587 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 588 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 589 | | 590 | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ | 591 | | 10.1.1.3:1234 | | 10.0.0.1:1234 | | 592 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 593 | | 594 | ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ | 595 | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | 596 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 597 | | 598 Client A Client B 599 10.0.0.1:1234 10.1.1.3:1234 601 Figure 6: Use local & public identities to communicate with peers. 603 Suppose that A and B use the UDP hole punching technique as outlined 604 above to establish a communication channel using server S as an 605 introducer. Then A and B will learn each other's public IP addresses 606 and port numbers as observed by server S, and start sending each 607 other messages at those public addresses. The two clients will be 608 able to communicate with each other this way as long as the NAT 609 allows hosts on the internal network to open translated UDP sessions 610 with other internal hosts and not just with external hosts. We refer 611 to this situation as "Hairpin translation," because packets arriving 612 at the NAT from the private network are translated and then looped 613 back to the private network rather than being passed through to the 614 public network. For example, when A sends a UDP packet to B's public 615 address, the packet initially has a source IP address and port number 616 of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT 617 receives this packet, translates it to have a source of 618 155.99.25.11:62000 (A's public address) and a destination of 619 10.1.1.3:1234, and then forwards it on to B. Even if hairpin 620 translation is supported by the NAT, this translation and forwarding 621 step is obviously unnecessary in this situation, and is likely to add 622 latency to the dialog between A and B as well as burdening the NAT. 624 The solution to this problem is straightforward, however. When A and 625 B initially exchange address information through server S, they 626 should include their own IP addresses and port numbers as "observed" 627 by themselves, as well as their addresses as observed by S. The 628 clients then simultaneously start sending packets to each other at 629 each of the alternative addresses they know about, and use the first 630 address that leads to successful communication. If the two clients 631 are behind the same NAT, then the packets directed to their private 632 addresses are likely to arrive first, resulting in a direct 633 communication channel not involving the NAT. If the two clients are 634 behind different NATs, then the packets directed to their private 635 addresses will fail to reach each other at all, but the clients will 636 hopefully establish connectivity using their respective public 637 addresses. It is important that these packets be authenticated in 638 some way, however, since in the case of different NATs it is entirely 639 possible for A's messages directed at B's private address to reach 640 some other, unrelated node on A's private network, or vice versa. 642 3.3.3. Peers separated by multiple NATs 644 In some topologies involving multiple NAT devices, it is not 645 possible for two clients to establish an "optimal" P2P route between 646 them without specific knowledge of the topology. Consider for 647 example the situation, depicted in figure 7. 649 Server S 650 18.181.0.31:1234 651 | 652 ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ 653 | 18.181.0.31:1234 | | | 18.181.0.31:1234 | 654 | 155.99.25.11:62000 | | | 155.99.25.11:62001 | 655 | 656 +--------------+ 657 | 155.99.25.11 | 658 | | 659 | P2P-friendly | 660 | NAT X | 661 | (Supporting | 662 | Hairpin | 663 | Translation) | 664 +--------------+ 665 | 666 +----------------------------+----------------------------+ 667 | | 668 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 669 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 670 | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | 671 | | 672 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 673 | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | 674 | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | 675 | | 676 +--------------+ +--------------+ 677 | 192.168.1.1 | | 192.168.1.2 | 678 | | | | 679 | P2P-friendly | | P2P-friendly | 680 | NAT A | | NAT B | 681 +--------------+ +--------------+ 682 | | 683 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 684 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 685 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 686 | | 687 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 688 | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | 689 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 690 | | 691 Client A Client B 692 10.0.0.1:1234 10.1.1.3:1234 694 Figure 7: Hairpin translation support in NAT to facilitate Direct-P2P 696 Suppose NAT X is a large industrial Cone NAT deployed by an internet 697 service provider (ISP) to multiplex many customers onto a few public 698 IP addresses, and NATs A and B are small consumer NAT gateways 699 deployed independently by two of the ISP's customers to multiplex 700 their private home networks onto their respective ISP-provided IP 701 addresses. Only server S and NAT X have globally routable IP 702 addresses; the "public" IP addresses used by NAT A and NAT B are 703 actually private to the ISP's addressing realm, while client A's and 704 B's addresses in turn are private to the addressing realms of NAT A 705 and B, respectively. Each client initiates an outgoing connection to 706 server S as before, causing NATs A and B each to create a single 707 public/private translation, and causing NAT X to establish a 708 public/private translation for each session. 710 Now suppose clients A and B attempt to establish a direct peer-to- 711 peer UDP connection. The optimal method would be for client A to 712 send messages to client B's public address at NAT B, 713 192.168.1.2:31000 in the ISP's addressing realm, and for client B to 714 send messages to A's public address at NAT B, namely 715 192.168.1.1:30000. Unfortunately, A and B have no way to learn these 716 addresses, because server S only sees the "global" public addresses 717 of the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if A 718 and B had some way to learn these addresses, there is still no 719 guarantee that they would be usable because the address assignments 720 in the ISP's private addressing realm might conflict with unrelated 721 address assignments in the clients' private realms. The clients 722 therefore have no choice but to use their global public addresses as 723 seen by S for their P2P communication, and rely on NAT X to provide 724 hairpin translation. 726 3.3.4. Where UDP hole punching fails 728 The UDP hole punching technique has a caveat in that it works only 729 if the traversing NAT is a P2P-friendly NAT. When a symmetric NAT 730 is enroute, P2P application is unable to reuse an already 731 established translation endpoint for communication with different 732 external destinations and the technique would fail. However, Cone 733 NATs are widely deployed in the Internet. That makes the UDP hole 734 punching technique broadly applicable; nevertheless a substantial 735 fraction of deployed NATs are symmetric NATs and do not support 736 the UDP hole punching technique. 738 3.4. Simultaneous TCP Open 740 Simultaneous TCP open (also known sometimes as TCP hole punching) 741 technique is used in some cases to establish direct peer-to-peer 742 TCP connections between a pair of nodes that are both behind 743 P2P-friendly NAT devices that implement Cone NAT behavior on 744 their TCP traffic. Most TCP sessions start with one endpoint 745 sending a SYN packet, to which the other party responds with a 746 SYN-ACK packet. It is permissible, however, for two endpoints to 747 start a TCP session by simultaneously sending each other SYN 748 packets, to which each party subsequently responds with a 749 separate ACK. This procedure is referred as "Simultaneous TCP 750 Open" technique. However, "Simultaneous TCP Open" is not 751 implemented correctly on many systems, including NAT devices. 753 If a NAT device receives a TCP SYN packet from outside the private 754 network attempting to initiate an incoming TCP connection, the 755 NAT device will normally reject the connection attempt by either 756 dropping the SYN packet or sending back a TCP RST (connection reset) 757 packet. In the case of SYN timeout or connection reset, the P2P 758 endpoint will continue to resend a SYN packet, until the peer did 759 the same from its end. 761 When a SYN packet arrives with source and destination addresses and 762 port numbers that correspond to a TCP session that the NAT device 763 believes is already active, then the NAT device will allow the 764 packet to pass through. In particular, if the NAT device has just 765 recently seen and transmitted an outgoing SYN packet with the same 766 addresses and port numbers, then it will consider the session 767 active and allow the incoming SYN through. If clients A and B can 768 each initiate an outgoing TCP connection with the other client 769 timed so that each client's outgoing SYN passes through its local 770 NAT device before either SYN reaches the opposite NAT device, 771 then a working peer-to-peer TCP connection will result. 773 This technique may not always work reliably for the following 774 reason(s). If either node's SYN packet arrives at the remote 775 NAT device too quickly (before the peering node had a chance to 776 send the SYN packet), then the remote NAT device may either 777 drop the SYN packet or reject the SYN with a RST packet. This 778 could cause the local NAT device in turn to close the new 779 NAT-session immediately or initiate end-of-session timeout 780 (refer section 2.6 of [NAT-TERM]) so as to close the 781 NAT-session at the end of the timeout. Even as both peering 782 nodes simultaneously initiate continued SYN retransmission 783 attempts, some remote NAT devices might not let the incoming 784 SYNs through if the NAT session is in end-of-session timeout 785 state. This in turn would cause the TCP connection to be not 786 established. 788 3.5. UDP port number prediction 790 A variant of the UDP hole punching technique exists that allows 791 peer-to-peer UDP sessions to be created in the presence of some 792 symmetric NATs. This method is sometimes called the "N+1" 793 technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. 794 The method works by analyzing the behavior of the NAT and attempting 795 to predict the public port numbers it will assign to future sessions. 796 Consider again the situation in which two clients, A and B, each 797 behind a separate NAT, have each established UDP connections with a 798 permanently addressable server S, as depicted in figure 8. 800 Server S 801 18.181.0.31:1234 802 | 803 +----------------------------+----------------------------+ 804 | | 805 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 806 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 807 | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | 808 | | 809 | | 810 +--------------+ +-------------+ 811 | 155.99.25.11 | | 138.76.29.7 | 812 | | | | 813 | Symmetric | | Symmetric | 814 | NAT A | | NAT B | 815 +--------------+ +-------------+ 816 | | 817 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 818 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 819 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 820 | | 821 Client A Client B 822 10.0.0.1:1234 10.1.1.3:1234 824 Figure 8: Use Peer's Symmetric-NAT Identity to predict P2P port 826 NAT A has assigned its own UDP port 62000 to the communication 827 session between A and S, and NAT B has assigned its port 31000 to 828 the session between B and S. By communicating through server S, A 829 and B learn each other's public IP addresses and port numbers as 830 observed by S. Client A now starts sending UDP messages to port 831 31001 at address 138.76.29.7 (note the port number increment), and 832 client B simultaneously starts sending messages to port 62001 at 833 address 155.99.25.11. If NATs A and B assign port numbers to new 834 sessions sequentially, and if not much time has passed since the 835 A-S and B-S sessions were initiated, then a working bi-directional 836 communication channel between A and B should result. A's messages 837 to B cause NAT A to open up a new session, to which NAT A will 838 (hopefully) assign public port number 62001, because 62001 is next 839 in sequence after the port number 62000 it previously assigned to 840 the session between A and S. Similarly, B's messages to A will 841 cause NAT B to open a new session, to which it will (hopefully) 842 assign port number 31001. If both clients have correctly guessed 843 the port numbers each NAT assigns to the new sessions, then a 844 bi-directional UDP communication channel will have been 845 established as shown in figure 9.. 847 Server S 848 18.181.0.31:1234 849 | 850 | 851 +----------------------------+----------------------------+ 852 | | 853 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 854 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 855 | | 155.99.25.11:62000 | | 138.76.29.7:31000 | | 856 | | 857 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 858 | | 138.76.29.7:31001 | | 155.99.25.11:62001 | | 859 | | 155.99.25.11:62001 | | 138.76.29.7:31001 | | 860 | | 861 +--------------+ +-------------+ 862 | 155.99.25.11 | | 138.76.29.7 | 863 | | | | 864 | Symmetric | | Symmetric | 865 | NAT A | | NAT B | 866 +--------------+ +-------------+ 867 | | 868 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 869 | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | 870 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 871 | | 872 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 873 | | 138.76.29.7:31001 | | 155.99.25.11:62001 | | 874 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 875 | | 876 Client A Client B 877 10.0.0.1:1234 10.1.1.3:1234 879 Figure 9: Use Port Prediction on Symmetric NATs to setup Direct-p2p 881 Clearly, there are many things that can cause this trick to fail. 882 If the predicted port number at either NAT already happens to be in 883 use by an unrelated session, then the NAT will skip over that port 884 number and the connection attempt will fail. If either NAT sometimes 885 or always chooses port numbers non-sequentially, then the trick will 886 fail. If a different client behind NAT A (or B respectively) opens 887 up a new outgoing UDP connection to any external destination after A 888 (B) establishes its connection with S but before sending its first 889 message to B (A), then the unrelated client will inadvertently 890 "steal" the desired port number. This trick is therefore much less 891 likely to work when either NAT involved is under load. 893 Since in practice a P2P application implementing this trick would 894 still need to work if the NATs are cone NATs, or if one is a cone NAT 895 and the other is a symmetric NAT, the application would need to 896 detect beforehand what kind of NAT is involved on either end [STUN] 897 and modify its behavior accordingly, increasing the complexity of the 898 algorithm and the general brittleness of the network. Finally, port 899 number prediction has no chance of working if either client is behind 900 two or more levels of NAT and the NAT(s) closest to the client are 901 symmetric. For all of these reasons, it is NOT recommended that new 902 applications implement this trick. This technique is mentioned here 903 only for historical and informational purposes. 905 3.6. TCP port number prediction 907 This is a variant of the "Simultaneous TCP open" technique that 908 allows peer-to-peer TCP sessions to be created in the presence of 909 some symmetric NATs. 911 Unfortunately, this trick may be even more fragile and timing- 912 sensitive than the UDP port number prediction trick described 913 earlier. First, even as both NAT devices implement Cone NAT 914 behavior on the TCP traffic, all the same things can go wrong 915 with each side's attempt to predict the public port numbers 916 that the respective NATs will assign to the new sessions can 917 happen with TCP port prediction as well. In addition, if either 918 client's SYN arrives at the opposite NAT device too quickly, then 919 the remote NAT device may reject the SYN with a RST packet, 920 causing the local NAT device in turn to close the new session 921 and make future SYN retransmission attempts using the same port 922 numbers futile. For this reason, this trick is mentioned here 923 only for historical reasons. It is NOT recommended for use by 924 applications. 926 4. Summary of observations 928 4.1. TCP/UDP hole punching 930 TCP/UDP hole punching is the most efficient existing method of 931 establishing direct TCP/UDP peer-to-peer communication between 932 two nodes that are both behind NATs. This technique has been 933 used with a wide variety of existing NATs. However, 934 applications should be prepared to fall back to simple relaying 935 when direct communication cannot be established. 937 4.2. Symmetric NATs are not P2P friendly 939 Symmetric NATs gained popularity with client-server applications 940 such as web browsers, which only need to initiate outgoing 941 connections. However, in the recent times, P2P applications such 942 as Instant messaging and audio conferencing have been in wide 943 use. Symmetric NATs do not support TCP/UDP Port Binding and are 944 not suitable for P2P applications. 946 4.3. Peer discovery 948 Applications should not assume all its peers to be outside its 949 NAT boundary. As such, an application should register all its 950 private IP addresses with the external server, so it can 951 connect to some of its peers within the NAT boundary without 952 having to traverse the NAT device. 954 4.4. Hairpin translation 956 Hairpin translation support is highly beneficial to allow 957 hosts behind a p2p-friendly NAT to communicate with other hosts 958 behind the same NAT device through their public, possibly 959 translated endpoints. Support for hairpin translation is 960 particularly useful in the case of large-capacity NATs deployed 961 as the first level of a multi-level NAT scenario. As described 962 in section 3.3.3, hosts behind the same first-level NAT but 963 different second-level NATs do not have a way to communicate 964 with each other using TCP/UDP hole punching technique, unless 965 the first-level NAT also supports hairpin translation. This 966 would be the case even when all NAT devices in the deployment 967 preserve endpoint identities, 969 5. Security considerations 971 This document does not inherently create new security issues. 972 Nevertheless, security risks may be present in the techniques 973 described. This section describes security risks the 974 applications could inadvertently create in attempting to 975 support P2P communication across NAT devices. Also described 976 are implications for the security policies of P2P-friendly 977 NAT devices. 979 5.1. Lack of Authentication can cause connection hijacking 981 NAT-friendly P2P applications must use appropriate authentication 982 mechanisms to protect their P2P connections from accidental 983 confusion with other P2P connections as well as from malicious 984 connection hijacking or denial-of-service attacks. NAT-friendly 985 P2P applications effectively must interact with multiple distinct 986 IP address domains, but are not generally aware of the exact 987 topology or administrative policies defining these address 988 domains. While attempting to establish P2P connections via 989 TCP/UDP hole punching, applications send packets that may 990 frequently arrive at an entirely different host than the 991 intended one. 993 For example, many consumer-level NAT devices provide DHCP 994 services that are configured by default to hand out site-local 995 IP addresses in a particular address range. Say, a particular 996 consumer NAT device, by default, hands out IP addresses starting 997 with 192.168.1.100. Most private home networks using that NAT 998 device will have a host with that IP address, and many of these 999 networks will probably have a host at address 192.168.1.101 as 1000 well. If host A at address 192.168.1.101 on one private network 1001 attempts to establish a connection by UDP hole punching with 1002 host B at 192.168.1.100 on a different private network, then as 1003 part of this process host A will send discovery packets to 1004 address 192.168.1.100 on its local network, and host B will send 1005 discovery packets to address 192.168.1.101 on its network. Clearly, 1006 these discovery packets will not reach the intended machine since 1007 the two hosts are on different private networks, but they are very 1008 likely to reach SOME machine on these respective networks at the 1009 standard UDP port numbers used by this application, potentially 1010 causing confusion, especially if the application is also running 1011 on those other machines and does not properly authenticate its 1012 messages. 1014 This risk due to aliasing is therefore present even without a 1015 malicious attacker. If one endpoint, say host A, is actually 1016 malicious, then without proper authentication the attacker could 1017 cause host B to connect and interact in unintended ways with 1018 another host on its private network having the same IP address 1019 as the attacker's (purported) private address. Since the two 1020 endpoint hosts A and B presumably discovered each other through 1021 a public server S, and neither S nor B has any means to verify 1022 A's reported private address, all P2P applications must assume 1023 that any IP address they find to be suspect until they successfully 1024 establish authenticated two-way communication. 1026 5.2. Denial-of-service attacks 1028 P2P applications and the public servers that support them must 1029 protect themselves against denial-of-service attacks, and ensure 1030 that they cannot be used by an attacker to mount denial-of-service 1031 attacks against other targets. To protect themselves, P2P 1032 applications and servers must avoid taking any action requiring 1033 significant local processing or storage resources until 1034 authenticated two-way communication is established. To avoid being 1035 used as a tool for denial-of-service attacks, P2P applications and 1036 servers must minimize the amount and rate of traffic they send to 1037 any newly-discovered IP address until after authenticated two-way 1038 communication is established with the intended target. 1040 For example, P2P applications that register with a public rendezvous 1041 server can claim to have any private IP address, or perhaps multiple 1042 IP addresses. A well-connected host or group of hosts that can 1043 collectively attract a substantial volume of P2P connection attempts 1044 (e.g., by offering to serve popular content) could mount a 1045 denial-of-service attack on a target host C simply by including C's 1046 IP address in their own list of IP addresses they register with the 1047 rendezvous server. There is no way the rendezvous server can verify 1048 the IP addresses, since they could well be legitimate private 1049 network addresses useful to other hosts for establishing 1050 network-local communication. The P2P application protocol must 1051 therefore be designed to size- and rate-limit traffic to unverified 1052 IP addresses in order to avoid the potential damage such a 1053 concentration effect could cause. 1055 5.3. Man-in-the-middle attacks 1057 Any network device on the path between a P2P client and a 1058 rendezvous server can mount a variety of man-in-the-middle 1059 attacks by pretending to be a NAT. For example, suppose 1060 host A attempts to register with rendezvous server S, but a 1061 network-snooping attacker is able to observe this registration 1062 request. The attacker could then flood server S with requests 1063 that are identical to the client's original request except with 1064 a modified source IP address, such as the IP address of the 1065 attacker itself. If the attacker can convince the server to 1066 register the client using the attacker's IP address, then the 1067 attacker can make itself an active component on the path of all 1068 future traffic from the server AND other P2P hosts to the 1069 original client, even if the attacker was originally only able 1070 to snoop the path from the client to the server. 1072 The client cannot protect itself from this attack by 1073 authenticating its source IP address to the rendezvous server, 1074 because in order to be NAT-friendly the application must allow 1075 intervening NATs to change the source address silently. This 1076 appears to be an inherent security weakness of the NAT paradigm. 1077 The only defense against such an attack is for the client to 1078 authenticate and potentially encrypt the actual content of its 1079 communication using appropriate higher-level identities, so that 1080 the interposed attacker is not able to take advantage of its 1081 position. Even if all application-level communication is 1082 authenticated and encrypted, however, this attack could still be 1083 used as a traffic analysis tool for observing who the client is 1084 communicating with. 1086 5.4. Security impact from a P2P-friendly NAT device 1088 Designing NAT devices to preserve endpoint identities does not 1089 weaken the security provided by the NAT device. For example, a 1090 Port-Restricted Cone NAT is inherently no more "promiscuous" 1091 than a Symmetric NAT in its policies for allowing either 1092 incoming or outgoing traffic to pass through the NAT device. 1093 As long as outgoing TCP/UDP sessions are enabled and the NAT 1094 device maintains consistent Binding between internal and external 1095 TCP/UDP ports, the NAT device will filter out any incoming TCP/UDP 1096 packets that do not match the active sessions initiated from 1097 within the enclave. Filtering incoming traffic aggressively while 1098 maintaining consistent Port Bindings thus allows a NAT device to 1099 be P2P friendly without compromising the principle of rejecting 1100 unsolicited incoming traffic. 1102 Maintaining consistent Port Binding could arguably increase the 1103 predictability of traffic emerging from the NAT device, by revealing 1104 the relationships between different UDP sessions and hence about 1105 the behavior of applications running within the enclave. This 1106 predictability could conceivably be useful to an attacker in 1107 exploiting other network or application level vulnerabilities. 1108 If the security requirements of a particular deployment scenario 1109 are so critical that such subtle information channels are of 1110 concern, however, then the NAT device almost certainly should not be 1111 configured to allow unrestricted outgoing TCP/UDP traffic in the 1112 first place. Such a NAT device should only allow communication 1113 originating from specific applications at specific ports, or 1114 via tightly-controlled application-level gateways. In this 1115 situation there is no hope of generic, transparent peer-to-peer 1116 connectivity across the NAT device (or transparent client/server 1117 connectivity for that matter); the NAT device must either 1118 implement appropriate application-specific behavior or disallow 1119 communication entirely. 1121 6. IANA Considerations 1123 There are no IANA considerations. 1125 7. Acknowledgments 1127 The authors wish to thank Henrik, Dave, and Christian Huitema 1128 for their valuable feedback. 1130 8. Normative References 1132 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 1133 (NAT) Terminology and Considerations", RFC 2663, August 1134 1999. 1136 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 1137 Translator (Traditional NAT)", RFC 3022, January 2001. 1139 [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, 1140 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1141 Through Network Address Translators (NATs)", RFC 3489, 1142 March 2003. 1144 9. Informative References 1146 [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design 1147 Guidelines for Traversal through Network Address 1148 Translators", draft-ford-behave-app-02.txt (Work In 1149 Progress), March 2006. 1151 [BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, 1152 "Bidirectional Peer-to-Peer Communication with Interposing 1153 Firewalls and NATs", August 2001. 1154 http://www.peer-to-peerwg.org/tech/nat/ 1156 [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): 1157 A Methodology for Network Address Translator (NAT) Traversal 1158 for Offer/Answer Protocols", draft-ietf-mmusic-ice-08 1159 (work in Progress), March, 2006. 1161 [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. 1162 http://www.alumni.caltech.edu/~dank/peer-nat.html 1164 [MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and 1165 Rayhan, A., "Middlebox communication architecture and 1166 framework", RFC 3303, August 2002. 1168 [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly 1169 Application Design Guidelines", RFC 3235, January 2002. 1171 [NAT-PMP] Cheshire, S., Krochmal, M., and Sekar, K., "NAT Port 1172 Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-00.txt 1173 (Work In Progress), June 2005. 1175 [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications 1176 with the IP Network Address Translator", RFC 3027, 1177 January 2001. 1179 [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address 1180 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1181 February 2000. 1183 [NSIS-NSLP] Stiemerling,M., Tschofenig, H., Aoun, C., and, Davies, E., 1184 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1185 draft-ietf-nsis-nslp-natfw-11.txt (Work In Progress), 1186 April 2006. 1188 [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm 1189 Specific IP: Framework", RFC 3102, October 2001. 1191 [SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R.,Koblas, D., and, 1192 Jones, L., "SOCKS Protocol Version 5", RFC 1928, 1193 March 1996. 1195 [SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", 1196 draft-takeda-symmetric-nat-traversal-00 (Work In 1197 Progress), June 2003. 1199 [TURN] J. Rosenberg, R. Mahy, and C. Huitema, 1200 "Traversal Using Relay NAT (TURN)", 1201 draft-rosenberg-midcom-turn-08.txt (Work In Progress), 1202 September 2005. 1204 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 1205 Self-Address Fixing (UNSAF) Across Network Address 1206 Translation", RFC 3424, November 2002. 1208 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1209 Device Control Protocol V 1.0", November 2001. 1210 http://www.upnp.org/standardizeddcps/igd.asp 1212 10. Authors' Addresses 1214 Pyda Srisuresh 1215 Consultant 1216 20072 Pacifica Dr. 1217 Cupertino, CA 95014 1218 U.S.A. 1219 Phone: (408)836-4773 1220 E-mail: srisuresh@yahoo.com 1222 Bryan Ford 1223 Laboratory for Computer Science 1224 Massachusetts Institute of Technology 1225 77 Massachusetts Ave. 1226 Cambridge, MA 02139 1227 Phone: (617) 253-5261 1228 E-mail: baford@mit.edu 1229 Web: http://www.brynosaurus.com/ 1231 Dan Kegel 1232 Kegel.com 1233 901 S. Sycamore Ave. 1234 Los Angeles, CA 90036 1235 Phone: 323 931-6717 1236 Email: dank@kegel.com 1237 Web: http://www.kegel.com/ 1239 Intellectual Property Statement 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Copyright Statement 1265 Copyright (C) The Internet Society (2006). 1267 This document is subject to the rights, licenses and restrictions 1268 contained in BCP 78, and except as set forth therein, the authors 1269 retain all their rights. 1271 This document and the information contained herein are provided on an 1272 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1273 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1274 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1275 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1276 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1277 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1279 Acknowledgment 1281 Funding for the RFC Editor function is currently provided by the 1282 Internet Society.