idnits 2.17.1 draft-iab-nat-implications-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The 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 2000) is 8653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 430 looks like a reference -- Missing reference section? '3' on line 578 looks like a reference -- Missing reference section? '4' on line 132 looks like a reference -- Missing reference section? '5' on line 133 looks like a reference -- Missing reference section? '6' on line 166 looks like a reference -- Missing reference section? '7' on line 1054 looks like a reference -- Missing reference section? '8' on line 322 looks like a reference -- Missing reference section? '9' on line 453 looks like a reference -- Missing reference section? '10' on line 570 looks like a reference -- Missing reference section? '11' on line 570 looks like a reference -- Missing reference section? '12' on line 868 looks like a reference -- Missing reference section? 'RFC 1752' on line 1030 looks like a reference -- Missing reference section? '14' on line 1057 looks like a reference -- Missing reference section? '15' on line 1080 looks like a reference -- Missing reference section? '16' on line 1099 looks like a reference -- Missing reference section? '17' on line 1099 looks like a reference -- Missing reference section? '18' on line 1099 looks like a reference -- Missing reference section? '19' on line 1104 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IAB T. Hain 3 Internet Draft Microsoft 4 Document: draft-iab-nat-implications-09.txt August 2000 5 Category: Informational 7 Architectural Implications of NAT 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 "This memo provides information for the Internet community. This 28 memo does not specify an Internet standard of any kind. Distribution 29 of this memo is unlimited." 31 Abstract 33 In light of the growing interest in, and deployment of network 34 address translation (NAT) RFC-1631, this paper will discuss some of 35 the architectural implications and guidelines for implementations. 36 It is assumed the reader is familiar with the address translation 37 concepts presented in RFC-1631. 39 Hain Informational - Expires January 2001 1 40 Architectural Implications of NAT August 2000 42 Table of Contents 43 Abstract............................................................1 44 1. Introduction....................................................3 45 2. Terminology.....................................................5 46 3. Scope...........................................................7 47 4. End-to-End Model................................................7 48 5. Advantages of NATs..............................................9 49 6. Problems with NATs.............................................11 50 7. Illustrations..................................................13 51 7.1 Single point of failure.......................................13 52 7.2. ALG complexity..............................................14 53 7.3. TCP state violations.........................................15 54 7.4. Symmetric state management..................................16 55 7.5. Need for a globally unique FQDN when advertising public 56 services..........................................................17 57 7.6. L2TP tunnels increase frequency of address collisions.......18 58 7.7. Centralized data collection system report correlation.......19 59 8. IPv6...........................................................19 60 9. Security Considerations........................................21 61 10. Deployment Guidelines.........................................23 62 11. Summary.......................................................24 63 12. References....................................................25 64 13. Acknowledgments...............................................27 65 14. Author's Addresses............................................27 67 Hain Informational - Expires January 2001 2 68 Architectural Implications of NAT August 2000 70 1. Introduction 72 Published in May 1994, written by K. Egevang and P. Francis, RFC- 73 1631 [2] defined NAT as one means to ease the growth rate of IPv4 74 address use. But the authors were worried about the impact of this 75 technology. Several places in the document they pointed out the need 76 to experiment and see what applications may be adversely affected by 77 NAT's header manipulations, even before there was any significant 78 operational experience. This is further evidenced in a quote from 79 the conclusions: 'NAT has several negative characteristics that make 80 it inappropriate as a long term solution, and may make it 81 inappropriate even as a short term solution.' 83 Now, six years later and in spite of the prediction, the use of NATs 84 is becoming widespread in the Internet. Some people are proclaiming 85 NAT as both the short and long term solution to some of the 86 Internet's address availability issues and questioning the need to 87 continue the development of IPv6. The claim is sometimes made that 88 NAT 'just works' with no serious effects except on a few legacy 89 applications. At the same time others see a myriad of difficulties 90 caused by the increasing use of NAT. 92 The arguments pro & con frequently take on religious tones, with 93 each side passionate about its position. 94 - Proponents bring enthusiasm and frequently cite the most popular 95 applications of Mail & Web services as shining examples of NAT 96 transparency. They will also point out that NAT is the feature 97 that finally breaks the semantic overload of the IP address as 98 both a locator and the global endpoint identifier (EID). 99 - An opposing view of NAT is that of a malicious technology, a weed 100 which is destined to choke out continued Internet development. 101 While recognizing there are perceived address shortages, the 102 opponents of NAT view it as operationally inadequate at best, 103 bordering on a sham as an Internet access solution. 104 Reality lies somewhere in between these extreme viewpoints. 106 In any case it is clear NAT affects the transparency of end-to-end 107 connectivity for transports relying on consistency of the IP header, 108 and for protocols which carry that address information in places 109 other than the IP header. Using a patchwork of consistently 110 configured application specific gateways (ALG's), endpoints can work 111 around some of the operational challenges of NAT. These operational 112 challenges vary based on a number of factors including network and 113 application topologies and the specific applications in use. It can 114 be relatively easy to deal with the simplest case, with traffic 115 between two endpoints running over an intervening network with no 116 parallel redundant NAT devices. But things can quickly get quite 117 complicated when there are parallel redundant NAT devices, or where 118 there are more distributed and multi-point applications like multi- 119 party document sharing. The complexity of coordinating the updates 120 necessary to work around NAT grows geometrically with the number of 122 Hain Informational - Expires January 2001 3 123 Architectural Implications of NAT August 2000 125 endpoints. In a large environment, this may require concerted effort 126 to simultaneously update all endpoints of a given application or 127 service. 129 The architectural intent of NAT is to divide the Internet into 130 independent address administrations, (also see "address realms", 131 RFC-2663 [3]) specifically facilitating casual use of private 132 address assignments RFC-1918 [4]. As noted by Carpenter, et al RFC- 133 2101 [5], once private use addresses were deployed in the network, 134 addresses were guaranteed to be ambiguous. For example, when simple 135 NATs are inserted into the network, the process of resolving names 136 to or from addresses becomes dependent on where the question was 137 asked. The result of this division is to enforce a client/server 138 architecture (vs. peer/peer) where the servers need to exist in the 139 public address realm. 141 A significant factor in the success of the Internet is the 142 flexibility derived from a few basic tenets. Foremost is the End-to- 143 End principle (discussed further below), which notes that certain 144 functions can only be performed in the endpoints, thus they are in 145 control of the communication, and the network should be a simple 146 datagram service that moves bits between these points. Restated, the 147 endpoint applications are often the only place capable of correctly 148 managing the data stream. Removing this concern from the lower layer 149 packet-forwarding devices streamlines the forwarding process, 150 contributing to system-wide efficiency. 152 Another advantage is that the network does not maintain per 153 connection state information. This allows fast rerouting around 154 failures through alternate paths and to better scaling of the 155 overall network. Lack of state also removes any requirement for the 156 network nodes to notify each other as endpoint connections are 157 formed or dropped. Furthermore, the endpoints are not, and need not 158 be, aware of any network components other than the destination, 159 first hop router(s), and an optional name resolution service. Packet 160 integrity is preserved through the network, and transport checksums 161 and any address-dependent security functions are valid end-to-end. 163 NAT devices (particularly the NAPT variety) undermine most of these, 164 basic advantages of the end-to-end model, reducing overall 165 flexibility, while often increasing operational complexity and 166 impeding diagnostic capabilities. NAT variants such as RSIP [6] have 167 recently been proposed to address some of the end-to-end concerns. 168 While these proposals may be effective at providing the private node 169 with a public address (if ports are available), they do not 170 eliminate several issues like network state management, upper layer 171 constraints like TCP_TIME_WAIT state, or well-known-port sharing. 172 Their port multiplexing variants also have the same DNS limitations 173 as NAPT, and each host requires significant stack modifications to 174 enable the technology (see below). 176 It must be noted that firewalls also break the end-to-end model and 177 raise several of the same issues that NAT devises do, while adding a 179 Hain Informational - Expires January 2001 4 180 Architectural Implications of NAT August 2000 182 few of their own. But one operational advantage with firewalls is 183 that they are generally installed into networks with the explicit 184 intent to interfere with traffic flow, so the issues are more likely 185 to be understood or at least looked at if mysterious problems arise. 186 The same issues with NAT devices can sometimes be overlooked since 187 NAT devices are frequently presented as transparent to applications. 189 One thing that should be clearly stated up front is, that attempts 190 to use a variant of NAT as a simple router replacement may create 191 several significant issues that should be addressed before 192 deployment. The goal of this document is to discuss these with the 193 intent to raise awareness. 195 2. Terminology 197 Recognizing that many of these terms are defined in detail in RFC 198 2663 [3], the following are summaries as used in this document. 200 NAT - Network Address Translation in simple form is a method by 201 which IP addresses are mapped from one address administration to 202 another. The NAT function is unaware of the applications traversing 203 it, as it only looks at the IP headers. 205 ALG - Application Layer Gateway: inserted between application peers 206 to simulate a direct connection when some intervening protocol or 207 device prevents direct access. It terminates the transport 208 protocol, and may modify the data stream before forwarding. 210 NAT/ALG - combines ALG functions with simple NAT. Generally more 211 useful than pure NAT, because it embeds components for specific 212 applications that would not work through a pure NAT. 214 DNS/ALG � a special case of the NAT/ALG, where an ALG for the DNS 215 service interacts with the NAT component to modify the contents of a 216 DNS response. 218 Firewall - access control point that may be a special case of an 219 ALG, or packet filter. 221 Proxy - A relay service designed into a protocol, rather than 222 arbitrarily inserted. Unlike an ALG, the application on at least one 223 end must be aware of the proxy. 225 Static NAT - provides stable one-to-one mapping between address 226 spaces. 228 Dynamic NAT - provides dynamic mapping between address spaces 229 normally used with a relatively large number of addresses on one 230 side (private space) to a few addresses on the other (public space). 232 NAPT - Network Address Port Translation accomplishes translation by 233 multiplexing transport level identifiers of multiple addresses from 235 Hain Informational - Expires January 2001 5 236 Architectural Implications of NAT August 2000 238 one side, simultaneously into the transport identifiers of a single 239 address on the other. See 4.1.2 of RFC-2663. This permits multiple 240 endpoints to share and appear as a single IP address. 242 RSIP - Realm Specific IP allows endpoints to acquire and use the 243 public address and port number at the source. It includes mechanisms 244 for the private node to request multiple resources at once. RSIP 245 clients must be aware of the address administration boundaries, 246 which specific administrative area its peer resides in for each 247 application, and the topology for reaching the peer. To complete a 248 connection, the private node client requests one or more addresses 249 and/or ports from the appropriate RSIP server, then initiates a 250 connection via that RSIP server using the acquired public resources. 251 Hosts must be updated with specific RSIP software to support the 252 tunneling functions. 254 VPN - For purposes of this document, Virtual Private Networks 255 technically treat an IP infrastructure as a multiplexing substrate, 256 allowing the endpoints to build virtual transit pathways, over which 257 they run another instance of IP. Frequently the 2nd instance of IP 258 uses a different set of IP addresses. 260 AH - IP Authentication Header, RFC-2401 [7], which provides data 261 integrity, data origin authentication, and an optional anti-replay 262 service. 264 ESP - Encapsulating Security Payload protocol, RFC 2401, may provide 265 data confidentiality (encryption), and limited traffic flow 266 confidentiality. It also may provide data integrity, data origin 267 authentication, and an anti-replay service. 269 Address administration - coordinator of an address pool assigned to 270 a collection of routers and end systems. 272 Addressing realm � a collection of routers and end systems 273 exchanging locally unique location knowledge. (Further defined in 274 RFC-2663 NAT Terminology). NAT is used a means to distribute address 275 allocation authority and provide a mechanism to map addresses from 276 one address administration into those of another administration. 278 Hain Informational - Expires January 2001 6 279 Architectural Implications of NAT August 2000 281 3. Scope 283 In discussing the architectural impact of NATs on the Internet, the 284 first task is defining the scope of the Internet. The most basic 285 definition is; a concatenation of networks built using IETF defined 286 technologies. This simple description does not distinguish between 287 the public network known as the Internet, and the private networks 288 built using the same technologies (including those connected via 289 NAT). Rekhter, et al in RFC-1918 defined hosts as public when they 290 need network layer access outside the enterprise, using a globally 291 unambiguous address. Those that need limited or no access are 292 defined as private. Another way to view this is in terms of the 293 transparency of the connection between any given node and the rest 294 of the Internet. 296 The ultimate resolution of public or private is found in the intent 297 of the network in question. Generally, networks that do not intend 298 to be part of the greater Internet will use some screening 299 technology to insert a barrier. Historically barrier devices between 300 the public and private networks were known as Firewalls or 301 Application Gateways, and were managed to allow approved traffic 302 while blocking everything else. Increasingly, part of the screening 303 technology is a NAT, which manages the network locator between the 304 public and private-use address spaces, and then, using ALGs adds 305 support for protocols that are incompatible with NAT. (Use of NAT 306 within a private network is possible, and is only addressed here in 307 the context that some component of the private network is used as a 308 common transit service between the NAT attached stubs.) 310 RFC-1631 limited the scope of NAT discussions to stub appendages of 311 a public Internet, that is, networks with a single connection to the 312 rest of the Internet. The use of NAT in situations in which a 313 network has multiple connections to the rest of the Internet is 314 significantly more complex than when there is only a single 315 connection since the NATs have to be coordinated to ensure that they 316 have a consistent understanding of address mapping for each 317 individual device. 319 4. End-to-End Model 321 The concept of the End-to-End model is reviewed by Carpenter in 322 Internet Transparency [8]. One of the key points is "state should 323 be maintained only in the endpoints, in such a way that the state 324 can only be destroyed when the endpoint itself breaks"; this is 325 termed "fate-sharing". The goal behind fate-sharing is to ensure 326 robustness. As networks grow in size, likelihood of component 327 failures affecting a connection becomes increasingly frequent. If 328 failures lead to loss of communication, because key state is lost, 329 then the network becomes increasingly brittle, and its utility 330 degrades. However, if an endpoint itself fails, then there is no 331 hope of subsequent communication anyway. Therefore the End-to-End 332 model argues that as much as possible, only the endpoints should 333 hold critical state. 335 Hain Informational - Expires January 2001 7 336 Architectural Implications of NAT August 2000 338 For NATs, this aspect of the End-to-End model translates into the 339 NAT becoming a critical infrastructure element: if it fails, all 340 communication through it fails, and, unless great care is taken to 341 assure consistent, stable storage of its state, even when it 342 recovers the communication that was passing through it will still 343 fail (because the NAT no longer translates it using the same 344 mappings). Note that this latter type of failure is more severe 345 than the failure of a router; when a router recovers, any 346 communication that it had been forwarding previous can continue to 347 be successfully forwarded through it. 349 There are other important facets to the End-to-End model: 350 - when state is held in the interior of the network, then traffic 351 dependent on that state cannot be routed around failures unless 352 somehow the state is replicated to the fail-over points, which can 353 be very difficult to do in a consistent yet efficient and timely 354 fashion. 355 - a key principle for scaling networks to large size is to push 356 state-holding out to the edges of the network. If state is held 357 by elements in the core of the network, then as the network grows 358 the amount of state the elements must holds likewise grows. The 359 capacities of the elements can become severe chokepoints and the 360 number of connections affected by a failure also grows. 361 - if security state must be held inside the network (see the 362 discussion below), then the possible trust models the network can 363 support become restricted. 364 A network for which endpoints need not trust network service 365 providers has a great deal more security flexibility than one which 366 does. (Picture, for example, a business traveler connecting from 367 their hotel room back to their home office: should they have to 368 trust the hotel's networking staff with their security keys?, or the 369 staff of the ISP that supplies the hotel with its networking 370 service? How about when the traveler connects over a wireless 371 connection at an airport?) 372 Related to this, RFC-2101 notes: 373 Since IP Security authentication headers assume that the addresses 374 in the network header are preserved end-to-end, it is not clear 375 how one could support IP Security-based authentication between a 376 pair of hosts communicating through either an ALG or a NAT. 378 In addition, there are distributed applications that assume that IP 379 addresses are globally scoped, globally routable, and all hosts and 380 applications have the same view of those addresses. Indeed, a 381 standard technique for such applications to manage their additional 382 control and data connections is for one host to send to another the 383 address and port that the second host should connect to. NATs break 384 these applications. Similarly, there are other applications that 385 assume that all upper layer ports from a given IP address map to the 386 same endpoint, and port multiplexing technologies like NAPT and RSIP 387 break these. For example, a web server may desire to associate a 388 connection to port 80 with one to port 443, but due to the possible 390 Hain Informational - Expires January 2001 8 391 Architectural Implications of NAT August 2000 393 presence of a NATPT, the same IP address no longer ensures the same 394 host. 396 Limiting such applications is not a minor issue: much of the success 397 of the Internet today is due to the ease with which new applications 398 can run on endpoints without first requiring upgrades to 399 infrastructure elements. If new applications must have the NATs 400 upgraded in order to achieve widespread deployment, then rapid 401 deployment is hindered, and the pace of innovation slowed. 403 5. Advantages of NATs 405 A quick look at the popularity of NAT as a technology shows that it 406 tackles several real world problems when used at the border of a 407 stub domain. 409 - By masking the address changes that take place, from either dial- 410 access or provider changes, minimizes impact on the local network 411 by avoiding renumbering. 412 - Globally routable addresses can be reused for intermittent access 413 customers. This pushes the demand for addresses towards the number 414 of active nodes rather than the total number of nodes. 415 - There is a potential that ISP provided and managed NATs would 416 lower support burden since there could be a consistent, simple 417 device with a known configuration at the customer end of an access 418 interface. 419 - Breaking the Internet into a collection of address authorities 420 limits the need for continual justification of allocations allows 421 network managers to avoid the use of more advanced routing 422 techniques such as variable length subnets. 423 - Changes in the hosts may not be necessary for applications that 424 don't rely on the integrity of the packet header, or carry IP 425 addresses in the payload. 426 - Like packet filtering Firewalls, NAPT, & RSIP block inbound 427 connections to all ports until they are administratively mapped. 429 Taken together these explain some of the strong motivations for 430 moving quickly with NAT deployment. Traditional NAT [2] provides a 431 relatively simple function that is easily understood. 433 Removing hosts that are not currently active lowers address demands 434 on the public Internet. In cases where providers would otherwise end 435 up with address allocations that could not be aggregated, this 436 improves the load on the routing system as well as lengthens the 437 lifetime of the IPv4 address space. While reclaiming idle addresses 438 is a natural byproduct of the existing dynamic allocation, dial- 439 access devices, in the dedicated connection case this service could 440 be provided through a NAT. In the case of a NAPT, the aggregation 441 potential is even greater as multiple end systems share a single 442 public address. 444 Hain Informational - Expires January 2001 9 445 Architectural Implications of NAT August 2000 447 By reducing the potential customer connection options and minimizing 448 the support matrix, it is possible that ISP provided NATs would 449 lower support costs. 451 Part of the motivation for NAT is to avoid the high cost of 452 renumbering inherent in the current IPv4 Internet. Guidelines for 453 the assignment of IPv4 addresses RFC-2050 [9] mean that ISP 454 customers are currently required to renumber their networks if they 455 want to switch to a new ISP. Using a NAT (or a firewall with NAT 456 functions) means that only the Internet facing IP addresses must be 457 changed and internal network nodes do not need to be reconfigured. 458 Localizing address administration to the NAT minimizes renumbering 459 costs, and simultaneously provides for a much larger local pool of 460 addresses than is available under current allocation guidelines. 461 (The registry guidelines are intended to prolong the lifetime of the 462 IPv4 address space and manage routing table growth, until IPv6 is 463 ready or new routing technology reduces the pressure on the routing 464 table. This is accomplished by managing allocations to match actual 465 demand and to enforce hierarchical addressing. An unfortunate 466 byproduct of the current guidelines is that they may end up 467 hampering growth in areas where it is difficult to sort out real 468 need from potential hoarding.) NAT is effective at masking provider 469 switching or other requirements to change addresses, thus mitigates 470 some of the growth issues. 472 NAT deployments have been raising the awareness of protocol 473 designers who are interested in ensuring that their protocols work 474 end-to-end. Breaking the semantic overload of the IP address will 475 force applications to find a more appropriate mechanism for endpoint 476 identification and discourage carrying the locator in the data 477 stream. Since this will not work for legacy applications, RFC-1631 478 discusses how to look into the packet and make NAT transparent to 479 the application (ie: create an application gateway). This may not be 480 possible for all applications (such as IP based authentication in 481 SNMPv3), and even with application gateways in the path it may be 482 necessary to modify each end host to be aware when there are 483 intermediaries modifying the data. 485 Another popular practice is hiding a collection of hosts that 486 provide a combined service behind a single IP address (ie: web host 487 load sharing). In many implementations this is architecturally a 488 NAT, since the addresses are mapped to the real destination on the 489 fly. When packet header integrity is not an issue, this type of 490 virtual host requires no modifications to the remote applications 491 since the end client is unaware of the mapping activity. While the 492 virtual host has the CPU performance characteristics of the total 493 set of machines, the processing and I/O capabilities of the NAT/ALG 494 device bound the overall performance as it funnels the packets back 495 and forth. 497 Hain Informational - Expires January 2001 10 498 Architectural Implications of NAT August 2000 500 6. Problems with NATs 502 - NATs break the flexible end-to-end model of the Internet. 503 - NATs create a single point where fates are shared, in the device 504 maintaining connection state and dynamic mapping information. 505 - NATs complicate the use of multi-homing by a site in order to 506 increase the reliability of their Internet connectivity. 507 (While single routers are a point of fate sharing, the lack of 508 state in a router makes creating redundancy trivial. Indeed, this 509 is on of the reasons why the Internet protocol suite developed 510 using a connectionless datagram service as its network layer.) 511 - NATs inhibit implementation of security at the IP level. 512 - NATs enable casual use of private addresses. These uncoordinated 513 addresses are subject to collisions when companies using these 514 addresses merge or want to directly interconnect using VPNs. 515 - NATs facilitate concatenating existing private name spaces with 516 the public DNS. 517 - Port versions (NAPT and RSIP) increase operational complexity when 518 publicly published services reside on the private side. 519 - NATs invalidate the authentication mechanism of SNMPv3. 520 - Products may embed a NAT function without identifying it as such. 522 By design, NATs impose limitations on flexibility. As such, 523 extended thought about the introduced complications is called for. 524 This is especially true for products where the NAT function is a 525 hidden service, such as load balancing routers that re-write the IP 526 address to other public addresses. Since the addresses may be all in 527 publicly administered space these are rarely recognized as NATs, but 528 they break the integrity of the end-to-end model just the same. 530 NATs place constraints on the deployment of applications that carry 531 IP addresses (or address derivatives) in the data stream, and they 532 operate on the assumption that each session is independent. 533 However, there are applications such as FTP and H.323 that use one 534 or more control sessions to set the characteristics of the follow-on 535 sessions in their control session payload. Other examples include 536 SNMP MIBs for configuration, and COPS policy messages. Applications 537 or protocols like these assume end-to-end integrity of addresses and 538 will fail when traversing a NAT. (TCP was specifically designed to 539 take advantage of, and reuse, the IP address in combination with its 540 ports for use as a transport address.) To fix how NATs break such 541 applications, an Application Level Gateway needs to exist within or 542 alongside each NAT. An additional gateway service is necessary for 543 each application that may imbed an address in the data stream. The 544 NAT may also need to assemble fragmented datagrams to enable 545 translation of the application stream, and then adjust TCP sequence 546 numbers, prior to forwarding. 548 As noted earlier, NATs break the basic tenet of the Internet that 549 the endpoints are in control of the communication. The original 550 design put state control in the endpoints so there would be no other 551 inherent points of failure. Moving the state from the endpoints to 552 specific nodes in the network reduces flexibility, while it 554 Hain Informational - Expires January 2001 11 555 Architectural Implications of NAT August 2000 557 increases the impact of a single point failure. See further 558 discussion in Illustration 1 below. 560 In addition, NATs are not transparent to all applications, and 561 managing simultaneous updates to a large array of ALGs may exceed 562 the cost of acquiring additional globally routable addresses. See 563 further discussion in Illustration 2 below. 565 While RSIP addresses the transparency and ALG issues, for the 566 specific case of an individual private host needing public access, 567 there is still a node with state required to maintain the 568 connection. Dynamic NAT and RSIP will eventually violate higher 569 layer assumptions about address/port number reuse as defined in RFC- 570 793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is 571 specifically designed to prevent replay of packets between the 4- 572 tuple of IP and port for a given IP address pair. Since the TCP 573 state machine of a node is unaware of any previous use of RSIP, its 574 attempt to connect to the same remote service that its neighbor just 575 released (which is still in TCP_TIME_WAIT) may fail, or with a 576 larger sequence number may open the prior connection directly from 577 TCP_TIME_WAIT state, at the loss of the protection afforded by the 578 TCP_TIME_WAIT state (further discussion in 2.6 of RFC-2663 [3]). 580 For address translators (which do not translate ports) to comply 581 with the TCP_TIME_WAIT requirements, they must refrain from 582 assigning the same address to a different host until a period of 583 2*MSL has elapsed since the last use of the address, where MSL is 584 the Maximum Segment Lifetime defined in RFC-793 as two minutes. For 585 address-and-port translators to comply with this requirement, they 586 similarly must refrain from assigning the same host/port pair until 587 2*MSL has elapsed since the end of its first use. While these 588 requirements are simple to state, they can place a great deal of 589 pressure on the NAT, because they temporarily reduce the pool of 590 available addresses and ports. Consequently, it will be tempting or 591 NAT implementers to ignore or shorten the TCP_TIME_WAIT 592 requirements, at the cost of some of TCP's strong reliability. Note 593 that in the case where the strong reliability is in fact compromised 594 by the appearance of an old packet, the failure can manifest itself 595 as the receiver accepting incorrect data. See further discussion in 596 Illustration 3 below. 598 It is sometimes argued that NATs simply function to facilitate 599 "routing realms", where each domain is responsible for finding 600 addresses within its boundaries. Such a viewpoint clouds the 601 limitations created by NAT with the better-understood need for 602 routing management. Compartmentalization of routing information is 603 correctly a function of routing protocols and their scope of 604 application. NAT is simply a means to distribute address allocation 605 authority and provide a mechanism to map addresses from one address 606 realm into those of another realm. 608 In particular, it is sometimes erroneously believed that NATs serve 609 to provide routing isolation. In fact, if someone were to define an 611 Hain Informational - Expires January 2001 12 612 Architectural Implications of NAT August 2000 614 OSPF ALG it would actually be possible to route across a NAT 615 boundary. Rather than NAT providing the boundary, it is the 616 experienced operators who know how to limit network topology that 617 serve to avoid leaking addresses across a NAT. This is an 618 operational necessity given the potential for leaked addresses to 619 introduce inconsistencies into the public infrastructure. 621 One of the greatest concerns from the explosion of NATs is the 622 impact on the fledgling efforts at deploying network layer end-to- 623 end IP security. One fundamental issue for IPSec is that with both 624 AH and ESP, the authentication check covers the TCP/UDP checksum 625 (which in turn covers the IP address). When a NAT changes the IP 626 address, the checksum calculation will fail, and therefore 627 authentication is guaranteed to fail. Attempting to use the NAT as a 628 security boundary fails when requirement is end-to-end network layer 629 encryption, since only the endpoints have access to the keys. See 630 further discussion in Illustration 4 below. 632 Finally, while the port multiplexing variants of NAT (popular 633 because they allow Internet access through a single address) work 634 modestly well for connecting private hosts to public services, they 635 create management problems for applications connecting from public 636 toward private. The concept of a well-known port is undermined 637 because only one private side system can be mapped through the 638 single public-side port number. This will affect home networks, when 639 applications like multi-player Internet games can only be played on 640 one system at a time. It will also affect small businesses when only 641 one system at a time can be operated on the standard port to provide 642 web services. These may sound like only medium-grade restrictions 643 for the present, but as a basic property of the Internet, not to 644 change years into the future, it is highly undesirable. The issue is 645 that the public toward private usage requires administrative mapping 646 for each target prior to connection. If the ISP chooses to provide 647 a standardized version of these to lower configuration options, they 648 may find the support costs of managing the ALGs will exceed the cost 649 of additional address space. See further discussion in Illustration 650 6 below. 652 7. Illustrations 654 7.1 Single point of failure 655 A characteristic of stateful devices like NATs is the creation of a 656 single point of failure. Attempts to avoid this by establishing 657 redundant NATs, creates a new set of problems related to timely 658 communication of the state, and routing related failures. This 659 encompasses several issues such as update frequency, performance 660 impact of frequent updates, reliability of the state update 661 transaction, a-priori knowledge of all nodes needing this state 662 information, and notification to end nodes of alternatives. (This 663 notification could be accomplished with a routing protocol, which 664 might require modifications to the hosts so they will listen.) 666 Hain Informational - Expires January 2001 13 667 Architectural Implications of NAT August 2000 669 -------- -------- 670 | Host A |-----| Host B | 671 -------- | -------- 672 ----------------- 673 | | 674 ------ ------ 675 | AD 1 | | AD 2 | 676 ------ ------ 677 \ / 678 -------- 679 /Internet\ 680 ---------- 682 -------- 683 Illustration 1 685 In the traditional case where Access Device (AD) 1 & 2 are routers, 686 the single point of failure is the end Host, and the only effort 687 needed to maintain the connections through a router or link failure 688 is a simple routing update from the surviving router. In the case 689 where the ADs are a NAT variant there will be connection state 690 maintained in the active path that would need to be shared with 691 alternative NATs. When the Hosts have open connections through 692 either NAT, and it fails, the application connections will drop 693 unless the state had been previously moved to the surviving NAT. 694 The hosts will still need to acquire a routing redirect. In the 695 case of RSIP, the public side address pool would also need to be 696 shared between the ADs to allow movement. This sharing creates 697 another real-time operational complexity to prevent conflicting 698 assignments at connection setup. NAT as a technology creates a 699 point fate sharing outside the endpoints, in direct contradiction to 700 the original Internet design goals. 702 7.2. ALG complexity 703 In the following example of a proposed corporate network, each 704 NAT/ALG was to be one or more devices at each physical location, and 705 there were to be multiple physical locations per diagramed 706 connection. The logistics of simply updating software on this scale 707 is cumbersome, even when all the devices are the same manufacturer 708 and model. While this would also be true with routers, it would be 709 unnecessary for all devices to run a consistent version for an 710 application to work across an arbitrary path. 712 Hain Informational - Expires January 2001 14 713 Architectural Implications of NAT August 2000 715 ---------------------------------------- 716 | Corporate Network | 717 | Asia |------| Americas |------| Europe | 718 ------ ---------- -------- 719 | | | 720 -------- -------- -------- 721 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 722 -------- -------- -------- 723 | | | 724 -------------------------------------------- 725 | Internet | 726 -------------------------------------------- 727 | | | 728 -------- -------- -------- 729 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 730 -------- -------- -------- 731 | | | 732 ------------------ -------------- ---------------- 733 Home Telecommuters Branch Offices Partner Networks 734 ------------------ -------------- ---------------- 736 -------- 737 Illustration 2 739 7.3. TCP state violations 740 The full range of upper layer architectural assumptions that are 741 broken by NAT technologies may not be well understood without a very 742 large-scale deployment, because it sometimes requires the diversity 743 that comes with large-scale use to uncover unusual failure modes. 744 The following example illustrates an instance of the problem 745 discussed above in section 6. 747 -------- -------- 748 | Host A |-----| Host B | 749 -------- | -------- 750 -------- 751 |NAT/RSIP| 752 -------- 753 | 754 -------- 755 |Internet| 756 -------- 757 | 758 --------- 759 | Web | 760 | Server | 761 --------- 763 -------- 764 Illustration 3 766 Hain Informational - Expires January 2001 15 767 Architectural Implications of NAT August 2000 769 Host A completes its transaction and closes the web service on TCP 770 port 80, and the RSIP releases the public side address used for Host 771 A. Host B attempts to open a connection to the same web service, 772 and the NAT assigns then next free public side address which is the 773 same one A just released. The source port selection rules on Host B 774 happen to lead it to the same choice that A used. The connect 775 request from Host B is rejected because the web server, conforming 776 to the TCP specifications, has that 4-tuple in TIME WAIT for 4 777 minutes. By the time a call from Host B gets through to the 778 helpdesk complaining about no access, the requested retry will work, 779 so the issue is marked as resolved, when it in fact is an on-going, 780 but intermittent, problem. 782 7.4. Symmetric state management 783 Operational management of networks incorporating stateful packet 784 modifying device is considerably easier if inbound and outbound 785 packets traverse the same path. (Otherwise it's a headache to keep 786 state for the two directions synchronized.) While easy to say, even 787 with careful planning it can be difficult to manage using a 788 connectionless protocol like IP. The problem of creating redundant 789 connections is ensuring that routes advertised to the private side 790 reach the end nodes and map to the same device as the public side 791 route advertisements. This state needs to persist throughout the 792 lifetime of sessions traversing the NAT, in spite of frequent or 793 simultaneous internal and external topology churn. Consider the 794 following case where the -X- links are broken, or flapping. 796 -------- -------- 797 | Host A | | Host B | 798 | Foo | | Bar | 799 -------- -------- 800 | | 801 ---- ---- 802 |Rtr1|---X1---|Rtr2| 803 ---- ---- 804 | | 805 ---- ---- 806 |NAT1| |NAT2| 807 ---- ---- 808 | | 809 -------------- 810 |Rtr Rtr| 811 | / Internet \ | --- 812 |Rtr----X2---Rtr|----|DNS| 813 -------------- --- 814 | | 815 | | 816 -------- -------- 817 | Host C | | Host D | 818 -------- -------- 820 -------- 821 Illustration 4 823 Hain Informational - Expires January 2001 16 824 Architectural Implications of NAT August 2000 826 To preserve a consistent view of routing, the best path to the 827 Internet for Routers 1 & 2 is via NAT1, while the Internet is told 828 the path to the address pool managed by the NATs is best found 829 through NAT1. When the path X1 breaks, Router 2 would attempt to 830 switch to NAT2, but the external return path would still be through 831 NAT1. This is because the NAT1 device is advertising availability of 832 a pool of addresses. Directly connected routers in this same 833 situation would advertise the specific routes that existed after the 834 loss. In this case, redundancy was useless. 836 Consider the case that the path between Router 1 & 2 is up, and some 837 remote link in the network X2 is down. It is also assumed that DNS 838 returns addresses for both NATs when queried for Hosts A or B. When 839 Host D tries to contact Host B, the request goes through NAT2, but 840 due to the internal routing, the reply is through NAT1. Since the 841 state information for this connection is in NAT2, NAT1 will provide 842 a new mapping. Even if the remote path is restored, the connection 843 will not be made because the requests are to the public IP of NAT2, 844 while the replies are from the public IP of NAT1. 846 In a third case, both Host A & B want to contact Host D, when the 847 remote link X2 in the Internet breaks. As long as the path X1 is 848 down, Host B is able to connect, but Host A is cut off. Without a 849 thorough understanding of the remote topology (unlikely since 850 Internet providers tend to consider that sensitive proprietary 851 information), the administrator of Hosts A & B would have no clue 852 why one worked and the other didn't. As far as he can tell the 853 redundant paths through the NATs are up but only one connection 854 works. Again, this is due to lack of visibility to the topology that 855 is inherent when a stateful device is advertising availability to a 856 pool rather than the actual connected networks. 858 In any network topology, individual router or link failures may 859 present problems with insufficient redundancy, but the state 860 maintenance requirements of NAT present an additional burden that is 861 not as easily understood or resolved. 863 7.5. Need for a globally unique FQDN when advertising public services 864 The primary feature of NATs is the 'simple' ability to connect 865 private networks to the public Internet. When the private network 866 exists prior to installing the NAT, it is unlikely and unnecessary 867 that its name resolver would use a registered domain. As noted in 868 RFC 1123 [12] DNS queries may be resolved via local multicast. 869 Connecting the NAT device, and reconfiguring it's resolver to proxy 870 for all external requests allows access to the public network by 871 hosts on the private network. Configuring the public DNS for the set 872 of private hosts that need inbound connections would require a 873 registered domain (either private, or from the connecting ISP) and a 874 unique name. At this point the partitioned name space is 875 concatenated and hosts would have different names based on inside 876 vs. outside queries. 878 Hain Informational - Expires January 2001 17 879 Architectural Implications of NAT August 2000 881 -------- -------- 882 | Host A | | Host B | 883 | Foo |-----| Bar | 884 -------- | -------- --- 885 |-------------|DNS| 886 --- --- 887 |NAT| 888 --- 889 | 890 -------- --- 891 |Internet|----|DNS| 892 -------- --- 893 | 894 --- 895 |NAT| 896 --- --- 897 |-------------|DNS| 898 -------- | -------- --- 899 | Host C |-----| Host D | 900 | Foo | | Bar | 901 -------- -------- 903 -------- 904 Illustration 5 906 Everything in this simple example will work until an application 907 embeds a name. For example, a Web service running on Host D might 908 present embedded URL's of the form http://D/bar.html, which would 909 work from Host C, but would thoroughly confuse Host A. If the 910 embedded name resolved to the public address, Host A would be happy, 911 but Host C would be looking for some remote machine. Using the 912 public FQDN resolution to establishing a connection from Host C to 913 D, the NAT would have to look at the destination rather than simply 914 forwarding the packet out to the router. (Normal operating mode for 915 a NAT is translate & forward out the other interface, while routers 916 do not send packets back on the same interface they came from). The 917 NAT did not create the name space fragmentation, but it facilitates 918 attempts to merge networks with independent name administrations. 920 7.6. L2TP tunnels increase frequency of address collisions 921 The recent mass growth of the Internet has been driven by support of 922 low cost publication via the web. The next big push appears to be 923 support of Virtual Private Networks (VPNs) frequently accomplished 924 using L2TP. Technically VPN tunnels treat an IP infrastructure as a 925 multiplexing substrate allowing the endpoints to build what appear 926 to be clear pathways from end-to-end. These tunnels redefine network 927 visibility and increase the likelihood of address collision when 928 traversing multiple NATs. Address management in the private space 929 behind NATs will become a significant burden, as there is no central 930 body capable of, or willing to do it. The lower burden for the ISP 931 is actually a transfer of burden to the local level, because 932 administration of addresses and names becomes both distributed and 933 more complicated. 935 Hain Informational - Expires January 2001 18 936 Architectural Implications of NAT August 2000 938 As noted in RFC-1918, the merging of private address spaces can 939 cause an overlap in address use, creating a problem. L2TP tunnels 940 will increase the likelihood and frequency of that merging through 941 the simplicity of their establishment. There are several 942 configurations of address overlap which will cause failure, but in 943 the simple example shown below the private use address of Host B 944 matches the private use address of the VPN pool used by Host A for 945 inbound connections. When Host B tries to establish the VPN 946 interface, Host A will assign it an address from its pool for 947 inbound connections, and identify the gateway for Host B to use. In 948 the example, Host B will not be able to distinguish the remote VPN 949 gateway address of Host A from its own private address on the 950 physical interface, thus the connection will fail. Since private use 951 addresses are by definition not publicly coordinated, as the 952 complexity of the VPN mesh increases so does the likelihood that 953 there will be a collision that cannot be resolved. 955 --------------- ---------------- 956 | 10.10.10.10 |--------L2TP-------| Assigned by A | 957 | Host A | --- --- | Host B | 958 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 959 --------------- --- --- ---------------- 961 -------- 962 Illustration 6 964 7.7. Centralized data collection system report correlation 965 It has been reported that NAT introduces additional challenges when 966 intrusion detection systems attempt to correlate reports between 967 sensors inside and outside the NAT. While the details of individual 968 systems are beyond the scope of this document, it is clear that a 969 centralized system with monitoring agents on both sides of the NAT 970 would also need access to the current NAT mappings to get this 971 right. It would also be critical that the resulting data be indexed 972 properly if there were agents behind multiple NATs using the same 973 address range for the private side. 975 This also applies to management data collected via SNMP. Any time 976 the data stream carries an IP address; the central collector or ALG 977 will need to manipulate the data based on the current mappings in 978 the NAT. 980 8. IPv6 982 It has been argued that IPv6 is no longer necessary because NATs 983 relieve the address space constraints and allow the Internet to 984 continue growing. The reality is they point out the need for IPv6 985 more clearly than ever. People are trying to connect multiple 986 machines through a single access line to their ISP and have been 987 willing to give up some functionality to get that at minimum cost. 989 Hain Informational - Expires January 2001 19 990 Architectural Implications of NAT August 2000 992 Frequently the reason for cost increases is the perceived scarcity 993 (therefore increased value) of IPv4 addresses, which would be 994 eliminated through deployment of IPv6. This crisis mentality is 995 creating a market for a solution to a problem already solved with 996 greater flexibility by IPv6. 998 If NAT had never been defined, the motivation to resolve the 999 dwindling IPv4 address space would be a much greater. Given that 1000 NATs are enabling untold new hosts to attach to the Internet daily, 1001 it is difficult to ascertain the actual impact to the lifetime of 1002 IPv4, but NAT has certainly extended it. It is also difficult to 1003 determine the extent of delay NAT is causing for IPv6, both by 1004 relieving the pressure, and by redirecting the intellectual cycles 1005 away from the longer-term solution. 1007 But at the same time NAT functionality may be a critical facilitator 1008 in the deployment of IPv6. There are already 100 million or more 1009 computers running IPv4 on data networks. Some of these networks are 1010 connected to and thus part of the Internet and some are on private 1011 isolated networks. It is inconceivable that we could have a "flag 1012 day" and convert all of the existing IPv4 nodes to IPv6 at the same 1013 time. There will be a very long period of coexistence while both 1014 IPv4 and IPv6 are being used in the Internet and in private 1015 networks. The original IPv6 transition plan relied heavily on having 1016 new IPv6 nodes also be able to run IPv4 - a "dual stack" approach. 1017 When the dual stack node looks up another node in the DNS it will 1018 get back a IPv4 or an IPv6 address in response. If the response is 1019 an IPv4 address then the node uses IPv4 to contact the other node. 1020 And if the response is an IPv6 address then IPv6 can be used to make 1021 the contact. Turning the NAT into a 6to4 [13]router enables 1022 widespread deployment of IPv6 while providing an IPv4 path if IPv6 1023 is unavailable. While this maintains the current set of issues for 1024 IPv4 connections, it reestablishes the end-to-end principle for IPv6 1025 connections. 1027 An alternative methodology would be to translate the packets between 1028 IPv6 and IPv4 at the boarders between IPv4 supporting networks and 1029 IPv6 supporting networks. The need for this functionality was 1030 recognized in [RFC 1752], the document that recommended to the IETF 1031 that IPv6 be developed and recommended that a set of working groups 1032 be established to work on a number of specific problems. Header 1033 translation (i.e, NAT) was one of those problems. 1035 Of course, NATs in an IPv6 to IPv4 translation environment encounter 1036 all of the same problems that NATs encounter in a pure IPv4 and the 1037 environment and cautions in this document apply to both situations. 1039 Hain Informational - Expires January 2001 20 1040 Architectural Implications of NAT August 2000 1042 9. Security Considerations 1044 NAT (particularly NAPT) actually has the potential to lower overall 1045 security because it creates the illusion of a security barrier, but 1046 does so without the managed intent of a firewall. Appropriate 1047 security mechanisms are implemented in the end host, without 1048 reliance on assumptions about routing hacks, firewall filters, or 1049 missing NAT translations, which may change over time to enable a 1050 service to a neighboring host. In general, defined security barriers 1051 assume that any threats are external, leading to practices that make 1052 internal breaches much easier. 1054 IPsec RFC-2401 [7] defines a set of mechanisms to support packet- 1055 level authentication and encryption for use in IP networks. While 1056 this may be less efficient than application-level security but in 1057 the words of RFC-1752 [14] "support for basic packet-level 1058 authentication will provide for the adoption of a much needed, 1059 widespread, security infrastructure throughout the Internet." 1061 NATs break IPsec's authentication and encryption technologies 1062 because these technologies depend on an end-to-end consistency of 1063 the IP addresses in the IP headers, and therefore may stall further 1064 deployment of enhanced security across the Internet. NATs raise a 1065 number of specific issues with IPsec. For example; 1066 - Use of AH is not possible via NAT as the hash protects the IP 1067 address in the header. 1068 - Authenticated certificates may contain the IP address as part of 1069 the subject name for authentication purposes. 1070 - Encrypted Quick Mode structures may contain IP addresses and ports 1071 for policy verifications. 1072 - The Revised Mode of public key encryption includes the peer 1073 identity in the encrypted payload. 1074 It may be possible to engineer and work around NATs for IPsec on a 1075 case-by-case basis, but at the cost of restricting the trust model, 1076 as discussed in section 4 above. With all of the restrictions placed 1077 on deployment flexibility, NATs present a significant obstacle to 1078 security integration being deployed in the Internet today. 1080 As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS 1081 name servers in the private domain. Zone transfers between DNSsec 1082 servers will be rejected when necessary modifications are attempted. 1083 It is also the case that DNS/ALG will break any modified, signed 1084 responses. This would be the case for all public side queries of 1085 private nodes, when the DNS server is on the private side. It would 1086 also be true for any private side queries for private nodes, when 1087 the DNS server is on the public side. Digitally signed records could 1088 be modified by the DNS/ALG if it had access to the source 1089 authentication key. DNSsec has been specifically designed to avoid 1090 distribution of this key, to maintain source authenticity. So NATs 1091 that use DNS/ALG to repair the namespace resolutions will either; 1092 break the security when modifying the record, or will require access 1093 to all source keys to requested resolutions. 1095 Hain Informational - Expires January 2001 21 1096 Architectural Implications of NAT August 2000 1098 Security mechanisms that do not protect or rely on IP addresses as 1099 identifiers, such as TLS [16], SSL [17], or SSH [18] may operate in 1100 environments containing NATs. For applications that can establish 1101 and make use of this type of transport connection, NATs do not 1102 create any additional complications. These technologies may not 1103 provide sufficient protection for all applications as the header is 1104 exposed, allowing subversive acts like TCP resets. RFC-2385 [19] 1105 discusses the issues in more detail. 1107 Arguments that NATs may operate in a secure mode preclude true End- 1108 to-End security, as the NAT becomes the security endpoint. 1109 Operationally the NAT must be managed as part of the security 1110 domain, and in this mode the packets on the unsecured side of the 1111 NAT are fully exposed. 1113 Hain Informational - Expires January 2001 22 1114 Architectural Implications of NAT August 2000 1116 10. Deployment Guidelines 1117 Given that NAT devices are being deployed at a fairly rapid pace, 1118 some guidelines are in order. Most of these cautionary in nature and 1119 are designed to make sure that the reader fully understands the 1120 implications of the use of NATs in their environment. 1121 - Determine the mechanism for name resolution, and ensure the 1122 appropriate answer is given for each address administration. 1123 Embedding the DNS server, or a DNS ALG in the NAT device will 1124 likely be more manageable than trying to synchronize independent 1125 DNS systems across administrations. 1126 - Is the NAT configured for static one to one mappings, or will it 1127 dynamically manage them? If dynamic, make sure the TTL of the DNS 1128 responses is set to 0, and that the clients pay attention to the 1129 don't cache notification. 1130 - Will there be a single NAT device, or parallel with multiple 1131 paths? If single, consider the impact of a device failure. If 1132 multiple, consider how routing on both sides will insure the 1133 packets flow through the same box over the connection lifetime of 1134 the applications. 1135 - Examine the applications that will need to traverse the NAT and 1136 verify their immunity to address changes. If necessary provide an 1137 appropriate ALG or establish a VPN to isolate the application from 1138 the NAT. 1139 - Determine need for public toward private connections, variability 1140 of destinations on the private side, and potential for 1141 simultaneous use of public side port numbers. NAPTs increase 1142 administration if these apply. 1143 - Determine if the applications traversing the NAPT or RSIP expect 1144 all ports from the public IP address to be the same endpoint. 1145 Administrative controls to prevent simultaneous access from 1146 multiple private hosts will be required if this is the case. 1147 - If there are encrypted payloads, the contents cannot be modified 1148 unless the NAT is a security endpoint, acting as a gateway between 1149 security realms. This precludes end-to-end confidentiality, as the 1150 path between the NAT and endpoint is exposed. 1151 - Determine the path for name resolutions. If hosts on the private 1152 side of a NAPT or RSIP server need visibility to each other, a 1153 private side DNS server may be required. 1154 - If the environment uses secure DNS records, the DNS/ALG will 1155 require access to the source authentication keys for all records 1156 to be translated. 1157 - When using VPNs over NATs, identify a clearinghouse for the 1158 private side addresses to avoid collisions. 1159 - Assure that applications used both internally and externally avoid 1160 embedding names, or use globally unique ones. 1161 - When using RSIP, recognize the scope is limited to individual 1162 private network connecting to the public Internet. If other NATs 1163 are in the path (including web-server load-balancing devices), the 1164 advantage of RSIP (end-to-end address/port pair use) is lost. 1165 - For RSIP, determine the probability of TCP_Time_Wait collisions 1166 when subsequent private side hosts attempt to contact a recently 1167 disconnected public side service. 1169 Hain Informational - Expires January 2001 23 1170 Architectural Implications of NAT August 2000 1172 11. Summary 1174 Over the 6-year period since RFC-1631, the experience base has 1175 grown, further exposing concerns raised by the original authors. NAT 1176 breaks a fundamental assumption of the Internet design; the 1177 endpoints are in control. Another design principle, 'keep-it-simple' 1178 is being overlooked as more features are added to the network to 1179 work around the complications created by NATs. In the end, overall 1180 flexibility and manageability are lowered, and support costs go up 1181 to deal with the problems introduced. 1183 Evangelists, for and against the technology, present their cases as 1184 righteous while downplaying any rebuttals. 1185 - NATs are a 'fact of life', and will proliferate as an enhancement 1186 that sustains the existing IPv4 infrastructure. 1187 - NATs are a 'necessary evil' and create an administrative burden 1188 that is not easily resolved. More significantly, they inhibit the 1189 roll out of IPsec, which will in turn slow growth of applications 1190 that require a secure infrastructure. 1191 In either case, NATs require strong applicability statements, 1192 clearly declaring what works and what does not. 1194 An overview of the pluses and minuses: 1195 NAT advantages NAT disadvantages 1196 -------------------------------- -------------------------------- 1197 Masks global address changes Breaks end-to-end model 1198 Eases renumbering when providers Facilitates concatenation of 1199 change multiple name spaces 1200 Breaks IPsec 1201 Stateful points of failure 1202 Address administrations avoid Requires source specific DNS reply 1203 justifications to registries or DNS/ALG 1204 DNS/ALG breaks DNSsec replies 1205 Lowers address utilization Enables end-to-end address 1206 conflicts 1207 Lowers ISP support burden Increases local support burden and 1208 complexity 1209 Transparent to end systems in some Unique development for each app 1210 cases 1211 Load sharing as virtual host Performance limitations with scale 1212 Delays need for IPv4 replacement May complicate integration of IPv6 1214 There have been many discussions lately about the value of 1215 continuing with IPv6 development when the market place is widely 1216 deploying IPv4 NATs. A shortsighted view would miss the point that 1217 both have a role, because NATs address some real-world issues today, 1218 while IPv6 is targeted at solving fundamental problems, as well as 1219 moving forward. It should be recognized that there will be a long 1220 co-existence as applications and services develop for IPv6, while 1221 the lifetime of the existing IPv4 systems will likely be measured in 1222 decades. NATs are a diversion from forward motion, but they do 1223 enable wider participation at the present state. They also break a 1225 Hain Informational - Expires January 2001 24 1226 Architectural Implications of NAT August 2000 1228 class of applications, which creates the need for complex work- 1229 around scenarios. 1231 Efforts to enhance general security in the Internet include IPsec 1232 and DNSsec. These technologies provide a variety of services to both 1233 authenticate and protect information during transit. By breaking 1234 these technologies, NAT and the DNS/ALG work-around, hinder 1235 deployment of enhanced security throughout the Internet. 1237 There have also been many questions about the probability of VPNs 1238 being established that might raise some of the listed concerns. 1239 While it is hard to predict the future, one way to avoid ALGs for 1240 each application is to establish a L2TP over the NATs. This 1241 restricts the NAT visibility to the headers of the tunnel packets, 1242 and removes its effects from all applications. While this solves the 1243 ALG issues, it raises the likelihood that there will be address 1244 collisions as arbitrary connections are established between 1245 uncoordinated address spaces. It also creates a side concern about 1246 how an application establishes the necessary tunnel. 1248 The original IP architecture is powerful because it provides a 1249 general mechanism on which other things (yet unimagined) may be 1250 built. While it is possible to build a house of cards, time and 1251 experience have lead to building standards with more structural 1252 integrity. IPv6 is the long-term solution that retains end-to-end 1253 transparency as a principle. NAT is a technological diversion to 1254 sustain the lifetime of IPv4. 1256 12. References 1258 1 RFC-2026 Bradner, S., " The Internet Standards Process -- 1259 Revision 3", BCP 9, RFC 2026, October 1996. 1261 2 RFC-1631 Egevang, K., Francis, P., "The IP Network Address 1262 Translator", RFC 1631, May 1994 1264 3 RFC-2663, Srisuresh & Holdrege, "NAT Terminology and 1265 Considerations", RFC 2663 August 1999 1267 4 RFC-1918, Rekhter, et al, "Address Allocation for Private 1268 Internets", RFC 1918 February 1996 1270 5 RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", RFC 1271 2101, February 1997 1273 6 draft-ietf-nat-rsip-protocol-06.txt, M. Borella, D. Grabelsky, 1274 J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification", 1275 March 2000 1277 Hain Informational - Expires January 2001 25 1278 Architectural Implications of NAT August 2000 1280 7 RFC-2401, Kent & Atkinson, "Security Architecture for IP", 1281 November 1998 1283 8 RFC-2775, Carpenter, "Internet Transparency", February 2000 1285 9 RFC-2050, Hubbard, et. Al., "Internet Registry IP Allocation 1286 Guidelines", November 1996 1288 10 RFC-793, J. Postel, "Transmission Control Protocol", RFC 793, 1289 September 1981 1291 11 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for 1292 High-Speed Paths", RFC 1185, October 1990 1294 12 RFC-1123, R. Braden, "Requirements for Internet Hosts", RFC 1295 1123, October 1989 1297 13 draft-ietf-ngtrans-6to4-06.txt, B. Carpenter, K. Moore, 1298 "Connection of IPv6 Domains via IPv4 Clouds without Explicit 1299 Tunnels", June 2000 1301 14 RFC-1752, Bradner & Mankin, "Recommendation for IPng", January 1302 1995 1304 15 RFC-2694, Srisuresh, et al., "DNS extensions to NAT", September 1305 1999 1307 16 RFC-2246, T. Dierks, C. Allen, "The TLS Protocol", January 1999 1309 17 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 1311 18 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH 1312 Protocol Architecture", August 1998 1314 19 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP 1315 MD5 Signature Option", RFC 2385, August 1998 1317 Hain Informational - Expires January 2001 26 1318 Architectural Implications of NAT August 2000 1320 13. Acknowledgments 1321 Valuable contributions to this draft came from the IAB, Vern Paxson 1322 (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas Narten 1323 (ibm), Yakov Rekhter(cisco), Pyda Srisuresh, Matt Holdrege (lucent), 1324 and Eliot Lear (cisco). 1326 14. Author's Addresses 1327 Tony Hain 1328 Microsoft 1329 One Microsoft Way Phone: 1-425-703-6619 1330 Redmond, Wa. USA Email: tonyhain@microsoft.com 1332 Hain Informational - Expires January 2001 27