idnits 2.17.1 draft-ford-behave-top-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1088. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 20 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Ideally, ISPs SHOULD not use NAT devices to connect their customers, so the customers do not get caught up in a multi-level NAT scenario and hairpin session flows. NAT devices MUST support hairpin translations for all protocol sessions the NAT device supports. Hairpin translation support is a requirement for peer node connectivity in multi-level NAT topologies. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Recommendation-4. Ideally, ISPs SHOULD not use NAT devices to provide connectivity to their customers. If they do, any servers on the ISP's private network that need to be accessible to the ISP's customers (e.g., mail servers) SHOULD have global IP addresses, to ensure accessibility to customers who deploy NAT devices themselves. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Recommendation-4. Ideally, ISPs SHOULD not use NAT devices to provide connectivity to their customers. If they do, any servers on the ISP's private network that need to be accessible to the ISP's customers (e.g., mail servers) SHOULD have global IP addresses, to ensure accessibility to customers who deploy NAT devices themselves. -- 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 (July 29, 2006) is 6453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') == Outdated reference: A later version (-04) exists of draft-srisuresh-behave-p2p-state-03 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Srisuresh 3 Document: draft-ford-behave-top-02.txt Consultant 4 Expires: January 29, 2007 B. Ford 5 M.I.T. 6 July 29, 2006 8 Complications from Network Address Translator Deployment Topologies 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document identifies two deployment scenarios that have arisen 37 from the unconventional network topologies formed using Network 38 Address Translator devices (NATs). First, the simplicity of 39 administering networks through the combination of NAT and DHCP has 40 increasingly lead to the deployment of multi-level hierarchies of 41 inter-connected private networks involving overlapping IP address 42 spaces. Second, the proliferation of private networks in enterprises, 43 hotels and conferences alike, and the wide spread use of remote 44 access Virtual Private Networks (VPNs) to access enterprise intranet 45 has increasingly lead to overlapping IP address space between remote 46 and corporate networks. The document does not dismiss these 47 unconventional scenarios as invalid, but recognizes them as real and 48 offers recommendations to ensure these real scenarios do work. 50 Table of Contents 52 1. Introduction and Scope........................................ 53 2. Multi-Level NAT Network Topologies ........................... 54 2.1 Operational Details of the Multi-Level NAT Network ....... 55 2.1.1. Client/Server Communication ....................... 56 2.1.2. Peer-to-Peer Communication ........................ 57 2.2. Anomalies of the Multi-Level NAT Network ................ 58 2.2.1. Plug-and-Play NAT Devices ......................... 59 2.2.2. Unconventional Addressing on NAT Devices .......... 60 2.2.3. Multi-Level NAT Translations ...................... 61 2.2.4. Mistaken End Host Identity ........................ 62 2.3. Summary of Recommendations .............................. 63 3. Remote Access VPN Network Topologies ......................... 64 3.1. Operational Details of the Remote Access VPN Network .... 65 3.2. Anomalies of the Remote Access VPN Network .............. 66 3.2.1. Remote Router and DHCP Server Address Conflict ... 67 3.2.2. Simultaneous Connectivity Conflict ............... 68 3.2.3. VIP Address Conflict ............................. 69 3.2.4. Mistaken End Host Identity ....................... 70 3.3. Summary of Recommendations .............................. 71 4. Security Considerations ...................................... 72 5. Acknowledgements ............................................. 73 6. Normative References ......................................... 74 7. Informational References ..................................... 76 1. Introduction and Scope 78 The Internet was originally designed to use a single, global 32-bit 79 IP address space to uniquely identify hosts on the network, allowing 80 applications on one host to address and initiate communications with 81 applications on any other host regardless of the respective hosts' 82 topological locations or administrative domains. For a variety of 83 pragmatic reasons, however, the Internet has gradually drifted away 84 from strict conformance to this ideal of a single flat global address 85 space, and towards a hierarchy of smaller "private" address spaces 86 [RFC1918] clustered around a large central "public" address space. 87 The most important pragmatic causes of this unintended evolution of 88 the Internet's architecture appear to be the following. 90 1. Depletion of the 32-bit IPv4 address space due to the exploding 91 total number of hosts on the Internet. Although IPv6 promises to 92 solve this problem, the uptake of IPv6 has in practice been slower 93 than expected. 95 2. Perceived Security and Privacy: Traditional NAT devices provide a 96 filtering function that permits session flows to cross the NAT in 97 just one direction, from private hosts to public network hosts. 98 This filtering function is widely perceived as a security benefit. 99 In addition, the NAT's translation of a host's original IP 100 addresses and port number in private network into an unrelated, 101 external IP address and port number is perceived by some as a 102 privacy benefit. 104 3. Ease-of-use: NAT vendors often combine the NAT function with a 105 DHCP server function in the same device, which creates a 106 compelling, effectively "plug-and-play" method of setting up small 107 Internet-attached personal networks that is often much easier in 108 practice for unsophisticated consumers than configuring an 109 IP subnet. The many popular and inexpensive consumer NAT devices 110 on the market are usually configured "out of the box" to obtain a 111 single "public" IP address from an ISP or "upstream" network via 112 DHCP, and the NAT device in turn acts as both a DHCP server and 113 default router for any "downstream" hosts (and even other NATs) 114 that the user plugs into it. Consumer NATs in this way effectively 115 create and manage private home networks automatically without 116 requiring any knowledge of network protocols or management on the 117 part of the user. Auto-configuration of private hosts makes 118 NAT devices a compelling solution in this common scenario. 120 The term NAT used throughout the document refers to the traditional 121 NAT, as defined in [NAT-TERM] and specified in [NAT-TRAD]. 123 [NAT-PROT] identifies various complications with application 124 protocols due to NAT devices. This document acts as an adjunct to 125 [NAT-PROT]. The scope of the document is restricted to the two 126 scenarios identified in sections 2 and 3, as arising out of 127 unconventional NAT deployment and private address space overlap. 128 Even though the scenarios appear unconventional, they are real and 129 and not uncommon to find. For each scenario, the document describes 130 the seeming anomalies and offers recommendations on how best to make 131 the topologies work. 133 Section 2 describes the problem of private address space overlap 134 due to multi-level NAT topology, the anomalies with the topology and 135 recommendations to address the anomalies. Section 3 describes the 136 problem of private address space overlap with remote access 137 Virtual Private Network (VPN) connection, the anomalies with 138 address overlap and recommendations to address the anomalies. 139 Section 4 describes the security considerations in these scenarios. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2 Multi-Level NAT Network Topologies 147 Due to the pragmatic considerations discussed in the previous 148 section and perhaps others, NATs are increasingly, and often 149 unintentionally, used to create hierarchically interconnected 150 clusters of private networks as illustrated in figure 1 below. The 151 creation of multi-level hierarchies is often unintentional, since 152 each level of NAT is typically deployed by a separate 153 administrative entity such as an ISP, a corporation, or a home user. 155 Public Internet 156 (Public IP addresses) 157 ----+---------------+---------------+---------------+---- 158 | | | | 159 | | | | 160 66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1 161 +-------+ Host A Host B +-------------+ 162 | NAT-1 | (Alice) (Jim) | NAT-2 | 163 | (Bob) | | (CheapoISP) | 164 +-------+ +-------------+ 165 10.1.1.1 10.1.1.1 166 | | 167 | | 168 Private Network 1 Private Network 2 169 (private IP addresses) (private IP addresses) 170 ----+--------+---- ----+-----------------------+---- 171 | | | | | 172 | | | | | 173 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 174 Host C Host D +-------+ Host E +-------+ 175 | NAT-3 | (Mary) | NAT-4 | 176 | (Ann) | | (Lex) | 177 +-------+ +-------+ 178 10.1.1.1 10.1.1.1 179 | | 180 | | 181 Private Network 3 | Private Network 4 182 (private IP addresses)| (private IP addresses) 183 ----+-----------+---+ ----+-----------+---- 184 | | | | 185 | | | | 186 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 187 Host F Host G Host H Host I 189 Figure 1. Multi-level NAT topology with Overlapping Address Space 190 In the above scenario, Bob, Alice, Jim, and CheapoISP have each 191 obtained a "genuine", globally routable IP address from an upstream 192 service provider. Alice and Jim have chosen to attach only a single 193 machine at each of these public IP addresses, preserving the 194 originally intended architecture of the Internet and making their 195 hosts, A and B, globally addressable throughout the Internet. Bob, 196 in contrast, has purchased and attached a typical consumer NAT box. 197 Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP 198 via DHCP, and automatically creates a private 10.1.1.x network for 199 Bob's hosts C and D, acting as the DHCP server and default router for 200 this private network. Bob probably does not even know anything about 201 IP addresses; he merely knows that plugging the NAT into the Internet 202 as instructed by the ISP, and then plugging his hosts into the NAT as 203 the NAT's manual indicates, seems to work and gives all of his hosts 204 access to Internet. 206 CheapoISP, an inexpensive service provider, has allocated only one or 207 a few globally routable IP addresses, and uses NAT to share these 208 public IP addresses among its many customers. Such an arrangement is 209 becoming increasingly common, especially in rapidly-developing 210 countries where the exploding number of Internet-attached hosts 211 greatly outstrips the ability of ISPs to obtain globally unique IP 212 addresses for them. CheapoISP has chosen the popular 10.1.1.x 213 address for its private network, since this is one of the three 214 well-known private IP address blocks allocated in [RFC1918] 215 specifically for this purpose. 217 Of the three incentives listed in section 1 for NAT deployment, the 218 last two still apply even to customers of ISPs that use NAT, 219 resulting in multi-level NAT topologies as illustrated in the right 220 side of the above diagram. Even three-level NAT topologies are known 221 to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained 222 a single IP address on CheapoISP's network (Private Network 2), via 223 DHCP. Mary attaches only a single host at this point, but 224 Ann and Lex each independently purchase and deploy consumer NATs in 225 the same way that Bob did above. As it turns out, these consumer 226 NATs also happen to use 10.1.1.x addresses for the private networks 227 they create, since these are the configuration defaults hard-coded 228 into the NATs by their vendors. Ann and Lex probably know nothing 229 about IP addresses, and in particular they are probably unaware that 230 the IP address spaces of their own private networks overlap not only 231 with each other but also with the private IP address space used by 232 their immediately upstream network. 234 Nevertheless, despite this direct overlap, all of the "multi-level 235 NATted hosts" - F, G, H, and I in this case - all nominally function 236 and are able to initiate connections to any public server on the 237 public Internet that has a globally routable IP address. Connections 238 made from these hosts to the main Internet are merely translated 239 twice. Once by the consumer NAT (NAT-3 or NAT-44) into the IP 240 address space of CheapoISP's Private Network 2, and then again by 241 CheapoISP's NAT-2 into the public Internet's global IP address 242 space. 244 2.1 Operational Details of the Multi-Level NAT Network 246 In the "de facto" Internet address architecture that has resulted 247 from the above pragmatic and economic incentives, only the nodes on 248 the public Internet have globally unique IP addresses assigned by 249 the official IP address registries. IP addresses on different 250 private networks are typically managed independently - either 251 manually by the administrator of the private network itself, or 252 automatically by the NAT through which the private network is 253 connected to its "upstream" service provider. 255 By convention, nodes on private networks are usually assigned IP 256 addresses in one of the private address space ranges specifically 257 allocated to this purpose in RFC 1918, ensuring that private IP 258 addresses are easily distinguishable and do not conflict with the 259 public IP addresses officially assigned to globally routable Internet 260 hosts. However, when "plug-and-play" NATs are used to create 261 hierarchically interconnected clusters of private networks, a given 262 private IP address can be and often is reused across many different 263 private networks. In figure 1 above, for example, private networks 264 1, 2, 3, and 4 all have a node with IP address 10.1.1.10. 266 2.1.1. Client/Server Communication 268 When a host on a private network initiates a client/server-style 269 communication session with a server on the public Internet, via the 270 server's public IP address, the NAT intercepts the packets comprising 271 that session (usually as a consequence of being the default router 272 for the private network), and modifies the packets' IP and TCP/UDP 273 headers so as to make the session appear externally as if it was 274 initiated by the NAT itself. 276 For example, if host C above initiates a connection to host A at IP 277 address 18.181.0.31, NAT-1 modifies the packets comprising the 278 session so as to appear on the public Internet as if the session 279 originated from NAT-1. Similarly, if host F on private network 3 280 initiates a connection to host A, NAT-3 modifies the outgoing packet 281 so the packet appears on private network 2 as if it had originated 282 from NAT-3 at IP address 10.1.1.10. When the modified packet 283 traverses NAT-2 on private network 2, NAT-2 further modifies the 284 outgoing packet so as to appear on the public Internet as if it had 285 originated from NAT-2 at public IP address 155.99.25.1. The NATs in 286 effect serve as proxies that give their private "downstream" client 287 nodes a temporary presence on "upstream" networks to support 288 individual communication sessions. 290 In summary, all hosts on the private networks 1, 2, 3, and 4 in 291 figure 1 above are able to establish a client/server-style 292 communication sessions with servers on the public Internet. 294 2.1.2. Peer-to-Peer Communication 296 While this network organization functions in practice for 297 client/server-style communication, when the client is behind one or 298 more levels of NAT and the server is on the public Internet, the lack 299 of globally routable addresses for hosts on private networks makes 300 direct peer-to-peer communication between those hosts difficult. For 301 example, two private hosts F and H on the network shown above might 302 "meet" and learn of each other through a well-known server on the 303 public Internet, such as Host A, and desire to establish direct 304 communication between G and H without requiring A to forward each 305 packet. If G and H merely learn each other's (private) IP addresses 306 from a registry kept by A, their attempts to connect to each other 307 will fail because G and H reside on different private networks. 308 Worse, if their connection attempts are not properly authenticated, 309 they may appear to succeed but end up talking to the wrong host. For 310 example, G may end up talking to Host F, the host on private 311 network 3 that happens to have the same private IP address as Host H. 312 Host H might similarly end up unintentionally connecting to Host I. 314 In summary, peer-to-peer communication between hosts on disjoint 315 private networks 1, 2, 3, and 4 in figure 1 above is a challenge 316 without the assistance of a well known server on the public 317 Internet. However, with assistance from a node in the public 318 Internet, all hosts on the private networks 1, 2, 3, and 4 in 319 figure 1 above are able to establish a peer-to-peer style 320 communication sessions amongst themselves as well as with hosts 321 on the public Internet. 323 2.2. Anomalies of the Multi-Level NAT Network 325 Even though conventional wisdom would suggest that the network 326 described above is seriously broken, in practice it still works in 327 many ways. We break up figure 1 into two sub figures to better 328 illustrate the anomalies. Figure 1.1 is the left half of figure 1 329 and reflects the conventional single NAT deployment that is widely 330 prevalent in many last-mile locations. The deployment in figure 1.1 331 is popularly viewed as a pragmatic solution to work around the 332 depletion of IPv4 address space and is not considered broken. 333 Figure 1.2 is the right half of figure-1 and is representative of 334 the anomalies we are about to discuss. 336 Public Internet 337 (Public IP addresses) 338 ----+---------------+---------------+----------- 339 | | | 340 | | | 341 66.39.3.7 18.181.0.31 138.76.29.7 342 +-------+ Host A Host B 343 | NAT-1 | (Alice) (Jim) 344 | (Bob) | 345 +-------+ 346 10.1.1.1 347 | 348 | 349 Private Network 1 350 (private IP addresses) 351 ----+--------+---- 352 | | 353 | | 354 10.1.1.10 10.1.1.11 355 Host C Host D 357 Figure 1.1. Conventional Single-level NAT Network topology 358 Public Internet 359 (Public IP addresses) 360 ---+---------------+---------------+---- 361 | | | 362 | | | 363 18.181.0.31 138.76.29.7 155.99.25.1 364 Host A Host B +-------------+ 365 (Alice) (Jim) | NAT-2 | 366 | (CheapoISP) | 367 +-------------+ 368 10.1.1.1 369 | 370 | 371 Private Network 2 372 (private IP addresses) 373 ----+---------------+-------------+--+------- 374 | | | 375 | | | 376 10.1.1.10 10.1.1.11 10.1.1.12 377 +-------+ Host E +-------+ 378 | NAT-3 | (Mary) | NAT-4 | 379 | (Ann) | | (Lex) | 380 +-------+ +-------+ 381 10.1.1.1 10.1.1.1 382 | | 383 | | 384 Private Network 3 Private Network 4 385 (private IP addresses) (private IP addresses) 386 ----+-----------+------ ----+-----------+---- 387 | | | | 388 | | | | 389 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 390 Host F Host G Host H Host I 392 Figure 1.2. Unconventional Multi-level NAT Network topology 394 2.2.1. Plug-and-Play NAT Devices 396 Consumer NAT devices are predominantly "plug-and-play" NAT devices, 397 and assume minimal user intervention during device setup. The 398 "plug-and-play" NAT devices provide DHCP service on one interface 399 and NAT function on another interface. Vendors of the consumer NAT 400 devices make assumptions about how their consumers configure and 401 hook up their PCs to the device. When consumers do not adhere to the 402 vendor assumptions, the consumers end up with a broken network. 404 A "plug-and-play" NAT device provides DHCP service on the LAN 405 attached to the private interface, and assumes that all private 406 hosts at the consumer site have DHCP client enabled and are 407 connected to the single LAN. Consumers SHOULD be informed of the 408 assumption that all private hosts MUST be on a single LAN, with no 409 router in between. 411 A "Plug-and-Play" NAT device also assumes that there is no other 412 NAT device or DHCP server device on the same LAN at the customer 413 premises. When there are multiple "Plug-and-play" NAT devices on 414 the same LAN, each NAT device will offer DHCP service on the same 415 LAN, and likely from the same address pool. This could result 416 in multiple end nodes on the same LAN ending up with identical IP 417 addresses. That will break network connectivity to end hosts. 418 Consumers SHOULD be cautioned against using more than one 419 "plug-and-play" NAT device on the same LAN. 421 Recommendation-1. Consumers SHOULD be informed that all private 422 hosts behind a "Plug-and-play" NAT must be on a single LAN subnet, 423 and that there SHOULD be no more than one "Plug-and-play" NAT device 424 on the same LAN. 426 2.2.2. Unconventional Addressing on NAT Devices 428 Let us consider the unconventional addressing with NAT-3 and 429 NAT-4. NAT-3 and NAT-4 are apparently multi-homed on the same 430 subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 431 through its external interface facing NAT-2, as well as through its 432 private interface facing clients Host-F and Host-G. Likewise, NAT-4 433 also has two interfaces on the same subnet 10.1.1/24. 435 In a traditional network, when a node has multiple interfaces with 436 IP addresses on the same subnet, it is natural to assume that all 437 interfaces with addresses on the same subnet must be on a single 438 connected LAN (bridged LAN or a single physical LAN). Clearly, that 439 is not the case here. Even though both NAT-3 and NAT-4 have two 440 interfaces on the same subnet 10.1.1/24, the NAT devices view the 441 two interfaces as being on two disjoint subnets and routing realms. 442 The "plug-and-play" NAT devices are really not multi-homed on the 443 same subnet as in a traditional sense. 445 In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should 446 be incapable of communicating reliably as a transport endpoint with 447 other nodes on their adjacent networks (ex: private networks 2 and 448 3 in the case of NAT-3 and private Networks 2 and 4 in the case of 449 NAT-4). This is because applications on either of the NAT devices 450 cannot know to differentiate packets from hosts on either of the 451 subnets bearing the same IP address. If NAT-3 attempts to resolve 452 the IP address of a neighboring host in the conventional manner by 453 broadcasting an ARP request on all of its physical interfaces 454 bearing the same subnet, it may get a different response on each 455 of its physical interfaces. 457 Even though both NAT-3 and NAT-4 have hosts bearing the same IP 458 address on the adjacent networks, the NAT devices do communicate 459 effectively as end points. Many of the "plug-and-play" NAT devices 460 offer a limited number of services on them. For example, many of 461 the NAT devices respond to pings from hosts on either of the 462 interfaces. Even though a NAT device is often not actively 463 managed, many of the NAT devices are equipped to be managed from 464 the private interface. This unconventional communication with 465 NAT devices is achievable because NAT devices view the 466 two interfaces as being on two disjoint routing domains and 467 distinguish between sessions with hosts on either interface 468 (private or public). 470 Consumer oriented "Plug-and-Play" NAT devices MUST and all NATs 471 SHOULD be able to handle multi-level NAT topologies such as the one 472 described in figure 1.2, in which a private IP address space on one 473 side of the NAT potentially conflicts with the private IP address 474 space on the other side. Essentially NAT must be able to keep the 475 two IP address spaces separate in its internal data structures, and 476 base all packet processing decisions on the "side" or "port" from 477 which the packet arrived and not just on the basis of the IP 478 addresses it contains. 480 Recommendation-2. NAT devices SHOULD support IP address space 481 overlap between the address space on its private interface and the 482 address space on its public interface. Essentially, a NAT device 483 SHOULD keep the two IP address spaces separate and base all packet 484 processing decisions on the "side" or "port" from which the packet 485 arrived and not just on the basis of the IP addresses it contains. 487 2.2.3. Multi-Level NAT Translations 489 Use of a single NAT to connect private hosts to the public Internet 490 as in figure 1.1 is a fairly common practice. Many consumer NATs are 491 deployed this way. However, use of multi-level NAT translations as 492 in figure 1.2 is not a common practice and is not well understood. 494 Let us consider the conventional single NAT translation in 495 figure 1.1. Because the public and private IP address ranges are 496 numerically disjoint, nodes on private networks can make use of both 497 public and private IP addresses when initiating network 498 communication sessions. Nodes on a private network can use private 499 IP addresses to refer to other nodes on the same private network, 500 and public IP addresses to refer to nodes on the public Internet. 501 For example, host C in figure 1.1 is on private network 1 and can 502 directly address hosts A, B and D using their assigned IP addresses. 503 This is in spite of the fact that hosts A and B are on the public 504 Internet and host D alone is on the private network. 506 Next, let us consider the unconventional multi-level NAT topology in 507 figure 1.2. In this scenario, private hosts are able to connect to 508 hosts on the public Internet. But, private hosts are not able to 509 connect with all other private hosts. For example, host F in 510 figure 1.2 can directly address hosts A, B, and G using their 511 assigned IP addresses, but F has no way to address any of the 512 other hosts in the diagram. Host F in particular cannot address 513 host E by its assigned IP address, even though host E is located on 514 the immediately "upstream" private network through which F is 515 connected to the Internet. Host E has the same IP address as 516 host G. Yet, this addressing is "legitimate" in the NAT world 517 because the two hosts are on different private networks. 519 It would seem that the topology in figure 1.2 with multiple 520 NAT translations is broken because private hosts are not able to 521 address each other directly. However, the network is not broken. 522 Nodes on any private network have no direct method of addressing 523 nodes on other private networks. The private networks 1, 2, 3 and 4 524 are all disjoint. Hosts on private network 1 are unable to directly 525 address nodes on private networks 2, 3 or 4 and vice versa. Multiple 526 NAT translations was not the cause of this. 528 As described in sections 2.1.1 and 2.1.2, client-server and 529 peer-to-peer communication can and should be possible even with 530 multi-level NAT topology deployment. A host on any private network 531 MUST be able to communicate with any other host, no matter which 532 private network the host is attached to or where the private network 533 is located. Host F should be able to communicate with host E and 534 carry out both client-server communication and peer-to-peer 535 communication, and vice versa. Host F and host E form a hairpin 536 session through NAT-2 to communicate with each other. Each host 537 uses the public endpoint assigned by the Internet facing NAT (NAT-2) 538 to address its peer. NAT devices SHOULD support hairpin translation 539 ([P2P-STATE]) for session flows that originate from a host on one 540 attached private network and targeted to a host on another private 541 network also attached to the same NAT device. Hairpin translation 542 is explained in detail in section 4.4 of [P2P-STATE]. 544 Ideally, ISPs SHOULD not use NAT devices to connect their customers, 545 so the customers do not get caught up in a multi-level NAT scenario 546 and hairpin session flows. NAT devices MUST support hairpin 547 translations for all protocol sessions the NAT device supports. 548 Hairpin translation support is a requirement for peer node 549 connectivity in multi-level NAT topologies. 551 Recommendation-3. NAT devices MUST support hairpin translation for 552 all protocol sessions the NAT device supports. 554 2.2.4. Mistaken End Host Identity 556 There can be a potential security threat due to mistaken identity 557 in figure 1.2. Suppose, the CheapoISP in figure 1.2 used host E as 558 the ISP mail server. Host E is assigned an RFC 1918 address of 559 10.1.1.11. This address can potentially overlap with addresses on 560 private networks 3 and 4. So, if a customer of CheapoISP had a 561 mail server installed on his/her private network, bearing an IP 562 address exactly the same as host E, this could pose a severe 563 security threat to customer's mail messages. Potentially, the 564 customer mail messages could be hijacked by the ISP's mail server. 566 Ideally, ISPs should not use NAT devices to provide connectivity to 567 their customers. If they do, any servers on the ISP's private 568 network that need to be accessible to the ISP's customers 569 (e.g., mail servers) SHOULD have global IP addresses, to ensure 570 accessibility to customers who deploy NAT devices themselves. 572 Recommendation-4. Ideally, ISPs SHOULD not use NAT devices to 573 provide connectivity to their customers. If they do, any 574 servers on the ISP's private network that need to be accessible to 575 the ISP's customers (e.g., mail servers) SHOULD have global IP 576 addresses, to ensure accessibility to customers who deploy NAT 577 devices themselves. 579 2.3. Summary of Recommendations 581 The following is a summary of recommendations identified in section 582 2.2 to support the unconventional multi-level NAT topologies, such 583 as the one identified in figure 1. The recommendations are addressed 584 to NAT vendors, ISPs and the consumers. 586 Recommendation-1. Consumers SHOULD be informed that all private 587 hosts behind a "Plug-and-play" NAT must be on a single LAN subnet, 588 and that there SHOULD be no more than one "Plug-and-play" NAT device 589 on the same LAN. 591 Recommendation-2. NAT devices SHOULD support IP address space 592 overlap between the address space on its private interface and the 593 address space on its public interface. Essentially, a NAT device 594 SHOULD keep the two IP address spaces separate and base all packet 595 processing decisions on the "side" or "port" from which the packet 596 arrived and not just on the basis of the IP addresses it contains. 598 Recommendation-3. NAT devices MUST support hairpin translation for 599 all protocol sessions the NAT device supports. 601 Recommendation-4. Ideally, ISPs SHOULD not use NAT devices to 602 provide connectivity to their customers. If they do, any 603 servers on the ISP's private network that need to be accessible to 604 the ISP's customers (e.g., mail servers) SHOULD have global IP 605 addresses, to ensure accessibility to customers who deploy NAT 606 devices themselves. 608 3. Remote Access VPN Network Topologies 610 Enterprises use remote access VPN to allow secure access to the 611 employees working outside the enterprise premises. While outside 612 the enterprise premises, an employee may be located in his/her 613 home office, hotel, conference or a partner's office. In all cases, 614 it is desirable for the employee at the remote site to have 615 unhindered access to his/her corporate network and the applications 616 running on the corporate networks. This is so the employee can get 617 his/her work done seamlessly without jeopardizing the integrity and 618 confidentiality of the corporate network and the applications 619 running on the network. 621 IPsec, L2TP and SSL are some of the well known secure VPN 622 technologies used by the remote access vendors. Besides 623 authenticating employees for granting access, remote access VPN 624 servers often enforce different forms of security (e.g. IPsec, SSL) 625 to protect the integrity and confidentiality of the run-time 626 traffic between the VPN client and the VPN server. 628 Many enterprises deploy their internal networks using RFC-1918 629 private address space and use NAT devices to connect to the public 630 Internet. Further, many of the applications in the corporate network 631 refer to information (such as URLs) and services using private 632 addresses in the corporate network. Applications such as NFS rely on 633 simple source IP address based filtering to restrict access to 634 corporate users. These are some reasons why the remote access VPN 635 servers are configured with a block of IP addresses from the 636 corporate private network to assign to remote access clients. VPN 637 clients use the virtual IP (VIP) address assigned to them (by the 638 corporate VPN server) to access applications inside the corporate. 640 Consider the remote access VPN scenario in figure 2 below. 642 (Corporate Private network 10.0.0.0/8) 643 ---------------+---------------------- 644 | 645 10.1.1.10 646 +---------+-------+ 647 | Enterprise Site | 648 | Remote Access | 649 | VPN Server | 650 +--------+--------+ 651 129.32.34.18 652 | 653 {---------+------} 654 { } 655 { } 656 { Public Internet } 657 { (Public IP addresses) } 658 { } 659 { } 660 {---------+------} 661 | 662 155.99.25.1 663 +--------+--------+ 664 | Remote Site NAT | 665 |(in a Hotel, | +--------+ 666 | remote | | Remote | 667 | Conference, or | | Site | 668 | any remote site)| | DHCP | 669 | | | Server | 670 +--------+--------+ +----+---+ 671 10.1.1.1 10.1.1.2 672 | | 673 Remote Site Private Network | | 674 -----+-----------+-----------+-------------+----------+-- 675 | | | | 676 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 677 Host A Host B +--------+ Host C 678 | Remote | 679 | User | 680 | PC | 681 |(VPN | 682 | Client)| 683 +--------+ 685 Figure 2. Remote Access VPN with Overlapping Address Space 686 In the above scenario, say an employee of the corporate is at a 687 remote location and attempts to access the corporate network using 688 the VPN client. The corporate network is laid out using RFC-1918 689 address pool of 10.0.0.0/8 and say the VPN server is configured with 690 an address block of 10.1.1.0/24 to assign virtual IP addresses to 691 remote access VPN clients. Now, say the employee at the remote site 692 is attached to a network on the remote site which also happens to be 693 using a RFC-1918 address space based network and coincidentally 694 overlaps the corporate network. In this scenario, it is 695 conventionally problematic for the VPN client to connect to the 696 server(s) and other hosts at the enterprise. 698 Nevertheless, despite the direct address overlap, the remote access 699 VPN connection between the VPN client at the remote site and the 700 VPN server at the enterprise should remain connected and should be 701 made to work. I.e., the NAT device at the remote site should not 702 obstruct the VPN connection traversing it. And, the remote user 703 should be able to connect to any host at the enterprise through the 704 VPN from the remote desktop. 706 The following subsections describe the operational details of the 707 VPN, anomalies with the address overlap and recommendations on 708 how best to address the situation. 710 3.1. Operational Details of Remote Access VPN Network 712 As mentioned earlier, in the "de facto" Internet address 713 architecture, only the nodes on the public Internet have globally 714 unique IP addresses assigned by the official IP address registries. 715 Many of the networks in the edges use private IP addresses from 716 RFC 1918 and use NAT devices to connect their private networks 717 to the public Internet. Many enterprises adapted the approach of 718 using private IP addresses internally. Employees within the 719 enterprise's Intranet private network are "trusted" and may connect 720 to any of the internal hosts with minimal administrative or policy 721 enforcement overhead. When an employee leaves the enterprise 722 premises, remote access VPN provides the same level of intranet 723 connectivity to the remote user. 725 The objective of this section is to provide an overview of the 726 operational details of a remote access VPN application so the reader 727 has an appreciation for the problem of remote address space overlap. 728 This is not a tutorial or specification of remote access VPN 729 products, per se. 731 When an employee at a remote site launches his/her remote access VPN 732 client, the VPN server at the corporate premises demands the VPN 733 client to authenticate itself. When the authentication succeeds, 734 the VPN server assigns a Virtual IP (VIP) address to the client for 735 connecting with the corporate Intranet. From this point onwards, 736 while the VPN is active, outgoing IP packets directed to the hosts 737 in the corporate Intranet are tunneled through the VPN, in that the 738 the VPN server serves as the next-hop and the VPN connection as the 739 next-hop link for these packets. Within the corporate Intranet, the 740 outbound IP packets appear as arriving from the VIP address. so, 741 IP packets from the corporate hosts to the remote user are sent to 742 the remote user's VIP address and the IP packets are tunneled 743 inbound to the remote user's PC through the VPN tunnel. 745 This works well so long as the subnets in the corporate network 746 do not conflict with subnets at the remote site where the remote 747 user's PC is located. However, when the corporate network is built 748 using RFC 1918 private address space and the remote location where 749 the VPN client is launched is also using an overlapping network from 750 RFC 1918 address space, there can be addressing conflicts. The 751 remote user's PC will have a conflict in accessing nodes on the 752 corporate site and nodes at the remote site bearing the same IP 753 address simultaneously. Consequently, the VPN client may be unable 754 to have full access to the employee's corporate network and the 755 local network at the remote site simultaneously. 757 In spite of address overlap, remote access VPN clients should be 758 able to successfully establish connections with Intranet hosts in 759 the enterprise. 761 3.2. Anomalies of the Remote Access VPN network 763 Even though conventional wisdom would suggest that the remote access 764 VPN scenario with overlapping address space would be seriously 765 broken, in practice it still works in many ways. Let us look at some 766 anomalies where there might be a problem and identify solutions 767 through which the remote access VPN application could be made to 768 work even under the problem situations. 770 3.2.1. Remote Router and DHCP Server Address Conflict 772 When there is address overlap between hosts at corporate Intranet 773 and hosts at the remote site, the remote VPN user is often unaware 774 of the address conflict. Address overlap could potentially cause the 775 remote user to loose connectivity to the enterprise entirely or 776 loose connectivity to an arbitrary block of hosts at the enterprise. 778 Consider, for example, a scenario where the IP address of the DHCP 779 server at the remote site matched the IP address of a host at 780 the enterprise network. When the remote user's PC is ready to 781 renew the lease of the locally assigned IP address, the remote 782 user's VPN client would incorrectly identify the IP packet 783 as being addressed to an enterprise host and tunnel the DHCP 784 renewal packet over the VPN to the remote VPN server. The DHCP 785 renewal requests simply do not reach the DHCP server at the 786 remote site. As a result, the remote PC would eventually loose the 787 lease on the IP address and the VPN connection to the enterprise 788 would be broken. 790 Consider another scenario where the IP address of the remote user's 791 router overlapped with the IP address of a host in the enterprise 792 network. If the remote user's PC were to send ping or some type of 793 periodic keep-alive packets to the router (say, to test the liveness 794 of the router), the packets are intercepted by the VPN client and 795 simply redirected to the VPN tunnel. This type of unintended 796 redirection has the twin effect of hijackng critical packets 797 addresed to the router as well as the host in the enterprise 798 network (bearing the same IP address as the remote router) being 799 bombarded with unintended keep-alive packets. Loss of connectivity 800 to the router can result in the VPN connection being broken. 802 Clearly, it is not desirable for the corporate intranet to conflict 803 with the IP addresses of the router and DHCP server at the remote 804 site. VPN servers should, at a minimum, disallow access to corporate 805 hosts that are using an IP address that might match any of the 806 following entities at the remote site - a) client's next-hop router 807 IP address used to access the VPN server, and b) DHCP server 808 providing address lease on the remote host network interface. By 809 doing this, VPN client on the remote PC will not intercept IP 810 packets whose target IP addresses are not in the authorized list 811 of enterprise hosts. And, the VPN connection remains. This however 812 has the downside that the VPN client looses connectivity to a 813 potentially mission critical host at the corporate site. 815 Recommendation-1. When there is conflict of address space between 816 corporate Intranet and the subnet on remote site, the VPN server 817 server SHOULD disallow access from the VPN client to corporate 818 hosts bearing the same IP address as the router or DHCP server at 819 the remote site. 821 3.2.2. Simultaneous Connectivity Conflict 823 Ideally speaking, it is not desirable for the corporate intranet to 824 conflict with any of the hosts at the remote site. As a general 825 practice, if simultaneous communication with end hosts at the remote 826 location is important to the remote user, it is advisable to 827 disallow access to any corporate network resource that overlaps 828 the client's external IP subnet. By doing this, the remote user 829 is able to connect to all local hosts simultaneously while the VPN 830 connection is active. For example, if the PC's external network 831 interface is configured with 10.1.1.1/24, the VPN server may be 832 configured to disallow access to the corporate network that 833 overlaps this subnet from the remote access VPN client. Such a 834 configuration on the VPN server is also termed sometimes as 835 "Split VPN" configuration. With "Split VPN" configuration set, 836 the remote user is able to carry out simultaneous communication 837 with hosts at the remote site and the hosts at the corporate 838 intranet, with the exception of the hosts that overlap the remote 839 subnet. 841 If simultaneous connectivity to local hosts is not important, the 842 VPN server may be configured to require the VPN client to direct 843 all communication traffic from the remote user to the VPN server 844 across the VPN tunnel. This essentially ensures that all 845 communication from the remote user's PC traverses the VPN link and 846 no communication takes place with hosts on the local subnet. This 847 configuration on the VPN server is also termed sometimes as 848 "Non-split VPN", as all traffic from the remote user's PC is 849 directed to the VPN server, with the exception of traffic directed 850 to the local router and DHCP server. 852 Recommendation-2. If simultaneous communication with end hosts at 853 the remote location is important to the remote user, enterprises 854 SHOULD configure the VPN server in "Split VPN" mode and disallow 855 access to any corporate network resource that overlaps the client's 856 external IP subnet. If simultaneous connectivity to local hosts is 857 not important, enterprises SHOULD configure the VPN server in 858 "Non-split VPN" mode, so the VPN client directs to the VPN tunnel 859 all traffic from the remote user, with the exception of traffic to 860 the local router and DHCP server. 862 3.2.3. VIP Address Conflict 864 When the VIP address assigned to the VPN client at the remote site 865 is in direct conflict with the IP address of the existing network 866 interface, the VPN client might be unable to establish the VPN 867 connection. 869 Consider a scenario where the VIP address assigned by the 870 VPN server directly matched the IP address of the networking 871 interface at the remote site. When the VPN client on the remote 872 host attempts to set the VIP address on a virtual adapter (specific 873 to the remote access application), the VIP address configuration 874 will simply fail due to conflict with the IP address of the existing 875 network interface. The configuration failure in turn will result in 876 the remote access VPN tunnel not being established. 878 Clearly, it is not advisable to have the VIP address overlap 879 the IP address of the remote user's existing network interface. As a 880 general rule, it is not advisable for the VIP address to overlap 881 any IP address in the remote user's local subnet, as the VPN client 882 on the remote PC might be forced to respond to ARP requests on the 883 remote site and the VPN client might not process the handling of ARP 884 requests gracefully. 886 We RECOMMEND that VPN vendors offer provision to detect conflict of 887 VIP address with remote site address space and switch between a 888 minimum two VIP address pools on the VPN server. We also RECOMMEND 889 enterprises deploying the VPN solution to use this vendor provision 890 and configure the VPN server with a minimum of two distinct IP 891 address pools. Alternately, the enterprises SHOULD deploy a minimum 892 of two VPN servers with different address pools. By doing this, a 893 VPN client that detected the conflict of VIP address with the local 894 subnet is able to reconnect with the alternate VPN server using 895 the alternate address pool that will not conflict. 897 Recommendation-3. We RECOMMEND that VPN vendors offer provision to 898 detect conflict of VIP address with remote site address space and 899 switch between a minimum two VIP address pools with different 900 subnets on the VPN server to ensure that the VIP address is not in 901 conflict with the subnet on the remote PC location. 903 Recommendation-4. We RECOMMEND that enterprises deploying the VPN 904 solution SHOULD adapt one of the following strategies to avoid VIP 905 address conflict with the subnet on remote PC location. 906 a) If the VPN device being deployed has provision to configure two 907 address pools (as in recommendation 3 above), configure the VPN 908 server with a minimum of two distinct IP address pools. 909 b) Deploy a minimum of two VPN servers with different address pools. 910 By doing this, a VPN client that detected the conflict of VIP 911 address with the local subnet is able to switch to alternate VPN 912 server and obviate VIP address conflict with the local subnet. 914 3.2.4. Mistaken End Host Identity 916 When "Split VPN" configuration is set on the VPN server, there can 917 be a potential security threat due to mistaken identity. 919 Say, a certain service (ex: SMTP mail service) is configured on 920 exactly the same IP address on both the corporate site and the 921 remote site. The user could unknowingly be using the service on the 922 remote site, thereby violating the integrity and confidentiality of 923 the contents relating to that application. Potentially, remote 924 user mail messages could be hijacked by the ISP's mail server. 926 Enterprises deploying remote access VPN servers SHOULD allocate 927 global IP addresses for the critical servers the remote VPN clients 928 typically need to access. By doing this, even if most of the private 929 corporate network uses RFC 1918 address space, this will ensure that 930 the remote VPN clients can always access the critical servers 931 regardless of the private address space used at the remote 932 attachment point. 934 Recommendation-5. When "Split VPN" is configured on the VPN server, 935 enterprises deploying remote access VPN servers SHOULD allocate 936 global IP addresses for the critical servers the remote VPN clients 937 typically need to access. 939 3.3. Summary of Recommendations 941 The following is a summary of recommendations identified in section 942 3.2 to support the address overlap in remote access VPN networks, 943 such as the one identified in figure 2. The recommendations are 944 addressed to remote access VPN vendors, enterprises deploying the 945 VPN servers and finally, the remote access VPN consumers. Following 946 the recommendations will help ensure that a complete "network 947 meltdown" is prevented. 949 Recommendation-1. When there is conflict of address space between 950 corporate Intranet and the subnet on remote site, the VPN server 951 server SHOULD disallow access from the VPN client to corporate 952 hosts bearing the same IP address as the router or DHCP server at 953 the remote site. 955 Recommendation-2. If simultaneous communication with end hosts at 956 the remote location is important to the remote user, enterprises 957 SHOULD configure the VPN server in "Split VPN" mode and disallow 958 access to any corporate network resource that overlaps the client's 959 external IP subnet. If simultaneous connectivity to local hosts is 960 not important, enterprises SHOULD configure the VPN server in 961 "Non-split VPN" mode, so the VPN client directs to the VPN tunnel 962 all traffic from the remote user, with the exception of traffic to 963 the local router and DHCP server. 965 Recommendation-3. We RECOMMEND that VPN vendors offer provision to 966 detect conflict of VIP address with remote site address space and 967 switch between a minimum two VIP address pools with different 968 subnets on the VPN server to ensure that the VIP address is not in 969 conflict with the subnet on the remote PC location. 971 Recommendation-4. We RECOMMEND that enterprises deploying the VPN 972 solution SHOULD adapt one of the following strategies to avoid VIP 973 address conflict with the subnet on remote PC location. 974 a) If the VPN device being deployed has provision to configure two 975 address pools (as in recommendation 3 above), configure the VPN 976 server with a minimum of two distinct IP address pools. 977 b) Deploy a minimum of two VPN servers with different address pools. 978 By doing this, a VPN client that detected the conflict of VIP 979 address with the local subnet is able to switch to alternate VPN 980 server and obviate VIP address conflict with the local subnet. 982 Recommendation-5. When an enterprise configures the VPN server in 983 "Split VPN" mode, the enterprise SHOULD allocate global IP addresses 984 for the critical servers the remote VPN clients typically need to 985 access. 987 4. Security Considerations 989 This document does not inherently create new security issues. 990 Security issues known to DHCP servers and NAT devices are 991 applicable, but not within the scope of this document. Likewise, 992 security issues specific to remote access VPN devices are also 993 appliable to the remote access VPN topology, but not within the 994 scope of this document. The security issues reviewed here only 995 those relevant to the topologies described in sections 2 and 3, 996 specifcally as they apply to private address space overlap in the 997 topologies described. 999 Mistaken end host identity is a security concern present in both 1000 topologies discussed. Mistaken end host identity, described in 1001 sections 2.2.4 and 3.2.4 for each of the topologies reviewed, 1002 essentially points the possibility of application services being 1003 hijacked by the wrong application server (ex: Mail server). Security 1004 violation due to mistaken end host identity arises principally due 1005 to critical servers being assigned RFC 1918 private addresses. The 1006 recommendation suggested for both scenarios is to assign globally 1007 unique pulic IP addresses for the critical servers. 1009 It is also recommended in section 2.1.2 that applications adapt 1010 end-to-end authentication and not depend on source IP address for 1011 authentication. Doing this will thwart connection hijacking and 1012 denial of service attacks. 1014 5. Acknowledgements 1016 The authors wish to thank Dan Wing for reviewing the document in 1017 detail and making helpful suggestions in reorganizing the 1018 document format. 1020 6. Normative References 1022 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 1023 (NAT) Terminology and Considerations", RFC 2663, August 1024 1999. 1026 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 1027 Translator (Traditional NAT)", RFC 3022, January 2001. 1029 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and 1030 Lear, E., "Address Allocation for Private Internets", BCP 5, 1031 RFC 1918, February 1996. 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, March 1997. 1036 7. Informational References 1038 [NAT-PROT] Holdrege, M., and Srisuresh, P., "Protocol Complications 1039 with the IP Network Address Translator", RFC 3027, 1040 January 2001. 1042 [P2P-STATE] Srisuresh, P., Ford, B., and Kegel, D., "State of Peer-to- 1043 Peer(P2P) Communication Across Network Address Translators 1044 (NATs)", draft-srisuresh-behave-p2p-state-03.txt, 1045 June 2006, Work in Progress. 1047 Authors' Addresses: 1049 Pyda Srisuresh 1050 Consultant 1051 20072 Pacifica Dr. 1052 Cupertino, CA 95014 1053 U.S.A. 1054 Phone: (408) 836-4773 1055 E-mail: srisuresh@yahoo.com 1056 Bryan Ford 1057 Computer Science and Artificial Intelligence Laboratory 1058 Massachusetts Institute of Technology 1059 77 Massachusetts Ave. 1060 Cambridge, MA 02139 1061 U.S.A. 1062 Phone: (617) 253-5261 1063 E-mail: baford@mit.edu 1064 Web: http://www.brynosaurus.com/ 1066 Intellectual Property Statement 1068 The IETF takes no position regarding the validity or scope of any 1069 Intellectual Property Rights or other rights that might be claimed to 1070 pertain to the implementation or use of the technology described in 1071 this document or the extent to which any license under such rights 1072 might or might not be available; nor does it represent that it has 1073 made any independent effort to identify any such rights. Information 1074 on the procedures with respect to rights in RFC documents can be 1075 found in BCP 78 and BCP 79. 1077 Copies of IPR disclosures made to the IETF Secretariat and any 1078 assurances of licenses to be made available, or the result of an 1079 attempt made to obtain a general license or permission for the use of 1080 such proprietary rights by implementers or users of this 1081 specification can be obtained from the IETF on-line IPR repository at 1082 http://www.ietf.org/ipr. 1084 The IETF invites any interested party to bring to its attention any 1085 copyrights, patents or patent applications, or other proprietary 1086 rights that may cover technology that may be required to implement 1087 this standard. Please address the information to the IETF at 1088 ietf-ipr@ietf.org. 1090 Full Copyright Statement 1092 Copyright (C) The Internet Society (2006). 1094 This document is subject to the rights, licenses and restrictions 1095 contained in BCP 78, and except as set forth therein, the authors 1096 retain all their rights. 1098 This document and the information contained herein are provided on 1099 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1100 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1101 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1102 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1103 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1104 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1105 PARTICULAR PURPOSE.