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