idnits 2.17.1 draft-ford-behave-top-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 740. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 14 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 380: '...d Play" NAT devices MUST, and all NATs...' RFC 2119 keyword, line 381: '... SHOULD, be able to handle topologie...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 317 has weird spacing: '...natural to as...' == Line 554 has weird spacing: '...rporate addre...' -- 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 (February 2005) is 7010 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) -- Missing reference section? 'RFC1918' on line 80 looks like a reference -- Missing reference section? 'BEHAVE-UDP' on line 390 looks like a reference -- Missing reference section? 'BEHAVE-TCP' on line 390 looks like a reference -- Missing reference section? 'BEHAVE-APP' on line 393 looks like a reference -- Missing reference section? 'BIDIR' on line 634 looks like a reference -- Missing reference section? 'ICE' on line 639 looks like a reference -- Missing reference section? 'IPSEC-NAT' on line 645 looks like a reference -- Missing reference section? 'KEGEL' on line 648 looks like a reference -- Missing reference section? 'MIDCOM' on line 651 looks like a reference -- Missing reference section? 'NAT-APPL' on line 655 looks like a reference -- Missing reference section? 'NAT-PROT' on line 658 looks like a reference -- Missing reference section? 'NAT-PT' on line 662 looks like a reference -- Missing reference section? 'NAT-TERM' on line 666 looks like a reference -- Missing reference section? 'NAT-TRAD' on line 670 looks like a reference -- Missing reference section? 'RSIP' on line 674 looks like a reference -- Missing reference section? 'SOCKS' on line 677 looks like a reference -- Missing reference section? 'STUN' on line 680 looks like a reference -- Missing reference section? 'SYM-STUN' on line 685 looks like a reference -- Missing reference section? 'TCP' on line 689 looks like a reference -- Missing reference section? 'TEREDO' on line 691 looks like a reference -- Missing reference section? 'TURN' on line 695 looks like a reference -- Missing reference section? 'UPNP' on line 700 looks like a reference -- Missing reference section? 'NAT-MIB' on line 704 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft B. Ford 3 Document: draft-ford-behave-top-00.txt M.I.T. 4 Expires: August 14, 2005 P. Srisuresh 5 Caymas Systems 6 February 2005 8 Topology complications from Network Address Translator deployments 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document identifies and provides recommendations for dealing 35 with issues that have arisen recently from the ubiquitous deployment 36 of network address translators (NAT), and the unconventional network 37 topologies that are often constructed with them. First, the 38 simplicity of administering networks through the combination of NAT 39 and DHCP is increasingly leading to the deployment of multi-level 40 hierarchies of inter-connected private networks involving 41 overlapping private IP address spaces. The creation of these 42 multi-level hierarchies is often unintentional, since each level of 43 NAT is typically deployed by a separate administrative entity such 44 as an ISP, a corporation, or a home user. Second, the popularity of 45 corporate virtual private networks (VPN) in conjunction with NAT 46 leads to problems in which the private IP address space of the 47 network through which a remote client is attached may 48 unintentionally conflict with the private IP address space of the 49 corporate network into which the remote client is tunneled. This 50 document specifies best current practice recommendations for 51 addressing the issues identified. 53 Table of Contents 55 1. Introduction ................................................. 56 2. Multi-Level Private Address Space Topologies ................. 57 2.1. Operational Details of the Network ...................... 58 2.1.1. Client/Server Communication ........................... 59 2.1.2. Peer-to-Peer Communication ............................ 60 2.2. Anomalies and Caveats with the Network .................. 61 2.2.1. Anomalies with the Network ............................ 62 2.2.2. Caveats with the Network .............................. 63 2.3. Recommendations ......................................... 64 3. Remote Access VPN Topologies with Private Address Space ...... 65 3.1. Operational Details of the Network ...................... 66 3.2. Caveats with the Network ................................ 67 3.3. Recommendations ......................................... 68 4. Security Considerations ...................................... 70 1. Introduction 72 The Internet was originally designed to use a single, global 32-bit 73 IP address space to identify hosts on the network, allowing 74 applications on one host to address and initiate communications with 75 applications on any other host regardless of the respective hosts' 76 topological locations or administrative domains. For a variety of 77 pragmatic reasons, however, the Internet has gradually drifted away 78 from strict conformance to this ideal of a single flat global address 79 space, and towards a hierarchy of smaller "private" address spaces 80 [RFC1918] clustered around a large central "public" address space. 81 The most important pragmatic causes of this unintended evolution of 82 the Internet's architecture appear to be: 84 1. Depletion of the 32-bit IPv4 address space due to the exploding 85 total number of hosts on the Internet. Although IPv6 promises to 86 solve this problem, the uptake of IPv6 has in practice been slower 87 than expected. 89 2. Perceived Security and Privacy: Traditional NAT devices provide a 90 filtering function that permits session flows to cross the NAT in 91 just one direction, from private hosts to public network hosts. 92 This filtering function is widely perceived as a security benefit. 93 In addition, the NAT's translation of a host's original IP 94 addresses and port number in private network into an unrelated, 95 external IP address and port number is perceived by some as a 96 privacy benefit. 98 3. Ease-of-use: NAT vendors often combine the NAT function with a 99 DHCP server function in the same device, which creates a 100 compelling, effectively "plug-and-play" method of setting up small 101 Internet-attached personal networks that is often much easier in 102 practice for unsophisticated consumers than configuring up a true 103 IP subnet. The many popular and inexpensive consumer NAT devices 104 on the market are usually configured "out of the box" to obtain a 105 single "public" IP address from an ISP or "upstream" network via 106 DHCP, and the NAT device in turn acts as both a DHCP server and 107 default router for any "downstream" hosts (and even other NATs) 108 that the user plugs into it. Consumer NATs in this way 109 effectively create and manage private home networks automatically 110 without requiring any knowledge of network protocols or management 111 on the part of the user. 113 This ease-of-use benefit of NAT stems ultimately from the fact 114 that DHCP is only capable of providing a single auto-configured IP 115 address to each client. A DHCP client currently has no way to 116 request a *block* of IP addresses from the server, from it might 117 in turn form its own auto-configured "downstream" IP subnet for 118 which it provides its own DHCP service. The fact that DHCP is 119 only capable of auto-configuring client hosts, and is not capable 120 of auto-configuring entire "client subnets", makes NAT a 121 compelling solution in this common scenario. 123 2 Multi-Level Private Address Space Topologies 125 Due to the above pragmatic considerations and perhaps others, NATs 126 are increasingly, and often unintentionally, used to create 127 hierarchically interconnected clusters of private networks as 128 illustrated in the following diagram. 130 Public Internet 131 (Public IP addresses) 132 ----+---------------+---------------+---------------+---- 133 | | | | 134 | | | | 135 66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1 136 +-------+ Host A Host B +-------------+ 137 | NAT-1 | (Alice) (Jim) | NAT-2 | 138 | (Bob) | | (CheapoISP) | 139 +-------+ +-------------+ 140 10.1.1.1 10.1.1.1 141 | | 142 | | 143 Private Network 1 Private Network 2 144 (private IP addresses) (private IP addresses) 145 ----+--------+---- ----+-----------------------+---- 146 | | | | | 147 | | | | | 148 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 149 Host C Host D +-------+ Host E +-------+ 150 | NAT-3 | (Mary) | NAT-4 | 151 | (Ann) | | (Lex) | 152 +-------+ +-------+ 153 10.1.1.1 10.1.1.1 154 | | 155 | | 156 Private Network 3 | Private Network 4 157 (private IP addresses)| (private IP addresses) 158 ----+-----------+---+ ----+-----------+---- 159 | | | | 160 | | | | 161 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 162 Host F Host G Host H Host I 164 Figure 1: Multi-level NAT topology with private address space 166 In the above scenario, Bob, Alice, Jim, and CheapoISP have each 167 obtained a "genuine", globally routable IP address from an upstream 168 service provider. Alice and Jim have chosen to attach only a single 169 machine at each of these public IP addresses, preserving the 170 originally intended architecture of the Internet and making their 171 hosts, A and B, globally addressable throughout the Internet. Bob, 172 in contrast, has purchased and attached a typical consumer NAT box. 173 Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP 174 via DHCP, and automatically creates a private 10.1.1.x network for 175 Bob's hosts C and D, acting as the DHCP server and default router for 176 this private network. Bob probably does not even know anything about 177 IP addresses; he merely knows that plugging the NAT into the Internet 178 as instructed by the ISP, and then plugging his hosts into the NAT as 179 the NAT's manual indicates, seems to work and gives all of his hosts 180 access to Internet. 182 CheapoISP, an inexpensive service provider, has allocated only one or 183 a few globally routable IP addresses, and uses NAT to share these 184 public IP addresses among its many customers. Such an arrangement is 185 becoming extremely common, especially in rapidly-developing countries 186 where the exploding number of Internet-attached hosts greatly 187 outstrips the ability of ISPs to obtain globally unique IP addresses 188 for them. CheapoISP has chosen the popular 10.1.1.x address for its 189 private network, since this is one of the three well-known private IP 190 address blocks allocated in RFC specifically for this purpose. 192 Out of the three incentives listed above for NAT deployment, the last 193 two still apply even to customers of ISPs that use NAT, resulting in 194 multi-level NAT topologies as illustrated in the right side of the 195 above diagram. (Even three-level NAT topologies are known to 196 exist.) CheapoISP's customers Ann, Mary, and Lex have each obtained 197 a single IP address on CheapoISP's network (Private Network 2), via 198 DHCP as usual. Mary attaches only a single host at this point, but 199 Ann and Lex each independently purchase and deploy consumer NATs in 200 the same way that Bob did above. As it turns out, these consumer 201 NATs also happen to use 10.1.1.x addresses for the private networks 202 they create, since these are the configuration defaults hard-coded 203 into the NATs by their vendors. Ann and Lex probably know nothing 204 about IP addresses, and in particular they are probably unaware that 205 the IP address spaces of their own private networks overlap not only 206 with each other but also with the private IP address space used by 207 their immediately upstream network. 209 Nevertheless, despite this direct overlap, all of the "multi-level 210 NATted hosts" - F, G, H, and I in this case - all nominally function 211 and are able to initiate connections to any public server on the main 212 Internet that has a globally routable IP address. Connections made 213 from these hosts to the main Internet are merely translated twice: 214 once by the consumer NAT (3 or 4) into the IP address space of 215 CheapoISP's Private Network 2, and then again by CheapoISP's NAT 2 216 into the main Internet's global IP address space. 218 2.1 Operational Details of the Network 220 In the "de facto" Internet address architecture that has resulted 221 from the above pragmatic and economic incentives, only the nodes on 222 the main Internet have globally unique IP addresses assigned by the 223 official IP address registries. IP addresses on different private 224 networks are typically managed independently: either manually by the 225 administrator of the private network itself, or automatically by the 226 NAT through which the private network is connected to its "upstream" 227 service provider. 229 By convention, nodes on private networks are usually assigned IP 230 addresses in one of the private address space ranges specifically 231 allocated to this purpose in RFC 1918, ensuring that private IP 232 addresses are easily distinguishable and do not conflict with the 233 public IP addresses officially assigned to globally routable Internet 234 hosts. A given private IP address can be and often is reused across 235 many different private networks, however. In the figure above, for 236 example, private networks 1, 2, 3, and 4 all have a node with IP 237 address 10.1.1.10. 239 Because the public and private IP address ranges are numerically 240 disjoint, nodes on private networks can make use of both public and 241 private IP addresses when initiating network communication sessions. 242 Nodes on private networks can use private IP addresses to refer to 243 other nodes on the same private network, and nodes can use public IP 244 addresses to refer to nodes on the main Internet. Nodes on private 245 networks have no direct method of addressing nodes on other private 246 networks, however, and nodes on the main Internet have no direct way 247 to address nodes on any private network. For example, host F in the 248 figure above can directly address hosts A, B, and G using their 249 assigned IP addresses, but F has no way to address any of the other 250 hosts in the diagram. Host F in particular has no way even to 251 address host E, even though E is located on the immediately 252 "upstream" private network through which F is connected to the 253 Internet! (Host E has the same IP address as host G, which is 254 "legitimate" in the NAT world because the two hosts are on different 255 private networks.) 257 2.1.1. Client/Server Communication 259 When a host on a private network initiates a client/server-style 260 communication session with a server on the main Internet, via the 261 server's public IP address, the NAT intercepts the packets comprising 262 that session (usually as a consequence of being the default router 263 for the private network), and modifies the packets' IP and TCP/UDP 264 headers so as to make the session appear externally as if it was 265 initiated by the NAT itself. 267 For example, if host C above initiates a connection to host A at IP 268 address 18.181.0.31, NAT 1 modifies the packets comprising the 269 session so as to appear on the main Internet as if the session 270 originated from NAT 1. Similarly, if host F on private network 3 271 initiates a connection to host A, NAT 3 modifies the session so as to 272 appear on private network 2 as if it had originated from NAT 3 at IP 273 address 10.1.1.10. The modified session then traverses private 274 network 2 and arrives at NAT 2, which further modifies the session so 275 as to appear on the main Internet as if it had originated from NAT 2 276 at public IP address 155.99.25.1. The NATs in effect serve as 277 proxies that give their private "downstream" client nodes a temporary 278 presence on "upstream" networks to support individual communication 279 sessions. 281 2.1.2. Peer-to-Peer Communication 283 While this network organization functions in practice for 284 client/server-style communication, when the client is behind one or 285 more levels of NAT and the server is on the main Internet, the lack 286 of globally routable addresses for hosts on private networks makes 287 direct peer-to-peer communication between those hosts difficult. For 288 example, two private hosts F and H on the network shown above might 289 "meet" and learn of each other through a well-known server on the 290 main Internet, such as Host A, and desire to establish direct 291 communication between G and H without requiring A to forward each 292 packet. If G and H merely learn each other's (private) IP addresses 293 from a registry kept by A, their attempts to connect to each other 294 will fail because G and H reside on different private networks. 295 Worse, if their connection attempts are not properly authenticated in 296 some fashion, they may appear to succeed but end up talking to the 297 wrong host: for example, G may end up talking to Host F, the host on 298 Private Network 3 that happens to have the same private IP address as 299 Host H. Host H might similarly end up unintentionally connecting to 300 Host I. 302 2.2. Anomalies and Caveats with the Network 303 (XXX needs work) 305 2.2.1 Anomalies with the network 307 Even though conventional wisdom would suggest that the network 308 described above is seriously broken, in practice it still works in 309 many ways. Let us look at some anomalies here. 311 For example, NAT-3 & NAT-4 are apparently multi-homed on the same 312 subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 313 through its external interface facing NAT-2, and is also on subnet 314 10.1.1/24 through its private interface facing clients, Host-F and 315 Host-G. Similarly the case wit NAT-4. In a traditional network, when 316 a node has multiple interfaces with IP addresses on the same subnet, 317 it is natural to assume that all interfaces with addresses on the 318 same subnet are on a single connected LAN (bridged LAN or a single 319 physical LAN). Clearly, that is not the case here. Even though both 320 NAT-3 and NAT-4 have two interfaces on the same subnet 10.1.1/24, the 321 two interfaces are on two disjoint subnets and LANs. So, the NATs are 322 really not multi-homed. This is an anomaly. 324 Both NAT-3 and NAT-4 are incapable of communicating reliably as a 325 transport endpoint with other nodes on their adjacent networks 326 (ex: private networks 2 and 3 in the case of NAT-3 and private 327 Networks 2 and 4 in the case of NAT-4). This is because applications 328 on either of the Nat devices cannot know to differentiate packets 329 from hosts either of the subnets bearing the same IP address. If 330 NAT-3 attempts to resolve the IP address of a neighboring host in 331 the conventional manner by broadcasting an ARP request on all of its 332 physical interfaces bearing the same subnet, it may get a different 333 response on each of its physical interfaces. This is another 334 anomaly. 336 Broken as it already is, it could have been worse and non-functional 337 if the network layout wasn't carefully orchestrated to work. 339 For example, all external interfaces for intermediate Nat devices 340 in figure 1 are arranged hierarchically, so the outgoing path for 341 all intermediate NAT devices are oriented towards the Internet 342 facing NAT. Further, the NAT devices provide the DHCP-service on 343 the private interfaces and the NAT service on the external interface. 344 If the nodes are connected differently or the services were offered 345 on the wrong interface, chaos could have ensued. Imagine NAT-3 346 device having its private interface on private network 2 and NAT 347 interface on private network 3. 349 Chaos would also ensue if there were multiple NAT devices on the same 350 LAN. Multiple NAT devices providing DHCP service on the same LAN, 351 from the same address pool is a recipe for chaos. Multiple nodes 352 would end up having the same IP address. That would make the network 353 broken. The network can also be broken if two NAT nodes attempt to 354 provide NAT service without coordination between the two. 356 The network will also be broken, if the address a NAT node (ex: NAT-3 357 or NAT-4) assumed on the DHCP-service providing interface is same as 358 the address it is assigned on the external interface. This can easily 359 happen when the vendors are different. Say, both interfaces being 360 assigned 10.1.1.1 362 2.2.1 Caveats with the network 364 Below are some known caveats with the network shown in figure 1. 366 1. The NAT boxes (NAT-3, NAT-4, NAT-1, NAT-2) themselves do not 367 provide any service other than respond to ping. NATs are not managed. 369 2. Hosts on the private realm are all assumed to be on a single LAN 370 subnet. 372 3. This can be a security threat. What if ISP unwisely uses private 373 RFC1918 IP addresses for its mail servers, etc., which need to be 374 accessible to its customers? Customer mail messages could be 375 hijacked by the ISP�s mail server. 377 2.3. Recommendations 378 (XXX needs work.) 380 Consumer-oriented "Plug and Play" NAT devices MUST, and all NATs 381 SHOULD, be able to handle topologies such as the one described above, 382 in which a private IP address space on one side of the NAT 383 potentially conflicts with the private IP address space on the other 384 side. This means that the NAT must be able to keep the two IP 385 address spaces separate in its internal data structures, and base all 386 packet processing decisions on the "side" or "port" from which the 387 packet arrived and not just on the basis of the IP addresses it 388 contains. 390 NATs should individually conform to [BEHAVE-UDP] and [BEHAVE-TCP] 391 guidelines, especially including hairpin translation support. 393 Peer-to-peer apps should conform to [BEHAVE-APP] guidelines for 394 middlebox traversal. 396 Ideally, ISPs should not NAT their customers. If they do, any 397 servers on the ISP's private network that need to be accessible to 398 the ISP's customers (e.g., mail servers) should have global IP 399 addresses, to ensure accessibility to customers who deploy NAT 400 themselves. 402 NAT boxes should provide an ability to use one of two DHCP address 403 pools and automagically use an address pool that does not conflict 404 with the external interface IP address. 406 3. Remote Access VPN Topologies with Private Address Space 408 Remote Access VPN is quite popular amongst enterprises. Enterprises 409 use Remote Access VPN as a means to allow secure access to their 410 employees working from outside the enterprise premises. While 411 outside the enterprise premises, the employee may be located in 412 his/her home office, a hotel, a conference or a partner's office. 413 In all cases, it is desirable for the employee at the remote site 414 to have complete access to his/her corporate network and the 415 applications running on the corporate networks. This is so the 416 employee can get his/her work done seamlessly without jeopardizing 417 the integrity and confidentiality of the corporate network and the 418 applications running on the network. 420 Besides authenticating the employees prior to granting access, 421 remote access servers in the enterprise enforce different forms of 422 security on the remote access VPN clients for securing the 423 integrity and confidentiality of the run-time traffic between the 424 VPN client and the remote access server. IPsec, L2TP and SSL are 425 some of the well known secure VPN technologies used by the remote 426 access vendors. 428 Many of the small enterprises deploy their internal networks using 429 the RFC-1918 specified private address space. The enterprises use 430 NAT devices to connect to the public Internet. Many of the 431 applications in the corporate network in turn refer to information 432 (such as URLs) and services that refer to other nodes in the 433 private corporate network. Some of the applications (such as NFS) 434 rely on simple source IP address based filtering to restrict 435 access to corporate users. These are some of the reasons why the 436 remote access servers are configured with a block of IP addresses 437 from the corporate network to assign to remote access VPN clients 438 prior to allowing access to corporate resources. VPN clients use 439 the virtual IP assigned to them by the corporate VPN server to 440 access networks and applications inside the corporate. 442 Consider the following remote access scenario. 444 (Corporate Private network 10.0.0.0/8) 445 --------+---------------+------------+---------- 446 | 447 | 448 10.1.1.1 449 +---------------+ 450 | | 451 | Secure | 452 | Remote Access | 453 | VPN Server | 454 +------+--------+ 455 129.32.34.18 456 | 457 {--------------------+---------------} 458 { } 459 { Public Internet } 460 { (Public IP addresses) } 461 { } 462 {--------------------+---------------} 463 | 464 155.99.25.1 465 +----------------+ 466 | NAT | 467 | (in a Hotel | +--------+ 468 | or home office | | | 469 | or a partner's | | DHCP | 470 | corp. office | | Server | 471 | | | | 472 +----------------+ +--------+ 473 10.1.1.1 10.1.1.2 474 | | 475 Remote Private Network | | 476 ----+-----------+-----------+-------------+----------+------ 477 | | | | 478 | | | | 479 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 480 Host A Host B +--------+ Host C 481 | RA-VPN | 482 | Client | 483 | PC | 484 +--------+ 486 Figure 2: Remote access VPN to access enterprise from private LAN 488 In the above scenario, say an employee of the corporate is at a 489 remote site and trying to access the corporate network using the 490 VPN client. The corporate network is laid out using 10.0.0.0/8 491 and say the VPN server is configured with an address block of 492 10.1.1.0/24 to assign virtual IP addresses to its remote access 493 clients. Now. say the employee at the remote site is attached to 494 a network on the remote site which also happens to be using a 495 RFC-1918 address space based network and coincidentally overlaps 496 the corporate network. In such a situation, there can be several 497 problems with using the VPN client to connect to the remote 498 access server at the enterprise. 500 The following subsections go on to describe the operational 501 details of the VPN, caveats with the above address overlap 502 situation and possible remedies to correct the situation. 504 3.1. Operational Details of the Network 506 Typically, when an employee at the remote site launches his/her 507 VPN client, the VPN client is required to authenticate with the VPN 508 server at the corporate premises. Once the authentication succeeds, 509 the VPN server assigns a Virtual IP (VIP) address for use by the 510 VPN client in all its transactions with the corporate network and 511 applications. The VPN client in turn installs a Virtual adapter 512 (VA) on the PC and configures the VA with the VIP address it was 513 assigned by the VPN server. Further, the VPN client adds new routes 514 to the PC such that all the subnets in the corporate are accessible 515 via the Virtual Adapter. By doing this, all traffic directed to 516 and from the corporate networks is redirected to the secure VPN, 517 while leaving all other routes unchanged on the PC. This works well 518 so long as there is no conflict of routes on the PC when new routes 519 to the corporate network are added. 521 This becomes tricky when the corporate intranet network is built 522 using RFC1918 address space and the remote location where the 523 VPN client is launched is also using the RFC1918 address space. 524 In such a situation, the routing table on the PC will have a 525 conflict in accessing nodes on the corporate site and nodes in 526 the remote site bearing the same IP address simultaneously. 527 Consequently, the VPN client may be unable to have full access 528 to the employee's corporate network. 530 3.2. Caveats with the Network 532 When there is address overlap between corporate network and the 533 remote site, the VPN user may be unaware of this and may loose 534 connectivity to an arbitrary block of services on the corporate 535 network. Worse yet, when a certain service (ex: SMTP mail service) 536 is configured on exactly the same IP address on both the corporate 537 site and the remote site, the user could unknowingly be using the 538 service on the wrong node at remote site, thereby violating the 539 integrity and confidentiality of the contents relating to that 540 application. 542 In the case a corporate address resource overlaps with the router 543 on the remote site, the VPN user could loose connectivity entirely 544 if requests to the router address are redirected to the VPN. 545 Likewise, if a corporate address resource overlaps with the DHCP 546 server on the remote site, the VPN user could also loose 547 connectivity if requests to the DHCP server are redirected to the 548 VPN. 550 3.3. Recommendations 552 Clearly, the remote access VPN client works best when the external 553 client IP address (on the ethernet NIC) does not overlap with the 554 corporate address space and the corporate VPN address pool. However, 555 this cannot be assumed always. Employees often need to work from 556 within arbitrary private IP address spaces such as hotel rooms, which 557 neither the employee nor the corporate network administrator has any 558 control over. In these situations, the following recommendations 559 will help ensure that a complete "network meltdown" is prevented. 561 1. The RA-VPN client's external IP address and subnet (at the remote 562 site) should not fall within the VIP address pool assigned by the 563 VPN server. 565 2. The VPN users should not attempt to access services on the remote 566 site and services on the corporate site simultaneously. 567 Specifically, while the VPN is connected, the VPN user should not 568 attempt to access services on the remote site. Some services such 569 as the routing and DHCP service may however be unavoidable. 571 3. Do not permit access to corporate services that are running on 572 an IP address that match the following entities at the remote 573 site. a) client's external IP address, b) client's next-hop 574 router IP address used to access the VPN server, and c) DHCP 575 server providing address lease on the external interface. 576 The good news is that all these three essential services are 577 on the same subnet on the external interface. 579 In general, it may be advisabale to disallow access to any 580 corporate network resource that overlaps the client's external 581 IP subnet. For example, if the PC's external NIC is configured 582 with 10.1.1.1/24, disallow access to the corporate network that 583 overlaps this subnet from the remote access VPN client. 585 Note, the above recommendations do not guarantee that the remote 586 employee will be able to gain complete access to the corporate 587 network he needs to if there is address overlap. Below are some 588 recommendations to ensure the employee is always able to 589 access mission critical application on the corporate network. 591 1. Even if most of the private corporate network uses RFC1918 address 592 space, allocate global IP addresses at least for the pool of IP 593 addresses assigned to remote VPN clients, and for the critical 594 servers on the corporate network that the remote VPN clients 595 typically need to access. This will ensure at least that the 596 remote VPN clients can always access those critical servers 597 regardless of the private address space used at the remote 598 attachment point. 600 2. We can suggest that there be two IP address pools on the VPN 601 server, (or) two VPN servers with different address pools so 602 the address pool which is used for a VPN client doesn't 603 ever conflict with the physical NIC's IP address. For example, 604 the VPN server might detect a conflict and inform the user that 605 he/she should try to connect to the "other" VPN server or IP 606 address pool. Ideally, the VPN client and server could 607 cooperate to perform this negotiation automatically. 609 3. the subnet mask used on the hotels be as small as possible (say, 610 /29) and the hotels have a centralized DHCP-server that covers 611 multiple small subnets. By doing this, the likelihood of 612 conflict with corporate services is highly minimized. 614 Perhaps, if the VPN server identified the overlap of the remote IP 615 network and notified the VPN-client of the loss of connectivity to 616 that portion of the corporate world, the VPN-client could do 617 something about it - such as talk to the local admin about 618 assigning himself an IP address from a different subnet (say, 619 plugging to a different plug point) if the hotel has such a 620 facility. 622 4. Finally, the VPN-client could come in as bump in the stack and 623 redirect all relevant packets in the subnet (with the exception of 624 those that match with the router and DHCP server) over the VPN. 625 This at least reduces the size of the "black hole" on the 626 corporate network from a whole subnet to merely the specific 627 services running on the DHCP server and the next-hop router. 629 4. Security Considerations 630 (xxx needs work) 632 References (XXX needs updating) 634 [BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, 635 "Bidirectional Peer-to-Peer Communication with Interposing 636 Firewalls and NATs", August 2001. 637 http://www.peer-to-peerwg.org/tech/nat/ 639 [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): 640 A Methodology for Network Address Translator (NAT) Traversal 641 for the Session Initiation Protocol (SIP)", 642 draft-rosenberg-sipping-ice-00 (Work In Progress), 643 February 2003. 645 [IPSEC-NAT] B. Aboba and W. Dixon, "IPsec-Network Address Translation 646 (NAT) Compatibility Requirements", RFC 3715, March 2004. 648 [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. 649 http://www.alumni.caltech.edu/~dank/peer-nat.html 651 [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and 652 A. Rayhan, "Middlebox communication architecture and 653 framework", RFC 3303, August 2002. 655 [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly 656 Application Design Guidelines", RFC 3235, January 2002. 658 [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications 659 with the IP Network Address Translator", RFC 3027, 660 January 2001. 662 [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address 663 Translation - Protocol Translation (NAT-PT)", RFC 2766, 664 February 2000. 666 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address 667 Translator (NAT) Terminology and Considerations", RFC 668 2663, August 1999. 670 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network 671 Address Translator (Traditional NAT)", RFC 3022, 672 January 2001. 674 [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, 675 "Realm Specific IP: Framework", RFC 3102, October 2001. 677 [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and 678 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 680 [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, 681 "STUN - Simple Traversal of User Datagram Protocol (UDP) 682 Through Network Address Translators (NATs)", RFC 3489, 683 March 2003. 685 [SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN", 686 draft-takeda-symmetric-nat-traversal-00.txt (Work In 687 Progress), June 2003. 689 [TCP] "Transmission Control Protocol", RFC 793, September 1981. 691 [TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", 692 draft-ietf-ngtrans-shipworm-08.txt (Work In Progress), 693 September 2002. 695 [TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema, 696 "Traversal Using Relay NAT (TURN)", 697 draft-rosenberg-midcom-turn-01 (Work In Progress), 698 March 2003. 700 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 701 Device Control Protocol V 1.0", November 2001. 702 http://www.upnp.org/standardizeddcps/igd.asp 704 [NAT-MIB] R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, and, 705 C. Wang, "Definitions of Managed Objects for Network 706 Address Translators (NAT)", RFC 4008, February 2005 708 Authors' Addresses: 710 Bryan Ford 711 Computer Science and Artificial Intelligence Laboratory 712 Massachusetts Institute of Technology 713 77 Massachusetts Ave. 714 Cambridge, MA 02139 715 U.S.A. 716 Phone: (617) 253-5261 717 E-mail: baford@mit.edu 718 Web: http://www.brynosaurus.com/ 720 Pyda Srisuresh 721 Caymas Systems, Inc. 722 1179-A North McDowell Blvd. 723 Petaluma, CA 94954 724 U.S.A. 725 Phone: (707) 283-5063 726 E-mail: srisuresh@yahoo.com 728 Full Copyright Statement 730 Copyright (C) The Internet Society (2005). This document is subject 731 to the rights, licenses and restrictions contained in BCP 78, and 732 except as set forth therein, the authors retain all their rights. 734 This document and the information contained herein are provided on an 735 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 736 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 737 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 738 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 739 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 740 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.