idnits 2.17.1 draft-iab-nat-implications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([RFC-1631]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 1998) is 9297 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-1631' is mentioned on line 48, but not defined ** Obsolete undefined reference: RFC 1631 (Obsoleted by RFC 3022) == Missing Reference: 'RFC-1918' is mentioned on line 79, but not defined == Missing Reference: 'RFC-2101' is mentioned on line 78, but not defined == Unused Reference: 'RFC 1631' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC 2101' is defined on line 608, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Downref: Normative reference to an Informational RFC: RFC 2101 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB T. Hain, Microsoft 2 Internet Draft 3 Document: draft-iab-nat-implications-02.txt October 1998 5 Architectural Implications of NAT 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet- Drafts as 17 reference material or to cite them other than as "work in progress." 19 To view the entire list of current Internet-Drafts, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 22 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 23 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 25 A revised version of this draft document will be submitted to the 26 RFC editor as an Informational RFC for the Internet Community. 27 Discussion and suggestions for improvement are requested. This 28 document will expire before October 1998. Distribution of this draft 29 is unlimited. 31 Abstract 33 In light of the growing interest in, and deployment of network 34 address translation (NAT) [RFC-1631], this paper will discuss some 35 of the architectural implications and guidelines for 36 implementations. It is assumed the reader is familiar with the 37 address translation concepts presented in [RFC-1631]. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC-2119]. 45 Hain Informational - Expires January 1999 1 46 Introduction 48 In discussing the architectural impact of NATs [RFC-1631] on the 49 Internet, the first task is defining the scope of the Internet. The 50 most basic definition is; a concatenation of networks built using 51 IETF defined technologies. This simple description does not 52 distinguish between the public network known as the Internet, and 53 the private networks built using the same technologies. An approach 54 resolving this would be including the resources of Names or 55 Addresses administered through IANA or its delegates. While this is 56 more accurate, it still includes many private networks that have 57 coordinated their names or addresses with the public Internet. 59 Rekhter, et al [RFC-1918] defined hosts as public when they need 60 network layer access outside the enterprise, using a globally 61 unambiguous address. Those that need limited or no access are 62 defined as private. Another way to view this is the transparency of 63 the connection between any given node and the rest of the Internet. 64 True transparency could be stated as; an unambiguous locator known 65 by a node and identifiable by any other node participating in the 66 public Internet, with no restrictions on packet delivery. 68 The ultimate resolution of public or private is found in the intent 69 of the network in question. Generally networks that use coordinated 70 names and addresses, but do not intend to be part of the greater 71 Internet will use some screening technology to insert a barrier. 72 Historically barrier devices between the public and private networks 73 were known as Firewalls or Application Gateways, and were managed to 74 allow approved traffic while blocking everything else. Increasingly 75 the screening technology is becoming a simple NAT, which manages the 76 network locator between the public and private use address spaces. 78 As noted by Carpenter, et al [RFC-2101], once private use addresses 79 [RFC-1918] were deployed in the network, addresses were guaranteed 80 to be ambiguous. At the same time when NATs were attached to the 81 network, the process of resolving names to or from addresses gained 82 a dependency on where the question was asked; thus both names and 83 addresses became globally ambiguous. As private use addresses are by 84 definition not part of the public infrastructure, and an unambiguous 85 locator is required within a routing realm, NATs are clearly left 86 sitting at the boundary of the Internet. Here they become another 87 screening technology for connecting private networks. 89 In one view, NAT is the feature which finally breaks the semantic 90 overload of the IP address as both a locator and the end point 91 identifier (EID). Another view of NAT is that of 'necessary evil', 92 where there is a real concern that the technology is the weed which 93 is destined to choke out continued development. In either case, 94 there is no direct impact on the public Internet, since NATs sit at 95 the boundary. This leaves the discussion focused on the impact on 96 end-to-end communications between hosts that use the public Internet 97 as a transport medium. 99 Hain Informational - Expires January 1999 2 100 A significant factor in the success of the Internet is the 101 flexibility derived from a few basic tenets. First and foremost is 102 the End-to-End principle, which assumes the end points are in 103 control of the communication and the network simply moves bits 104 between these points. Restated, the data stream delivered by the 105 transport protocol of the end points is of no concern to the lower 106 layer packet routing devices and therefore may contain anything the 107 end point applications consider appropriate. Another is that the 108 network does not maintain per connection state information to allow 109 fast rerouting around failures through parallel paths. Lack of state 110 also removes any requirement for the network nodes to notify each 111 other as connections are formed or dropped and enables 112 connectionless transports. Furthermore, the end points are not, and 113 need not be, aware of any network components other than the first 114 hop router(s), name resolution service, and destination. Packet 115 integrity is preserved through the network, and transport checksums 116 are valid end to end. NATs (particularly the port multiplexing 117 variety) break most of these, reducing overall flexibility, 118 increasing operational complexity, and impeding diagnostic 119 capabilities. 121 Terminology 123 Locator - the address within a packet directing its delivery within 124 a routing realm. 126 Routing realm - unambiguous address pool used by a contiguous 127 collection of routers and end systems. 129 End point identifier (EID) - used by one end system to identify the 130 other end of a communication. Uniqueness is required only within the 131 context of the originating end. Using the Domain Name System as a 132 common database requires uniqueness throughout the Internet. 134 NAT - segregates realms of routing information by connecting between 135 and rewriting packet headers as necessary. A NAT does not interpret 136 packet contents in any way. 138 Application Gateway - segregates realms of transport information by 139 terminating an application data stream then reconstructing packet 140 contents as necessary before forwarding to the next destination. 142 Firewall - blocks unauthorized end-to-end connections. Often used 143 within a routing realm, firewalls adhere to forwarding rules but do 144 not modify packet headers or contents. 146 VPN - Virtual Private Network which technically treats an IP 147 infrastructure as a multiplexing substrate allowing the end points 148 to build virtual circuits to run another instance of IP over. 150 Hain Informational - Expires January 1999 3 151 Utility of NATs 153 A quick look at the popularity of NAT technology shows that it 154 addresses several real world problems. 156 - Masking the address changes that take place, from either dial- 157 access or provider changes, improves stability in the local 158 network. 159 - Globally routable addresses can be reused for intermittent access 160 customers. This lowers the demand and utilization of addresses to 161 the number of active nodes rather than the total number of nodes. 162 - There is a potential that NATs would lower an ISP's support burden 163 since there could be a consistent, simple device with a known 164 configuration at the customer end of the access interface. 165 - Breaking the Internet into a collection of routing realms would 166 limit the scope of routing knowledge, and thereby the workload on 167 the routers within each realm. 168 - For applications which don't care about the integrity of the 169 packet header, there are no changes necessary in the hosts. 171 Taken together these are strong motivations for moving quickly with 172 NAT deployment. 174 Removing hosts that are not currently active lowers address demands 175 of the public Internet, which improves the load on the routing 176 system as well as lengthens the lifetime of the IPv4 address space. 177 While this is a natural byproduct of the existing dynamic allocation 178 dial access devices, in the dedicated connection case this service 179 could be provided through a NAT. In the case of a port multiplexing 180 NAT, the aggregation potential is even greater as multiple end 181 systems share a single public address. 183 Compartmentalizing routing knowledge and distributing the overhead 184 by breaking a network into a collection of routing realms might 185 improve its stability. It could also alleviate some of the pressure 186 on the routing infrastructure causing ISP's to enforce artificial 187 boundaries on how much detail they are willing to accept in routing 188 updates. Since the details of adjacent routing realms could be 189 completely masked, the level of aggregation possible would dwarf all 190 prior efforts. The number of entries in the routing table would be 191 reduced to the number of external attachments (albeit at the expense 192 of increasing the NAT mapping table at each attachment point). 193 Determination of the proper exit point is left as an exercise for 194 the reader. 196 NAT deployments should raise the awareness of protocol designers who 197 are interested in ensuring that their protocols work end to end. 198 Breaking the semantic overload of the IP address will force 199 applications to find a more appropriate mechanism for end point 200 identification and discourage carrying the locator in the data 201 stream. Since this will not work for legacy applications, RFC-1631 202 discusses how to look into the packet and make NAT transparent to 203 the application (ie: create an application gateway). 205 Hain Informational - Expires January 1999 4 206 Another popular practice is hiding a collection of hosts behind a 207 single IP address. In many implementations this is architecturally a 208 NAT, since the addresses are mapped to the real destination on the 209 fly. When packet header integrity is not an issue, this type of 210 virtual host requires no modifications to the remote applications 211 since the end client is unaware of the mapping activity. While the 212 virtual host has the CPU performance characteristics of the total 213 set of machines, the overall performance is bounded by the 214 processing and I/O capabilities of the NAT device as it funnels the 215 packets back and forth. 217 Repercussion of NATs 219 As noted earlier, NATs break the basic tenet of the Internet that 220 the end points are in control of the communication. The greatest 221 concern from the explosion of NATs is the impact on the fledgling 222 efforts at deploying IP security. For lack of another globally 223 unique EID, the traditional use of the IP address was assumed. This 224 combination of required global uniqueness of the address, and 225 assured ambiguity by NAT leaves the IPsec effort with a severely 226 restricted working set. 228 In a statement about the use of IPv4 today, RFC-2101 details 229 architectural issues and notes: 231 "... it has been considered more useful to deliver the packet, 232 then worry about how to identify the end points, than to provide 233 identity in a packet that cannot be delivered." 235 This argument presumes that delivering the packet has an inherent 236 value, even if the end points can't be identified. In a self- 237 fulfillment of that prophecy, the applications developed to date are 238 structured to assume packets will be delivered and identity is only 239 assured in controlled environments. In many ways, this fundamental 240 impediment to basic trust has been the stalling factor in deploying 241 security across the Internet. In another note from RFC-2101: 243 "Since IP Security authentication headers assume that the 244 addresses in the network header are preserved end-to-end, it is 245 not clear how one could support IP Security-based authentication 246 between a pair of hosts communicating through either an ALG (ed: 247 Application Level Gateway) or a NAT." 249 A feature of stateful devices like NATs is the creation of a single 250 point of failure. Attempts to avoid this by establishing redundant 251 NATs, creates a new set of problems related to timely communication 252 of the state. This encompasses several issues such as update 253 frequency, performance impact of frequent updates, reliability of 254 the state update transaction, a-priori knowledge of all nodes 255 needing this state information, and notification to end nodes of 256 appropriate path for each transaction. 258 Hain Informational - Expires January 1999 5 259 It has been observed that operational management of networks 260 incorporating stateful packet modifying device is considerably 261 easier if inbound and outbound packets traverse the same path. While 262 easy to say, it is difficult to manage even with careful planning. 263 The problem is ensuring that routes advertised to the private side 264 reach the end nodes and map to the same device as the public side 265 route advertisements. In many cases this borders on the impossible, 266 given the internal and external topology churn. 268 Another major drawback of NAT technology is the process of resolving 269 addresses from names, or names from addresses. When the public DNS 270 is required to resolve a given host name on both sides of a NAT 271 there is no obviously correct answer. 273 In the example below it is not clear what answer DNS should return 274 for Host D. Returning the local address will assure global 275 invisibility, while returning the global address will prevent local 276 access from Host C. If DNS were to return both, the results would be 277 unpredictable. By knowing which side the request came from the DNS 278 server could provide the correct answer, but significant development 279 would be required to add the capability to DNS for source specific 280 responses. (note: since Host A has no access to the DNS service it 281 is required to maintain a local table, but the others may be 282 expecting DNS to provide the appropriate resolution.) 284 In the case where Hosts C & D share an address (either time shared 285 or port multiplexed), there is no way Host B could know which it was 286 connecting to. DNS would return a public side address for either, 287 then it is up to the NAT to decide where the packets are eventually 288 directed. Since Host B cannot rely on the fully qualified domain 289 name to uniquely identify a specific host, the name space is 290 fragmented, resulting in pockets of validity. 292 -------- --- --- -------- 293 | Host A |--|NAT|------|NAT|--| Host B | 294 -------- --- --- -------- 295 \ \ 296 --- -------- --- 297 |NAT|---|Internet|----|DNS| 298 --- -------- --- 299 | 300 ----------------- 301 | | 302 -------- -------- 303 | Host C | | Host D | 304 -------- -------- 306 Even if forward mappings are working, implementations that require 307 an unambiguous reverse mapping from the in-addr.arpa tree will fail 308 (diagnostic tools come to mind). 310 Hain Informational - Expires January 1999 6 311 Discussions about an arbitrary mesh of NAT connections will 312 ultimately exaggerate the issue of name space integration with the 313 routing infrastructure and show that the only resolution to 314 appropriately answer name queries in a NAT environment is to locate 315 the DNS service within each NAT. This brings the additional 316 complexity of knowing which NAT to look to for remote resolutions. 317 Since most NATs are engineered to be auto configuring turnkey 318 devices, and DNS has not been known for its auto configuring 319 properties, this is not a particularly viable approach. 321 One proposal to deal with locating the DNS service in each NAT is 322 the DNS ALG (1). Rather than running the full DNS server in the NAT, 323 it provides a mapping service by intercepting DNS messages and 324 modifying the contents appropriately. 326 The recent mass growth of the Internet has been driven by support of 327 low cost publication via the web. The next big push appears to be 328 support of Virtual Private Networks (VPNs). Technically VPNs treat 329 an IP infrastructure as a multiplexing substrate allowing the end 330 points to build what appear to be clear pathways from end to end. 331 VPNs redefine network visibility and increase the likelihood of 332 address collision when traversing NATs. Address management in the 333 hidden space behind NATs will become a significant burden, as there 334 is no central body capable of, or willing to do it. The lower burden 335 for the ISP is actually a transfer of burden to the local level, 336 because administration of addresses and names becomes both 337 distributed and more complicated. 339 As noted in RFC-1918, the merging of private address spaces can 340 cause an overlap in address use, which creates a problem. VPNs will 341 increase the likelihood and frequency of that merging through the 342 simplicity of their establishment. There are several configurations 343 of address overlap which will cause failure, but in the simple 344 example shown below the private use address of Host B matches the 345 private use address of the VPN pool used by Host A for inbound 346 connections. When Host B tries to establish the VPN, Host A will 347 assign it an address from its pool for inbound connections, and 348 identify the gateway for Host B to use. In the example, Host B will 349 not be able to distinguish the VPN address of Host A from its own 350 address so the connection will fail. Since private use addresses are 351 by definition not coordinated, as the complexity of the VPN mesh 352 increases so does the likelihood that there will be a collision 353 which cannot be resolved. 355 --------------- ---------------- 356 | 10.10.10.10 |--------VPN--------| Assigned by A | 357 | Host A | --- --- | Host B | 358 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 359 --------------- --- --- ---------------- 361 ---------- 362 1 draft-ietf-nat-dns-alg-00.txt (work in progress 7/98) 364 Hain Informational - Expires January 1999 7 365 The primary feature of NATs is the ability to simply connect private 366 networks to the public Internet. When the private network exists 367 prior to installing the NAT, it is unlikely and unnecessary that its 368 name resolver would use a registered domain. Connecting the NAT 369 device, and reconfiguring the resolver to proxy for all external 370 requests allows access to the public network by hosts on the private 371 network. Configuring the public DNS for the set of private hosts 372 that need inbound connections would require a registered domain 373 (either private, or from the connecting ISP) and a unique name. At 374 this point the name space is partitioned as hosts would have 375 different names based on inside vs. outside queries. 377 -------- -------- 378 | Host A | | Host B | 379 | Foo |-----| Bar | 380 -------- | -------- --- 381 |-------------|DNS| 382 --- --- 383 |NAT| 384 --- 385 | 386 -------- --- 387 |Internet|----|DNS| 388 -------- --- 389 | 390 --- 391 |NAT| 392 --- --- 393 |-------------|DNS| 394 -------- | -------- --- 395 | Host C |-----| Host D | 396 | Foo | | Bar | 397 -------- -------- 399 Everything in this simple example will work until an application 400 embeds a name. For example, a Web service running on Host D might 401 present embedded URL's of the form http://bar/*.html, which would 402 work from Host C, but would thoroughly confuse Host A. If the 403 embedded name matched the public DNS, Host A would be happy, but 404 Host C would not. To establish a connection from Host C, the NAT 405 would have to look at the destination rather than simply forwarding 406 the packet to a router (which would not send it back on the same 407 interface it came from). 409 NATs place constraints on the deployment of applications that carry 410 IP addresses in the data stream. Applications or protocols that 411 assume end to end integrity of the address will fail when traversing 412 a NAT. The resolution to this is to provide an Application Level 413 Gateway within or alongside each NAT. An additional gateway service 414 is necessary for each application that may imbed an address. Even 415 this approach will fail when requirement is end to end encryption 416 since only the end points have access to the keys. 418 Hain Informational - Expires January 1999 8 419 Finally, while the port multiplexing NATs (popular because they 420 allow Internet access through a single address, thus lowering cost) 421 work modestly well for private toward public connections, they 422 create management problems for applications connecting from public 423 toward private. Since only one private side system can be mapped 424 through the single public side port number, applications like multi- 425 player Internet games can only be played on one system at a time, 426 and X-windows services relying on port 6000 need to be manually 427 mapped to each target prior to connection. 429 IPv6 Considerations 431 It has been argued that IPv6 is no longer necessary because NATs 432 relieve the address space constraints and allow the Internet to 433 continue growing. The reality is they point out the need for IPv6 434 more clearly than ever. People are trying to connect multiple 435 machines through a single access line to their ISP and have been 436 willing to give up some functionality to get that at minimum cost. 437 Frequently the reason for cost increases is the perceived scarcity 438 (therefore increased value) of IPv4 addresses, which would be 439 eliminated through deployment of IPv6. This crisis mentality is 440 creating a market for a solution to a problem already solved with 441 greater flexibility by IPv6. 443 Beyond all of the above issues, the existence of NATs will 444 complicate the integration of IPv6 in the Internet because the name 445 space and end point addresses are not consistent and globally 446 unique. While multiple addresses are less of a concern to an IPv6 447 node, the disjoint name space will certainly make management 448 interesting. If IPv6 nodes are willing to continue in private 449 networks behind a NAT, they will only need a link local address and 450 all of the issues become the same as IPv4. If the intent is to move 451 into a public space as a feature of moving to IPv6, address and name 452 administration will require explicit effort. 454 Security Considerations 456 NATs break most implementation modes of IPsec, and therefore may 457 stall further deployment of enhanced security across the Internet. 458 It is difficult to identify all the combinations of header orderings 459 and options that are possible using NATs, VPNs, and IPsec. It is 460 even more difficult to clearly state which of those are applicable, 461 or workable in any given context. For example, use of AH is not 462 possible via NAT as the hash protects the IP address in the header. 463 In some cases, authenticated certificates may contain the IP address 464 as part of the subject name for authentication purposes. Encrypted 465 Quick Mode structures may contain IP addresses and ports for policy 466 verifications. While the Revised Mode of public key encryption 467 includes the peer identity in the encrypted payload. 469 It may be possible to engineer and work around NATs for IPsec on a 470 case by case basis, but attempts to retrofit IPsec over and existing 471 NAT infrastructure can be problematic. With all of the restrictions 473 Hain Informational - Expires January 1999 9 474 placed on deployment flexibility, NATs present the greatest single 475 threat to security integration being deployed in the Internet today. 477 Security mechanisms that do not protect or rely on IP addresses as 478 identifiers, such as TLS (2), SSL (3), or SSH (4) may operate in 479 environments containing NATs. For applications that can establish 480 and make use of this type of transport connection, NATs do not 481 create any additional complications. 483 Guidelines 485 Given that NAT devices are being deployed at a fairly rapid pace, 486 some guidelines are in order. Most of these amount to 'think before 487 you leap', then think again. 489 - Determine the mechanism for name resolution, and ensure the 490 appropriate answer is given for each routing realm. Embedding the 491 DNS server, or its ALG in the NAT device will be more manageable 492 than trying to synchronize independent DNS systems across realms. 494 - Is the NAT configured for static one to one mappings, or will it 495 dynamically manage them? If dynamic, make sure the TTL of the DNS 496 responses is set to 0, and that the clients pay attention to the 497 don't cache notification. 499 - Examine the applications that will need to traverse the NAT and 500 verify their immunity to address changes. If necessary provide an 501 appropriate ALG or establish a VPN to isolate the application from 502 the NAT. 504 - Determine need for public toward private connections, variability 505 of destinations on the private side, and potential for simultaneous 506 use of public side port numbers. Avoid port NATs if these apply. 508 - If there are encrypted payloads, the contents cannot be modified 509 unless the NAT is a security end point acting as a gateway between 510 security realms. This precludes end to end confidentiality, as the 511 NAT becomes the security end point. 513 - When using VPNs over NATs, identify a clearinghouse for addresses 514 to avoid collisions. 516 - Assure that applications that will be used both internally and 517 externally either avoid embedding names, or use globally unique 518 ones. 520 ---------- 521 2 draft-ietf-tls-protocol-05.txt (work in progress 11/97) 522 3 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 523 4 draft-ietf-secsh-architecture-02.txt 525 Hain Informational - Expires January 1999 10 526 Summary 528 Wherever they are located topologically, NATs break a long-standing 529 architectural principle that applications can trust packets to move 530 between end points without modification beyond ttl or tos. Another 531 design principle, 'keep-it-simple' is being overlooked as more 532 features are added to the network to work around the complications 533 created by NATs. In the end the overall flexibility and 534 manageability are lowered while support costs go up dealing with the 535 problems introduced. 537 NATs are a 'fact of life', and will proliferate as an enhancement 538 that sustains the existing IPv4 infrastructure. At the same time, 539 they require strong applicability statements, clearly stating what 540 works and what does not. 542 NATs are a 'necessary evil' as well, and by fragmenting the Name 543 Space, NATs create an administrative burden that is not easily 544 resolved. More significantly, they inhibit the roll out of IPsec, 545 which will in turn slow growth of applications that require a secure 546 infrastructure. As such, NATs represent the single greatest threat 547 to a secure Internet. 549 An overview of the pluses and minuses: 551 NAT utility NAT repercussions 552 -------------------------------- -------------------------------- 553 Masks Global Address Changes Mandates Multiple Name Spaces 554 Routing realms distribute overhead Requires source specific DNS reply 555 Lowers Address Utilization Allows end-to-end address conflicts 556 Lowers ISP support burden Increases local support burden 557 Breaks end-to-end association Breaks end-to-end association 558 Transparent to end systems Unique development for each app 559 Load sharing as virtual host Performance impact with scale 560 Delays need for IPv4 replacement Complicates integration of IPv6 562 There have been many discussions lately about the value of 563 continuing with IPv6 development when the market place is widely 564 deploying IPv4 NATs. A short sighted view would miss the point that 565 both have a role, because NATs address some real-world issues today, 566 while IPv6 is targeted at solving fundamental problems, as well as 567 moving forward. It should be recognized that there will be a long 568 co-existence as applications and services develop for IPv6, while 569 the lifetime of the existing IPv4 systems will likely be measured in 570 decades. At their best, NATs are a diversion from forward motion, 571 but they do enable wider participation at the present state. At 572 their worst, they break an association that arguably should never 573 have been made to begin with. 575 There have also been many questions about the probability of VPNs 576 being established which would raise some of the concerns listed 577 above. While it is hard to predict the future, one way to avoid ALGs 578 for each application is to establish a VPN over the NATs. This 580 Hain Informational - Expires January 1999 11 581 restricts the NAT visibility to the headers of the tunnel packets, 582 and removes its effects from all applications. While this solves the 583 ALG issues, it raises the likelihood that there will be address 584 collisions as arbitrary connections are established between 585 uncoordinated address spaces. 587 The IAB wants to remind everyone to focus on the goal, which is 588 continued evolution of the Internet, and recognize continued 589 development of IP (in all current and future versions) is the path. 590 It has been noted that the success of the Internet is based on the 591 'living' characteristic of IP. As in life, when growth, evolution, 592 and forward progress stops, decay overtakes and destroys. History 593 has shown that protocols that were 'complete and finished' as 594 presented, have had very short lifetimes while those still 'a work 595 in progress' manage to survive and continue moving ahead. All 596 parties need to understand the significant role they are playing in 597 pursuing the goal, and that none can get there without all the 598 others. 600 References 602 [RFC 1631], Egevang, K., Francis, P., "The IP Network Address 603 Translator", RFC 1631, May 1994 605 [RFC 1918], Rekhter, et al, "Address Allocation for Private 606 Internets", RFC 1918 February 1996 608 [RFC 2101], Carpenter, et al, "IPv4 Address Behavior Today", RFC 609 2101, February 1997 611 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", RFC 2119, March 1997 614 draft-ietf-nat-dns-alg-00.txt, P. Srisuresh, et al, .DNS extensions 615 to Network Address Translators., July 1998 617 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS 618 Protocol", November 1997 620 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH 621 Protocol Architecture", August 1998 623 Acknowledgments 625 Valuable contributions to this draft came from the IAB, Yakov 626 Rekhter(cisco) and Eliot Lear (cisco). 628 Author's Addresses 630 Tony Hain 631 Microsoft 632 One Microsoft Way Phone: 1-425-703-6619 633 Redmond, Wa. USA Email: tonyhain@microsoft.com 635 Hain Informational - Expires January 1999 12