idnits 2.17.1 draft-iab-nat-implications-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1483 lines 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 324 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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: ---------------------------------------------------------------------------- == Line 1168 has weird spacing: '...istries or D...' -- 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 (April 1999) is 9144 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 24 looks like a reference -- Missing reference section? '2' on line 76 looks like a reference -- Missing reference section? '3' on line 133 looks like a reference -- Missing reference section? '4' on line 134 looks like a reference -- Missing reference section? '5' on line 164 looks like a reference -- Missing reference section? '6' on line 164 looks like a reference -- Missing reference section? '7' on line 259 looks like a reference -- Missing reference section? '8' on line 322 looks like a reference -- Missing reference section? '9' on line 395 looks like a reference -- Missing reference section? '10' on line 438 looks like a reference -- Missing reference section? '11' on line 516 looks like a reference -- Missing reference section? '12' on line 516 looks like a reference -- Missing reference section? '13' on line 516 looks like a reference -- Missing reference section? '14' on line 523 looks like a reference -- Missing reference section? '15' on line 867 looks like a reference -- Missing reference section? '16' on line 1012 looks like a reference -- Missing reference section? '17' on line 1051 looks like a reference -- Missing reference section? '18' on line 1051 looks like a reference -- Missing reference section? '19' on line 1051 looks like a reference -- Missing reference section? '20' on line 1056 looks like a reference -- Missing reference section? '21' on line 1059 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB T. Hain 2 Internet Draft Microsoft 3 Document: draft-iab-nat-implications-04.txt April 1999 4 Category: Informational 6 Architectural Implications of NAT 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026 [1]. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- Drafts 18 as reference material or to cite them other than as "work in 19 progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 "This memo provides information for the Internet community. This 26 memo does not specify an Internet standard of any kind. Distribution 27 of this memo is unlimited." 29 Abstract 31 In light of the growing interest in, and deployment of network 32 address translation (NAT) RFC-1631, this paper will discuss some of 33 the architectural implications and guidelines for implementations. 34 It is assumed the reader is familiar with the address translation 35 concepts presented in RFC-1631. 37 Hain Informational - Expires August 1999 1 39 Architectural Implications of NAT February 1999 40 Table of Contents 42 Status of this Memo ..................................................1 43 Abstract .............................................................1 44 Introduction .........................................................3 45 Definitions ..........................................................5 46 Terminology ........................................................5 47 Scope ..............................................................7 48 End-to-End Model ...................................................7 49 Advantages of NATs ...................................................8 50 Disadvantages of NATs ...............................................10 51 Illustrations .......................................................12 52 1. Single point of failure .......................................12 53 2. ALG complexity ................................................13 54 3. TCP state violations ..........................................13 55 4. Symmetric state management ....................................14 56 5. Need for a globally unique FQDN ...............................15 57 6. Name space collisions .........................................16 58 7. VPNs increase frequency of collisions .........................18 59 8. Address Reuse .................................................19 60 Considerations ......................................................20 61 IPv6 ..............................................................20 62 Security ..........................................................20 63 Deployment Guidelines .............................................22 64 Summary .............................................................23 65 References ..........................................................25 66 Acknowledgments ...................................................26 67 Author's Addresses ................................................26 68 Copyright .........................................................26 70 Hain Informational - Expires August 1999 2 72 Architectural Implications of NAT February 1999 74 Introduction 76 In May 1994, K. Egevang and P. Francis RFC-1631 [2] defined NAT as 77 one means to ease the growth rate of IPv4 address use. Several 78 places in the document they recognized the need to experiment and 79 see what applications may be adversely affected by NAT's header 80 manipulations, even before there was any significant operational 81 experience. This is further evidenced in a quote from the 82 conclusions: 'NAT has several negative characteristics that make it 83 inappropriate as a long term solution, and may make it inappropriate 84 even as a short term solution.' 86 Nearly five years later, there are arguments that NAT is 'THE' short 87 'AND' long-term solution, while questioning the strategy or 88 continued effort at developing IPv6 as a replacement protocol. At 89 the same time, the shortage of IPv4 addresses, caused by the current 90 stringent allocation guidelines and drive to limit routing table 91 growth, creates a perceived need to promote private address use via 92 NAT. This increase in popularity of private addresses has resulted 93 in additional experience, further exposing NAT's shortcomings. 94 Unfortunately even as the failings of NAT are exposed, the 95 technology is widely promoted as if it 'just works' with no serious 96 effects except on a few legacy applications. 98 The arguments pro and con frequently take on religious tones, with 99 each side passionate about its position. 100 - Proponents bring enthusiasm and frequently cite the most popular 101 applications of Mail & Web services as sucessful examples of their 102 cause. They will also point out that NAT is the feature that 103 finally breaks the semantic overload of the IP address as both a 104 locator and the global endpoint identifier (EID). 105 - The opposing view of NAT is that of a malicious technology, where 106 there is a concern that NAT is the weed which is destined to choke 107 out continued Internet development. While recognizing there are 108 perceived address shortages, the opponents of NAT view it as 109 operationally inadequate at best, bordering on a sham as an 110 Internet access solution. 112 With reality somewhere in between these extreme viewpoints, it is 113 clear NAT affects the transparency of end-to-end connectivity for 114 transports relying on consistency of the IP header. Using a 115 patchwork of mutually configured Application Layer Gateways (ALGs), 116 endpoints can work around some of the operational challenges of NAT. 117 When there are two endpoints in a conversation this effort is 118 straightforward, but for applications with more distributed and 119 multi-point expectations (like multi-party document sharing) it can 120 be a significant ordeal. The complexity of coordinating the updates 121 necessary to work around NAT grows geometrically with the number of 122 endpoints. In a large environment (like an auto manufacturer network 123 connecting independent suppliers who may also connect to other 124 manufacturers), this may require concerted effort to simultaneously 125 upgrade all endpoints of a given application or service. 127 Hain Informational - Expires August 1999 3 129 Architectural Implications of NAT February 1999 131 The architectural role of NAT is to divide the Internet into 132 independent address administrations, specifically facilitating 133 casual use of private address assignments RFC-1918 [3]. As noted by 134 Carpenter, et al RFC-2101 [4], once private use addresses were 135 deployed in the network, addresses were guaranteed to be ambiguous. 136 At the same time when NATs are attached to the network, the process 137 of resolving names to or from addresses gains a dependency on where 138 the question was asked. As NAT concatenates existing stand-alone 139 name spaces, both names and addresses become globally ambiguous. 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 is a simple datagram 146 service that moves bits between these points. Restated, the endpoint 147 applications are the only place capable of correctly managing the 148 data stream. Removing this concern from the lower layer packet 149 routing devices streamlines the forwarding process, contributing to 150 system-wide efficiency. Another is that the network does not 151 maintain per connection state information, which allows fast 152 rerouting around failures through alternate paths. Lack of state 153 also removes any requirement for the network nodes to notify each 154 other as endpoint connections are formed or dropped. Furthermore, 155 the endpoints are not, and need not be, aware of any network 156 components other than the destination, first hop router(s), and 157 optional name resolution service. Packet integrity is preserved 158 through the network, and transport checksums are valid end-to-end. 159 NATs (particularly the NAPT variety) break most of these, reducing 160 overall flexibility, while increasing operational complexity and 161 impeding diagnostic capabilities. (Note: while firewalls also break 162 the end-to-end model, they are installed with the explicit intent to 163 manage traffic flow, where NAT claims to be transparent.) The HNAT 164 [5] and RSIP [6] variants have recently been proposed to address the 165 end-to-end concerns. While they may be effective at providing the 166 private node with a public address (when ports/addresses are 167 available), they do not deal with the issues of; network state 168 management, upper layer constraints like TCP TIME_WAIT state, or 169 inbound well-known-port sharing. Their port multiplexing variants 170 also share the same neighbor DNS visibility concerns of NAPT, and 171 each host requires significant stack modifications to enable the 172 technology. 174 One thing that should be clearly stated up front is that any attempt 175 to use a NAT variant as a simple router replacement, will create a 176 set of issues that must be addressed. Some of these are discussed in 177 this document with the intent to raise awareness. 179 Hain Informational - Expires August 1999 4 181 Architectural Implications of NAT February 1999 182 Definitions 184 Terminology 186 NAT - Network Address Translation in simple form is a method by 187 which IP addresses are mapped from one address administration to 188 another. The NAT function is unaware of the applications traversing 189 it, as it only looks at the IP headers. 191 ALG - Application Layer Gateway inserted between application peers 192 to simulate a direct connection, when some intervening protocol or 193 device prevents direct access. It terminates the transport protocol, 194 and may modify the data stream before forwarding. 196 NAT/ALG - combines ALG functions with simple NAT. Generally more 197 useful than pure NAT, because it embeds a work around to a specific 198 application that NAT breaks. 200 DNS/ALG - special case of NAT/ALG, where an ALG for the DNS service 201 interacts with the NAT component to manage the contents of a DNS 202 reply. 204 Firewall - access control point that may be a special case of an 205 ALG, or routing filter. 207 Proxy - Special case of an ALG that is a simple relay service 208 designed into a protocol, rather than arbitrarily inserted. 210 Static NAT - provides stable one-to-one mapping between address 211 spaces. 213 Dynamic NAT - provides many-to-few mapping from a relatively large 214 number of addresses on one side to a few addresses on the other. 216 NAPT - Network Address Port Translation accomplishes translation by 217 multiplexing transport level identifiers of multiple addresses from 218 one side, simultaneously into the transport identifiers of a single 219 address on the other. 221 HNAT - Host NAT allows endpoints to acquire and use their public 222 address and port number at the source. The public / private process 223 only allocates public addresses and forwards unmodified packets. 224 This has the same requirement to modify Hosts as RSIP. 226 RSIP - Realm Specific IP is a generalization of HNAT, including 227 mechanisms for the private node to request multiple resources at 228 once. RSIP clients must be aware of the address administration 229 boundaries, which specific administration the peer resides in for 230 each application, and the topology for reaching it. To complete a 231 connection, the private node client requests one or more 232 addresses/ports from the appropriate RSIP server, then initiates a 233 connection via that RSIP server using the acquired public resources. 235 Hain Informational - Expires August 1999 5 237 Architectural Implications of NAT February 1999 238 VPN - For purposes of this document, Virtual Private Networks 239 technically treat an IP infrastructure as a multiplexing substrate, 240 allowing the endpoints to build virtual transit pathways, over which 241 they run another instance of IP. 243 AH - IP Authentication Header which provides connectionless 244 integrity, data origin authentication, and an optional anti-replay 245 service. 247 ESP - Encapsulating Security Payload protocol may provide 248 confidentiality (encryption), and limited traffic flow 249 confidentiality. It also may provide connectionless integrity, data 250 origin authentication, and an anti-replay service. 252 Address administration - coordinator of an address pool assigned to 253 a collection of routers and end systems. 255 Routing realm - collection of routers and end systems exchanging 256 locally unique location knowledge (potentially in a hierarchical 257 arrangement). 258 NAT proponents define the NAT function as providing routing 259 realms [7], where each domain is responsible for finding 260 addresses within its boundaries. This work-around to the 261 limitations created by NAT, attempts to hide them behind the 262 well-understood need for routing management. Compartmentalization 263 of routing information is actually a function of routing 264 protocols and their scope of application. NAT is simply a means 265 to distribute address allocation authority and provide a 266 mechanism to map addresses from one address administration into 267 those of another administration. The fact that experienced 268 operators limit network topology, and don't leak addresses across 269 a NAT, does not mean NAT itself provides any routing isolation 270 services. By announcing the private addresses (which may include 271 any of the address space from the public side) across the NAT, 272 the public infrastructure can become confused. In fact, if 273 someone were to define an OSPF ALG it would be technically 274 possible to route across a NAT boundary. Using a routing ALG, in 275 combination with the fact that NAT breaks IPsec, could allow a 276 private network to enforce which endpoints are even capable of 277 attempting secure access while allowing non-secure access to 278 other services. 280 Hain Informational - Expires August 1999 6 282 Architectural Implications of NAT February 1999 283 Scope 285 RFC-1631 limited the scope of NAT discussions to stub appendages of 286 a public Internet. Therefore, in discussing the architectural impact 287 of NATs on the Internet, the first task is defining the scope of the 288 Internet. The most basic definition is; a concatenation of networks 289 built using IETF defined technologies. This simple description does 290 not distinguish between the public network known as the Internet, 291 and the private networks built using the same technologies 292 (including those connected via NAT). An approach resolving this 293 would be including the resources of Names or Addresses administered 294 through IANA or its delegates. While this is more accurate, it still 295 includes many private networks that have coordinated their names or 296 addresses with the public Internet. Rekhter, et al RFC-1918 defined 297 hosts as public when they need network layer access outside the 298 enterprise, using a globally unambiguous address. Those that need 299 limited or no access are defined as private. Another way to view 300 this is the transparency of the connection between any given node 301 and the rest of the Internet. 303 The ultimate resolution of public or private is found in the intent 304 of the network in question. Generally, networks that do not intend 305 to be part of the greater Internet will use some screening 306 technology to insert a barrier. Historically barrier devices between 307 the public and private networks were known as Firewalls or 308 Application Gateways, and were managed to allow approved traffic 309 while blocking everything else. Increasingly the screening 310 technology is becoming a simple NAT, which manages the network 311 locator between the public and private-use address spaces, and then, 312 using ALGs, attempts to be transparent to protocols incompatible 313 with NAT. (Use of NAT within a private network is possible, and is 314 only addressed here in the context that some component of the 315 private network is used as a common transit service between the NAT 316 attached stubs.) The primary distinction between a Firewall and NAT 317 in this context is the intent to block, or facilitate traffic flow. 319 End-to-End Model 321 The concept of the End-to-End model is reviewed for current 322 attention by Carpenter in Internet Transparency [8]. One of the key 323 points, "state should be maintained only in the endpoints, in such a 324 way that the state can only be destroyed when the endpoint itself 325 breaks" has direct significance when discussing NAT. The highly 326 robust nature of a stateless network is lost as NAT is deployed. 327 Taken to the extreme, global connectivity would end up depending on 328 endless patchwork of application gateways and encapsulation headers. 330 Another point is the inclination of applications toward client / 331 server, rather than peer / peer due to the ambiguity of endpoint 332 identity. While there may be additional reasons for this tendency, 333 the intentional spread of ambiguity in the endpoint identifier will 334 not lead to an environment where peer /peer is easier. 336 Hain Informational - Expires August 1999 7 338 Architectural Implications of NAT February 1999 340 In a statement about the use of IPv4 today, RFC-2101 details 341 architectural issues and notes: 342 "... it has been considered more useful to deliver the packet, 343 then worry about how to identify the endpoints, than to provide 344 identity in a packet that cannot be delivered." 346 This argument presumes that delivering the packet has an inherent 347 value, even if the endpoints cannot be identified. In a self- 348 fulfillment of that prophecy, many applications developed to date 349 are structured to assume packets will be delivered and identity is 350 only assured in controlled environments. 352 In another note from RFC-2101: 353 "Since IP Security authentication headers assume that the 354 addresses in the network header are preserved end-to-end, it is 355 not clear how one could support IP Security-based authentication 356 between a pair of hosts communicating through either an ALG (ed: 357 Application Level Gateway) or a NAT." 359 There are distributed applications that assume that IP addresses are 360 globally scoped, globally unique, globally routable, and all hosts 361 have the same view of those addresses. NATs break these 362 applications. There are other applications that assume that all 363 upper layer ports from a given IP address map to the same endpoint, 364 and port multiplexing technologies like NAPT, HNAPT, and RSIP breaks 365 those. For example, a web server may desire to associate a 366 connection to port 80, with one to port 443, but the same IP address 367 no longer insures the same host. 369 Advantages of NATs 371 A quick look at the popularity of NAT as a technology shows that it 372 tackles several real world problems. 374 - Masking the address changes that take place, from either dial- 375 access or provider changes, minimizes impact on the local network 376 by avoiding renumbering. 377 - Globally routable addresses can be reused for intermittent access 378 customers. This lowers the demand and utilization of addresses to 379 the number of active nodes rather than the total number of nodes. 380 - There is a potential that ISP-provided and managed NATs would 381 lower support burden since there could be a consistent, simple 382 device with a known configuration at the customer end of the 383 access interface. 384 - Breaking the Internet into a collection of address authorities 385 limits the need for continual justification of new allocations. 386 - For applications that don't rely on the integrity of the packet 387 header, changes in the hosts may not be necessary. 388 - Like route filtering Firewalls, NAPT, HNAPT, & RSIP block inbound 389 connections to all ports until they are administratively mapped. 391 Hain Informational - Expires August 1999 8 393 Architectural Implications of NAT February 1999 394 Taken together these explain some of the strong motivations for 395 moving quickly with NAT deployment. Traditional NAT [9] provides a 396 relatively simple function that is easily understood. 398 Removing hosts that are not currently active lowers address demands 399 of the public Internet. In cases where providers would end up with 400 address allocations that could not be aggregated, this improves the 401 load on the routing system as well as lengthens the lifetime of the 402 IPv4 address space. While removing idle addresses is a natural 403 byproduct of the existing dynamic allocation dial-access devices, in 404 the dedicated connection case this service could be provided through 405 a NAT. In the case of a NAPT, the aggregation potential is even 406 greater as multiple end systems share a single public address. 408 By reducing the options and minimizing the potential support matrix, 409 there is a potential for ISP-provided NATs to lower support costs. 411 Part of the motivation for NAT is to avoid the high cost of 412 renumbering inherent in the current IPv4 Internet. Localizing 413 address administration minimizes those costs, and simultaneously 414 provides for a much larger local pool of addresses than is available 415 under current allocation guidelines. (The registry guidelines are 416 intended to prolong the lifetime of the IPv4 address space and 417 manage routing table growth, until IPv6 is ready, by managing 418 allocations to match actual demand. They may end up hampering growth 419 in areas where it is difficult to sort out real need from potential 420 hoarding.) Until IPv6 provides a simpler solution, NAT is effective 421 at masking provider-switching or other requirements to change 422 addresses. 424 NAT deployments have been raising the awareness of protocol 425 designers who are interested in ensuring that their protocols work 426 end-to-end. Breaking the semantic overload of the IP address will 427 force applications to find a more appropriate mechanism for endpoint 428 identification and discourage carrying the locator in the data 429 stream. Since this will not work for legacy applications, RFC-1631 430 discusses how to look into the packet and make NAT transparent to 431 the application (ie: create an application gateway). This may not be 432 possible for all applications, and even with application gateways in 433 the path, it may be necessary to modify the end host to be aware 434 there may be intermediaries modifying the data. 436 Another popular practice is hiding a collection of hosts that 437 provide a combined service behind a single IP address (ie: web host 438 load sharing) [10]. In many implementations this is architecturally 439 a NAT, since the addresses are mapped to the real destination on the 440 fly. When packet header integrity is not an issue, this type of 441 virtual host requires no modifications to the remote applications 442 since the end client is unaware of the mapping activity. While the 443 virtual host has the CPU performance characteristics of the total 444 set of machines, the processing and I/O capabilities of the NAT/ALG 445 device bound the overall performance as it funnels the packets back 446 and forth. 448 Hain Informational - Expires August 1999 9 450 Architectural Implications of NAT February 1999 452 Disadvantages of NATs 454 - NATs break the flexible End-to-End model of the Internet. 455 - NATs create a single point where fates are shared, in the device 456 maintaining connection state and dynamic mapping information. 457 (While single routers have the same property, the lack of state in 458 a router makes creating redundancy trivial.) 459 - NATs inhibit implementation of security at the IP level. 460 - NATs enable casual use of private addresses. These uncoordinated 461 addresses are subject to collisions when VPNs traverse multiple 462 NATs along a path. 463 - NATs facilitate concatenating existing name spaces with the DNS. 464 - Port versions (NAPT, HNAPT, & RSIP) increase operational 465 complexity when publicly published services reside on the private 466 side. This includes the restriction that only one private side 467 well-known-port can be accessed through a given public side name. 468 - NATs invalidate the authentication mechanism of SNMPv3 469 - Products may embed a NAT function without identifying it as such. 471 By design, NATs impose limitations on flexibility. As such, extended 472 thought about the introduced complications is called for. This is 473 especially true for products where the NAT function is a hidden 474 service, such as load balancing routers that re-write the IP address 475 to other public addresses. Since the addresses may be all in 476 publicly administered space these are rarely recognized as NATs, but 477 they break the end-to-end integrity just the same. 479 NATs place constraints on the deployment of applications that carry 480 IP addresses (or address derivatives) in the data stream, and they 481 operate on the assumption that each session is independent. 482 However, there are applications such as H.323 that use one or more 483 control sessions to set the characteristics of the follow-on 484 sessions in their control session payload. Applications or protocols 485 such as this that assume end-to-end integrity of the address will 486 fail when traversing a NAT. (TCP was specifically designed to take 487 advantage of, and reuse the IP address in combination with its ports 488 for use as a transport address.) To resolve this, an Application 489 Level Gateway needs to exist within or alongside each NAT. An 490 additional gateway service is necessary for each application that 491 may imbed an address. The NAT may also need to assemble fragmented 492 datagrams, to enable translation of the application stream, prior to 493 forwarding. 495 As noted earlier, NATs break the basic tenet of the Internet that 496 the endpoints are in control of the communication. The original 497 design put state control in the endpoints so there would be no other 498 inherent points of failure. Moving the state from the endpoints to 499 specific nodes in the network reduces flexibility, while it 500 increases the impact of a single point failure. Further discussion 501 in Illustration 1. 503 Hain Informational - Expires August 1999 10 505 Architectural Implications of NAT February 1999 506 In addition, NATs are not transparent to all applications, as they 507 Managing simultaneous updates to a large array of ALGs may exceed 508 the cost of acquiring additional globally routable addresses. 509 Further discussion in Illustration 2. 511 While RSIP addresses the transparency and ALG issues, for the 512 specific case of individual private host needing public access, 513 there is still a node with specific state required to maintain the 514 connection. Dynamic NAT, HNAT, and RSIP will all eventually violate 515 higher layer assumptions about address/port number reuse as defined 516 in RFC-793 [11] RFC-1185 [12] RFC-1323 [13]. The TCP state, 517 TIME_WAIT, is specifically designed to prevent replay of packets 518 between the 4-tuple of IP & port for a given IP address pair. Since 519 the TCP state machine of a second node is unaware of any previous 520 use via RSIP, their attempt to connect to the same remote service 521 its neighbor just released (which is still in TIME_WAIT) may fail, 522 or with a larger sequence number may even REOPEN the prior 523 connection directly from TIME_WAIT state [14]. Further discussion in 524 Illustration 3. 526 One of the greatest concerns from the explosion of NATs is the 527 impact on the fledgling efforts at deploying network layer end-to- 528 end IP security. One fundamental issue for IPSec is that with both 529 AH and ESP, the authentication check covers the TCP/UDP checksum 530 (which in turn covers the IP address). When a NAT changes the IP 531 address, the checksum calculation will fail, and therefore 532 authentication will fail. This combination of required global 533 uniqueness of the address, and assured ambiguity by NAT leaves the 534 IPsec effort without a workable solution. Attempting to use the NAT 535 as a security boundary will fail when requirement is end-to-end 536 network layer encryption, since only the endpoints have access to 537 the keys. Further discussion in Illustration 4. 539 Finally, while the port multiplexing variants of NAT (popular 540 because they allow Internet access through a single address) work 541 modestly well for connecting private hosts to public services, they 542 create management problems for applications connecting from public 543 toward private. The concept of a well-known-port is undermined 544 because only one private side system can be mapped through the 545 single public-side port number at a time. This can affect home 546 networks, when applications like multi-player Internet games can 547 only be played on one system at a time. It will also affect small 548 businesses when only one system at a time can be operated on the 549 standard port to provide web services. The issue is that the public 550 toward private usage requires administrative mapping for each target 551 prior to connection. If the ISP chooses to provide a standardized 552 version of these to lower configuration options, they may find the 553 support costs of managing the ALGs will exceed the cost of 554 additional address space. Further discussion in Illustration 6. 556 Hain Informational - Expires August 1999 11 558 Architectural Implications of NAT February 1999 560 Illustrations 562 1. Single point of failure 563 A characteristic of stateful devices like NATs is the creation of a 564 single point of failure. Attempts to avoid this by establishing 565 redundant NATs, creates a new set of problems related to timely 566 communication of the state, and routing related failures. This 567 encompasses several issues such as update frequency, performance 568 impact of frequent updates, reliability of the state update 569 transaction, a-priori knowledge of all nodes needing this state 570 information, and notification to end nodes of alternatives. 572 -------- -------- 573 | Host A |-----| Host B | 574 -------- | -------- 575 ----------------- 576 | | 577 ------ ------ 578 | AD 1 | | AD 2 | 579 ------ ------ 580 \ / 581 -------- 582 |Internet| 583 -------- 585 In the traditional case where Access Device (AD) 1 & 2 are simple 586 routers, the single point of failure is the end Host, and the only 587 effort needed to maintain the connections through a router or link 588 failure is a simple routing update from the surviving router. In the 589 case where the Ads are a NAT variant there will be connection state 590 maintained in the active path that would need to be shared with 591 alternative NATs. When the Hosts have open connections through 592 either NAT, and it fails, the application connections will drop 593 unless the state had been previously moved to the surviving NAT. The 594 hosts will also need to acquire a redirect. In the case of RSIP, the 595 public side address pool would also need to be shared between the 596 Ads to allow movement. This sharing creates another real-time 597 operational complexity to prevent conflicting assignments at 598 connection setup. NAT as a technology creates a point fate sharing 599 outside the endpoints, in direct contradiction to the original 600 Internet design goals. 602 Hain Informational - Expires August 1999 12 604 Architectural Implications of NAT February 1999 605 2. ALG complexity 606 In the following (actually proposed) example, each NAT/ALG may be 607 one or more devices at each physical location, and there may be 608 multiple physical locations per diagramed connection. The logistics 609 of simply updating software on this potential scale is cumbersome, 610 even when all the devices are all the same manufacturer and model. 612 ---------------------------------------- 613 | Corporate Network | 614 | Asia |------| Americas |------| Europe | 615 ------ ---------- -------- 616 | | | 617 -------- -------- -------- 618 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 619 -------- -------- -------- 620 | | | 621 ---------------------------------------- 622 | Internet | 623 ---------------------------------------- 624 | | | 625 -------- -------- -------- 626 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 627 -------- -------- -------- 628 | | | 629 ------------------ -------------- ---------------- 630 Home Telecommuters Branch Offices Partner Networks 631 ------------------ -------------- ---------------- 633 3. TCP state violations 634 The full range of upper layer architectural assumptions that are 635 broken by NAT technologies may not be well understood without a very 636 large-scale deployment. The following example outlines one simple 637 case. 639 -------- -------- 640 | Host A |-----| Host B | 641 -------- | -------- 642 -------- 643 |NAT/RSIP| 644 -------- 645 | 646 -------- 647 |Internet| 648 -------- 649 | 650 --------- 651 | Web | 652 | Server | 653 --------- 655 Hain Informational - Expires August 1999 13 657 Architectural Implications of NAT February 1999 658 Host A completes its transaction and closes the web service on TCP 659 port 80, and the DNAT/RSIP releases the public side address used for 660 Host A. Host B attempts to open a connection to the same web 661 service, and the NAT assigns then next free public side address 662 which is the same one A just released. The source port selection 663 rules on Host B lead it to the same choice that A used. The connect 664 request from Host B is rejected because the web server, conforming 665 to the TCP specifications, has that 4-tuple in TIME WAIT for 4 666 minutes. By the time a call from Host B gets through to the helpdesk 667 complaining about no access, the requested retry will work so the 668 issue is marked as resolved, when it is really deployed to be 669 intermittent. In the case Host B had happened to select a sequence 670 number that was higher than that used by Host A, the Web server may 671 have REOPENED the prior connection. The results of this action are 672 clearly application dependent, but the potential exists for Host B 673 to access data intended to be private for Host A. 675 4. Symmetric state management 676 It has been observed that operational management of networks 677 incorporating stateful packet modifying device is considerably 678 easier if inbound and outbound packets traverse the same path. While 679 easy to say, even with careful planning it is difficult to manage 680 using a connectionless protocol like IP. The problem is ensuring 681 that routes advertised to the private side reach the end nodes and 682 map to the same device as the public side route advertisements. This 683 state needs to persist throughout the lifetime of sessions 684 traversing the NAT. A point to bear in mind is the frequency of 685 simultaneous internal and external topology churn. Consider the 686 following cases where the -X- links are broken, or flapping. 687 -------- -------- 688 | Host A | | Host B | 689 | Foo | | Bar | 690 -------- -------- 691 | | 692 ---- ---- 693 |Rtr1|---X1---|Rtr2| 694 ---- ---- 695 | | 696 ---- ---- 697 |NAT1| |NAT2| 698 ---- ---- 699 | | 700 -------------- 701 |Rtr Rtr| 702 | / Internet \ | --- 703 |Rtr----X2---Rtr|----|DNS| 704 -------------- --- 705 | | 706 | | 707 -------- -------- 708 | Host C | | Host D | 709 -------- -------- 711 Hain Informational - Expires August 1999 14 713 Architectural Implications of NAT February 1999 715 To maintain sanity with external routing, the default path for 716 Routers 1 & 2 is via NAT1. When the path X1 between Router 1 & 2 717 breaks, Router 2 would attempt to switch to NAT2, but the external 718 return path would still be through NAT1. In this case, Internet 719 access redundancy was useless. While this scenario is strictly a 720 routing failure, the normal routing tools for resolving it are not 721 available because the connection to the Internet is via stateful 722 NATs. 724 Consider the case that the path between Router 1 & 2 is up, and some 725 remote link in the network X2 is down. It is also assumed that DNS 726 returns addresses for both NAT 1 & 2 when queried for Hosts A or B. 727 When Host D tries to contact Host B, the working request goes 728 through NAT2, but the Router 2 default will send the reply through 729 NAT1. Since the state information for this connection is in NAT2, 730 NAT1 will provide a new mapping or fail. Even if the remote path is 731 restored, the connection will not be made because the initial 732 request was to the public IP of NAT2, while the replies are from the 733 public IP of NAT1. 735 In a third case, both Host A & B want to contact Host D, when the 736 remote link X2 in the Internet breaks. As long as the path X1 is 737 still down, Host B is able to connect, but Host A is cut off. In 738 addition, Host A is unable to contact DNS to even find the address 739 of Host D. Without a thorough understanding of the remote topology 740 (unlikely since that tends to be sensitive proprietary information), 741 the administrator of Hosts A & B would have no clue why one worked 742 and the other didn't. As far as he can tell both paths are up and 743 the redundancy is covering any local outage, but only one connection 744 works. 746 In any network topology, individual router or link failures may 747 present problems with insufficient redundancy, but the state 748 maintenance requirements of NAT present an additional burden that is 749 not as easily resolved. 751 5. Need for a globally unique FQDN 752 The primary feature of NATs is the 'simple' ability to connect 753 private networks to the public Internet. When the private network 754 exists prior to installing the NAT, it is unlikely and unnecessary 755 that its name resolver would use a registered domain. Connecting the 756 NAT device, and reconfiguring the resolver to proxy for all external 757 requests allows access to the public network by hosts on the private 758 network. Configuring the public DNS for the set of private hosts 759 that need inbound connections would require a registered domain 760 (either private, or from the connecting ISP) and a unique name. At 761 this point the partitioned name space is concatenated and hosts 762 would have different names based on inside vs. outside queries. 764 Hain Informational - Expires August 1999 15 766 Architectural Implications of NAT February 1999 767 -------- -------- 768 | Host A | | Host B | 769 | Foo |-----| Bar | 770 -------- | -------- --- 771 |-------------|DNS| 772 --- --- 773 |NAT| 774 --- 775 | 776 -------- --- 777 |Internet|----|DNS| 778 -------- --- 779 | 780 --- 781 |NAT| 782 --- --- 783 |-------------|DNS| 784 -------- | -------- --- 785 | Host C |-----| Host D | 786 | Foo | | Bar | 787 -------- -------- 789 Everything in this simple example will work until an application 790 embeds a name. For example, a Web service running on Host D might 791 present embedded URL's of the form http://bar/*.html, which would 792 work from Host C, but would thoroughly confuse Host A. If the 793 embedded name resolved to the public address, Host A would be happy, 794 but Host C would be looking for some remote machine. Using the 795 public FQDN resolution to establishing a connection from Host C to 796 D, the NAT would have to look at the destination rather than simply 797 forwarding the packet out to the router. (Normal operating mode for 798 a NAT is translate & forward out the other interface, while routers 799 do not send packets back on the same interface they came from). The 800 NAT did not create the name space fragmentation, but it facilitates 801 attempts to merge networks with independent name administrations. 803 6. Name space collisions 804 The most common installation of NAT technology is to connect the 805 existing office, or home where globally unique names were not 806 necessary, and local name resolutions may not have used DNS. The 807 private name space used in this environment may not be administered, 808 thus clients test a string to see if it is currently being used for 809 name selection. When this environment is attached to the Internet 810 through a NAT without renaming all hosts, the name spaces are 811 concatenated. 813 By facilitating concatenation of multiple name spaces, NAT 814 exaggerates a problem in the process of resolving addresses from 815 names, or names from addresses. When the public DNS is required to 816 resolve a given host name on both sides of a NAT there is no 817 obviously correct answer. In the example below it is not clear what 818 answer DNS should return for Host D. Returning the local address 819 will assure global invisibility, while returning the global address 821 Hain Informational - Expires August 1999 16 823 Architectural Implications of NAT February 1999 824 will prevent local access from Host C. If DNS were to return both, 825 the results would be unpredictable. By knowing which side the 826 request came from the DNS server could provide the correct answer, 827 but significant development would be required to add the capability 828 to DNS for source specific responses. Another option for a DNS/ALG 829 is discussed below. 831 The example below shows a potential configuration as three sites 832 deploy NAT. (note: since Host A has no access to the Internet DNS it 833 is required to maintain a local table, but the others may be 834 expecting DNS to provide the appropriate resolution.) In the case 835 where Hosts C & D share an address (either time-shared or port 836 multiplexed), there is no way Host B could know which it was 837 connecting to. DNS would return the same public side address for 838 either, then it is up to the NAT to decide where the packets are 839 eventually directed. Since Host B cannot tell, it may end up 840 connecting to a very different service than it expected for the name 841 used. For connections originating from C or D toward B, B would not 842 be able to resolve which system was really trying to connect, and 843 might inadvertently allow access to the wrong system. 845 -------- --- --- -------- 846 | Host A |--|NAT|------|NAT|--| Host B | 847 -------- --- --- -------- 848 \ \ 849 --- -------- --- 850 |NAT|---|Internet|----|DNS| 851 --- -------- --- 852 | 853 ----------------- 854 | | 855 -------- -------- 856 | Host C | | Host D | 857 -------- -------- 859 Even if forward mappings are working, implementations that require 860 an unambiguous reverse mapping from the in-addr.arpa tree will fail. 862 Discussions about an arbitrary mesh of NAT connections will 863 ultimately exaggerate the issue of name space integration with the 864 routing infrastructure. It will show that the only resolution to 865 appropriately answer name queries in a NAT environment is to locate 866 the DNS service within each NAT. One proposal to deal with locating 867 the DNS service in each NAT is the DNS/ALG [15]. Rather than running 868 the full DNS server in the NAT, it provides a mapping service by 869 intercepting DNS messages and modifying the contents appropriately. 870 This method presents a requirement that the DNS response traverse 871 the node with access to the mapping state for the final connection. 872 (note: see illustration 4 for operational failure potential of 873 finding the correct NAT.) The DNS/ALG specifically avoids discussion 874 of private nodes finding each other when the DNS server is on the 875 far side of a NAPT. While it may appear that this case would never 876 occur, it is likely that unique services are provided on individual 878 Hain Informational - Expires August 1999 17 880 Architectural Implications of NAT February 1999 881 machines, thus allowing multiple inbound connections by name that 882 map to the same IP address. For this reason, if a port type NAT is 883 used, the DNS service must be provided on the private side for 884 private resolutions. 886 7. VPNs increase frequency of collisions 887 The recent massive growth of the Internet has been driven by support 888 of low cost publication via the web. The next big push appears to be 889 support of Virtual Private Networks (VPNs). Technically VPNs treat 890 an IP infrastructure as a multiplexing substrate allowing the 891 endpoints to build what appear to be clear pathways from end-to-end. 892 VPNs redefine network visibility and increase the likelihood of 893 address collision when traversing multiple NATs. Address management 894 in the private space behind NATs will become a significant burden, 895 as there is no central body capable of, or willing to do it. The 896 lower burden for the ISP is actually a transfer of burden to the 897 local level, because administration of addresses and names becomes 898 both distributed and more complicated. 900 As noted in RFC-1918, the merging of private address spaces can 901 cause an overlap in address use, creating a problem. VPNs will 902 increase the likelihood and frequency of that merging through the 903 simplicity of their establishment. There are several configurations 904 of address overlap which will cause failure, but in the simple 905 example shown below the private use address of Host B matches the 906 private use address of the VPN pool used by Host A for inbound 907 connections. When Host B tries to establish the VPN, Host A will 908 assign it an address from its pool for inbound connections, and 909 identify the gateway for Host B to use. In the example, Host B will 910 not be able to distinguish the remote VPN address of Host A from its 911 own address, so the connection will fail. Since private use 912 addresses are by definition not publicly coordinated, as the 913 complexity of the VPN mesh increases so does the likelihood that 914 there will be a collision which cannot be resolved. 916 --------------- ---------------- 917 | Host A | --- --- | Host B | 918 | 10.10.10.10 |~~+~~~+~VPN~+~~~+~~| Assigned by A | 919 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 920 --------------- --- --- ---------------- 922 Hain Informational - Expires August 1999 18 924 Architectural Implications of NAT February 1999 925 8. Address Reuse 926 Another potential use of NAT is reusing a range of allocated 927 addresses at multiple sites within an organization. In the following 928 example, the network manager has chosen to use time-shared 929 traditional NAT, with /24 of the corporate allocation on the public 930 side at each site. To avoid publicized problems with private address 931 use, the same half of the publicly allocated address block is 932 assigned to the local DHCP service, at each site. 934 -------- -------- 935 | Host A |-----| Host B | 936 -------- | -------- 937 | 134.1.x.x /20 --- 938 |----------------|DNS| 939 --- --- 940 |NAT| 941 --- 942 | 134.1.1.x /24 943 --------- --- 944 | ISP |----|DNS| 945 --------- --- 946 | 134.1.2.x /24 947 --- 948 |NAT| 949 --- 950 | 134.1.x.x /20 --- 951 |----------------|DNS| 952 -------- | -------- --- 953 | Host C |-----| Host D | 954 -------- -------- 956 NAT used in this instance has all the same characteristics as the 957 implementations using any of the private ranges. This example shows 958 that that NAT creating address ambiguity is the source of the 959 concerns, not the use of published private address ranges. 961 Hain Informational - Expires August 1999 19 963 Architectural Implications of NAT February 1999 964 Considerations 966 IPv6 968 It has been argued that IPv6 is no longer necessary because NATs 969 relieve the address space constraints and allow the Internet to 970 continue growing. The reality is they point out the need for IPv6 971 more clearly than ever. People are trying to connect multiple 972 machines through a single access line to their ISP and have been 973 willing to give up some functionality to get that at minimum cost. 974 Frequently the reason for cost increases is the perceived scarcity 975 (therefore increased value) of IPv4 addresses, which would be 976 eliminated through deployment of IPv6. This crisis mentality is 977 creating a market for a solution to a problem already solved with 978 greater flexibility by IPv6. 980 If NAT had never been defined, the motivation to resolve the 981 dwindling IPv4 address space would be a much greater. Given that 982 NATs are enabling untold new hosts to attach to the Internet daily, 983 it is difficult to ascertain the actual impact to the lifetime of 984 IPv4, but NAT has certainly extended it. It is also difficult to 985 determine the extent of delay NAT is causing for IPv6, both by 986 relieving the pressure, and by redirecting the intellectual cycles 987 away from the longer-term solution. 989 Beyond all of the above issues, the existence of NATs will 990 complicate the integration of IPv6 in the Internet as the name space 991 and endpoint addresses attempt to become consistent and globally 992 unique. While an IPv6 node explicitly supports multiple addresses, 993 the disjoint name space described in illustration 6 will certainly 994 make management interesting. If IPv6 nodes are willing to continue 995 in private networks behind a NAT, they will only need a site local 996 address and all of the issues become the same as IPv4. If the intent 997 is to move into a public address allocation as a feature of moving 998 to IPv6, any independent name administrations will require explicit 999 effort to merge with the public DNS as well. 1001 Security 1003 NAT (particularly NAPT) may actually lower overall security because 1004 it creates the illusion of a security barrier. Appropriate security 1005 mechanisms are implemented in the end host, without reliance on 1006 assumptions about routing hacks, firewall filters, or missing NAT 1007 translations, which without notification may change over time to 1008 enable a service to a neighboring host. In general, defined security 1009 barriers assume that any threats are external, leading to lax 1010 practices making internal breaches that much easier. 1012 NATs break the defined implementation modes of IPsec [16], and 1013 therefore may stall further deployment of enhanced security across 1014 the Internet. It is difficult to identify all the combinations of 1015 header orderings and options that are possible using NATs, VPNs, and 1017 Hain Informational - Expires August 1999 20 1019 Architectural Implications of NAT February 1999 1020 IPsec. It is even more difficult to clearly state which of those are 1021 applicable, or workable in any given context. For example; 1022 - Use of AH is not possible via NAT as the hash protects the IP 1023 address in the header. 1024 - Authenticated certificates may contain the IP address as part of 1025 the subject name for authentication purposes. 1026 - Encrypted Quick Mode structures may contain IP addresses and ports 1027 for policy verifications. 1028 - The Revised Mode of public key encryption includes the peer 1029 identity in the encrypted payload. 1030 It may be possible to engineer and work around NATs for IPsec on a 1031 case-by-case basis. With all of the restrictions placed on 1032 deployment flexibility, NATs present a significant obstacle to 1033 security integration being deployed in the Internet today. 1035 As noted in the DNS/ALG draft, the DNS/ALG cannot support secure DNS 1036 name servers in the private domain. Zone transfers between DNSsec 1037 servers will be rejected when necessary modifications are attempted. 1038 It is also the case that DNS/ALG will break any modified, signed 1039 responses. This would be the case for all public side queries of 1040 private nodes, when the DNS server is on the private side. It would 1041 also be true for any private side queries for private nodes, when 1042 the DNS server is on the public side. Digitally signed records could 1043 be modified by the DNS/ALG if it had access to the source 1044 authentication key. DNSsec has been specifically designed to avoid 1045 distribution of this key, to maintain source authenticity, so NATs 1046 that use DNS/ALG to repair the namespace resolutions will either; 1047 break the security when modifying the record, or will require access 1048 to all source keys to requested resolutions. 1050 Security mechanisms that do not protect or rely on IP addresses as 1051 identifiers, such as TLS [17], SSL [18], or SSH [19] may operate in 1052 environments containing NATs. For applications that can establish 1053 and make use of this type of transport connection, NATs do not 1054 create any additional complications. These technologies may not 1055 provide sufficient protection for all applications as the header is 1056 exposed, allowing subversive acts like TCP resets. RFC-2385 [20] 1057 discusses the issues in more detail. 1059 Arguments that NAT may operate in a secure mode [21] preclude true 1060 End-to-End security, as the NAT becomes the security endpoint. 1061 Operationally the NAT must be managed as part of the security 1062 domain, and in this mode the packets on the unsecured side of the 1063 NAT are fully exposed. 1065 One of the more subtle security exposures is that created by RSIP 1066 when multiple nodes share an address. Without a means to prevent it, 1067 the probability is high that a subsequent node will choose the same 1068 port number as its neighbor. If its choice of sequence numbers is 1069 higher than the previous connection at closure, this enables the 1070 subsequent node to REOPEN a connection in TIME-WAIT. The result of 1071 this action is application dependent, but the potential security 1072 risk exists for inadvertent data access. 1074 Hain Informational - Expires August 1999 21 1076 Architectural Implications of NAT February 1999 1077 Deployment Guidelines 1079 Given that NAT devices are being deployed at a fairly rapid pace, 1080 some guidelines are in order. Most of these amount to 'think before 1081 you leap', then think again, then make sure you really want to start 1082 down this path. 1083 - Determine the mechanism for name resolution, and ensure the 1084 appropriate answer is given for each address administration. 1085 Embedding the DNS server, or a DNS ALG in the NAT device will 1086 likely be more manageable than trying to synchronize independent 1087 DNS systems across administrations. 1088 - Is the NAT configured for static one to one mappings, or will it 1089 dynamically manage them? If dynamic, make sure the TTL of the DNS 1090 responses is set to zero, and that the clients pay attention to 1091 the don't cache notification. 1092 - Will there be a single NAT device, or parallel with multiple 1093 paths? If single, consider the impact of a device failure. If 1094 multiple, consider how routing on both sides will insure the 1095 packets flow through the same box over the connection lifetime of 1096 the applications. 1097 - Examine the applications that will need to traverse the NAT and 1098 verify their immunity to address changes. Provide an appropriate 1099 ALG or establish a VPN to isolate the application from the NAT. 1100 - Determine need for public toward private connections, variability 1101 of destinations on the private side, and potential for 1102 simultaneous use of public side port numbers. NAPTs increase 1103 administration if these apply. 1104 - Determine if the applications traversing the NAPT, HNAPT, or RSIP 1105 expect all ports from the public IP address to be the same 1106 endpoint. Administrative controls to prevent simultaneous access 1107 from multiple private hosts will be required if this is the case. 1108 - If there are encrypted payloads, the contents cannot be modified 1109 unless the NAT is a security endpoint, acting as a gateway between 1110 security realms. This precludes end-to-end confidentiality, as the 1111 path between the NAT and endpoint is exposed. 1112 - Determine the path for name resolutions. If hosts on the private 1113 side of a NAPT, HNAPT, or RSIP server need visibility to each 1114 other, a private side DNS server may be required. 1115 - If the environment uses secure DNS records, a DNS/ALG will require 1116 access to the authentication keys for all translated records. 1117 - When using VPNs over NATs, identify a clearinghouse for the 1118 private side addresses to avoid collisions. 1119 - Assure that applications used both internally and externally avoid 1120 embedding names, or use globally unique ones. 1121 - When using HNAT or RSIP, recognize the scope is limited to 1122 individual private network connecting to the public Internet. If 1123 other NATs are in the path (including web-server load-balancing 1124 devices), the advantage is lost. In addition, the port 1125 multiplexing versions of these carry the same well-known-port 1126 sharing problem of NAPT. 1127 - For DNAT or RSIP, determine the probability of Time-Wait 1128 collisions when subsequent private side hosts attempt to contact a 1129 recently disconnected public side service. 1131 Hain Informational - Expires August 1999 22 1133 Architectural Implications of NAT February 1999 1135 Summary 1137 Over the 5-year period since RFC-1631, the experience base has 1138 grown, further exposing concerns raised by the original authors. NAT 1139 breaks a fundamental assumption of the Internet design; the 1140 endpoints are in control. Another design principle, 'keep-it-simple' 1141 is being overlooked as more features are added to the network to 1142 work around the complications created by NATs. In the end, overall 1143 flexibility and manageability are lowered, and support costs go up 1144 to deal with the problems introduced. 1146 Evangelists, for and against the technology, present their cases as 1147 righteous while downplaying any rebuttals. 1148 - NATs are a 'fact of life', and will proliferate as an enhancement 1149 that sustains the existing IPv4 infrastructure. 1150 - NATs are a 'necessary evil' and create an administrative burden 1151 that is not easily resolved. More significantly, they inhibit the 1152 roll out of IPsec, which will in turn slow growth of applications 1153 that require a secure infrastructure. 1154 In either case, NATs require strong applicability statements, 1155 clearly declaring what works and what does not. 1157 An overview of the pluses and minuses: 1158 NAT advantages NAT disadvantages 1159 -------------------------------- -------------------------------- 1160 Masks global address changes and Breaks end-to-end model 1161 eases renumbering 1162 Lowers address utilization Enables end-to-end address 1163 conflicts 1164 Stateful points of failure 1165 Lowers ISP support burden Increases local support burden and 1166 complexity 1167 Independent address administrations Requires source specific DNS reply 1168 avoid justifications to registries or DNS/ALG 1169 Facilitates concatenation of 1170 multiple name spaces 1171 DNS/ALG breaks DNSsec replies 1172 Breaks IPsec 1173 May allow a node to REOPEN a 1174 connection of another node when the 1175 remote end is in TCP-TIME-WAIT 1176 Transparent to end systems in some Unique ALG development for each app 1177 cases 1178 Load sharing as virtual host Performance limitations with scale 1179 Delays need for IPv4 replacement May complicate integration of IPv6 1181 There have been many discussions lately about the value of 1182 continuing with IPv6 development when the market place is widely 1183 deploying IPv4 NATs. A short sighted view would miss the point that 1184 both have a role, because NATs address some real-world issues today, 1185 while IPv6 is targeted at solving fundamental problems, as well as 1186 moving forward. It should be recognized that there will be a long 1188 Hain Informational - Expires August 1999 23 1190 Architectural Implications of NAT February 1999 1191 co-existence as applications and services develop for IPv6, while 1192 the lifetime of the existing IPv4 systems will likely be measured in 1193 decades. At their best, NATs are a diversion from forward motion, 1194 but they do enable wider participation at the present state. At 1195 their worst, they break a class of applications, which creates the 1196 need for complex work-arounds. 1198 Efforts to enhance general security in the Internet include IPsec 1199 and DNSsec. These technologies provide a variety of services to both 1200 authenticate and protect information during transit. By breaking 1201 these technologies, NAT and the DNS/ALG work-around, hinder 1202 deployment of enhanced security throughout the Internet. 1204 There have also been many questions about the probability of VPNs 1205 being established that might raise some of the listed concerns. 1206 While it is hard to predict the future, one way to avoid ALGs for 1207 each application is to establish a VPN over the NATs. This restricts 1208 the NAT visibility to the headers of the tunnel packets, and removes 1209 its effects from all applications. While this solves the ALG issues, 1210 it raises the likelihood that there will be address collisions as 1211 arbitrary connections are established between uncoordinated address 1212 spaces. It also creates a side concern about how an application 1213 establishes the necessary VPN. 1215 The original IP architecture is powerful because it provides a 1216 general mechanism on which other things (yet unimagined) may be 1217 built. While it is possible to build a house of cards, time and 1218 experience have lead to building standards with more structural 1219 integrity. IPv6 is the long-term solution that retains end-to-end 1220 transparency as a principle. NAT is a technological diversion to 1221 sustain the lifetime of IPv4. 1223 Everyone needs to focus on the goal, which is continued evolution of 1224 the Internet, and recognize continued development of IP (in all 1225 current and future versions) is the path. It has been noted that the 1226 success of the Internet is based on the 'living' characteristic of 1227 IP. As in life, when growth, evolution, and forward progress stops, 1228 decay overtakes and destroys. History has shown that protocols that 1229 were 'complete and finished' as presented, have had very short 1230 lifetimes while those still 'a work in progress' manage to survive 1231 and continue moving ahead. All parties need to understand the 1232 significant role they are playing in pursuing the goal, and that 1233 none can get there without all the others. 1235 Hain Informational - Expires August 1999 24 1237 Architectural Implications of NAT February 1999 1238 References 1240 1 RFC-2026 Bradner, S., " The Internet Standards Process -- 1241 Revision 3", BCP 9, October 1996. 1243 2 RFC-1631 Egevang, K., Francis, P., "The IP Network Address 1244 Translator", May 1994 1246 3 RFC-1918, Rekhter, et al, "Address Allocation for Private 1247 Internets", February 1996 1249 4 RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", 1250 February 1997 1252 5 draft-ietf-nat-hnat-00.txt, Jeffrey LoCategory, K.Taniguchi, "IP 1253 Host Network Address (and Port) Translation", November 1998 1255 6 draft-ietf-nat-rsip-protocol-00.txt, M. Borella, D. Grabelsky, 1256 J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification", 1257 February 1999 1259 7 draft-ietf-nat-terminology-01.txt, P. Srisuresh, Matt Holdrege, 1260 "IP Network Address Translator (NAT) Terminology and 1261 Considerations", October 1998 1263 8 draft-carpenter-transparency-01.txt, B. Carpenter, "Internet 1264 Transparency", April 1999 1266 9 draft-ietf-nat-traditional-01.txt P. Srisuresh, K. Egevang, 1267 "Traditional IP Network Address Translator", October 1998 1269 10 RFC-2391, P. Srisuresh, D. Gan, "Load Sharing using IP Network 1270 Address Translation", August 1998 1272 11 RFC-793, J. Postel, "Transmission Control Protocol", September 1273 1981 1275 12 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for 1276 High-Speed Paths", October 1990 1278 13 RFC-1323, V. Jacobson, R. Braden, D. Borman, " TCP Extensions for 1279 High Performance", May 1992 (Appendix B.2) 1281 14 RFC 1122, R. Braden, "Requirements for Internet Hosts", October 1282 1989 1284 15 draft-ietf-nat-dns-alg-01.txt, P. Srisuresh, G. Tsirtsis, P. 1285 Akkiraju, A. Heffernan "DNS extensions to Network Address 1286 Translators", October 1998 1288 16 RFC 2401, S. Kent, R. Atkinson, "Security Architecture for the 1289 Internet Protocol", November 1998 1291 Hain Informational - Expires August 1999 25 1293 Architectural Implications of NAT February 1999 1295 17 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS 1296 Protocol", November 1997 1298 18 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 1300 19 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH 1301 Protocol Architecture", August 1998 1303 20 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP 1304 MD5 Signature Option", August 1998 1306 21 draft-ietf-nat-security-01.txt, P. Srisuresh, "Security Model for 1307 Network Address Translator", February 1999 1309 Acknowledgments 1310 Valuable contributions to this draft came from the IAB, Vern Paxson 1311 (lbl), Keith Moore (utk), Thomas Narten (ibm), Matt Holdrege 1312 (Ascend), Pyda Srisuresh (lucent), Yakov Rekhter(cisco), and Eliot 1313 Lear (cisco). 1315 Author's Addresses 1316 Tony Hain 1317 Microsoft 1318 One Microsoft Way Phone: 1-425-703-6619 1319 Redmond, Wa. USA Email: tonyhain@microsoft.com 1321 Copyright 1322 "Copyright (C) The Internet Society (date). All Rights Reserved. 1323 This document and translations of it may be copied and furnished to 1324 others, and derivative works that comment on or otherwise explain it 1325 or assist in its implementation may be prepared, copied, published 1326 and distributed, in whole or in part, without restriction of any 1327 kind, provided that the above copyright notice and this paragraph 1328 are included on all such copies and derivative works. However, this 1329 document itself may not be modified in any way, such as by removing 1330 the copyright notice or references to the Internet Society or other 1331 Internet organizations, except as needed for the purpose of 1332 developing Internet standards in which case the procedures for 1333 copyrights defined in the Internet Standards process must be 1334 followed, or as required to translate it into languages other than 1335 English. The limited permissions granted above are perpetual and 1336 will not be revoked by the Internet Society or its successors or 1337 assigns. This document and the information contained herein is 1338 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1339 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1340 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1341 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1344 Hain Informational - Expires August 1999 26