idnits 2.17.1 draft-iab-nat-implications-03.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. 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 (February 1999) is 9202 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 57 looks like a reference -- Missing reference section? '3' on line 110 looks like a reference -- Missing reference section? '4' on line 111 looks like a reference -- Missing reference section? '5' on line 138 looks like a reference -- Missing reference section? '6' on line 138 looks like a reference -- Missing reference section? '7' on line 209 looks like a reference -- Missing reference section? '8' on line 371 looks like a reference -- Missing reference section? '9' on line 372 looks like a reference -- Missing reference section? '10' on line 578 looks like a reference -- Missing reference section? '11' on line 787 looks like a reference -- Missing reference section? '12' on line 787 looks like a reference -- Missing reference section? '13' on line 787 looks like a reference -- Missing reference section? '14' on line 792 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 17 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-03.txt February 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 Table of Contents 38 Abstract ............................................................1 39 Definitions .........................................................4 40 Terminology ........................................................4 41 Advantages of NATs ..................................................7 42 Disadvantages of NATs ...............................................8 43 Illustrations ......................................................10 44 Considerations .....................................................16 45 IPv6 ..............................................................16 46 Security ..........................................................16 47 Deployment Guidelines .............................................18 48 Summary ............................................................19 49 References .........................................................21 50 Acknowledgments ...................................................22 51 Author's Addresses ................................................22 52 Copyright .........................................................22 54 Hain Informational - Expires August 1999 1 55 Introduction 57 In May 1994, K. Egevang and P. Francis RFC-1631 [2] defined NAT as 58 one means to ease the growth rate of IPv4 address use. Several 59 places in the document they recognized the need to experiment and 60 see what applications may be adversely affected by NAT's header 61 manipulations, even before there was any significant operational 62 experience. This is further evidenced in a quote from the 63 conclusions: 'NAT has several negative characteristics that make it 64 inappropriate as a long term solution, and may make it inappropriate 65 even as a short term solution.' 67 Nearly five years later, we find arguments that NAT is 'THE' short 68 *AND* long-term solution, while questioning the strategy or 69 continued effort at developing IPv6 as a replacement protocol. At 70 the same time, the artificial shortage of IPv4 addresses, caused by 71 the current stringent allocation guidelines, creates a perceived 72 need to promote private address use via NAT. This increase in 73 popularity of private addresses has resulted in additional 74 experience, further exposing NAT's shortcomings. Unfortunately even 75 as the failings of NAT are exposed, the technology is widely 76 promoted as if it 'just works' with no serious effects except on a 77 few legacy applications. 79 The arguments pro & con frequently take on religious tones, with 80 each side passionate about its position. 81 - Proponents bring enthusiasm and frequently cite the most popular 82 applications of Mail & Web services as shining examples of their 83 cause. They will also point out that NAT is the feature that 84 finally breaks the semantic overload of the IP address as both a 85 locator and the global endpoint identifier (EID). 86 - The opposing view of NAT is that of a malicious technology, where 87 there is a concern that NAT is the weed which is destined to choke 88 out continued Internet development. While recognizing there are 89 perceived address shortages, the opponents of NAT view it as 90 operationally inadequate at best, bordering on a sham as an 91 Internet access solution. 93 With reality somewhere in between these extreme viewpoints, it is 94 clear NAT affects the transparency of end-to-end connectivity for 95 transports relying on consistency of the IP header. Using a 96 patchwork of mutually configured application specific gateways 97 (ALG's), endpoints can work around some of the operational 98 challenges of NAT. When there are two endpoints in a conversation 99 this effort is straightforward, but for applications with more 100 distributed and multi-point expectations it can be a significant 101 ordeal. The complexity of coordinating the updates necessary to work 102 around NAT grows geometrically with the number of endpoints. In a 103 large environment, this may require concerted effort to 104 simultaneously upgrade all endpoints of a given application or 105 service. 107 Hain Informational - Expires August 1999 2 108 The architectural role of NAT is to divide the Internet into 109 independent address administrations, specifically facilitating 110 casual use of private address assignments RFC-1918 [3]. As noted by 111 Carpenter, et al RFC-2101 [4], once private use addresses were 112 deployed in the network, addresses were guaranteed to be ambiguous. 113 At the same time when NATs are attached to the network, the process 114 of resolving names to or from addresses gains a dependency on where 115 the question was asked. As NAT concatenates existing stand-alone 116 name spaces, both names and addresses become globally ambiguous. 118 A significant factor in the success of the Internet is the 119 flexibility derived from a few basic tenets. Foremost is the End-to- 120 End principle, which assumes the endpoints are in control of the 121 communication and the network simply moves bits between these 122 points. Restated, the data stream delivered by the transport 123 protocol of the endpoints is of no concern to the lower layer packet 124 routing devices, and therefore may contain anything the endpoint 125 applications consider appropriate. (Note: while firewalls also break 126 the end-to-end model, they are installed with the explicit intent to 127 prevent access, where NAT claims to be transparent.) Another is that 128 the network does not maintain per connection state information, 129 which allows fast rerouting around failures through alternate paths. 130 Lack of state also removes any requirement for the network nodes to 131 notify each other as endpoint connections are formed or dropped. 132 Furthermore, the endpoints are not, and need not be, aware of any 133 network components other than the first hop router(s), name 134 resolution service, and destination. Packet integrity is preserved 135 through the network, and transport checksums are valid end-to-end. 136 NATs (particularly the NAPT variety) break most of these, reducing 137 overall flexibility, while increasing operational complexity and 138 impeding diagnostic capabilities. The HNAT [5] and RSIP [6] 139 variants have recently been proposed to address the end-to-end 140 concerns. While they may be effective at providing the private node 141 with a public address (if ports are available), they do not deal 142 with the issues of; network state management, upper layer 143 constraints like TCP TIME_WAIT state, or well-known-port sharing. 144 Their port multiplexing variants also share the same neighbor DNS 145 visibility concerns of NAPT, and each host requires significant 146 stack modifications to enable the technology. 148 Hain Informational - Expires August 1999 3 149 Definitions 151 Terminology 153 NAT - Network Address Translation in simple form is a method by 154 which IP addresses are mapped from one address administration to 155 another. 157 ALG/NAT - combines ALG functions with simple NAT. Generally more 158 useful than pure NAT, because it embeds a work around to specific 159 applications that NAT breaks. 161 DNS/ALG - special case of ALG/NAT, where an ALG for the DNS service 162 interacts with the NAT component to manage DNS response contents. 164 Static NAT - provides stable one-to-one mapping between address 165 spaces. 167 Dynamic NAT - provides many-to-few mapping from a relatively large 168 number of addresses on one side to a few addresses on the other. 170 NAPT - Network Address Port Translation accomplishes translation by 171 multiplexing transport level identifiers of multiple addresses from 172 one side, simultaneously into the transport identifiers of a single 173 address on the other. 175 HNAT - Host NAT allows endpoints to acquire and use their public 176 address and port number at the source. The public / private process 177 only allocates public addresses and forwards unmodified packets. 178 This approach requires significant changes to the host stack 179 implementation to dynamically manage tunnels to the HNAT server. 181 RSIP - Realm Specific IP is a generalization of HNAT, including 182 mechanisms for the private node to request multiple resources at 183 once. This has the same requirement to modify Hosts as HNAT. 185 ALG - Application Gateway is inserted between application peers to 186 simulate a direct connection, when some intervening protocol or 187 device prevents direct access. It terminates the transport protocol, 188 and may modify the data stream before forwarding. 190 Firewall - Special case of an ALG or routing filter, which 191 implements access controls. 193 Proxy - Special case of an ALG that is a simple relay service 194 designed into a protocol, rather than capriciously inserted. 196 VPN - Virtual Private Networks technically treat an IP 197 infrastructure as a multiplexing substrate, allowing the endpoints 198 to build virtual transit pathways, over which they run another 199 instance of IP. 201 Hain Informational - Expires August 1999 4 202 Address administration - coordinator of an address pool assigned to 203 a collection of routers and end systems. 205 Routing realm - collection of routers and end systems exchanging 206 locally unique location knowledge (potentially in a hierarchical 207 arrangement). 208 NAT proponents define the NAT function as providing routing 209 realms [7], where each domain is responsible for finding 210 addresses within its boundaries. This work-around to the 211 limitations NAT creates, hides them behind the well-understood 212 need for routing management. Compartmentalization of routing 213 information is really a function of routing protocols and their 214 scope of application. NAT is simply a means to distribute address 215 allocation authority and provide a mechanism to map one 216 administrations addresses into those of another administration. 217 The fact that experienced operators limit network topology, and 218 don't leak addresses across a NAT, does not mean NAT itself 219 provides any routing isolation services. In fact, if someone were 220 to define an OSPF ALG it would be technically possible to route 221 across a NAT boundary. Using a routing ALG, in combination with 222 the fact that NAT breaks IPsec, could allow a private network to 223 enforce which endpoints are even capable of attempting secure 224 access while allowing non-secure access to other services. 226 Hain Informational - Expires August 1999 5 227 Scope 229 RFC-1631 limited the scope of NAT discussions to stub appendages of 230 a public Internet. Therefore, in discussing the architectural impact 231 of NATs on the Internet, the first task is defining the scope of the 232 Internet. The most basic definition is; a concatenation of networks 233 built using IETF defined technologies. This simple description does 234 not distinguish between the public network known as the Internet, 235 and the private networks built using the same technologies 236 (including those connected via NAT). An approach resolving this 237 would be including the resources of Names or Addresses administered 238 through IANA or its delegates. While this is more accurate, it still 239 includes many private networks that have coordinated their names or 240 addresses with the public Internet. Rekhter, et al RFC-1918 defined 241 hosts as public when they need network layer access outside the 242 enterprise, using a globally unambiguous address. Those that need 243 limited or no access are defined as private. Another way to view 244 this is the transparency of the connection between any given node 245 and the rest of the Internet. 247 The ultimate resolution of public or private is found in the intent 248 of the network in question. Generally, networks that do not intend 249 to be part of the greater Internet will use some screening 250 technology to insert a barrier. Historically barrier devices between 251 the public and private networks were known as Firewalls or 252 Application Gateways, and were managed to allow approved traffic 253 while blocking everything else. Increasingly the screening 254 technology is becoming a simple NAT, which manages the network 255 locator between the public and private-use address spaces, and then 256 using ALGs attempts to be transparent to protocols incompatible with 257 NAT. (Use of NAT within a private network is possible, and is only 258 addressed here in the context that some component of the private 259 network is used as a common transit service between the NAT attached 260 stubs.) The primary distinction between a Firewall and NAT in this 261 context is the intent to block, or facilitate traffic flow. 263 Hain Informational - Expires August 1999 6 264 Advantages of NATs 266 A quick look at the popularity of NAT as a technology shows that it 267 tackles several real world problems. 269 - Masking the address changes that take place, from either dial- 270 access or provider changes, minimizes impact on the local network 271 by avoiding renumbering. 272 - Globally routable addresses can be reused for intermittent access 273 customers. This lowers the demand and utilization of addresses to 274 the number of active nodes rather than the total number of nodes. 275 - There is a potential that ISP provided and managed NATs would 276 lower support burden since there could be a consistent, simple 277 device with a known configuration at the customer end of the 278 access interface. 279 - Breaking the Internet into a collection of address authorities 280 limits the need for continual justification of allocations. 281 - For applications that don't rely on the integrity of the packet 282 header, changes in the hosts may not be necessary. 283 - Like route filtering Firewalls, NAPT, HNAPT, & RSIP block inbound 284 connections to all ports until they are administratively mapped. 286 Taken together these explain some of the strong motivations for 287 moving quickly with NAT deployment. 289 Removing hosts that are not currently active, lowers address demands 290 of the public Internet. In cases where providers would end up with 291 address allocations that could not be aggregated, this improves the 292 load on the routing system as well as lengthens the lifetime of the 293 IPv4 address space. While removing idle addresses is a natural 294 byproduct of the existing dynamic allocation, dial-access devices, 295 in the dedicated connection case this service could be provided 296 through a NAT. In the case of a NAPT, the aggregation potential is 297 even greater as multiple end systems share a single public address. 299 By reducing the options and minimizing the potential support matrix, 300 there is a potential that ISP provided NATs would lower support 301 costs. (These savings may be more than offset by the additional 302 support costs created when NAT breaks various applications.) 304 Part of the motivation here is to avoid the high cost of renumbering 305 inherent in the current IPv4 Internet. Localizing address 306 administration minimizes those costs, and simultaneously provides 307 for a much larger local pool of addresses than is available under 308 current allocation guidelines. (The registry guidelines are intended 309 to prolong the lifetime of the IPv4 address space until IPv6 is 310 ready, by managing allocations to match actual demand. They may end 311 up hampering growth in areas where it is difficult to sort out real 312 need from potential hoarding.) Until IPv6 provides a simpler 313 solution, NAT is effective at masking provider switching or other 314 requirements to change addresses. 316 Hain Informational - Expires August 1999 7 317 NAT deployments have been raising the awareness of protocol 318 designers who are interested in ensuring that their protocols work 319 end-to-end. Breaking the semantic overload of the IP address will 320 force applications to find a more appropriate mechanism for endpoint 321 identification and discourage carrying the locator in the data 322 stream. Since this will not work for legacy applications, RFC-1631 323 discusses how to look into the packet and make NAT transparent to 324 the application (ie: create an application gateway). This may not be 325 possible for all applications, and even with application gateways in 326 the path, it may be necessary to modify the end host to be aware 327 there may be intermediaries modifying the data. 329 Another popular practice is hiding a collection of hosts that 330 provide a combined service behind a single IP address (ie: web host 331 load sharing). In many implementations this is architecturally a 332 NAT, since the addresses are mapped to the real destination on the 333 fly. When packet header integrity is not an issue, this type of 334 virtual host requires no modifications to the remote applications 335 since the end client is unaware of the mapping activity. While the 336 virtual host has the CPU performance characteristics of the total 337 set of machines, the overall performance is bounded by the 338 processing and I/O capabilities of the NAT device as it funnels the 339 packets back and forth. 341 Disadvantages of NATs 343 - NATs break the flexible end-to-end model of the Internet. 344 - NATs create a single point where fates are shared, in the device 345 maintaining connection state and dynamic mapping information. 346 - NATs inhibit implementation of security at the IP level. 347 - NATs facilitate concatenating existing name spaces with the DNS. 348 - NATs enable address collisions when VPNs traverse multiple NATs 349 along a path. 350 - NAPT, HNAPT, & RSIP increase operational complexity when published 351 services reside on the private side. This includes the restriction 352 that only one private side system can be accessed through a given 353 public side well-known-port. 355 As noted earlier, NATs break the basic tenet of the Internet that 356 the endpoints are in control of the communication. The original 357 design put state control in the endpoints so there would be no other 358 inherent points of failure. Moving the state from the endpoints to 359 specific nodes in the network reduces flexibility, while it 360 increases the impact of a single point failure. 362 In addition, NATs are not transparent to all applications, and 363 managing simultaneous updates to a large array of ALGs may exceed 364 the cost of acquiring additional globally routable addresses. While 365 RSIP addresses the transparency and ALG issues, for the specific 366 case of individual private to public, there is still a node with 367 specific state required to maintain the connection. 369 Hain Informational - Expires August 1999 8 370 Dynamic NAT, HNAT, and RSIP will eventually violate higher layer 371 assumptions about address/port number reuse RFC-793 [8] RFC-1185 372 [9]. The TCP state, TIME_WAIT, is specifically designed to prevent 373 replay of packets between the 4-tuple of IP & port for a given IP 374 address pair. Since the TCP state machine of a second private side 375 node is unaware of any previous use, its attempts to connect to the 376 same service as its neighbor, which is still in TIME_WAIT, will 377 fail. The full range of upper layer architectural assumptions that 378 are broken by NAT technologies may not be well understood without a 379 very large-scale deployment. 381 One of the greatest concerns from the explosion of NATs is the 382 impact on the fledgling efforts at deploying IP security. One 383 fundamental issue for IPSec is that with both AH and ESP, the 384 authentication check covers the TCP/UDP checksum (which in turn 385 covers the IP address). When a NAT changes the IP address, the 386 checksum calculation will fail, and therefore authentication will 387 fail. This combination of required global uniqueness of the address, 388 and assured ambiguity by NAT leaves the IPsec effort without a 389 workable solution. 391 In a statement about the use of IPv4 today, RFC-2101 details 392 architectural issues and notes: 393 "... it has been considered more useful to deliver the packet, 394 then worry about how to identify the endpoints, than to provide 395 identity in a packet that cannot be delivered." 396 This argument presumes that delivering the packet has an inherent 397 value, even if the endpoints cannot be identified. In a self- 398 fulfillment of that prophecy, many applications developed to date 399 are structured to assume packets will be delivered and identity is 400 only assured in controlled environments. 402 In another note from RFC-2101: 403 "Since IP Security authentication headers assume that the 404 addresses in the network header are preserved end-to-end, it is 405 not clear how one could support IP Security-based authentication 406 between a pair of hosts communicating through either an ALG (ed: 407 Application Level Gateway) or a NAT." 408 There are distributed applications that assume that IP addresses are 409 globally scoped, globally unique, globally routable, and all hosts 410 have the same view of those addresses. NATs break these 411 applications. There are other applications that assume that all 412 upper layer ports from a given IP address map to the same endpoint, 413 and port multiplexing technologies like NAPT, HNAPT, and RSIP breaks 414 those. 416 NATs place constraints on the deployment of applications that carry 417 IP addresses (or derivatives), in the data stream. Applications or 418 protocols that assume end-to-end integrity of the address will fail 419 when traversing a NAT. (TCP was specifically designed to take 420 advantage of, and reuse the IP address for use as a transport 421 address.) To resolve this, an Application Level Gateway needs to 423 Hain Informational - Expires August 1999 9 424 exist within each NAT. An additional gateway service is necessary 425 for each application that may imbed an address. Even this approach 426 will fail when requirement is end-to-end encryption since only the 427 endpoints have access to the keys. 429 Finally, while the port multiplexing variants of NAT (popular 430 because they allow Internet access through a single address) work 431 modestly well for connecting private hosts to public services, they 432 create management problems for applications connecting from public 433 toward private. The concept of a well-known-port is undermined 434 because only one private side system can be mapped through the 435 single public-side port number. This will affect home networks, when 436 applications like multi-player Internet games can only be played on 437 one system at a time. It will also affect small businesses when only 438 one system at a time can be operated on the standard port to provide 439 web services. The issue is that the public toward private usage 440 requires administrative mapping for each target prior to connection. 442 Illustrations 444 A feature of stateful devices like NATs is the creation of a single 445 point of failure. Attempts to avoid this by establishing redundant 446 NATs, creates a new set of problems related to timely communication 447 of the state, and routing related failures. This encompasses several 448 issues such as update frequency, performance impact of frequent 449 updates, reliability of the state update transaction, a-priori 450 knowledge of all nodes needing this state information, and 451 notification to end nodes of alternatives. (This last point could be 452 accomplished with a routing protocol, which might require 453 modifications to the hosts so they will listen.) 455 It has been observed that operational management of networks 456 incorporating stateful packet modifying device is considerably 457 easier if inbound and outbound packets traverse the same path. While 458 easy to say, it is difficult to manage using a connectionless 459 protocol, even with careful planning. The problem is ensuring that 460 routes advertised to the private side reach the end nodes and map to 461 the same device as the public side route advertisements. This state 462 needs to persist throughout the lifetime of sessions traversing the 463 NAT. A point to bear in mind is the frequency of simultaneous 464 internal and external topology churn. Consider the following case 465 where the -X- links are broken, or flapping. 467 Hain Informational - Expires August 1999 10 468 -------- -------- 469 | Host A | | Host B | 470 | Foo | | Bar | 471 -------- -------- 472 | | 473 ---- ---- 474 |Rtr1|---X----|Rtr2| 475 ---- ---- 476 | | 477 ---- ---- 478 |NAT1| |NAT2| 479 ---- ---- 480 | | 481 -------------- 482 |Rtr Rtr| 483 | / Internet \ | --- 484 |Rtr----X----Rtr|----|DNS| 485 -------------- --- 486 | | 487 | | 488 -------- -------- 489 | Host C | | Host D | 490 -------- -------- 492 To maintain sanity with external routing, the default path for 493 Routers 1 & 2 is via NAT1. When the path between Router 1 & 2 494 breaks, Router 2 would attempt to switch to NAT2, but the external 495 return path would still be through NAT1. In this case, redundancy 496 was useless. While this scenario is strictly a routing failure, the 497 normal routing tools for resolving it are not available because the 498 connection to the Internet is via NATs. 500 Consider the case that the path between Router 1 & 2 is up, and some 501 remote link in the network is down. When Host D tries to contact 502 Host B, the request goes through NAT2, but the reply is through 503 NAT1. Since the state information for this connection is in NAT2, 504 NAT1 will provide a new mapping. Even if the remote path is 505 restored, the connection will not be made because the requests are 506 to the public IP of NAT2, while the replies are from the public IP 507 of NAT1. 509 In another case, both Host A & B want to contact Host D, when some 510 remote link in the Internet breaks. As long as the path between 511 Router 1 & 2 is still down, Host B is able to connect, but Host A is 512 cut off. In addition, Host A is unable to contact DNS to even find 513 the address of Host D. Without a thorough understanding of the 514 remote topology (unlikely since that tends to be sensitive 515 proprietary information), the administrator of Hosts A & B would 516 have no clue why one worked and the other didn't. As far as he can 517 tell both paths are up and the redundancy is covering the local 518 outage, but only one connection works. 520 Hain Informational - Expires August 1999 11 521 In any network topology, individual router or link failures may 522 present problems with insufficient redundancy, but the state 523 maintenance requirements of NAT present an additional burden that is 524 not as easily resolved. 526 By facilitating concatenation of multiple name spaces, NAT 527 exaggerates a problem in the process of resolving addresses from 528 names, or names from addresses. (This occurs when an existing stand- 529 alone site attaches to the Internet through a NAT, without renaming 530 all hosts.) When the public DNS is required to resolve a given host 531 name on both sides of a NAT there is no obviously correct answer. In 532 the example below it is not clear what answer DNS should return for 533 Host D. Returning the local address will assure global 534 invisibility, while returning the global address will prevent local 535 access from Host C. If DNS were to return both, the results would be 536 unpredictable. By knowing which side the request came from the DNS 537 server could provide the correct answer, but significant development 538 would be required to add the capability to DNS for source specific 539 responses. (note: since Host A has no access to the Internet 540 (therefore the DNS service), it is required to maintain a local 541 table, but the others may be expecting DNS to provide the 542 appropriate resolution.) In the case where Hosts C & D share an 543 address (either time-shared or port multiplexed), there is no way 544 Host B could know which it was connecting to. DNS would return a 545 public side address for either, then it is up to the NAT to decide 546 where the packets are eventually directed. Since Host B cannot tell, 547 it may end up connecting to a very different service than it 548 expected for the name used. (This would also be true for connections 549 from C or D to the other.) For connections originating from C or D 550 toward B, B would not be able to resolve which system was really 551 trying to connect, and might inadvertently allow access to the wrong 552 system. 554 -------- --- --- -------- 555 | Host A |--|NAT|------|NAT|--| Host B | 556 -------- --- --- -------- 557 \ \ 558 --- -------- --- 559 |NAT|---|Internet|----|DNS| 560 --- -------- --- 561 | 562 ----------------- 563 | | 564 -------- -------- 565 | Host C | | Host D | 566 -------- -------- 568 Even if forward mappings are working, implementations that require 569 an unambiguous reverse mapping from the in-addr.arpa tree will fail. 571 Discussions about an arbitrary mesh of NAT connections will 572 ultimately exaggerate the issue of name space integration with the 573 routing infrastructure. It will show that the only resolution to 575 Hain Informational - Expires August 1999 12 576 appropriately answer name queries in a NAT environment is to locate 577 the DNS service within each NAT. One proposal to deal with locating 578 the DNS service in each NAT is the DNS/ALG [10]. Rather than running 579 the full DNS server in the NAT, it provides a mapping service by 580 intercepting DNS messages and modifying the contents appropriately. 581 This method presents a requirement that the DNS response traverse 582 the node with the mapping state for the final connection. Note the 583 first example for operational failure potential of finding the 584 correct NAT. DNS/ALG specifically avoids discussion of private nodes 585 finding each other when the DNS server is on the far side of a NAPT. 587 The primary feature of NATs is the 'simple' ability to connect 588 private networks to the public Internet. When the private network 589 exists prior to installing the NAT, it is unlikely and unnecessary 590 that its name resolver would use a registered domain. Connecting the 591 NAT device, and reconfiguring the resolver to proxy for all external 592 requests allows access to the public network by hosts on the private 593 network. Configuring the public DNS for the set of private hosts 594 that need inbound connections would require a registered domain 595 (either private, or from the connecting ISP) and a unique name. At 596 this point the partitioned name space is concatenated and hosts 597 would have different names based on inside vs. outside queries. 599 -------- -------- 600 | Host A | | Host B | 601 | Foo |-----| Bar | 602 -------- | -------- --- 603 |-------------|DNS| 604 --- --- 605 |NAT| 606 --- 607 | 608 -------- --- 609 |Internet|----|DNS| 610 -------- --- 611 | 612 --- 613 |NAT| 614 --- --- 615 |-------------|DNS| 616 -------- | -------- --- 617 | Host C |-----| Host D | 618 | Foo | | Bar | 619 -------- -------- 621 Everything in this simple example will work until an application 622 embeds a name. For example, a Web service running on Host D might 623 present embedded URL's of the form http://bar/*.html, which would 624 work from Host C, but would thoroughly confuse Host A. If the 625 embedded name resolved to the public address, Host A would be happy, 626 but Host C would be looking for some remote machine. Using the 627 public FQDN resolution to establishing a connection from Host C to 628 D, the NAT would have to look at the destination rather than simply 630 Hain Informational - Expires August 1999 13 631 forwarding the packet out to the router. (Normal operating mode for 632 a NAT is translate & forward out the other interface, while routers 633 do not send packets back on the same interface they came from). The 634 NAT did not create the name space fragmentation, but it facilitates 635 attempts to merge networks with independent name administrations. 637 The recent mass growth of the Internet has been driven by support of 638 low cost publication via the web. The next big push appears to be 639 support of Virtual Private Networks (VPNs). Technically VPNs treat 640 an IP infrastructure as a multiplexing substrate allowing the 641 endpoints to build what appear to be clear pathways from end-to-end. 642 VPNs redefine network visibility and increase the likelihood of 643 address collision when traversing multiple NATs. Address management 644 in the private space behind NATs will become a significant burden, 645 as there is no central body capable of, or willing to do it. The 646 lower burden for the ISP is actually a transfer of burden to the 647 local level, because administration of addresses and names becomes 648 both distributed and more complicated. 650 As noted in RFC-1918, the merging of private address spaces can 651 cause an overlap in address use, creating a problem. VPNs will 652 increase the likelihood and frequency of that merging through the 653 simplicity of their establishment. There are several configurations 654 of address overlap which will cause failure, but in the simple 655 example shown below the private use address of Host B matches the 656 private use address of the VPN pool used by Host A for inbound 657 connections. When Host B tries to establish the VPN, Host A will 658 assign it an address from its pool for inbound connections, and 659 identify the gateway for Host B to use. In the example, Host B will 660 not be able to distinguish the remote VPN address of Host A from its 661 own address, so the connection will fail. Since private use 662 addresses are by definition not publicly coordinated, as the 663 complexity of the VPN mesh increases so does the likelihood that 664 there will be a collision which cannot be resolved. 666 --------------- ---------------- 667 | 10.10.10.10 |--------VPN--------| Assigned by A | 668 | Host A | --- --- | Host B | 669 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 670 --------------- --- --- ---------------- 672 Hain Informational - Expires August 1999 14 673 Another potential use of NAT is reusing a range of allocated 674 addresses at multiple sites within an organization. In the following 675 example, the network manager has chosen to use time-shared 676 traditional NAT, with /8 of the corporate allocation on the public 677 side at each site. To avoid any problems with private addresses, the 678 upper half of the publicly allocated address block is assigned to 679 the local DHCP service, at each site. 681 -------- -------- 682 | Host A |-----| Host B | 683 -------- | -------- 684 | 1.1.128.x /15 --- 685 |----------------|DNS| 686 --- --- 687 |NAT| 688 --- 689 | 1.1.2.x /8 690 -------- --- 691 | ISP |----|DNS| 692 -------- --- 693 | 1.1.3.x /8 694 --- 695 |NAT| 696 --- 697 | 1.1.128.x /15 --- 698 |----------------|DNS| 699 -------- | -------- --- 700 | Host C |-----| Host D | 701 -------- -------- 703 While the addresses used are from publicly assigned space, the NAT 704 in the path puts them in the same class as private allocations. NAT 705 used in this instance has all the same characteristics as the 706 implementations using any of the private ranges. This example shows 707 that that NAT is the source of the concerns, not the use of private 708 addresses. 710 Hain Informational - Expires August 1999 15 711 Considerations 713 IPv6 715 It has been argued that IPv6 is no longer necessary because NATs 716 relieve the address space constraints and allow the Internet to 717 continue growing. The reality is they point out the need for IPv6 718 more clearly than ever. People are trying to connect multiple 719 machines through a single access line to their ISP and have been 720 willing to give up some functionality to get that at minimum cost. 721 Frequently the reason for cost increases is the perceived scarcity 722 (therefore increased value) of IPv4 addresses, which would be 723 eliminated through deployment of IPv6. This crisis mentality is 724 creating a market for a solution to a problem already solved with 725 greater flexibility by IPv6. 727 Beyond all of the above issues, the existence of NATs will 728 complicate the integration of IPv6 in the Internet as the name space 729 and endpoint addresses attempt to become consistent and globally 730 unique. While multiple addresses are explicitly supported by an IPv6 731 node, the disjoint name space will certainly make management 732 interesting. If IPv6 nodes are willing to continue in private 733 networks behind a NAT, they will only need a site local address and 734 all of the issues become the same as IPv4. If the intent is to move 735 into a public address allocation as a feature of moving to IPv6, any 736 independent name administrations will require explicit effort to 737 merge with the public DNS as well. 739 Security 741 NAT (particularly NAPT) lowers overall security because it creates 742 the illusion of a security barrier. Appropriate security mechanisms 743 are implemented in the end host, without reliance on assumptions 744 about routing hacks, firewall filters, or missing NAT translations, 745 which may change over time to enable a service to a neighboring 746 host. In general, defined security barriers assume that any threats 747 are external, leading to practices which make internal breaches that 748 much easier. 750 NATs break the defined implementation modes of IPsec, and therefore 751 may stall further deployment of enhanced security across the 752 Internet. It is difficult to identify all the combinations of header 753 orderings and options that are possible using NATs, VPNs, and IPsec. 754 It is even more difficult to clearly state which of those are 755 applicable, or workable in any given context. For example; 756 - Use of AH is not possible via NAT as the hash protects the IP 757 address in the header. 758 - Authenticated certificates may contain the IP address as part of 759 the subject name for authentication purposes. 760 - Encrypted Quick Mode structures may contain IP addresses and ports 761 for policy verifications. 763 Hain Informational - Expires August 1999 16 764 - The Revised Mode of public key encryption includes the peer 765 identity in the encrypted payload. 766 It may be possible to engineer and work around NATs for IPsec on a 767 case by case basis. With all of the restrictions placed on 768 deployment flexibility, NATs present a significant obstacle to 769 security integration being deployed in the Internet today. 771 As noted in the DNS/ALG draft, the DNS/ALG cannot support secure DNS 772 name servers in the private domain. Zone transfers between DNSsec 773 servers will be rejected when necessary modifications are attempted. 774 It is also the case that DNS/ALG will break any modified, signed 775 responses. This would be the case for all public side queries of 776 private nodes, when the DNS server is on the private side. It would 777 also be true for any private side queries for private nodes, when 778 the DNS server is on the public side. Digitally signed records could 779 be modified by the DNS/ALG if it had access to the source 780 authentication key. DNSsec has been specifically designed to avoid 781 distribution of this key, to maintain source authenticity. So NATs 782 that use DNS/ALG to repair the namespace resolutions will either; 783 break the security when modifying the record, or will require access 784 to all source keys to requested resolutions. 786 Security mechanisms that do not protect or rely on IP addresses as 787 identifiers, such as TLS [11], SSL [12], or SSH [13] may operate in 788 environments containing NATs. For applications that can establish 789 and make use of this type of transport connection, NATs do not 790 create any additional complications. These technologies may not 791 provide sufficient protection for all applications as the header is 792 exposed, allowing subversive acts like TCP resets. RFC-2385 [14] 793 discusses the issues in more detail. 795 Hain Informational - Expires August 1999 17 796 Deployment Guidelines 798 Given that NAT devices are being deployed at a fairly rapid pace, 799 some guidelines are in order. Most of these amount to 'think before 800 you leap', then think again, then make sure you really want to start 801 down this path. 802 - Determine the mechanism for name resolution, and ensure the 803 appropriate answer is given for each address administration. 804 Embedding the DNS server, or a DNS ALG in the NAT device will 805 likely be more manageable than trying to synchronize independent 806 DNS systems across realms. 807 - Is the NAT configured for static one to one mappings, or will it 808 dynamically manage them? If dynamic, make sure the TTL of the DNS 809 responses is set to 0, and that the clients pay attention to the 810 don't cache notification. 811 - Will there be a single NAT device, or parallel with multiple 812 paths? If single, consider the impact of a device failure. If 813 multiple, consider how routing on both sides will insure the 814 packets flow through the same box over the connection lifetime of 815 the applications. 816 - Examine the applications that will need to traverse the NAT and 817 verify their immunity to address changes. If necessary provide an 818 appropriate ALG or establish a VPN to isolate the application from 819 the NAT. 820 - Determine need for public toward private connections, variability 821 of destinations on the private side, and potential for 822 simultaneous use of public side port numbers. NAPTs increase 823 administration if these apply. 824 - Determine if the applications traversing the NAPT, HNAPT, or RSIP 825 expect all ports from the public IP address to be the same 826 endpoint. Administrative controls to prevent simultaneous access 827 from multiple private hosts will be required if this is the case. 828 - If there are encrypted payloads, the contents cannot be modified 829 unless the NAT is a security endpoint, acting as a gateway between 830 security realms. This precludes end-to-end confidentiality, as the 831 path between the NAT and endpoint is exposed. 832 - Determine the path for name resolutions. If hosts on the private 833 side of a NAPT, HNAPT, or RSIP server need visibility to each 834 other, a private side DNS server may be required. 835 - If the environment uses secure DNS records, the DNS/ALG will 836 require access to the source authentication keys for all records 837 to be translated. 838 - When using VPNs over NATs, identify a clearinghouse for the 839 private side addresses to avoid collisions. 840 - Assure that applications used both internally and externally avoid 841 embedding names, or use globally unique ones. 842 - When using HNAT or RSIP, recognize the scope is limited to 843 individual private network connecting to the public Internet. If 844 other NATs are in the path (including web-server load-balancing 845 devices), the advantage is lost. In addition, the port 846 multiplexing versions of these carry the same well-known-port 847 sharing problem of NAPT. 849 Hain Informational - Expires August 1999 18 850 Summary 852 Over the 5-year period since RFC-1631, the experience base has 853 grown, further exposing concerns raised by the original authors. NAT 854 breaks a fundamental assumption of the Internet design; the 855 endpoints are in control. Another design principle, 'keep-it-simple' 856 is being overlooked as more features are added to the network to 857 work around the complications created by NATs. In the end, overall 858 flexibility and manageability are lowered, and support costs go up 859 to deal with the problems introduced. 861 Evangelists, for and against the technology, present their cases as 862 righteous while downplaying any rebuttals. 863 - NATs are a 'fact of life', and will proliferate as an enhancement 864 that sustains the existing IPv4 infrastructure. 865 - NATs are a 'necessary evil' and create an administrative burden 866 that is not easily resolved. More significantly, they inhibit the 867 roll out of IPsec, which will in turn slow growth of applications 868 that require a secure infrastructure. 869 In either case, NATs require strong applicability statements, 870 clearly declaring what works and what does not. 872 An overview of the pluses and minuses: 873 NAT advantages NAT disadvantages 874 -------------------------------- -------------------------------- 875 Masks global address changes Breaks end-to-end model 876 Stateful points of failure 877 Breaks IPsec 878 Facilitates concatenation of 879 multiple name spaces 880 Address administrations avoid Requires source specific DNS reply 881 justifications to registries or DNS/ALG 882 DNS/ALG breaks DNSsec replies 883 Lowers address utilization Enables end-to-end address 884 conflicts 885 Lowers ISP support burden Increases local support burden and 886 complexity 887 Transparent to end systems in some Unique development for each app 888 cases 889 Load sharing as virtual host Performance limitations with scale 890 Delays need for IPv4 replacement May complicate integration of IPv6 892 There have been many discussions lately about the value of 893 continuing with IPv6 development when the market place is widely 894 deploying IPv4 NATs. A short sighted view would miss the point that 895 both have a role, because NATs address some real-world issues today, 896 while IPv6 is targeted at solving fundamental problems, as well as 897 moving forward. It should be recognized that there will be a long 898 co-existence as applications and services develop for IPv6, while 899 the lifetime of the existing IPv4 systems will likely be measured in 900 decades. At their best, NATs are a diversion from forward motion, 901 but they do enable wider participation at the present state. At 903 Hain Informational - Expires August 1999 19 904 their worst, they break a class of applications, which creates the 905 need for complex work-arounds. 907 Efforts to enhance general security in the Internet include IPsec 908 and DNSsec. These technologies provide a variety of services to both 909 authenticate and protect information during transit. By breaking 910 these technologies, NAT and the DNS/ALG work-around, hinder 911 deployment of enhanced security throughout the Internet. 913 There have also been many questions about the probability of VPNs 914 being established that might raise some of the listed concerns. 915 While it is hard to predict the future, one way to avoid ALGs for 916 each application is to establish a VPN over the NATs. This restricts 917 the NAT visibility to the headers of the tunnel packets, and removes 918 its effects from all applications. While this solves the ALG issues, 919 it raises the likelihood that there will be address collisions as 920 arbitrary connections are established between uncoordinated address 921 spaces. It also creates a side concern about how an application 922 establishes the necessary VPN. 924 The original IP architecture is powerful because it provides a 925 general mechanism on which other things (yet unimagined) may be 926 built. While it is possible to build a house of cards, time and 927 experience have lead to building standards with more structural 928 integrity. IPv6 is the long-term solution that retains end-to-end 929 transparency as a principle. NAT is a technological diversion to 930 sustain the lifetime of IPv4. 932 Everyone needs to focus on the goal, which is continued evolution of 933 the Internet, and recognize continued development of IP (in all 934 current and future versions) is the path. It has been noted that the 935 success of the Internet is based on the 'living' characteristic of 936 IP. As in life, when growth, evolution, and forward progress stops, 937 decay overtakes and destroys. History has shown that protocols that 938 were 'complete and finished' as presented, have had very short 939 lifetimes while those still 'a work in progress' manage to survive 940 and continue moving ahead. All parties need to understand the 941 significant role they are playing in pursuing the goal, and that 942 none can get there without all the others. 944 Hain Informational - Expires August 1999 20 945 References 947 1 RFC-2026 Bradner, S., " The Internet Standards Process -- 948 Revision 3", BCP 9, RFC 2026, October 1996. 950 2 RFC-1631 Egevang, K., Francis, P., "The IP Network Address 951 Translator", RFC 1631, May 1994 953 3 RFC-1918, Rekhter, et al, "Address Allocation for Private 954 Internets", RFC 1918 February 1996 956 4 RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", RFC 957 2101, February 1997 959 5 draft-ietf-nat-hnat-00.txt, Jeffrey LoCategory, K.Taniguchi, "IP 960 Host Network Address (and Port) Translation", November 1998 962 6 draft-ietf-nat-rsip-protocol-00.txt, M. Borella, D. Grabelsky, 963 J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification", 964 February 1999 966 7 draft-ietf-nat-terminology-01.txt, P. Srisuresh, Matt Holdrege, 967 "IP Network Address Translator (NAT) Terminology and 968 Considerations", October 1998 970 8 RFC-793, J. Postel, "Transmission Control Protocol", RFC 793, 971 September 1981 973 9 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for 974 High-Speed Paths", RFC 1185, October 1990 976 10 draft-ietf-nat-dns-alg-01.txt, P. Srisuresh, G. Tsirtsis, P. 977 Akkiraju, A. Heffernan "DNS extensions to Network Address 978 Translators", October 1998 980 11 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS 981 Protocol", November 1997 983 12 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 985 13 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH 986 Protocol Architecture", August 1998 988 14 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP 989 MD5 Signature Option", RFC 2385, August 1998 991 Hain Informational - Expires August 1999 21 992 Acknowledgments 993 Valuable contributions to this draft came from the IAB, Vern Paxson 994 (lbl), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter(cisco) 995 and Eliot Lear (cisco). 997 Author's Addresses 998 Tony Hain 999 Microsoft 1000 One Microsoft Way Phone: 1-425-703-6619 1001 Redmond, Wa. USA Email: tonyhain@microsoft.com 1003 Copyright 1004 "Copyright (C) The Internet Society (date). All Rights Reserved. 1005 This document and translations of it may be copied and furnished to 1006 others, and derivative works that comment on or otherwise explain it 1007 or assist in its implementation may be prepared, copied, published 1008 and distributed, in whole or in part, without restriction of any 1009 kind, provided that the above copyright notice and this paragraph 1010 are included on all such copies and derivative works. However, this 1011 document itself may not be modified in any way, such as by removing 1012 the copyright notice or references to the Internet Society or other 1013 Internet organizations, except as needed for the purpose of 1014 developing Internet standards in which case the procedures for 1015 copyrights defined in the Internet Standards process must be 1016 followed, or as required to translate it into languages other than 1017 English. The limited permissions granted above are perpetual and 1018 will not be revoked by the Internet Society or its successors or 1019 assigns. This document and the information contained herein is 1020 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1021 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1022 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1023 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1024 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Hain Informational - Expires August 1999 22