idnits 2.17.1 draft-ford-behave-top-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 26 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2009) is 5365 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended Status: Informational P. Srisuresh 3 Internet Draft: draft-ford-behave-top-07.txt Kazeon Systems 4 Expires: February 12, 2010 B. Ford 5 MPI-SWS 6 August 12, 2009 8 Unintended Consequence of two NAT deployments with 9 Overlapping Address Space 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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/ietf/1id-abstracts.txt. 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 two deployment scenarios that have arisen 35 from the unconventional network topologies formed using Network 36 Address Translator devices (NATs). First, the simplicity of 37 administering networks through the combination of NAT and DHCP has 38 increasingly lead to the deployment of multi-level inter-connected 39 private networks involving overlapping private IP address spaces. 40 Second, the proliferation of private networks in enterprises, hotels 41 and conferences, and the wide spread use of Virtual Private Networks 42 (VPNs) to access enterprise intranet from remote locations has 43 increasingly lead to overlapping private IP address space between 44 remote and corporate networks. The document does not dismiss these 45 unconventional scenarios as invalid, but recognizes them as real and 46 offers recommendations to help ensure these deployments can 47 function without a meltdown. 49 Table of Contents 51 1. Introduction and Scope....................................... 52 2. Terminology and Conventions Used ............................ 53 3. Multi-Level NAT Network Topologies .......................... 54 3.1 Operational Details of the Multi-Level NAT Network ...... 55 3.1.1. Client/Server Communication ....................... 56 3.1.2. Peer-to-Peer Communication ........................ 57 3.2. Anomalies of the Multi-Level NAT Network ............... 58 3.2.1. Plug-and-Play NAT Devices ......................... 59 3.2.2. Unconventional Addressing on NAT Devices .......... 60 3.2.3. Multi-Level NAT Translations ...................... 61 3.2.4. Mistaken End Host Identity ........................ 62 4. Remote Access VPN Network Topologies ........................ 63 4.1. Operational Details of the Remote Access VPN Network ... 64 4.2. Anomalies of the Remote Access VPN Network ............. 65 4.2.1. Remote Router and DHCP Server Address Conflict ... 66 4.2.2. Simultaneous Connectivity Conflict ............... 67 4.2.3. VIP Address Conflict ............................. 68 4.2.4. Mistaken End Host Identity ....................... 69 5. Summary of Recommendations .................................. 70 6. IANA Considerations ......................................... 71 7. Security Considerations ..................................... 72 8. Acknowledgements ............................................ 73 9. Normative References ........................................ 74 10. 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 ([DHCP]), and the NAT device in turn acts as both a DHCP 113 server and default router for any "downstream" hosts (and even 114 other NATs) that the user plugs into it. Consumer NATs in this way 115 effectively create and manage private home networks automatically 116 without requiring any knowledge of network protocols or management 117 on the part of the user. Auto-configuration of private hosts makes 118 NAT devices a compelling solution in this common scenario. 120 [NAT-PROT] identifies various complications with application 121 protocols due to NAT devices. This document acts as an adjunct to 122 [NAT-PROT]. The scope of the document is restricted to the two 123 scenarios identified in sections 3 and 4, as arising out of 124 unconventional NAT deployment and private address space overlap. 125 Even though the scenarios appear unconventional, they are not 126 uncommon to find. For each scenario, the document describes the 127 seeming anomalies and offers recommendations on how best to make 128 the topologies work. 130 Section 2 describes the terminology and conventions used in the 131 document. Section 3 describes the problem of private address space 132 overlap in a multi-level NAT topology, the anomalies with the 133 topology, and recommendations to address the anomalies. Section 4 134 describes the problem of private address space overlap with remote 135 access Virtual Private Network (VPN) connection, the anomalies with 136 the topology, and recommendations to address the anomalies. 137 Section 5 describes the security considerations in these scenarios. 139 2. Terminology and Conventions Used 141 In this document, the IP addresses 192.0.2.1, 192.0.2.64, 142 192.0.2.128, and 192.0.2.254 are used as example public IP addresses 143 [RFC3330]. Although these addresses are all from the same /24 144 network, this is a limitation of the example addresses available in 145 [RFC3330]. In practice, these addresses would be on different 146 networks. 148 Readers are urged to refer to [NAT-TERM] for information on NAT 149 taxonomy and terminology. Unless prefixed with a NAT type or 150 explicitly stated otherwise, the term NAT, used throughout this 151 document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has 152 two variations, namely, Basic NAT and Network Address Port Translator 153 (NAPT). Of these, NAPT is by far the most commonly deployed NAT 154 device. NAPT allows multiple private hosts to share a single public 155 IP address simultaneously. 157 3. Multi-Level NAT Network Topologies 159 Due to the pragmatic considerations discussed in the previous 160 section and perhaps others, NATs are increasingly, and often 161 unintentionally, used to create hierarchically interconnected 162 clusters of private networks as illustrated in figure 1 below. The 163 creation of multi-level hierarchies is often unintentional, since 164 each level of NAT is typically deployed by a separate 165 administrative entity such as an ISP, a corporation, or a home user. 167 Public Internet 168 (Public IP addresses) 169 ----+---------------+---------------+---------------+---- 170 | | | | 171 | | | | 172 192.0.2.1 192.0.2.64 192.0.2.128 192.0.2.254 173 +-------+ Host A Host B +-------------+ 174 | NAT-1 | (Alice) (Jim) | NAT-2 | 175 | (Bob) | | (CheapoISP) | 176 +-------+ +-------------+ 177 10.1.1.1 10.1.1.1 178 | | 179 | | 180 Private Network 1 Private Network 2 181 (private IP addresses) (private IP addresses) 182 ----+--------+---- ----+-----------------------+---- 183 | | | | | 184 | | | | | 185 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 186 Host C Host D +-------+ Host E +-------+ 187 | NAT-3 | (Mary) | NAT-4 | 188 | (Ann) | | (Lex) | 189 +-------+ +-------+ 190 10.1.1.1 10.1.1.1 191 | | 192 | | 193 Private Network 3 | Private Network 4 194 (private IP addresses)| (private IP addresses) 195 ----+-----------+---+ ----+-----------+---- 196 | | | | 197 | | | | 198 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 199 Host F Host G Host H Host I 201 Figure 1. Multi-level NAT topology with Overlapping Address Space 203 In the above scenario, Bob, Alice, Jim, and CheapoISP have each 204 obtained a "genuine", globally routable IP address from an upstream 205 service provider. Alice and Jim have chosen to attach only a single 206 machine at each of these public IP addresses, preserving the 207 originally intended architecture of the Internet and making their 208 hosts, A and B, globally addressable throughout the Internet. Bob, 209 in contrast, has purchased and attached a typical consumer NAT box. 210 Bob's NAT obtains its external IP address (192.0.2.1) from Bob's ISP 211 via DHCP, and automatically creates a private 10.1.1.x network for 212 Bob's hosts C and D, acting as the DHCP server and default router for 213 this private network. Bob probably does not even know anything about 214 IP addresses; he merely knows that plugging the NAT into the Internet 215 as instructed by the ISP, and then plugging his hosts into the NAT as 216 the NAT's manual indicates, seems to work and gives all of his hosts 217 access to Internet. 219 CheapoISP, an inexpensive service provider, has allocated only one or 220 a few globally routable IP addresses, and uses NAT to share these 221 public IP addresses among its many customers. Such an arrangement is 222 becoming increasingly common, especially in rapidly-developing 223 countries where the exploding number of Internet-attached hosts 224 greatly outstrips the ability of ISPs to obtain globally unique IP 225 addresses for them. CheapoISP has chosen the popular 10.1.1.x 226 address for its private network, since this is one of the three 227 well-known private IP address blocks allocated in [RFC1918] 228 specifically for this purpose. 230 Of the three incentives listed in section 1 for NAT deployment, the 231 last two still apply even to customers of ISPs that use NAT, 232 resulting in multi-level NAT topologies as illustrated in the right 233 side of the above diagram. Even three-level NAT topologies are known 234 to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained 235 a single IP address on CheapoISP's network (Private Network 2), via 236 DHCP. Mary attaches only a single host at this point, but 237 Ann and Lex each independently purchase and deploy consumer NATs in 238 the same way that Bob did above. As it turns out, these consumer 239 NATs also happen to use 10.1.1.x addresses for the private networks 240 they create, since these are the configuration defaults hard-coded 241 into the NATs by their vendors. Ann and Lex probably know nothing 242 about IP addresses, and in particular they are probably unaware that 243 the IP address spaces of their own private networks overlap not only 244 with each other but also with the private IP address space used by 245 their immediately upstream network. 247 Nevertheless, despite this direct overlap, all of the "multi-level 248 NATed hosts" - F, G, H, and I in this case - all nominally function 249 and are able to initiate connections to any public server on the 250 public Internet that has a globally routable IP address. Connections 251 made from these hosts to the main Internet are merely translated 252 twice. Once by the consumer NAT (NAT-3 or NAT-44) into the IP 253 address space of CheapoISP's Private Network 2, and then again by 254 CheapoISP's NAT-2 into the public Internet's global IP address 255 space. 257 3.1. Operational Details of the Multi-Level NAT Network 259 In the "de facto" Internet address architecture that has resulted 260 from the above pragmatic and economic incentives, only the nodes on 261 the public Internet have globally unique IP addresses assigned by 262 the official IP address registries. IP addresses on different 263 private networks are typically managed independently - either 264 manually by the administrator of the private network itself, or 265 automatically by the NAT through which the private network is 266 connected to its "upstream" service provider. 268 By convention, nodes on private networks are usually assigned IP 269 addresses in one of the private address space ranges specifically 270 allocated to this purpose in RFC 1918, ensuring that private IP 271 addresses are easily distinguishable and do not conflict with the 272 public IP addresses officially assigned to globally routable Internet 273 hosts. However, when "plug-and-play" NATs are used to create 274 hierarchically interconnected clusters of private networks, a given 275 private IP address can be and often is reused across many different 276 private networks. In figure 1 above, for example, private networks 277 1, 2, 3, and 4 all have a node with IP address 10.1.1.10. 279 3.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 public 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 192.0.2.64, NAT-1 modifies the packets comprising the 291 session so as to appear on the public 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 outgoing packet 294 so the packet appears on private network 2 as if it had originated 295 from NAT-3 at IP address 10.1.1.10. When the modified packet 296 traverses NAT-2 on private network 2, NAT-2 further modifies the 297 outgoing packet so as to appear on the public Internet as if it had 298 originated from NAT-2 at public IP address 192.0.2.254. The NATs in 299 effect serve as proxies that give their private "downstream" client 300 nodes a temporary presence on "upstream" networks to support 301 individual communication sessions. 303 In summary, all hosts on the private networks 1, 2, 3, and 4 in 304 figure 1 above are able to establish a client/server-style 305 communication sessions with servers on the public Internet. 307 3.1.2. Peer-to-Peer Communication 309 While this network organization functions in practice for 310 client/server-style communication, when the client is behind one or 311 more levels of NAT and the server is on the public Internet, the lack 312 of globally routable addresses for hosts on private networks makes 313 direct peer-to-peer communication between those hosts difficult. For 314 example, two private hosts F and H on the network shown above might 315 "meet" and learn of each other through a well-known server on the 316 public Internet, such as Host A, and desire to establish direct 317 communication between G and H without requiring A to forward each 318 packet. If G and H merely learn each other's (private) IP addresses 319 from a registry kept by A, their attempts to connect to each other 320 will fail because G and H reside on different private networks. 321 Worse, if their connection attempts are not properly authenticated, 322 they may appear to succeed but end up talking to the wrong host. For 323 example, G may end up talking to Host F, the host on private 324 network 3 that happens to have the same private IP address as Host H. 325 Host H might similarly end up unintentionally connecting to Host I. 327 In summary, peer-to-peer communication between hosts on disjoint 328 private networks 1, 2, 3, and 4 in figure 1 above is a challenge 329 without the assistance of a well known server on the public 330 Internet. However, with assistance from a node in the public 331 Internet, all hosts on the private networks 1, 2, 3, and 4 in 332 figure 1 above are able to establish a peer-to-peer style 333 communication sessions amongst themselves as well as with hosts 334 on the public Internet. 336 3.2. Anomalies of the Multi-Level NAT Network 338 Even though conventional wisdom would suggest that the network 339 described above is seriously broken, in practice it still works in 340 many ways. We break up figure 1 into two sub figures to better 341 illustrate the anomalies. Figure 1.1 is the left half of figure 1 342 and reflects the conventional single NAT deployment that is widely 343 prevalent in many last-mile locations. The deployment in figure 1.1 344 is popularly viewed as a pragmatic solution to work around the 345 depletion of IPv4 address space and is not considered broken. 346 Figure 1.2 is the right half of figure-1 and is representative of 347 the anomalies we are about to discuss. 349 Public Internet 350 (Public IP addresses) 351 ----+---------------+---------------+----------- 352 | | | 353 | | | 354 192.0.2.1 192.0.2.64 192.0.2.128 355 +-------+ Host A Host B 356 | NAT-1 | (Alice) (Jim) 357 | (Bob) | 358 +-------+ 359 10.1.1.1 360 | 361 | 362 Private Network 1 363 (private IP addresses) 364 ----+--------+---- 365 | | 366 | | 367 10.1.1.10 10.1.1.11 368 Host C Host D 370 Figure 1.1. Conventional Single-level NAT Network topology 371 Public Internet 372 (Public IP addresses) 373 ---+---------------+---------------+---- 374 | | | 375 | | | 376 192.0.2.64 192.0.2.128 192.0.2.254 377 Host A Host B +-------------+ 378 (Alice) (Jim) | NAT-2 | 379 | (CheapoISP) | 380 +-------------+ 381 10.1.1.1 382 | 383 | 384 Private Network 2 385 (private IP addresses) 386 ----+---------------+-------------+--+------- 387 | | | 388 | | | 389 10.1.1.10 10.1.1.11 10.1.1.12 390 +-------+ Host E +-------+ 391 | NAT-3 | (Mary) | NAT-4 | 392 | (Ann) | | (Lex) | 393 +-------+ +-------+ 394 10.1.1.1 10.1.1.1 395 | | 396 | | 397 Private Network 3 Private Network 4 398 (private IP addresses) (private IP addresses) 399 ----+-----------+------ ----+-----------+---- 400 | | | | 401 | | | | 402 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 403 Host F Host G Host H Host I 405 Figure 1.2. Unconventional Multi-level NAT Network topology 407 3.2.1. Plug-and-Play NAT Devices 409 Consumer NAT devices are predominantly "plug-and-play" NAT devices, 410 and assume minimal user intervention during device setup. The 411 "plug-and-play" NAT devices provide DHCP service on one interface 412 and NAT function on another interface. Vendors of the consumer NAT 413 devices make assumptions about how their consumers configure and 414 hook up their PCs to the device. When consumers do not adhere to the 415 vendor assumptions, the consumers can end up with a broken network. 417 A "plug-and-play" NAT device provides DHCP service on the LAN 418 attached to the private interface, and assumes that all private 419 hosts at the consumer site have DHCP client enabled and are 420 connected to the single LAN. Consumers need to be aware that all 421 private hosts must be on a single LAN, with no router in between. 423 A "Plug-and-Play" NAT device also assumes that there is no other 424 NAT device or DHCP server device on the same LAN at the customer 425 premises. When there are multiple "Plug-and-play" NAT devices on 426 the same LAN, each NAT device will offer DHCP service on the same 427 LAN, and may even be from the same private address pool. This could 428 result in multiple end nodes on the same LAN ending up with identical 429 IP addresses and breaking network connectivity. 431 As it turns out, most consumer deployments have a single LAN where 432 there they deploy a "plug-and-play" NAT device and the concerns 433 raised above have not been an issue in reality. 435 3.2.2. Unconventional Addressing on NAT Devices 437 Let us consider the unconventional addressing with NAT-3 and 438 NAT-4. NAT-3 and NAT-4 are apparently multi-homed on the same 439 subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 440 through its external interface facing NAT-2, as well as through its 441 private interface facing clients Host-F and Host-G. Likewise, NAT-4 442 also has two interfaces on the same subnet 10.1.1/24. 444 In a traditional network, when a node has multiple interfaces with 445 IP addresses on the same subnet, it is natural to assume that all 446 interfaces with addresses on the same subnet must be on a single 447 connected LAN (bridged LAN or a single physical LAN). Clearly, that 448 is not the case here. Even though both NAT-3 and NAT-4 have two 449 interfaces on the same subnet 10.1.1/24, the NAT devices view the 450 two interfaces as being on two disjoint subnets and routing realms. 451 The "plug-and-play" NAT devices are really not multi-homed on the 452 same subnet as in a traditional sense. 454 In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should 455 be incapable of communicating reliably as a transport endpoint with 456 other nodes on their adjacent networks (ex: private networks 2 and 457 3 in the case of NAT-3 and private Networks 2 and 4 in the case of 458 NAT-4). This is because applications on either of the NAT devices 459 cannot know to differentiate packets from hosts on either of the 460 subnets bearing the same IP address. If NAT-3 attempts to resolve 461 the IP address of a neighboring host in the conventional manner by 462 broadcasting an ARP request on all of its physical interfaces 463 bearing the same subnet, it may get a different response on each 464 of its physical interfaces. 466 Even though both NAT-3 and NAT-4 have hosts bearing the same IP 467 address on the adjacent networks, the NAT devices do communicate 468 effectively as end points. Many of the "plug-and-play" NAT devices 469 offer a limited number of services on them. For example, many of 470 the NAT devices respond to pings from hosts on either of the 471 interfaces. Even though a NAT device is often not actively 472 managed, many of the NAT devices are equipped to be managed from 473 the private interface. This unconventional communication with 474 NAT devices is achievable because many of the NAT devices conform to 475 REQ-7 of [BEH-UDP] and view the two interfaces as being on two 476 disjoint routing domains and distinguish between sessions initiated 477 from hosts on either interface (private or public). 479 3.2.3. Multi-Level NAT Translations 481 Use of a single NAT to connect private hosts to the public Internet 482 as in figure 1.1 is a fairly common practice. Many consumer NATs are 483 deployed this way. However, use of multi-level NAT translations as 484 in figure 1.2 is not a common practice and is not well understood. 486 Let us consider the conventional single NAT translation in 487 figure 1.1. Because the public and private IP address ranges are 488 numerically disjoint, nodes on private networks can make use of both 489 public and private IP addresses when initiating network 490 communication sessions. Nodes on a private network can use private 491 IP addresses to refer to other nodes on the same private network, 492 and public IP addresses to refer to nodes on the public Internet. 493 For example, host C in figure 1.1 is on private network 1 and can 494 directly address hosts A, B and D using their assigned IP addresses. 495 This is in spite of the fact that hosts A and B are on the public 496 Internet and host D alone is on the private network. 498 Next, let us consider the unconventional multi-level NAT topology in 499 figure 1.2. In this scenario, private hosts are able to connect to 500 hosts on the public Internet. But, private hosts are not able to 501 connect with all other private hosts. For example, host F in 502 figure 1.2 can directly address hosts A, B, and G using their 503 assigned IP addresses, but F has no way to address any of the 504 other hosts in the diagram. Host F in particular cannot address 505 host E by its assigned IP address, even though host E is located on 506 the immediately "upstream" private network through which F is 507 connected to the Internet. Host E has the same IP address as 508 host G. Yet, this addressing is "legitimate" in the NAT world 509 because the two hosts are on different private networks. 511 It would seem that the topology in figure 1.2 with multiple 512 NAT translations is broken because private hosts are not able to 513 address each other directly. However, the network is not broken. 514 Nodes on any private network have no direct method of addressing 515 nodes on other private networks. The private networks 1, 2, 3 and 4 516 are all disjoint. Hosts on private network 1 are unable to directly 517 address nodes on private networks 2, 3 or 4 and vice versa. Multiple 518 NAT translations was not the cause of this. 520 As described in sections 3.1.1 and 3.1.2, client-server and 521 peer-to-peer communication can and should be possible even with 522 multi-level NAT topology deployment. A host on any private network 523 must be able to communicate with any other host, no matter which 524 private network the host is attached to or where the private network 525 is located. Host F should be able to communicate with host E and 526 carry out both client-server communication and peer-to-peer 527 communication, and vice versa. Host F and host E form a hairpin 528 session through NAT-2 to communicate with each other. Each host 529 uses the public endpoint assigned by the Internet facing NAT (NAT-2) 530 to address its peer. 532 When the NAT devices deployed conform to the hairpin translation 533 requirements in [BEH-UDP], [BEH-TCP] and [BEH-ICMP], peer nodes are 534 able to connect even in this type of multi-level NAT topologies. 536 3.2.4. Mistaken End Host Identity 538 Mistaken end host identity can result in accidental malfunction in 539 some cases of multi-level NAT deployments. Consider the scenario in 540 figure 1.3. Figure 1.3 depicts 2 levels of NATs between an end-user 541 in private network-3 and the public Internet. 543 Suppose CheapoISP assigns 10.1.1.11 to its DNS resolver, which it 544 advertises through DHCP to NAT-3, the gateway for Ann's home. 545 NAT-3 in turn advertises 10.1.1.11 as the DNS resolver to 546 host F (10.1.1.10) and host G (10.1.1.11) on private network 3. 547 However, when host F sends a DNS query to 10.1.1.11, it will be 548 delivered locally to host G on private network 3 rather than 549 CheapoISP's DNS resolver. This is clearly a case of mistaken 550 identity due to CheapoISP advertising a server that could 551 potentially overlap with its customers' IP addresses. 553 Public Internet 554 (Public IP addresses) 555 ---+---------------+---------------+---- 556 | | | 557 | | | 558 192.0.2.64 192.0.2.128 192.0.2.254 559 Host A Host B +-------------+ 560 (Alice) (Jim) | NAT-2 | 561 | (CheapoISP) | 562 +-------------+ 563 10.1.1.1 564 | 565 | 566 Private Network 2 567 (private IP addresses) 568 ------------+------------------+-------+---------- 569 | | 570 10.1.1.10 | 571 +-------+ 10.1.1.11 572 | NAT-3 | Host E 573 | (Ann) | (DNS resolver) 574 +-------+ 575 10.1.1.1 576 | Private Network 3 577 | (private IP addresses) 578 ----+---+-----------+---------------- 579 | | 580 | | 581 10.1.1.10 10.1.1.11 582 Host F Host G 584 Figure 1.3. Mistaken server identity in Multi-level NAT topology 586 Recommendation-1: ISPs, using NAT devices to provide connectivity 587 to customers, should assign non-overlapping addresses to servers 588 advertised to customers. One way to do this would be to assign 589 global addresses to advertised servers. 591 4. Remote Access VPN Network Topologies 593 Enterprises use remote access VPN to allow secure access to the 594 employees working outside the enterprise premises. While outside 595 the enterprise premises, an employee may be located in his/her 596 home office, hotel, conference or a partner's office. In all cases, 597 it is desirable for the employee at the remote site to have 598 unhindered access to his/her corporate network and the applications 599 running on the corporate network. While doing so, the employee 600 should not jeopardize the integrity and confidentiality of the 601 corporate network and the applications running on the network. 603 IPsec, L2TP and SSL are some of the well known secure VPN 604 technologies used by the remote access vendors. Besides 605 authenticating employees for granting access, remote access VPN 606 servers often enforce different forms of security (e.g. IPsec, SSL) 607 to protect the integrity and confidentiality of the run-time 608 traffic between the VPN client and the VPN server. 610 Many enterprises deploy their internal networks using RFC-1918 611 private address space and use NAT devices to connect to the public 612 Internet. Further, many of the applications in the corporate network 613 refer to information (such as URLs) and services using private 614 addresses in the corporate network. Applications such as NFS rely on 615 simple source IP address based filtering to restrict access to 616 corporate users. These are some reasons why the remote access VPN 617 servers are configured with a block of IP addresses from the 618 corporate private network to assign to remote access clients. VPN 619 clients use the virtual IP (VIP) address assigned to them (by the 620 corporate VPN server) to access applications inside the corporate. 622 Consider the remote access VPN scenario in figure 2 below. 624 (Corporate Private network 10.0.0.0/8) 625 ---------------+---------------------- 626 | 627 10.1.1.10 628 +---------+-------+ 629 | Enterprise Site | 630 | Remote Access | 631 | VPN Server | 632 +--------+--------+ 633 192.0.2.1 634 | 635 {---------+------} 636 { } 637 { } 638 { Public Internet } 639 { (Public IP addresses) } 640 { } 641 { } 642 {---------+------} 643 | 644 192.0.2.254 645 +--------+--------+ 646 | Remote Site | 647 | "Plug-and-Play" | 648 | NAT router | 649 +--------+--------+ 650 10.1.1.1 651 | 652 Remote Site Private Network | 653 -----+-----------+-----------+-------------+----------- 654 | | | | 655 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 656 Host A Host B +--------+ Host C 657 | VPN | 658 | Client | 659 | on a PC| 660 +--------+ 662 Figure 2. Remote Access VPN with Overlapping Address Space 664 In the above scenario, say an employee of the corporate is at a 665 remote location and attempts to access the corporate network using 666 the VPN client. The corporate network is laid out using RFC-1918 667 address pool of 10.0.0.0/8 and say the VPN server is configured with 668 an address block of 10.1.1.0/24 to assign virtual IP addresses to 669 remote access VPN clients. Now, say the employee at the remote site 670 is attached to a network on the remote site which also happens to be 671 using a RFC-1918 address space based network and coincidentally 672 overlaps the corporate network. In this scenario, it is 673 conventionally problematic for the VPN client to connect to the 674 server(s) and other hosts at the enterprise. 676 Nevertheless, despite the direct address overlap, the remote access 677 VPN connection between the VPN client at the remote site and the 678 VPN server at the enterprise should remain connected and should be 679 made to work. I.e., the NAT device at the remote site should not 680 obstruct the VPN connection traversing it. And, the remote user 681 should be able to connect to any host at the enterprise through the 682 VPN from the remote desktop. 684 The following subsections describe the operational details of the 685 VPN, anomalies with the address overlap and recommendations on 686 how best to address the situation. 688 4.1. Operational Details of Remote Access VPN Network 690 As mentioned earlier, in the "de facto" Internet address 691 architecture, only the nodes on the public Internet have globally 692 unique IP addresses assigned by the official IP address registries. 693 Many of the networks in the edges use private IP addresses from 694 RFC 1918 and use NAT devices to connect their private networks 695 to the public Internet. Many enterprises adapted the approach of 696 using private IP addresses internally. Employees within the 697 enterprise's Intranet private network are "trusted" and may connect 698 to any of the internal hosts with minimal administrative or policy 699 enforcement overhead. When an employee leaves the enterprise 700 premises, remote access VPN provides the same level of intranet 701 connectivity to the remote user. 703 The objective of this section is to provide an overview of the 704 operational details of a remote access VPN application so the reader 705 has an appreciation for the problem of remote address space overlap. 706 This is not a tutorial or specification of remote access VPN 707 products, per se. 709 When an employee at a remote site launches his/her remote access VPN 710 client, the VPN server at the corporate premises demands the VPN 711 client to authenticate itself. When the authentication succeeds, 712 the VPN server assigns a Virtual IP (VIP) address to the client for 713 connecting with the corporate Intranet. From this point onwards, 714 while the VPN is active, outgoing IP packets directed to the hosts 715 in the corporate Intranet are tunneled through the VPN, in that the 716 the VPN server serves as the next-hop and the VPN connection as the 717 next-hop link for these packets. Within the corporate Intranet, the 718 outbound IP packets appear as arriving from the VIP address. so, 719 IP packets from the corporate hosts to the remote user are sent to 720 the remote user's VIP address and the IP packets are tunneled 721 inbound to the remote user's PC through the VPN tunnel. 723 This works well so long as the subnets in the corporate network 724 do not conflict with subnets at the remote site where the remote 725 user's PC is located. However, when the corporate network is built 726 using RFC 1918 private address space and the remote location where 727 the VPN client is launched is also using an overlapping network from 728 RFC 1918 address space, there can be addressing conflicts. The 729 remote user's PC will have a conflict in accessing nodes on the 730 corporate site and nodes at the remote site bearing the same IP 731 address simultaneously. Consequently, the VPN client may be unable 732 to have full access to the employee's corporate network and the 733 local network at the remote site simultaneously. 735 In spite of address overlap, remote access VPN clients should be 736 able to successfully establish connections with Intranet hosts in 737 the enterprise. 739 4.2. Anomalies of the Remote Access VPN network 741 Even though conventional wisdom would suggest that the remote access 742 VPN scenario with overlapping address space would be seriously 743 broken, in practice it still works in many ways. Let us look at some 744 anomalies where there might be a problem and identify solutions 745 through which the remote access VPN application could be made to 746 work even under the problem situations. 748 4.2.1. Remote Router and DHCP Server Address Conflict 750 Routing and DHCP service are bootstrap services essential for a 751 remote host to establish a VPN connection. Without DHCP lease, the 752 remote host can not communicate over the IP network. Without a 753 router to connect to the Internet, the remote host is unable to 754 access past the local subnet to connect to the VPN server at the 755 enterprise. It is essential that neither of these bootstrap services 756 be tampered at the remote host in order for the VPN connection to 757 stay operational. Typically, a "Plug-and-play" NAT device at the 758 remote site provides both routing and DHCP services from the same 759 IP address. 761 When there is address overlap between hosts at corporate Intranet 762 and hosts at the remote site, the remote VPN user is often unaware 763 of the address conflict. Address overlap could potentially cause the 764 remote user to lose connectivity to the enterprise entirely or 765 lose connectivity to an arbitrary block of hosts at the enterprise. 767 Consider, for example, a scenario where the IP address of the DHCP 768 server at the remote site matched the IP address of a host at 769 the enterprise network. When the remote user's PC is ready to 770 renew the lease of the locally assigned IP address, the remote 771 user's VPN client would incorrectly identify the IP packet 772 as being addressed to an enterprise host and tunnel the DHCP 773 renewal packet over the VPN to the remote VPN server. The DHCP 774 renewal requests simply do not reach the DHCP server at the 775 remote site. As a result, the remote PC would eventually lose the 776 lease on the IP address and the VPN connection to the enterprise 777 would be broken. 779 Consider another scenario where the IP address of the remote user's 780 router overlapped with the IP address of a host in the enterprise 781 network. If the remote user's PC were to send ping or some type of 782 periodic keep-alive packets to the router (say, to test the liveness 783 of the router), the packets are intercepted by the VPN client and 784 simply redirected to the VPN tunnel. This type of unintended 785 redirection has the twin effect of hijacking critical packets 786 addressed to the router as well as the host in the enterprise 787 network (bearing the same IP address as the remote router) being 788 bombarded with unintended keep-alive packets. Loss of connectivity 789 to the router can result in the VPN connection being broken. 791 Clearly, it is not desirable to route traffic directed to the local 792 router or DHCP server to be redirected to the corporate intranet. 793 VPN client on remote PC should be configured such that IP packets 794 whose target IP address match the following are disallowed to be 795 redirected over the VPN. 796 a) client's next-hop router IP address used to access the VPN 797 server, 798 b) DHCP server providing address lease on the remote host network 799 interface. 801 Recommendation-2: VPN client on remote PC should be configured such 802 that IP packets whose target IP address match the following are 803 disallowed to be redirected over the VPN. 804 a) client's next-hop router IP address used to access the VPN 805 server, 806 b) DHCP server providing address lease on the remote host network 807 interface. 809 4.2.2. Simultaneous Connectivity Conflict 811 Ideally speaking, it is not desirable for the corporate intranet to 812 conflict with any of the hosts at the remote site. As a general 813 practice, if simultaneous communication with end hosts at the remote 814 location is important, it is advisable to disallow access to any 815 corporate network resource that overlaps the client's subnet at the 816 remote site. By doing this, the remote user is able to connect to 817 all local hosts simultaneously while the VPN connection is active. 819 Some VPN clients allow the remote PC to access the corporate network 820 over VPN and all other subnets directly without routing through the 821 VPN. Such a configuration is termed as "Split VPN" configuration. 822 "Split VPN" configuration allows the remote user to run applications 823 requiring communication with hosts at the remote site or the public 824 Internet, as well as hosts at the corporate intranet, unless there 825 is address overlap with the remote subnet. Applications needing 826 access to the hosts at the remote site or the public Internet do not 827 traverse the VPN, and hence are likely to have better performance 828 when compared to traversing the VPN. This can be quite valuable 829 for latency sensitive applications such as VoIP and interactive 830 gaming. If there is no overriding security concern to directly 831 accessing hosts at the remote site or the public Internet, the VPN 832 client on remote PC should be configured in "Split VPN" mode. 834 If simultaneous connectivity to hosts at remote site is not 835 important, the VPN client may be configured to direct all 836 communication traffic from the remote user to the VPN. Such a 837 configuration is termed as "Non-Split VPN" configuration. 838 "Non-Split VPN" configuration ensures that all communication from 839 the remote user's PC traverses the VPN link and routed through the 840 VPN server, with the exception of traffic directed to the router 841 and DHCP server at the remote site. No other communication takes 842 place with hosts at the remote site. Applications needing access 843 to the public Internet also traverse the VPN. If the goal is to 844 maximize the security and reliability of connectivity to the 845 corporate network, the VPN client on remote PC should be 846 configured in "Non-Split VPN" mode. "Non-Split VPN" configuration 847 will minimize the likelihood of access loss to corporate hosts. 849 Recommendation-3: VPN client on a remote-PC may be configured in 850 "Split VPN" or 'Non-Split VPN" mode as follows, depending on the 851 goal of VPN deployment. 852 a) If the goal is to maximize the security and reliability of 853 connectivity to the corporate network, the VPN client on remote 854 PC should be configured in "Non-split VPN" mode. "Non-Split VPN" 855 mode ensures that the VPN client directs all traffic from the 856 remote user to the VPN server (at corporate site), with the 857 exception of traffic directed to the router and DHCP server at 858 the remote site. 859 b) If there is no overriding security concern to directly 860 accessing hosts at the remote site or the public Internet, the 861 VPN client on remote PC should be configured in "Split VPN" 862 mode. "Split VPN" mode ensures that only the corporate traffic 863 is directed over the VPN. All other traffic does not have the 864 overhead of traversing the VPN. 866 4.2.3. VIP Address Conflict 868 When the VIP address assigned to the VPN client at remote site is 869 in direct conflict with the IP address of the existing network 870 interface, the VPN client might be unable to establish the VPN 871 connection. 873 Consider a scenario where the VIP address assigned by the 874 VPN server directly matched the IP address of the networking 875 interface at the remote site. When the VPN client on the remote 876 host attempts to set the VIP address on a virtual adapter (specific 877 to the remote access application), the VIP address configuration 878 will simply fail due to conflict with the IP address of the existing 879 network interface. The configuration failure in turn can result in 880 the remote access VPN tunnel not being established. 882 Clearly, it is not advisable to have the VIP address overlap 883 the IP address of the remote user's existing network interface. As a 884 general rule, it is not advisable for the VIP address to overlap 885 any IP address in the remote user's local subnet, as the VPN client 886 on the remote PC might be forced to respond to ARP requests on the 887 remote site and the VPN client might not process the handling of ARP 888 requests gracefully. 890 Some VPN vendors offer provision to detect conflict of VIP address 891 with remote site address space and switch between two or more address 892 pools with different subnets so the VIP address assigned is not in 893 conflict with the address space at remote site. Enterprises deploying 894 VPNs that support this type of vendor provisioning are advised to 895 configure the VPN server with a minimum of two distinct IP address 896 pools. However, this is not 897 universally the case. 899 Alternately, enterprises may deploy two or more VPN servers with 900 different address pools. By doing so, a VPN client that detects 901 conflict of VIP address with the subnet at remote site will have 902 the ability able to switch to an alternate VPN server that will not 903 conflict. 905 Recommendation-4: Enterprises deploying remote access VPN solution 906 are advised to adapt a strategy to avoid VIP address conflict with 907 the subnet at remote site. Below are two suggestions. 908 a) If the VPN server being deployed has provision to configure two 909 or more address pools, configure the VPN server with a minimum of 910 two distinct IP address pools. 911 b) Deploy two or more VPN servers with distinct IP address pools. 912 By doing so, a VPN client that detects conflict of VIP address with 913 the subnet at remote site will have the ability to switch to 914 alternate VPN server that will not conflict. 916 4.2.4. Mistaken End Host Identity 918 When "Split VPN" is configured on the VPN client on remote PC, 919 there can be a potential security threat due to mistaken identity. 920 Say, a certain service (ex: SMTP mail service) is configured on 921 exactly the same IP address on both the corporate site and the 922 remote site. The user could unknowingly be using the service on the 923 remote site, thereby violating the integrity and confidentiality of 924 the contents relating to that application. Potentially, remote 925 user mail messages could be hijacked by the ISP's mail server. 927 Enterprises deploying remote access VPN servers should allocate 928 global IP addresses for the critical servers the remote VPN clients 929 typically need to access. By doing this, even if most of the private 930 corporate network uses RFC 1918 address space, this will ensure that 931 the remote VPN clients can always access the critical servers 932 regardless of the private address space used at the remote 933 attachment point. This is akin to recommendation-1 provided in 934 conjunction with multi-level NAT deployments. 936 Recommendation-5: When "Split VPN" is configured on VPN client of 937 a remote PC, enterprises deploying remote access VPN servers are 938 advised to assign global IP addresses for the critical servers the 939 remote VPN clients are likely to access. 941 5. Summary of Recommendations 943 NAT vendors are advised to refer BEHAVE protocol documents 944 ([BEH-UDP], [BEH-TCP] and [BEH-ICMP]) for a comprehensive list of 945 conformance requirements for NAT devices. 947 The following is a summary of recommendations to support the 948 unconventional NAT topologies identified in this document. The 949 recommendations are deployment specific and addressed to the 950 personnel responsible for the deployments. These personnel 951 include ISP administrators and enterprise IT administrators. 953 Recommendation-1: ISPs, using NAT devices to provide connectivity 954 to customers, should assign non-overlapping addresses to servers 955 advertised to customers. One way to do this would be to assign 956 global addresses to advertised servers. 958 Recommendation-2: VPN client on remote PC should be configured such 959 that IP packets whose target IP address match the following are 960 disallowed to be redirected over the VPN. 961 a) client's next-hop router IP address used to access the VPN 962 server, 963 b) DHCP server providing address lease on the remote host network 964 interface. 966 Recommendation-3: VPN client on a remote-PC may be configured in 967 "Split VPN" or 'Non-Split VPN" mode as follows, depending on the 968 goal of VPN deployment. 969 a) If the goal is to maximize the security and reliability of 970 connectivity to the corporate network, the VPN client on remote 971 PC should be configured in "Non-split VPN" mode. "Non-Split VPN" 972 mode ensures that the VPN client directs all traffic from the 973 remote user to the VPN server (at corporate site), with the 974 exception of traffic directed to the router and DHCP server at 975 the remote site. 976 b) If there is no overriding security concern to directly 977 accessing hosts at the remote site or the public Internet, the 978 VPN client on remote PC should be configured in "Split VPN" 979 mode. "Split VPN" mode ensures that only the corporate traffic 980 is directed over the VPN. All other traffic does not have the 981 overhead of traversing the VPN. 983 Recommendation-4: Enterprises deploying remote access VPN solution 984 are advised to adapt a strategy to avoid VIP address conflict with 985 the subnet at remote site. Below are two suggestions. 986 a) If the VPN server being deployed has provision to configure two 987 or more address pools, configure the VPN server with a minimum of 988 two distinct IP address pools. 989 b) Deploy two or more VPN servers with distinct IP address pools. 990 By doing so, a VPN client that detects conflict of VIP address with 991 the subnet at remote site will have the ability to switch to 992 alternate VPN server that will not conflict. 994 Recommendation-5: When "Split VPN" is configured on VPN client of 995 a remote PC, enterprises deploying remote access VPN servers are 996 advised to assign global IP addresses for the critical servers the 997 remote VPN clients are likely to access. 999 6. IANA Considerations 1001 This document does not warrant any IANA considerations. 1003 7. Security Considerations 1005 This document does not inherently create new security issues. 1006 Security issues known to DHCP servers and NAT devices are 1007 applicable, but not within the scope of this document. Likewise, 1008 security issues specific to remote access VPN devices are also 1009 applicable to the remote access VPN topology, but not within the 1010 scope of this document. The security issues reviewed here only 1011 those relevant to the topologies described in sections 2 and 3, 1012 specifically as they apply to private address space overlap in 1013 the topologies described. 1015 Mistaken end host identity is a security concern present in both 1016 topologies discussed. Mistaken end host identity, described in 1017 sections 2.2.4 and 3.2.4 for each of the topologies reviewed, 1018 essentially points the possibility of application services being 1019 hijacked by the wrong application server (ex: Mail server). Security 1020 violation due to mistaken end host identity arises principally due 1021 to critical servers being assigned RFC 1918 private addresses. The 1022 recommendation suggested for both scenarios is to assign globally 1023 unique public IP addresses for the critical servers. 1025 It is also recommended in section 2.1.2 that applications adapt 1026 end-to-end authentication and not depend on source IP address for 1027 authentication. Doing this will thwart connection hijacking and 1028 denial of service attacks. 1030 8. Acknowledgements 1032 The authors wish to thank Dan Wing for reviewing the document in 1033 detail and making helpful suggestions in reorganizing the 1034 document format. The authors also wish to thank Ralph Droms for 1035 helping with rewording the text and recommendation-1 in section 1036 3.2.4 and Cullen Jennings for helping with rewording the text 1037 and recommendation-3 in section 4.2.2. 1039 9. Normative References 1041 [BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and Guha, S., 1042 "NAT Behavioral Requirements for ICMP Protocol", 1043 BCP 148, RFC 5508, January 2009. 1045 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 1046 Srisuresh, P., "NAT Behavioral Requirements for TCP", 1047 BCP 142, RFC 5382, October 2008. 1049 [BEH-UDP] Audet, F. and Jennings, C., "NAT Behavioral Requirements 1050 for Unicast UDP", BCP 127, RFC 4787, January 2007. 1052 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 1053 (NAT) Terminology and Considerations", RFC 2663, 1054 August 1999. 1056 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 1057 Translator (Traditional NAT)", RFC 3022, January 2001. 1059 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and 1060 Lear, E., "Address Allocation for Private Internets", BCP 5, 1061 RFC 1918, February 1996. 1063 10. Informational References 1065 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1066 March 1997. 1068 [NAT-PROT] Holdrege, M., and Srisuresh, P., "Protocol Complications 1069 with the IP Network Address Translator", RFC 3027, 1070 January 2001. 1072 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 1073 2002. 1075 Authors' Addresses: 1077 Pyda Srisuresh 1078 Kazeon Systems, Inc. 1079 1161 San Antonio Rd. 1080 Mountain View, CA 94043 1081 U.S.A. 1082 Phone: +1 408 836 4773 1083 EMail: srisuresh@yahoo.com 1084 Bryan Ford 1085 Max Planck Institute for Software Systems 1086 Campus Building E1 4 1087 D-66123 Saarbruecken 1088 Germany 1089 Phone: +49-681-9325657 1090 EMail: baford@mpi-sws.org 1092 Copyright Notice 1094 Copyright (c) 2009 IETF Trust and the persons identified as the 1095 document authors. All rights reserved. 1097 This document is subject to BCP 78 and the IETF Trust's Legal 1098 Provisions Relating to IETF Documents in effect on the date of 1099 publication of this document (http://trustee.ietf.org/license-info). 1100 Please review these documents carefully, as they describe your rights 1101 and restrictions with respect to this document.