idnits 2.17.1 draft-ford-behave-top-01.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 722. ** 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. 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 401: '...d Play" NAT devices MUST, and all NATs...' RFC 2119 keyword, line 402: '... 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 338 has weird spacing: '...natural to as...' -- 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 (March 5, 2006) is 6621 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: 'BEHAVE-UDP' is mentioned on line 411, but not defined == Missing Reference: 'BEHAVE-TCP' is mentioned on line 411, but not defined == Missing Reference: 'BEHAVE-APP' is mentioned on line 414, but not defined == Unused Reference: 'KEGEL' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'NAT-PT' is defined on line 675, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 5 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-01.txt Consultant 4 Expires: September 5, 2006 B. Ford 5 M.I.T. 6 March 5, 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 problems that have arisen from the 37 the unconventional network topologies that are often constructed 38 with the deployment of network address translator devices (NATs). 39 This document also specifies best current practice recommendations 40 for dealing with the issues identified with the two problems. 41 First, the simplicity of administering networks through the 42 combination of NAT and DHCP has increasingly lead to the 43 deployment of multi-level hierarchies of inter-connected private 44 networks involving overlapping private IP address spaces. Second, 45 the proliferation of private networks in the corporates and the 46 wide spread use of remote access virtual private networks (VPNs) can 47 lead to conflict of private IP address space between the remote 48 network where the VPN client is located and the corporate network. 50 Table of Contents 52 1. Introduction and Scope........................................ 53 2. Multi-Level Private Address Space Topologies ................. 54 2.1. Operational Details of the Network ...................... 55 2.1.1. Client/Server Communication ........................... 56 2.1.2. Peer-to-Peer Communication ............................ 57 2.2. Anomalies and Caveats with the Network .................. 58 2.2.1. Anomalies with the Network ............................ 59 2.2.2. Caveats with the Network .............................. 60 2.3. Recommendations ......................................... 61 3. Remote Access VPN Topologies with Private Address Space ...... 62 3.1. Operational Details of the Network ...................... 63 3.2. Caveats with the Network ................................ 64 3.3. Recommendations ......................................... 65 4. Security Considerations ...................................... 66 5. Informational References ..................................... 68 1. Introduction and Scope 70 The Internet was originally designed to use a single, global 32-bit 71 IP address space to identify hosts on the network, allowing 72 applications on one host to address and initiate communications with 73 applications on any other host regardless of the respective hosts' 74 topological locations or administrative domains. For a variety of 75 pragmatic reasons, however, the Internet has gradually drifted away 76 from strict conformance to this ideal of a single flat global address 77 space, and towards a hierarchy of smaller "private" address spaces 78 [RFC1918] clustered around a large central "public" address space. 79 The most important pragmatic causes of this unintended evolution of 80 the Internet's architecture appear to be: 82 1. Depletion of the 32-bit IPv4 address space due to the exploding 83 total number of hosts on the Internet. Although IPv6 promises to 84 solve this problem, the uptake of IPv6 has in practice been slower 85 than expected. 87 2. Perceived Security and Privacy: Traditional NAT devices provide a 88 filtering function that permits session flows to cross the NAT in 89 just one direction, from private hosts to public network hosts. 90 This filtering function is widely perceived as a security benefit. 92 In addition, the NAT's translation of a host's original IP 93 addresses and port number in private network into an unrelated, 94 external IP address and port number is perceived by some as a 95 privacy benefit. 97 3. Ease-of-use: NAT vendors often combine the NAT function with a 98 DHCP server function in the same device, which creates a 99 compelling, effectively "plug-and-play" method of setting up small 100 Internet-attached personal networks that is often much easier in 101 practice for unsophisticated consumers than configuring an 102 IP subnet. The many popular and inexpensive consumer NAT devices 103 on the market are usually configured "out of the box" to obtain a 104 single "public" IP address from an ISP or "upstream" network via 105 DHCP, and the NAT device in turn acts as both a DHCP server and 106 default router for any "downstream" hosts (and even other NATs) 107 that the user plugs into it. Consumer NATs in this way 108 effectively create and manage private home networks automatically 109 without requiring any knowledge of network protocols or management 110 on the part of the user. 112 This ease-of-use benefit of NAT stems ultimately from the fact 113 that DHCP is only capable of providing a single auto-configured 114 IP address to each client. A DHCP client currently has no way to 115 request a *block* of IP addresses from the server, from which it 116 might form its own auto-configured "downstream" IP subnet for use 117 with the DHCP service it offers. The fact that the DHCP function 118 in the NAT devices is capable of auto-configuring client hosts 119 makes NAT devices a compelling solution in this common scenario. 121 The term NAT used throughout the document specifically refers to 122 the traditional NAT, as defined in [NAT-TERM] and specified in 123 [NAT-TRAD]. 125 [NAT-PROT] identifies various complications with application 126 protocols due to NAT devices. This document acts as an adjunct to 127 [NAT-PROT]. The scope of the document is restricted specifically to 128 two problems that were identified as arising out of private address 129 space overlaps. For each of the problems, the document describes the 130 problem statement, caveats, topologies in which the problem can 131 occur, and offers recommendations on how to alleviate. 133 Section 2 describes the problem of private address space overlap 134 due to multi-level hierarchies of private networks and provides 135 recommendations on how to alleviate them. Section 3 describes the 136 problem of private address space conflict between the address space 137 at remote access VPN client locations and the VPN server site, and 138 makes recommendations on how to alleviate them. Section 4 refers 139 the security considerations in these scenarios. 141 2 Multi-Level Private Address Space Topologies 143 Due to the above pragmatic considerations and perhaps others, NATs 144 are increasingly, and often unintentionally, used to create 145 hierarchically interconnected clusters of private networks as 146 illustrated in the following diagram. The creation of multi-level 147 hierarchies is often unintentional, since each level of NAT is 148 typically deployed by a separate administrative entity such 149 as an ISP, a corporation, or a home user. 151 Public Internet 152 (Public IP addresses) 153 ----+---------------+---------------+---------------+---- 154 | | | | 155 | | | | 156 66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1 157 +-------+ Host A Host B +-------------+ 158 | NAT-1 | (Alice) (Jim) | NAT-2 | 159 | (Bob) | | (CheapoISP) | 160 +-------+ +-------------+ 161 10.1.1.1 10.1.1.1 162 | | 163 | | 164 Private Network 1 Private Network 2 165 (private IP addresses) (private IP addresses) 166 ----+--------+---- ----+-----------------------+---- 167 | | | | | 168 | | | | | 169 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 170 Host C Host D +-------+ Host E +-------+ 171 | NAT-3 | (Mary) | NAT-4 | 172 | (Ann) | | (Lex) | 173 +-------+ +-------+ 174 10.1.1.1 10.1.1.1 175 | | 176 | | 177 Private Network 3 | Private Network 4 178 (private IP addresses)| (private IP addresses) 179 ----+-----------+---+ ----+-----------+---- 180 | | | | 181 | | | | 182 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 183 Host F Host G Host H Host I 185 Figure 1: Multi-level NAT topology with private address space 187 In the above scenario, Bob, Alice, Jim, and CheapoISP have each 188 obtained a "genuine", globally routable IP address from an upstream 189 service provider. Alice and Jim have chosen to attach only a single 190 machine at each of these public IP addresses, preserving the 191 originally intended architecture of the Internet and making their 192 hosts, A and B, globally addressable throughout the Internet. Bob, 193 in contrast, has purchased and attached a typical consumer NAT box. 194 Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP 195 via DHCP, and automatically creates a private 10.1.1.x network for 196 Bob's hosts C and D, acting as the DHCP server and default router for 197 this private network. Bob probably does not even know anything about 198 IP addresses; he merely knows that plugging the NAT into the Internet 199 as instructed by the ISP, and then plugging his hosts into the NAT as 200 the NAT's manual indicates, seems to work and gives all of his hosts 201 access to Internet. 203 CheapoISP, an inexpensive service provider, has allocated only one or 204 a few globally routable IP addresses, and uses NAT to share these 205 public IP addresses among its many customers. Such an arrangement is 206 becoming increasingly common, especially in rapidly-developing 207 countries where the exploding number of Internet-attached hosts 208 greatly outstrips the ability of ISPs to obtain globally unique IP 209 addresses for them. CheapoISP has chosen the popular 10.1.1.x 210 address for its private network, since this is one of the three 211 well-known private IP address blocks allocated in RFC1918 212 specifically for this purpose. 214 Of the three incentives listed in section 1 for NAT deployment, the 215 last two still apply even to customers of ISPs that use NAT, 216 resulting in multi-level NAT topologies as illustrated in the right 217 side of the above diagram. Even three-level NAT topologies are known 218 to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained 219 a single IP address on CheapoISP's network (Private Network 2), via 220 DHCP. Mary attaches only a single host at this point, but 221 Ann and Lex each independently purchase and deploy consumer NATs in 222 the same way that Bob did above. As it turns out, these consumer 223 NATs also happen to use 10.1.1.x addresses for the private networks 224 they create, since these are the configuration defaults hard-coded 225 into the NATs by their vendors. Ann and Lex probably know nothing 226 about IP addresses, and in particular they are probably unaware that 227 the IP address spaces of their own private networks overlap not only 228 with each other but also with the private IP address space used by 229 their immediately upstream network. 231 Nevertheless, despite this direct overlap, all of the "multi-level 232 NATted hosts" - F, G, H, and I in this case - all nominally function 233 and are able to initiate connections to any public server on the main 234 Internet that has a globally routable IP address. Connections made 235 from these hosts to the main Internet are merely translated twice. 236 once by the consumer NAT (3 or 4) into the IP address space of 237 CheapoISP's Private Network 2, and then again by CheapoISP's NAT 2 238 into the main Internet's global IP address space. 240 2.1 Operational Details of the Network 242 In the "de facto" Internet address architecture that has resulted 243 from the above pragmatic and economic incentives, only the nodes on 244 the main Internet have globally unique IP addresses assigned by the 245 official IP address registries. IP addresses on different private 246 networks are typically managed independently - either manually by 247 the administrator of the private network itself, or automatically by 248 the NAT through which the private network is connected to its 249 "upstream" service provider. 251 By convention, nodes on private networks are usually assigned IP 252 addresses in one of the private address space ranges specifically 253 allocated to this purpose in RFC 1918, ensuring that private IP 254 addresses are easily distinguishable and do not conflict with the 255 public IP addresses officially assigned to globally routable Internet 256 hosts. A given private IP address can be and often is reused across 257 many different private networks, however. In the figure above, for 258 example, private networks 1, 2, 3, and 4 all have a node with IP 259 address 10.1.1.10. 261 Because the public and private IP address ranges are numerically 262 disjoint, nodes on private networks can make use of both public and 263 private IP addresses when initiating network communication sessions. 264 Nodes on private networks can use private IP addresses to refer to 265 other nodes on the same private network, and nodes can use public IP 266 addresses to refer to nodes on the main Internet. Nodes on private 267 networks have no direct method of addressing nodes on other private 268 networks, however, and nodes on the main Internet have no direct way 269 to address nodes on any private network. For example, host F in the 270 figure above can directly address hosts A, B, and G using their 271 assigned IP addresses, but F has no way to address any of the other 272 hosts in the diagram. Host F in particular has no way even to 273 address host E, even though E is located on the immediately 274 "upstream" private network through which F is connected to the 275 Internet! Host E has the same IP address as host G. Yet, this is 276 "legitimate" in the NAT world because the two hosts are on different 277 private networks. 279 2.1.1. Client/Server Communication 281 When a host on a private network initiates a client/server-style 282 communication session with a server on the main Internet, via the 283 server's public IP address, the NAT intercepts the packets comprising 284 that session (usually as a consequence of being the default router 285 for the private network), and modifies the packets' IP and TCP/UDP 286 headers so as to make the session appear externally as if it was 287 initiated by the NAT itself. 289 For example, if host C above initiates a connection to host A at IP 290 address 18.181.0.31, NAT 1 modifies the packets comprising the 291 session so as to appear on the main Internet as if the session 292 originated from NAT 1. Similarly, if host F on private network 3 293 initiates a connection to host A, NAT 3 modifies the session so as to 294 appear on private network 2 as if it had originated from NAT 3 at IP 295 address 10.1.1.10. The modified session then traverses private 296 network 2 and arrives at NAT 2, which further modifies the session so 297 as to appear on the main Internet as if it had originated from NAT 2 298 at public IP address 155.99.25.1. The NATs in effect serve as 299 proxies that give their private "downstream" client nodes a temporary 300 presence on "upstream" networks to support individual communication 301 sessions. 303 2.1.2. Peer-to-Peer Communication 305 While this network organization functions in practice for 306 client/server-style communication, when the client is behind one or 307 more levels of NAT and the server is on the main Internet, the lack 308 of globally routable addresses for hosts on private networks makes 309 direct peer-to-peer communication between those hosts difficult. For 310 example, two private hosts F and H on the network shown above might 311 "meet" and learn of each other through a well-known server on the 312 main Internet, such as Host A, and desire to establish direct 313 communication between G and H without requiring A to forward each 314 packet. If G and H merely learn each other's (private) IP addresses 315 from a registry kept by A, their attempts to connect to each other 316 will fail because G and H reside on different private networks. 317 Worse, if their connection attempts are not properly authenticated in 318 some fashion, they may appear to succeed but end up talking to the 319 wrong host: for example, G may end up talking to Host F, the host on 320 Private Network 3 that happens to have the same private IP address as 321 Host H. Host H might similarly end up unintentionally connecting to 322 Host I. 324 2.2. Anomalies and Caveats with the Network 326 2.2.1 Anomalies with the network 328 Even though conventional wisdom would suggest that the network 329 described above is seriously broken, in practice it still works in 330 many ways. Let us look at some anomalies here. 332 For example, NAT-3 and NAT-4 are apparently multi-homed on the same 333 subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 334 through its external interface facing NAT-2, and is also on subnet 335 10.1.1/24 through its private interface facing clients, Host-F and 336 Host-G. Similarly the case with NAT-4. In a traditional network, when 337 a node has multiple interfaces with IP addresses on the same subnet, 338 it is natural to assume that all interfaces with addresses on the 339 same subnet are on a single connected LAN (bridged LAN or a single 340 physical LAN). Clearly, that is not the case here. Even though both 341 NAT-3 and NAT-4 have two interfaces on the same subnet 10.1.1/24, 342 the two interfaces are on two disjoint subnets and LANs. So, the 343 NATs are really not multi-homed. This is an anomaly. 345 Both NAT-3 and NAT-4 are incapable of communicating reliably as a 346 transport endpoint with other nodes on their adjacent networks 347 (ex: private networks 2 and 3 in the case of NAT-3 and private 348 Networks 2 and 4 in the case of NAT-4). This is because applications 349 on either of the NAT devices cannot know to differentiate packets 350 from hosts either of the subnets bearing the same IP address. If 351 NAT-3 attempts to resolve the IP address of a neighboring host in 352 the conventional manner by broadcasting an ARP request on all of its 353 physical interfaces bearing the same subnet, it may get a different 354 response on each of its physical interfaces. This is another 355 anomaly. 357 Broken as it already is, it could have been worse and non-functional 358 if the network layout wasn't carefully orchestrated. 360 For example, all external interfaces for intermediate Nat devices 361 in figure 1 are arranged hierarchically, so the outgoing path for 362 all intermediate NAT devices are oriented towards the Internet 363 facing NAT. Further, the NAT devices provide the DHCP-service on 364 the private interfaces and the NAT service on the external interface. 365 If the nodes are connected differently or the services were offered 366 on the wrong interface, chaos could have ensued. Imagine NAT-3 367 device having its private interface on private network 2 and NAT 368 interface on private network 3. 370 Chaos would also ensue if there were multiple NAT devices on the same 371 LAN. Multiple NAT devices providing DHCP service on the same LAN, 372 from the same address pool is a recipe for chaos. Multiple nodes 373 would end up having the same IP address. That would make the network 374 broken. The network can also be broken if two NAT nodes attempted to 375 provide NAT service without coordination between the two. 377 The network will also be broken, if the address a NAT node 378 (ex: NAT-3 or NAT-4) assumed on the DHCP-service providing interface 379 is same as the address it is assigned on the external interface. 380 This can easily happen when the vendors are different. Say, both 381 interfaces being assigned 10.1.1.1 383 2.2.1 Caveats with the network 385 Below are some known caveats with the network shown in figure 1. 387 1. The NAT boxes (NAT-3, NAT-4, NAT-1, NAT-2) themselves do not 388 provide any service other than respond to ping. NATs are not 389 managed. 391 2. Hosts on the private realm are all assumed to be on a single LAN 392 subnet. 394 3. There can be a security threat. Suppose, an ISP unwisely used 395 RFC1918 IP addresses for its mail servers and say these addresses 396 overlapped with the customer's mail servers. In such a case, 397 Customer mail messages could be hijacked by the ISP�s mail server. 399 2.3. Recommendations 401 Consumer-oriented "Plug and Play" NAT devices MUST, and all NATs 402 SHOULD, be able to handle topologies such as the one described above, 403 in which a private IP address space on one side of the NAT 404 potentially conflicts with the private IP address space on the other 405 side. This means that the NAT must be able to keep the two IP 406 address spaces separate in its internal data structures, and base 407 all packet processing decisions on the "side" or "port" from which 408 the packet arrived and not just on the basis of the IP addresses it 409 contains. 411 NATs should individually conform to [BEHAVE-UDP] and [BEHAVE-TCP] 412 guidelines, especially including hairpin translation support. 414 Peer-to-peer apps should conform to [BEHAVE-APP] guidelines for 415 middlebox traversal. 417 Ideally, ISPs should not NAT their customers. If they do, any 418 servers on the ISP's private network that need to be accessible to 419 the ISP's customers (e.g., mail servers) should have global IP 420 addresses, to ensure accessibility to customers who deploy NAT 421 themselves. 423 NAT boxes should provide an ability to use one of two DHCP address 424 pools and automagically use an address pool that does not conflict 425 with the external interface IP address. 427 3. Remote Access VPN Topologies with Private Address Space 429 Remote Access Virtual Private Network (VPN) is popular with 430 enterprises. Enterprises use Remote Access VPN to allow secure 431 access to their employees working outside the enterprise premises. 432 While outside the enterprise premises, the employee may be located 433 in his/her home office, hotel, conference or a partner's office. 434 In all cases, it is desirable for the employee at the remote site 435 to have unhindered access to his/her corporate network and the 436 applications running on the corporate networks. This is so the 437 employee can get his/her work done seamlessly without jeopardizing 438 the integrity and confidentiality of the corporate network and the 439 applications running on the network. 441 Besides authenticating employees for granting access, remote access 442 VPN servers often enforce different forms of security to protect the 443 integrity and confidentiality of the run-time traffic between the 444 VPN client and the remote access server. IPsec, L2TP and SSL are 445 some of the well known secure VPN technologies used by the remote 446 access vendors. 448 Many small enterprises deploy their internal networks using RFC-1918 449 private address space. The enterprises use NAT devices to connect to 450 the public Internet. Further, many of the applications in the 451 corporate network refer to information (such as URLs) and services 452 using private addresses in the corporate network. Applications such 453 as NFS rely on simple source IP address based filtering to restrict 454 access to corporate users. These are some reasons why the remote 455 access VPN servers are configured with a block of IP addresses from 456 the corporate private network to assign to remote access clients. 457 VPN clients use the virtual IP address assigned to them (by the 458 corporate VPN server) to access applications inside the corporate. 460 Consider the following remote access scenario. 462 (Corporate Private network 10.0.0.0/8) 463 --------+---------------+------------+---------- 464 | 465 | 466 10.1.1.1 467 +---------------+ 468 | | 469 | Secure | 470 | Remote Access | 471 | VPN Server | 472 +------+--------+ 473 129.32.34.18 474 | 475 {--------------------+---------------} 476 { } 477 { Public Internet } 478 { (Public IP addresses) } 479 { } 480 {--------------------+---------------} 481 | 482 155.99.25.1 483 +----------------+ 484 | NAT | 485 | (in a Hotel | +--------+ 486 | or home office | | | 487 | or a partner's | | DHCP | 488 | corp. office | | Server | 489 | | | | 490 +----------------+ +--------+ 491 10.1.1.1 10.1.1.2 492 | | 493 Remote Private Network | | 494 ----+-----------+-----------+-------------+----------+------ 495 | | | | 496 | | | | 497 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 498 Host A Host B +--------+ Host C 499 | RA-VPN | 500 | Client | 501 | PC | 502 +--------+ 504 Figure 2: Remote access VPN to access enterprise from private LAN 506 In the above scenario, say an employee of the corporate is at a 507 remote site and trying to access the corporate network using the 508 VPN client. The corporate network is laid out using 10.0.0.0/8 509 and say the VPN server is configured with an address block of 510 10.1.1.0/24 to assign virtual IP addresses to its remote access 511 clients. Now. say the employee at the remote site is attached to 512 a network on the remote site which also happens to be using a 513 RFC-1918 address space based network and coincidentally overlaps 514 the corporate network. In such a situation, there can be several 515 problems with using the VPN client to connect to the remote 516 access server at the enterprise. 518 The following subsections describe the operational of VPNs, 519 caveats with the address overlap scenario and potential remedies 520 to correct the situation. 522 3.1. Operational Details of the Network 524 Below is a high level description of how a remote access VPN 525 typically works. The specifics may vary from vendor to vendor. The 526 intent is to provide a high level understanding of the operation to 527 gain appreciation for the problem at hand. 529 Typically, when an employee at the remote site launches his/her 530 VPN client, the VPN client is required to authenticate with the VPN 531 server at the corporate premises. Once the authentication succeeds, 532 the VPN server assigns a Virtual IP (VIP) address for use by the 533 VPN client in all its transactions with the corporate network and 534 applications. The VPN client in turn installs a Virtual adapter 535 (VA) on the PC and configures the VA with the VIP address it was 536 assigned by the VPN server. Further, the VPN client adds new routes 537 to the PC such that all the subnets in the corporate are accessible 538 via the Virtual Adapter. By doing this, all traffic directed to 539 and from the corporate networks is redirected to the secure VPN, 540 while leaving all other routes unchanged on the PC. 542 This works well so long as there is no conflict of routes on the PC 543 when new routes to the corporate network are added. This becomes 544 tricky when the corporate intranet network is built using RFC1918 545 address space and the remote location where the VPN client is 546 launched is also using an overlapping network from RFC1918 address 547 space. 549 In such a situation, the routing table on the PC will have a 550 conflict in accessing nodes on the corporate site and nodes in 551 the remote site bearing the same IP address simultaneously. 552 Consequently, the VPN client may be unable to have full access 553 to the employee's corporate network. 555 3.2. Caveats with the Network 556 When there is address overlap between corporate network and the 557 remote site, the VPN user may be unaware of this and may loose 558 connectivity to an arbitrary block of services on the corporate 559 network. Worse yet, when a certain service (ex: SMTP mail service) 560 is configured on exactly the same IP address on both the corporate 561 site and the remote site, the user could unknowingly be using the 562 service on the wrong node at remote site, thereby violating the 563 integrity and confidentiality of the contents relating to that 564 application. 566 In the case a corporate address resource overlaps with the router 567 on the remote site, the VPN user could loose connectivity entirely 568 if requests to the router address are redirected to the VPN. 569 Likewise, if a corporate address resource overlaps with the DHCP 570 server on the remote site, the VPN user could also loose 571 connectivity if requests to the DHCP server are redirected to the 572 VPN. 574 3.3. Recommendations 576 Remote access VPN clients work best when the external client IP 577 address (on the physical network interface) does not overlap with 578 the address space from the corporate VPN address pool. However, 579 this cannot be assumed always. Employees often need to work from 580 locations such as hotel rooms and conferences that use arbitrary 581 blocks of private address spaces, which neither the employee nor 582 the corporate network administrator has any control over. In these 583 situations, the following recommendations will help ensure that a 584 complete "network meltdown" is prevented. 586 1. The VPN client's external IP address and subnet (at the remote 587 site) should not fall within the VIP address pool assigned by the 588 VPN server. 590 2. The VPN users should not attempt to access services on the remote 591 site and services on the corporate site simultaneously. 592 Specifically, when the VPN is connected, the VPN user should not 593 attempt to access services on the remote site. Unavoidable 594 services such as the routing and DHCP service at the remote site 595 are exempted. 597 3. VPN servers should not permit access to corporate services that 598 are running on an IP address that match the following entities 599 at the remote site. a) client's external IP address, b) client's 600 next-hop router IP address used to access the VPN server, and 601 c) DHCP server providing address lease on the external interface. 602 The good news is that all these three essential services are 603 on the same subnet on the external interface. 605 As a general practice, it is advisable to disallow access to any 606 corporate network resource that overlaps the client's external 607 IP subnet. For example, if the PC's external network interface is 608 configured with 10.1.1.1/24, disallow access to the corporate 609 network that overlaps this subnet from the remote access VPN 610 client. 612 The above recommendations do not guarantee that the remote 613 employee will be able to gain complete access to the corporate 614 network he needs to if there is address overlap. Below are some 615 recommendations to ensure the employee is always able to 616 access mission critical application on the corporate network. 618 1. Even if most of the private corporate network uses RFC1918 address 619 space, allocate global IP addresses at least for the pool of IP 620 addresses assigned to remote VPN clients, and for the critical 621 servers on the corporate network that the remote VPN clients 622 typically need to access. This will ensure that the remote VPN 623 clients can always access those critical servers regardless of 624 the private address space used at the remote attachment point. 626 2. We suggest that there be two IP address pools on the VPN 627 server, (or) two VPN servers with different address pools so 628 the address pool which is used for a VPN client doesn't 629 ever conflict with the physical Network interface IP address. 630 For example, the VPN server might detect a conflict and inform 631 the user that he/she should try to connect to the "other" VPN 632 server or IP address pool. Ideally, the VPN client and server 633 could cooperate to perform this negotiation automatically. 635 3. The subnet mask used on the hotels be as small as possible (say, 636 /29) and the hotels have a centralized DHCP-server that covers 637 multiple small subnets. By doing this, the likelihood of 638 conflict with corporate services is minimized. 640 Perhaps, if the VPN server identified the overlap of the remote 641 IP network and notified the VPN-client of the loss of 642 connectivity to that portion of the corporate world, the 643 VPN-client could do something about it - such as talk to the 644 local admin about assigning himself an IP address from a 645 different subnet (say, plugging to a different plug point) if 646 the hotel has such a facility. 648 4. Finally, the VPN-client could come in as bump in the stack and 649 redirect all relevant packets in the subnet (with the exception 650 of those that match with the router and DHCP server) over the 651 VPN. This at least reduces the size of the "black hole" on the 652 corporate network from a whole subnet to merely the specific 653 services running on the DHCP server and the next-hop router. 655 4. Security Considerations 657 Sections 2.2.1 and 3.2 specify the potential security violations 658 that can arise when there are IP address conflicts from topological 659 deployments. Sections 2.3 and 3.3 recommend ways to protect the 660 users from these security violations. 662 5. Informational References 664 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and 665 Lear, E., "Address Allocation for Private Internets", BCP 5, 666 RFC 1918, February 1996. 668 [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. 669 http://www.alumni.caltech.edu/~dank/peer-nat.html 671 [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications 672 with the IP Network Address Translator", RFC 3027, 673 January 2001. 675 [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address 676 Translation - Protocol Translation (NAT-PT)", RFC 2766, 677 February 2000. 679 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address 680 Translator (NAT) Terminology and Considerations", RFC 681 2663, August 1999. 683 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network 684 Address Translator (Traditional NAT)", RFC 3022, 685 January 2001. 687 Authors' Addresses: 689 Pyda Srisuresh 690 Consultant 691 20072 Pacifica Dr. 692 Cupertino, CA 95014 693 U.S.A. 694 Phone: (408) 836-4773 695 E-mail: srisuresh@yahoo.com 697 Bryan Ford 698 Computer Science and Artificial Intelligence Laboratory 699 Massachusetts Institute of Technology 700 77 Massachusetts Ave. 701 Cambridge, MA 02139 702 U.S.A. 703 Phone: (617) 253-5261 704 E-mail: baford@mit.edu 705 Web: http://www.brynosaurus.com/ 707 Full Copyright Statement 709 Copyright (C) The Internet Society (2006). 711 This document is subject to the rights, licenses and restrictions 712 contained in BCP 78, and except as set forth therein, the authors 713 retain all their rights. 715 This document and the information contained herein are provided on 716 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 717 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 718 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 719 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 720 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 721 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 722 PARTICULAR PURPOSE.