idnits 2.17.1 draft-ietf-nat-terminology-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 is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages 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 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 135 has weird spacing: '...on flow indic...' == Line 881 has weird spacing: '...r to be the e...' == Line 892 has weird spacing: '...-Server would...' == Line 1012 has weird spacing: '...ions of addre...' -- 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 (June 1999) is 9075 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Ref 2' on line 179 -- Looks like a reference, but probably isn't: 'Ref 7' on line 208 -- Looks like a reference, but probably isn't: 'Ref 1' on line 252 -- Looks like a reference, but probably isn't: 'Ref 17' on line 1075 -- Looks like a reference, but probably isn't: 'Ref 18' on line 1101 -- Looks like a reference, but probably isn't: 'Ref 4' on line 1280 == Unused Reference: '1' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1319, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1327, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1329, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1331, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1344, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1350, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1361, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2401 (ref. '12') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '13') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. '14') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '15') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. '16') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2385 (ref. '17') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2535 (ref. '18') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 15 errors (**), 0 flaws (~~), 25 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group P. Srisuresh 2 INTERNET-DRAFT Lucent Technologies 3 Category: Informational Matt Holdrege 4 Expire in six months Ascend Communications 5 June 1999 7 IP Network Address Translator (NAT) Terminology and Considerations 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Preface 32 The motivation behind this document is to provide clarity to 33 the terms used in conjunction with Network Address Translators. 34 The term "Network Address Translator" means different things in 35 different contexts. The intent of this document is to define the 36 various flavors of NAT and standardize the meaning of terms used. 38 The authors listed are editors for this document and owe the content 39 to contributions from members of the working group. Large chunks of 40 the draft, titled "IP Network Address Translator (NAT)" were 41 extracted almost as is, to form the initial basis for this document. 42 The editors would like to thank the authors Pyda Srisuresh and Kjeld 43 Egevang for the same. The editors would like to thank Praveen 44 Akkiraju for his contributions in describing NAT deployment 45 scenarios. The editors would also like to thank the IESG members 46 Scott Bradner, Vern Paxson and Thomas Narten for their detailed 47 review of the document and adding clarity to the text. 49 Abstract 51 Network Address Translation is a method by which IP addresses are 52 mapped from one realm to another, in an attempt to provide 53 transparent routing to hosts. Traditionally, NAT devices are used 54 to connect an isolated address realm with private unregistered 55 addresses to an external realm with globally unique registered 56 addresses. This document attempts to describe the operation of NAT 57 devices and the associated considerations in general, and to define 58 the terminology used to identify various flavors of NAT. 60 1. Introduction and Overview 62 The need for IP Address translation arises when a network's 63 internal IP addresses cannot be used outside the network either 64 because they are invalid for use outside, or because the internal 65 addressing must be kept private from the external network. 67 Address translation allows (in many cases, except as noted in 68 sections 8 and 9) hosts in a private network to transparently 69 communicate with destinations on an external network and vice versa. 70 There are a variety of flavors of NAT and terms to match them. This 71 document attempts to define the terminology used and to identify 72 various flavors of NAT. The document also attempts to describe other 73 considerations applicable to NAT devices in general. 75 Note, however, this document is not intended to describe the 76 operations of individual NAT variations or the applicability 77 of NAT devices. 79 NAT devices attempt to provide a transparent routing solution to 80 end hosts trying to communicate from disparate address realms. This 81 is achieved by modifying end node addresses en-route and maintaining 82 state for these updates so that datagrams pertaining to a session 83 are routed to the right end-node in either realm. This solution only 84 works when the applications do not use the IP addresses as part of 85 the protocol itself. For example, identifying endpoints using DNS 86 names rather than addresses makes applications less dependent of 87 the actual addresses that NAT chooses and avoids the need to also 88 translate payload contents when NAT changes an IP address. 90 The NAT function cannot by itself support all applications 91 transparently and often must co-exist with application level gateways 92 (ALGs) for this reason. People looking to deploy NAT based solutions 93 need to determine their application requirements first and assess the 94 NAT extensions (i.e., ALGs) necessary to provide application 95 transparency for their environment. 97 IPsec techniques which are intended to preserve the Endpoint 98 addresses of an IP packet will not work with NAT enroute for most 99 applications in practice. Techniques such as AH and ESP protect 100 the contents of the IP headers (including the source and 101 destination addresses) from modification. Yet, NAT's fundamental 102 role is to alter the addresses in the IP header of a packet. 104 2. Terminology and concepts used 106 Terms most frequently used in the context of NAT are defined here 107 for reference. 109 2.1. Address realm or realm 111 An address realm is a network domain in which the network addresses 112 are uniquely assigned to entities such that datagrams can be 113 routed to them. Routing protocols used within the network domain 114 are responsible for finding routes to entities given their network 115 addresses. Note that this document is limited to describing NAT in 116 a IPv4 environment and does not address the use of NAT in any other 117 types of environment. (e.g. IPv6 environments) 119 2.2. Transparent routing 121 The term "transparent routing" is used throughout the document to 122 identify the routing functionality that a NAT device provides. 123 This is different from the routing functionality provided by a 124 traditional router device in that a traditional router routes 125 packets within a single address realm. 127 Transparent routing refers to routing a datagram between disparate 128 address realms, by modifying address contents in the IP header 129 to be valid in the address realm into which the datagram is routed. 130 Section 3.2 has a detailed description of transparent routing. 132 2.3. Session flow vs. Packet flow 134 Connection or session flows are different from packet flows. 135 A session flow indicates the direction in which the session was 136 initiated with reference to a network interface. Packet flow is 137 the direction in which the packet has traveled with reference to 138 a network interface. Take for example, an outbound telnet session. 139 The telnet session consists of packet flows in both inbound and 140 outbound directions. Outbound telnet packets carry terminal 141 keystrokes and inbound telnet packets carry screen displays from 142 the telnet server. 144 For purposes of discussion in this document, a session is defined 145 as the set of traffic that is managed as a unit for translation. 146 TCP/UDP sessions are uniquely identified by the tuple of (source 147 IP address, source TCP/UDP port, target IP address, target TCP/UDP 148 port). ICMP query sessions are identified by the tuple of (source 149 IP address, ICMP query ID, target IP address). All other sessions 150 are characterized by the tuple of (source IP address, target IP 151 address, IP protocol). 153 Address translations performed by NAT are session based and 154 would include translation of incoming as well as outgoing packets 155 belonging to that session. Session direction is identified by the 156 direction of the first packet of that session (see sec 2.5). 158 Note, there is no guarantee that the idea of a session, determined 159 as above by NAT, will coincide with the application's idea of a 160 session. An application might view a bundle of sessions (as viewed 161 by NAT) as a single session and might not even view its 162 communication with its peers as a session. Not all applications 163 are guaranteed to work across realms, even with an ALG (defined 164 below in section 2.9) enroute. 166 2.4. TU ports, Server ports, Client ports 168 For the reminder of this document, we will refer TCP/UDP ports 169 associated with an IP address simply as "TU ports". 171 For most TCP/IP hosts, TU port range 0-1023 is used by servers 172 listening for incoming connections. Clients trying to initiate 173 a connection typically select a source TU port in the range of 174 1024-65535. However, this convention is not universal and not 175 always followed. Some client stations initiate connections using 176 a source TU port number in the range of 0-1023, and there are 177 servers listening on TU port numbers in the range of 1024-65535. 179 A list of assigned TU port services may be found in RFC 1700 [Ref 2]. 181 2.5. Start of session for TCP, UDP and others 183 The first packet of every TCP session tries to establish a session 184 and contains connection startup information. The first packet of a 185 TCP session may be recognized by the presence of SYN bit and 186 absence of ACK bit in the TCP flags. All TCP packets, with the 187 exception of the first packet, must have the ACK bit set. 189 However, there is no deterministic way of recognizing the start of 190 a UDP based session or any non-TCP session. A heuristic approach 191 would be to assume the first packet with hitherto non-existent 192 session parameters (as defined in section 2.3) as constituting 193 the start of new session. 195 2.6. End of session for TCP, UDP and others 197 The end of a TCP session is detected when FIN is acknowledged by 198 both halves of the session or when either half receives a segment 199 with the RST bit in TCP flags field. However, because it is 200 impossible for a NAT device to know whether the packets it sees 201 will actually be delivered to the destination (they may be dropped 202 between the NAT device and the destination), the NAT device cannot 203 safely assume that the segments containing FINs or SYNs will be 204 the last packets of the session (i.e., there could be 205 retransmissions). Consequently, a session can be assumed to have 206 been terminated only after a period of 4 minutes subsequent to 207 this detection. The need for this extended wait period is 208 described in RFC 793 [Ref 7], which suggests a TIME-WAIT duration 209 of 2 * MSL (Maximum Segment Lifetime) or 4 minutes. 211 Note that it is also possible for a TCP connection to terminate 212 without the NAT device becoming aware of the event (e.g., in the 213 case where one or both peers reboot). Consequently, garbage 214 collection is necessary on NAT devices to clean up unused state 215 about TCP sessions that no longer exist. However, it is not 216 possible in the general case to distinguish between connections 217 that have been idle for an extended period of time from those 218 that no longer exist. In the case of UDP-based sessions, there 219 is no single way to determine when a session ends, since 220 UDP-based protocols are application specific. 222 Many heuristic approaches are used to terminate sessions. You can 223 make the assumption that TCP sessions that have not been used for 224 say, 24 hours, and non-TCP sessions that have not been used for 225 a couple of minutes, are terminated. Often this assumption works, 226 but sometimes it doesn't. These idle period session timeouts vary 227 a great deal both from application to application and for 228 different sessions of the same application. Consequently, session 229 timeouts must be configurable. Even so, there is no guarantee that 230 a satisfactory value can be found. Further, as stated in section 231 2.3, there is no guarantee that NAT's view of session termination 232 will coincide with that of the application. 234 Another way to handle session terminations is to timestamp entries 235 and keep them as long as possible and retire the longest idle 236 session when it becomes necessary. 238 2.7. Public/Global/External network 240 A Global or Public Network is an address realm with unique network 241 addresses assigned by Internet Assigned Numbers Authority (IANA) 242 or an equivalent address registry. This network is also referred 243 as External network during NAT discussions. 245 2.8. Private/Local network 247 A private network is an address realm independent of external 248 network addresses. Private network may also be referred alternately 249 as Local Network. Transparent routing between hosts in private 250 realm and external realm is facilitated by a NAT router. 252 RFC 1918 [Ref 1] has recommendations on address space allocation 253 for private networks. Internet Assigned Numbers Authority (IANA) 254 has three blocks of IP address space, namely 10/8, 172.16/12, and 255 192.168/16 set aside for private internets. In pre-CIDR notation, 256 the first block is nothing but a single class A network number, 257 while the second block is a set of 16 contiguous class B networks, 258 and the third block is a set of 256 contiguous class C networks. 260 An organization that decides to use IP addresses in the address 261 space defined above can do so without coordination with IANA 262 or any other Internet registry such as APNIC, RIPE and ARIN. 263 The address space can thus be used privately by many independent 264 organizations at the same time. However, if those independent 265 organizations later decide they wish to communicate with each 266 other or the public Internet, they will either have to renumber 267 their networks or enable NAT on their border routers. 269 2.9. Application Level gateway (ALG) 271 Not all applications lend themselves easily to translation by NAT 272 devices; especially those that include IP addresses and TCP/UDP 273 ports in the payload. Application Level Gateways (ALGs) are 274 application specific translation agents that allow an application 275 on a host in one address realm to connect to its counterpart 276 running on a host in different realm transparently. An ALG may 277 interact with NAT to set up state, use NAT state information, 278 modify application specific payload and perform whatever else 279 is necessary to get the application running across disparate 280 address realms. 282 ALGs may not always utilize NAT state information. They may glean 283 application payload and simply notify NAT to add additional state 284 information in some cases. ALGs are similar to Proxies, in that, 285 both ALGs and proxies facilitate Application specific 286 communication between clients and servers. Proxies use a special 287 protocol to communicate with proxy clients and relay client data 288 to servers and vice versa. Unlike Proxies, ALGs do not use a 289 special protocol to communicate with application clients and do 290 not require changes to application clients. 292 3. What is NAT? 294 Network Address Translation is a method by which IP addresses are 295 mapped from one address realm to another, providing transparent 296 routing to end hosts. There are many variations of address 297 translation that lend themselves to different applications. 298 However, all flavors of NAT devices should share the following 299 characteristics. 301 a) Transparent Address assignment. 302 b) Transparent routing through address translation. 303 (routing here refers to forwarding packets, and not 304 exchanging routing information) 305 c) ICMP error packet payload translation. 307 Below is a diagram illustrating a scenario in which NAT is enabled 308 on a stub domain border router, connected to the Internet through a 309 regional router made available by a service provider. 311 \ | / . / 312 +---------------+ WAN . +-----------------+/ 313 |Regional Router|----------------------|Stub Router w/NAT|--- 314 +---------------+ . +-----------------+\ 315 . | \ 316 . | LAN 317 . --------------- 318 Stub border 320 Figure 1: A typical NAT operation scenario 322 3.1. Transparent Address Assignment 324 NAT binds addresses in private network with addresses in global 325 network and vice versa to provide transparent routing for 326 the datagrams traversing between address realms. The binding in some 327 cases may extend to transport level identifiers (such as TCP/UDP 328 ports). Address binding is done at the start of a session. The 329 following sub-sections describe two types of address assignments. 331 3.1.1. Static Address assignment 333 In the case of static address assignment, there is one-to-one 334 address mapping for hosts between a private network address and 335 an external network address for the lifetime of NAT operation. 336 Static address assignment ensures that NAT does not have to 337 administer address management with session flows. 339 3.1.2. Dynamic Address assignment 341 In this case, external addresses are assigned to private network 342 hosts or vice versa, dynamically based on usage requirements and 343 session flow determined heuristically by NAT. When the last session 344 using an address binding is terminated, NAT would free the binding 345 so that the global address could be recycled for later use. The 346 exact nature of address assignment is specific to individual NAT 347 implementations. 349 3.2. Transparent routing 351 A NAT router sits at the border between two address realms and 352 translates addresses in IP headers so that when the packet leaves 353 one realm and enters another, it can be routed properly. Because 354 NAT devices have connections to multiple address realms, they must 355 be careful to not improperly propagate information (e.g., via 356 routing protocols) about networks from one address realm into 357 another, where such an advertisement would be deemed unacceptable. 359 There are three phases to Address translation, as follows. Together 360 these phases result in creation, maintenance and termination of 361 state for sessions passing through NAT devices. 363 3.2.1. Address binding 365 Address binding is the phase in which a local node IP address is 366 associated with an external address or vice versa, for purposes of 367 translation. Address binding is fixed with static address 368 assignments and is dynamic at session startup time with dynamic 369 address assignments. Once the binding between two addresses is in 370 place, all subsequent sessions originating from or to this host 371 will use the same binding for session based packet translation. 373 New address bindings are made at the start of a new session, if 374 such an address binding didn't already exist. Once a local address 375 is bound to an external address, all subsequent sessions 376 originating from the same local address or directed to the same 377 local address will use the same binding. 379 The start of each new session will result in the creation of a state 380 to facilitate translation of datagrams pertaining to the session. 381 There can be many simultaneous sessions originating from the same 382 host, based on a single address binding. 384 3.2.2. Address lookup and translation 386 Once a state is established for a session, all packets belonging 387 to the session will be subject to address lookup (and transport 388 identifier lookup, in some cases) and translation. 390 Address or transport identifier translation for a datagram will 391 result in the datagram forwarding from the origin address realm 392 to the destination address realm with network addresses 393 appropriately updated. 395 3.2.3. Address unbinding 397 Address unbinding is the phase in which a private address is no 398 longer associated with a global address for purposes of 399 translation. NAT will perform address unbinding when it believes 400 that the last session using an address binding has terminated. 401 Refer section 2.6 for some heuristic ways to handle session 402 terminations. 404 3.3. ICMP error packet translation 406 All ICMP error messages (with the exception of Redirect message 407 type) will need to be modified, when passed through NAT. The ICMP 408 error message types needing NAT modification would include 409 Destination-Unreachable, Source-Quench, Time-Exceeded and 410 Parameter-Problem. NAT should not attempt to modify a Redirect 411 message type. 413 Changes to ICMP error message will include changes to the 414 original IP packet (or portions thereof) embedded in the payload 415 of the ICMP error message. In order for NAT to be completely 416 transparent to end hosts, the IP address of the IP header embedded 417 in the payload of the ICMP packet must be modified, the checksum 418 field of the same IP header must correspondingly be modified, and 419 the accompanying transport header. The ICMP header checksum must 420 also be modified to reflect changes made to the IP and transport 421 headers in the payload. Furthermore, the normal IP header must 422 also be modified. 424 4.0. Various flavors of NAT 426 There are many variations of address translation that lend 427 themselves to different applications. NAT flavors listed in the 428 following sub-sections are by no means exhaustive, but they do 429 capture the significant differences that abound. 431 The following diagram will be used as a base model to illustrate 432 NAT flavors. Host-A, with address Addr-A is located in a private 433 realm, represented by the network N-Pri. N-Pri is isolated from 434 external network through a NAT router. Host-X, with address Addr-X 435 is located in an external realm, represented by the network N-Ext. 436 NAT router with two interfaces, each attached to one of the realms 437 provides transparent routing between the two realms. The interface 438 to the external realm is assigned an address of Addr-Nx and the 439 interface to private realm is assigned an address of Addr-Np. 440 Further, it may be understood that addresses Addr-A and Addr-Np 441 correspond to N-Pri network and the addresses Addr-X and Addr-Nx 442 correspond to N-Ext network. 444 ________________ 445 ( ) 446 ( External ) +--+ 447 ( Address Realm )-- |__| 448 ( (N-Ext) ) /____\ 449 (________________) Host-X 450 | (Addr-X) 451 |(Addr-Nx) 452 +--------------+ 453 | | 454 | NAT router | 455 | | 456 +--------------+ 457 |(Addr-Np) 458 | 459 ---------------- 460 ( ) 461 +--+ ( Private ) 462 |__|------( Address Realm ) 463 /____\ ( (N-pri) ) 464 Host-A (________________) 465 (Addr-A) 467 Figure 2: A base model to illustrate NAT terms. 469 4.1. Traditional NAT (or) Outbound NAT 471 Traditional NAT would allow hosts within a private network to 472 transparently access hosts in the external network, in most 473 cases. In a traditional NAT, sessions are uni-directional, 474 outbound from the private network. This is in contrast with 475 Bi-directional NAT, which permits sessions in both inbound 476 and outbound directions. A detailed description of 477 Bi-directional NAT may be found in section 4.2. 479 The following is a description of the properties of realms 480 supported by traditional NAT. IP addresses of hosts in external 481 network are unique and valid in external as well as private 482 networks. However, the addresses of hosts in private network are 483 unique only within the private network and may not be valid in 484 the external network. In other words, NAT would not advertise 485 private networks to the external realm. But, networks from the 486 external realm may be advertised within the private network. 487 The addresses used within private network must not overlap with 488 the external addresses. Any given address must either be a 489 private address or an external address; not both. 491 A traditional NAT router in figure 2 would allow Host-A to 492 initiate sessions to Host-X, but not the other way around. Also, 493 N-Ext is routable from within N-Pri, whereas N-Pri may not be 494 routable from N-Ext. 496 Traditional NAT is primarily used by sites using private addresses 497 that wish to allow outbound sessions from their site. 499 There are two variations to traditional NAT, namely Basic NAT and 500 NAPT (Network Address Port Translation). These are discussed in the 501 following sub-sections. 503 4.1.1. Basic NAT 505 With Basic NAT, a block of external addresses are set aside for 506 translating addresses of hosts in a private domain as they originate 507 sessions to the external domain. For packets outbound from the 508 private network, the source IP address and related fields such as 509 IP, TCP, UDP and ICMP header checksums are translated. For inbound 510 packets, the destination IP address and the checksums as listed 511 above are translated. 513 A Basic NAT router in figure 2 may be configured to translate 514 N-Pri into a block of external addresses, say Addr-i through 515 Addr-n, selected from the external network N-Ext. 517 4.1.2. Network Address Port Translation (NAPT) 519 NAPT extends the notion of translation one step further by also 520 translating transport identifier (e.g., TCP and UDP port 521 numbers, ICMP query identifiers). This allows the transport 522 identifiers of a number of private hosts to be multiplexed into 523 the transport identifiers of a single external address. NAPT 524 allows a set of hosts to share a single external address. Note 525 that NAPT can be combined with Basic NAT so that a pool of 526 external addresses are used in conjunction with port translation. 528 For packets outbound from the private network, NAPT would translate 529 the source IP address, source transport identifier and related 530 fields such as IP, TCP, UDP and ICMP header checksums. Transport 531 identifier can be one of TCP/UDP port or ICMP query ID. For inbound 532 packets, the destination IP address, destination transport 533 identifier and the IP and transport header checksums are 534 translated. 536 A NAPT router in figure 2 may be configured to translate sessions 537 originated from N-Pri into a single external address, say Addr-i. 539 Very often, the external interface address Addr-Nx of NAPT router 540 is used as the address to map N-Pri to. 542 4.2. Bi-directional NAT (or) Two-Way NAT 544 With a Bi-directional NAT, sessions can be initiated from hosts in 545 the public network as well as the private network. Private network 546 addresses are bound to globally unique addresses, statically or 547 dynamically as connections are established in either direction. 548 The name space (i.e., their Fully Qualified Domain Names) between 549 hosts in private and external networks is assumed to be end-to-end 550 unique. Hosts in external realm access private realm hosts by 551 using DNS for address resolution. A DNS-ALG must be employed in 552 conjunction with Bi-Directional NAT to facilitate name to address 553 mapping. Specifically, the DNS-ALG must be capable of translating 554 private realm addresses in DNS Queries and responses into their 555 external realm address bindings, and vice versa, as DNS packets 556 traverse between private and external realms. 558 The address space requirements outlined for traditional NAT routers 559 are applicable here as well. 561 A Bi-directional NAT router in figure 2 would allow Host-A to 562 initiate sessions to Host-X, and Host-X to initiate sessions to 563 Host-A. Just as with traditional NAT, N-Ext is routable from within 564 N-Pri, but N-Pri may not be routable from N-Ext. 566 4.3. Twice NAT 568 Twice NAT is a variation of NAT in that both the source and 569 destination addresses are modified by NAT as a datagram crosses 570 address realms. This is in contrast to Traditional-NAT and 571 Bi-Directional NAT, where only one of the addresses (either source 572 or destination) is translated. Note, there is no such term as 573 'Once-NAT'. 575 Twice NAT is necessary when private and external realms have 576 address collisions. The most common case where this would happen is 577 when a site had (improperly) numbered its internal nodes using 578 public addresses that have been assigned to another organization. 579 Alternatively, a site may have changed from one provider to another, 580 but chosen to keep (internally) the addresses it had been assigned 581 by the first provider. That provider might then later reassign those 582 addresses to someone else. The key issue in such cases is that the 583 address of the host in the external realm may have been assigned the 584 same address as a host within the local site. If that address were to 585 appear in a packet, it would be forwarded to the internal node rather 586 than through the NAT device to the external realm. Twice-NAT attempts 587 to bridge these realms by translating both source and destination 588 address of an IP packet, as the packet transitions realms. 590 Twice-NAT works as follows. When Host-A wishes to initiate a session 591 to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the 592 DNS query, and in the response returned to Host-A the DNS-ALG 593 replaces the address for Host-X with one that is properly routable in 594 the local site (say Host-XPRIME). Host A then initiates communication 595 with Host-XPRIME. When the packets traverse the NAT device, the 596 source IP address is translated (as in the case of traditional NAT) 597 and the destination address is translated to Host-X. A similar 598 translation is performed on return packets coming from Host-X. 600 The following is a description of the properties of realms supported 601 by Twice-NAT. Network address of hosts in external network are 602 unique in external networks, but not within private network. 603 Likewise, the network address of hosts in private network are 604 unique only within the private network. In other words, the address 605 space used in private network to locate hosts in private and public 606 networks is unrelated to the address space used in public network 607 to locate hosts in private and public networks. Twice NAT would 608 not be allowed to advertise local networks to the external network 609 or vice versa. 611 A Twice NAT router in figure 2 would allow Host-A to initiate 612 sessions to Host-X, and Host-X to initiate sessions to Host-A. 613 However, N-Ext (or a subset of N-Ext) is not routable from within 614 N-Pri, and N-Pri is not routable from N-Ext. 616 Twice NAT is typically used when address space used in a Private 617 network overlaps with addresses used in the Public space. 618 For example, say a private site uses the 200.200.200.0/24 address 619 space which is officially assigned to another site in the public 620 internet. Host_A (200.200.200.1) in Private space seeks to connect 621 to Host_X (200.200.200.100) in Public space. In order to make this 622 connection work, Host_X's address is mapped to a different address 623 for Host_A and vice versa. The twice NAT located at the Private site 624 border may be configured as follows : 626 Private to Public : 200.200.200.0/24 -> 138.76.28.0/24 627 Public to Private : 200.200.200.0/24 -> 172.16.1.0/24 629 Datagram flow : Host_A(Private) -> Host_X(Public) 631 a) Within private network 633 DA: 172.16.1.100 SA: 200.200.200.1 635 b) After twice-NAT translation 637 DA: 200.200.200.100 SA: 138.76.28.1 639 Datagram flow Host_X (Public) -> Host_A (Private) 641 a) Within Public network 643 DA: 138.76.28.1 SA: 200.200.200.100 645 b) After twice-NAT translation, in private network 647 SA: 200.200.200.1 DA: 172.16.1.100 649 4.4. Multihomed NAT 651 There are limitations to using NAT. For example, requests and 652 responses pertaining to a session must be routed via the same 653 NAT router, as a NAT router maintains state information for 654 sessions established through it. For this reason, it is often 655 suggested that NAT routers be operated on a border router unique 656 to a stub domain, where all IP packets are either originated from 657 the domain or destined to the domain. However, such a 658 configuration would turn a NAT router into a single point of 659 failure. 661 In order for a private network to ensure that connectivity with 662 external networks is retained even as one of the NAT links fail, 663 it is often desirable to multihome the private network to same 664 or multiple service providers with multiple connections from the 665 private domain, be it from same or different NAT boxes. 667 For example, a private network could have links to two different 668 providers and the sessions from private hosts could flow through 669 the NAT router with the best metric for a destination. When one 670 of NAT routers fail, the other could route traffic for all 671 connections. 673 Multiple NAT boxes or multiple links on the same NAT box, sharing 674 the same NAT configuration can provide fail-safe backup for each 675 other. In such a case, it is necessary for backup NAT device to 676 exchange state information so that a backup NAT can take on 677 session load transparently when the primary NAT fails. NAT backup 678 becomes simpler, when configuration is based on static maps. 680 5.0. Realm Specific IP (RSIP) 682 "Realm Specific IP" (RSIP) is used to characterize the 683 functionality of a realm-aware host in a private realm, which 684 assumes realm-specific IP address to communicate with hosts in 685 private or external realm. 687 A "Realm Specific IP Client" (RSIP client) is a host in a private 688 network that adopts an address in an external realm when 689 connecting to hosts in that realm to pursue end-to-end 690 communication. Packets generated by hosts on either end in such a 691 setup would be based on addresses that are end-to-end unique in 692 the external realm and do not require translation by an 693 intermediary process. 695 A "Realm Specific IP Server" (RSIP server) is a node resident on 696 both private and external realms, that can facilitate routing of 697 external realm packets within a private realm. These packets may 698 either have been originated by an RSIP client or directed to an 699 RSIP-client. RSIP-Server may also be the same node that assigns 700 external realm addresses to RSIP-Clients. 702 There are two variations to RSIP, namely Realm-specific Address IP 703 (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). These 704 variations are discussed in the following sub-sections. 706 5.1. Realm Specific Address IP (RSA-IP) 708 A Realm Specific Address IP (RSA-IP) client adopts an IP address 709 from the external address space when connecting to a host in 710 external realm. Once an RSA-IP client assumes an external address, 711 no other host in private or external domain can assume the same 712 address, until that address is released by the RSA-IP client. 714 The following is a discussion of routing alternatives that may be 715 pursued for the end-to-end RSA-IP packets within private realm. 716 One approach would be to tunnel the packet to the destination. The 717 outer header can be translated by NAT as normal without affecting 718 the addresses used in the internal header. Another approach would 719 be to set up a bi-directional tunnel between the RSA-IP Client and 720 the border router straddling the two address realms. Packets to 721 and from the client would be tunneled, but packets would be 722 forwarded as normal between the border router and the remote 723 destination. Note, the tunnel from the client TO the border router 724 may not be necessary. You might be able to just forward the packet 725 directly. This should work so long as your internal network isn't 726 filtering packets based on source addresses (which in this case 727 would be external addresses). 729 As an example, Host-A in figure 2 above, could assume an address 730 Addr-k from the external realm and act as RSA-IP-Client to allow 731 end-to-end sessions between Addr-k and Addr-X. Traversal of 732 end-to-end packets within private realm may be illustrated as 733 follows: 735 First method, using NAT router enroute to translate: 736 =================================================== 738 Host-A NAT router Host-X 739 ------ ----------- ------ 741 , 743 embedding 744 746 -----------------------------> 748 , 750 embedding 751 753 ---------------------------> 755 . 756 . 757 . 759 , 761 embedding 762 764 <--------------------------------- 766 , 768 embedding 770 <-------------------------------------- 772 Second method, using a tunnel within private realm: 773 ================================================== 775 Host-A NAT router Host-X 776 ------ ----------- ------ 778 , 780 embedding 781 783 -----------------------------> 785 787 -------------------------------> 789 . 790 . 791 . 793 795 <-------------------------------- 797 , 799 embedding 801 <---------------------------------- 803 There may be other approaches to pursue. 805 An RSA-IP-Client has the following characteristics. The collective 806 set of operations performed by an RSA-IP-Client may be termed 807 "RSA-IP". 809 1. Aware of the realm to which its peer nodes belong. 811 2. Assumes an address from external realm when communicating with 812 hosts in that realm. Such an address may be assigned statically 813 or obtained dynamically (through a yet-to-be-defined protocol) 814 from a node capable of assigning addresses from external realm. 815 RSA-IP-Server could be the node coordinating external realm 816 address assignment. 818 3. Route packets to external hosts using an approach amenable to 819 RSA-IP-Server. In all cases, RSA-IP-Client will likely need 820 to act as a tunnel end-point, capable of encapsulating 821 end-to-end packets while forwarding and decapsulating in the 822 return path. 824 "Realm Specific Address IP Server" (RSA-IP server) is a node 825 resident on both private and external realms, that facilitates 826 routing of external realm packets specific to RSA-IP clients 827 inside a private realm. An RSA-IP-Server may be described as 828 having the following characteristics. 830 1. May be configured to assign addresses from external realm to 831 RSA-IP-Clients, either statically or dynamically. 833 2. Must be a router resident on both the private and external 834 address realms. 836 3. Must be able to provide a mechanism to route external realm 837 packets within private realm. Of the two approaches described, 838 the first approach requires RSA-IP-Server to be a NAT router 839 providing transparent routing for the outer header. This 840 approach requires the external peer to be a tunnel end-point. 842 With the second approach, an RSA-IP-Server could be any router 843 (including a NAT router) that can be a tunnel end-point with 844 RSA-IP-Clients. It would detunnel end-to-end packets outbound 845 from RSA-IP-Clients and forward to external hosts. On the 846 return path, it would locate RSA-IP-Client tunnel, based on the 847 destination address of the end-to-end packet and encapsulate the 848 packet in a tunnel to forward to RSA-IP-Client. 850 RSA-IP-Clients may pursue any of the IPsec techniques, namely 851 transport or tunnel mode Authentication and confidentiality using 852 AH and ESP headers on the embedded packets. Any of the tunneling 853 techniques may be adapted for encapsulation between RSA-IP-Client 854 and RSA-IP-Server or between RSA-IP-Client and external host. 855 For example, IPsec tunnel mode encapsulation is a valid type of 856 encapsulation that ensures IPsec authentication and confidentiality 857 for the embedded end-to-end packets. 859 5.1. Realm Specific Address and port IP (RSAP-IP) 861 Realm Specific Address and port IP (RSAP-IP) is a variation 862 of RSIP in that multiple private hosts use a single external 863 address, multiplexing on transport IDentifiers (i.e., TCP/UDP 864 port numbers and ICMP Query IDs). 866 "RSAP-IP-Client" may be defined similar to RSA-IP-Client with 867 the variation that RSAP-IP-Client assumes a tuple of (external 868 address, transport Identifier) when connecting to hosts in external 869 realm to pursue end-to-end communication. As such, communication 870 with external nodes for an RSAP-IP-Client may be limited to TCP, 871 UDP and ICMP sessions. 873 "RSAP-IP-Server" is similar to RSA-IP-Server in that it facilitates 874 routing of external realm packets specific to RSAP-IP clients 875 inside a private realm. Typically, an RSAP-IP-Server would also be 876 the one to assign transport tuples to RSAP-IP-Clients. 878 A NAPT router enroute could serve as RSAP-IP-Server, when the 879 outer encapsulation is TCP/UDP based and is addressed between the 880 RSAP-IP-Client and external peer. This approach requires the 881 external peer to be the end-point of TCP/UDP based tunnel. Using 882 this approach, RSAP-IP-Clients may pursue any of the IPsec 883 techniques, namely transport or tunnel mode authentication and 884 confidentiality using AH and ESP headers on the embedded packets. 885 Note however, IPsec tunnel mode is not a valid type of 886 encapsulation, as a NAPT router cannot provide routing transparency 887 to AH and ESP protocols. 889 Alternately, packets may be tunneled between RSAP-IP-Client and 890 RSAP-IP-Server such that RSAP-IP-Server would detunnel packets 891 outbound from RSAP-IP-Clients and forward to external hosts. On 892 the return path, RSAP-IP-Server would locate RSAP-IP-Client 893 tunnel, based on the tuple of (destination address, transport 894 Identifier) and encapsulate the original packet within a tunnel 895 to forward to RSAP-IP-Client. With this approach, there is no 896 limitation on the tunneling technique employed between 897 RSAP-IP-Client and RSAP-IP-Server. However, there are 898 limitations to applying IPsec based security on end-to-end packets. 899 Transport mode based authentication and integrity may be attained. 900 But, confidentiality cannot be permitted because RSAP-IP-Server 901 must be able to examine the destination transport Identifier in 902 order to identify the RSAP-IP-tunnel to forward inbound packets 903 to. For this reason, only the transport mode TCP, UDP and ICMP 904 packets protected by AH and ESP-authentication can traverse a 905 RSAP-IP-Server using this approach. 907 As an example, say Host-A in figure 2 above, obtains a tuple of 908 (Addr-Nx, TCP port T-Nx) from NAPT router to act as 909 RSAP-IP-Client to initiate end-to-end TCP sessions with Host-X. 910 Traversal of end-to-end packets within private realm may be 911 illustrated as follows. In the first method, outer layer of the 912 outgoing packet from Host-A uses (private address Addr-A, source 913 port T-Na) as source tuple to communicate with Host-X. NAPT router 914 enroute translates this tuple into (Addr-Nx, Port T-Nxa). This 915 translation is independent of RSAP-IP-Client tuple parameters 916 used in the embedded packet. 918 First method, using NAPT router enroute to translate: 919 ==================================================== 921 Host-A NAPT router Host-X 922 ------ ----------- ------ 924 , 927 embedding 928 930 -----------------------------> 932 , 935 embedding 936 938 ---------------------------------------> 940 . 941 . 942 . 944 , 947 embedding 948 951 <---------------------------------- 953 , 956 embedding 957 960 <----------------------------------- 962 Second method, using a tunnel within private realm: 963 ================================================== 965 Host-A NAPT router Host-X 966 ------ ----------- ------ 968 , 970 embedding 971 974 -----------------------------> 976 979 --------------------------------> 981 . 982 . 983 . 985 988 <---------------------------------- 990 , 992 embedding 993 996 <---------------------------------- 998 6.0. Private Networks and Tunnels 1000 Let us consider the case where your private network is connected 1001 to the external world via tunnels. In such a case, tunnel 1002 encapsulated traffic may or may not contain translated packets 1003 depending upon the characteristics of address realms a tunnel is 1004 bridging. 1006 The following subsections discuss two scenarios where tunnels are 1007 used (a) in conjunction with Address translation, and (b) without 1008 translation. 1010 6.1. Tunneling translated packets 1012 All variations of address translations discussed in the previous 1013 section can be applicable to direct connected links as well as 1014 tunnels and virtual private networks (VPNs). 1016 For example, a private network connected to a business partner 1017 through a VPN could employ traditional NAT to communicate with 1018 the partner. Likewise, it is possible to employ twice NAT, 1019 if the partner's address space overlapped with the private 1020 network. There could be a NAT device on one end of the tunnel 1021 or on both ends of the tunnel. In all cases, traffic across the 1022 VPN can be encrypted for security purposes. Security here refers 1023 to security for traffic across VPNs alone. End-to-end security 1024 requires trusting NAT devices within private network. 1026 6.2. Backbone partitioned private Networks 1028 There are many instances where a private network (such as a 1029 corporate network) is spread over different locations and use 1030 public backbone for communications between those locations. In 1031 such cases, it is not desirable to do address translation, both 1032 because large numbers of hosts may want to communicate across the 1033 backbone, thus requiring large address tables, and because there 1034 will be more applications that depend on configured addresses, 1035 as opposed to going to a name server. We call such a private 1036 network a backbone-partitioned private network. 1038 Backbone-partitioned stubs should behave as though they were a 1039 non-partitioned stub. That is, the routers in all partitions 1040 should maintain routes to the local address spaces of all 1041 partitions. Of course, the (public) backbones do not maintain 1042 routes to any local addresses. Therefore, the border routers must 1043 tunnel (using VPNs) through the backbones using encapsulation. 1044 To do this, each NAT box will set aside a global address for 1045 tunneling. 1047 When a NAT box x in stub partition X wishes to deliver a packet 1048 to stub partition Y, it will encapsulate the packet in an IP 1049 header with destination address set to the global address 1050 of NAT box y that has been reserved for encapsulation. When NAT 1051 box y receives a packet with that destination address, it 1052 decapsulates the IP header and routes the packet internally. 1053 Note, there is no address translation in the process; merely 1054 transfer of private network packets over an external network 1055 tunnel backbone. 1057 7.0. NAT operational characteristics 1059 NAT devices are application unaware in that the translations are 1060 limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. 1061 NAT devices do not change the payload of the packets, as payloads 1062 tend to be application specific. 1064 NAT devices (without the inclusion of ALGs) do not examine or 1065 modify transport payload. For this reason, NAT devices are 1066 transparent to applications in many cases. There are two areas, 1067 however, where NAT devices often cause difficulties: 1) when an 1068 application payload includes an IP address, and 2) when end-to-end 1069 security is needed. Note, this is not a comprehensive list. 1071 Application layer security techniques that do not make use of or 1072 depend on IP addresses will work correctly in the presence of NAT 1073 (e.g., TLS, SSL and ssh). In contrast, transport layer techniques 1074 such as IPSec transport mode or the TCP MD5 Signature Option 1075 RFC 2385 [Ref 17] do not. 1077 In IPSec transport mode, both AH and ESP have an integrity check 1078 covering the entire payload. When the payload is TCP or UDP, the 1079 TCP/UDP checksum is covered by the integrity check. When a NAT 1080 device modifies an address the checksum is no longer valid with 1081 respect to the new address. Normally, NAT also updates the 1082 checksum, but this is ineffective when when AH and ESP are used. 1083 Consequently, receivers will discard a packet either because it 1084 fails the IPSec integrity check (if the NAT device updates the 1085 checksum), or because the checksum is invalid (if the NAT device 1086 leaves the checksum unmodified). 1088 Note that IPsec tunnel mode ESP is permissible so long as the 1089 embedded packet contents are unaffected by the outer IP header 1090 translation. Although this technique does not work in traditional 1091 NAT deployments (i.e., where hosts are unaware that NATs are 1092 present), the technique is applicable to Realm-Specific IP as 1093 described in Section 5.0. 1095 Note also that end-to-end ESP based transport mode authentication 1096 and confidentiality are permissible for packets such as ICMP, 1097 whose IP payload content is unaffected by the outer IP header 1098 translation. 1100 NAT devices also break fundamental assumptions by public key 1101 distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] 1102 and X.509 certificates with signed public keys. In the case of 1103 Secure DNS, each DNS RRset is signed with a key from within the 1104 zone. Moreover, the authenticity of a specific key is verified by 1105 following a chain of trust that goes all the way to the DNS root. 1106 When a DNS-ALG modifies addresses (e.g., as in the case of 1107 Twice-NAT), verification of signatures fails. 1109 It may be of interest to note that IKE (Session key negotiation 1110 protocol) is a UDP based session layer protocol and is not 1111 protected by network based IPsec security. Only a portion of the 1112 individual payloads within IKE are protected. As a result, IKE 1113 sessions are permissible across NAT, so long as IKE payload does 1114 not contain addresses and/or transport IDs specific to one realm 1115 and not the other. Given that IKE is used to setup IPSec 1116 associations, and there are at present no known ways of making 1117 IPSec work through a NAT function, it is a future work item to 1118 take advantage of IKE through a NAT box. 1120 One of the most popular internet applications "FTP" would not work 1121 with the definition of NAT as described. The following sub-section 1122 is devoted to describing how FTP is supported on NAT devices. FTP 1123 ALG is an integral part of most NAT implementations. Some vendors 1124 may choose to include additional ALGs to custom support other 1125 applications on the NAT device. 1127 7.1. FTP support 1129 "PORT" command and "PASV" response in FTP control session payload 1130 identify the IP address and TCP port that must be used for the 1131 data session it supports. The arguments to the PORT command and 1132 PASV response are an IP address and a TCP port in ASCII. An FTP 1133 ALG is required to monitor and update the FTP control session 1134 payload so that information contained in the payload is relevant 1135 to end nodes. The ALG must also update NAT with appropriate data 1136 session tuples and session orientation so that NAT could set up 1137 state information for the FTP data sessions. 1139 Because the address and TCP port are encoded in ASCII, this may 1140 result in a change in the size of packet. For instance, 1141 10,18,177,42,64,87 is 18 ASCII characters, whereas 1142 193,45,228,137,64,87 is 20 ASCII characters. If the new size is 1143 same as the previous, only the TCP checksum needs adjustment as a 1144 result of change of data. If the new size is less than or greater 1145 than the previous, TCP sequence numbers must also be changed to 1146 reflect the change in length of FTP control data portion. A 1147 special table may be used by the ALG to correct the TCP sequence 1148 and acknowledge numbers. The sequence number and acknowledgement 1149 correction will need to be performed on all future packet of the 1150 connection. 1152 8.0. NAT limitations 1154 8.1. Applications with IP-address Content 1156 Not All applications lend themselves easily to address translation 1157 by NAT devices. Especially, the applications that carry IP address 1158 (and TU port, in case of NAPT) inside the payload. Application Level 1159 Gateways, or ALGs must be used to perform translations on packets 1160 pertaining to such applications. ALGs may optionally utilize address 1161 (and TU port) assignments made by NAT and perform translations 1162 specific to the application. The combination of NAT functionality 1163 and ALGs will not provide end-to-end security assured by IPsec. 1164 However, tunnel mode IPsec can be accomplished with NAT router 1165 serving as tunnel end point. 1167 SNMP is one such application with address content in payload. NAT 1168 routers would not translate IP addresses within SNMP payloads. It 1169 is not uncommon for an SNMP specific ALG to reside on a NAT router 1170 to perform SNMP MIB translations proprietary to the private network. 1172 8.2. Applications with inter-dependent control and data sessions 1174 NAT devices operate on the assumption that each session is 1175 independent. Session characteristics like session orientation, 1176 source and destination IP addresses, session protocol, and source 1177 and destination transport level identifiers are determined 1178 independently at the start of each new session. 1180 However, there are applications such as H.323 that use one or 1181 more control sessions to set the characteristics of the follow-on 1182 sessions in their control session payload. Such applications 1183 require use of application specific ALGs that can interpret and 1184 translate the payload, if necessary. Payload interpretation 1185 would help NAT be prepared for the follow-on data sessions. 1187 8.3. Debugging Considerations 1189 NAT increases the probability of mis-addressing. For example, 1190 same local address may be bound to different global address at 1191 different times and vice versa. As a result, any traffic flow 1192 study based purely on global addresses and TU ports could be 1193 confused and might misinterpret the results. 1195 If a host is abusing the Internet in some way (such as trying to 1196 attack another machine or even sending large amounts of junk mail 1197 or something) it is more difficult to pinpoint the source of the 1198 trouble because the IP address of the host is hidden in a NAT 1199 router. 1201 8.4. Translation of fragmented FTP control packets 1203 Translation of fragmented FTP control packets is tricky when the 1204 packets contain "PORT" command or response to "PASV" command. 1205 Clearly, this is a pathological case. NAT router would need to 1206 assemble the fragments together first and then translate prior 1207 to forwarding. 1209 Yet another case would be when each character of packets 1210 containing "PORT" command or response to "PASV" is sent in a 1211 separate datagram, unfragmented. In this case, NAT would simply 1212 have to let the packets through, without translating the TCP 1213 payload. Of course, the application will fail if the payload 1214 needed to be altered. The application could still work in a few 1215 cases, where the payload contents can be valid in both realms, 1216 without modifications enroute. For example, FTP originated from 1217 a private host would still work while traversing a traditional NAT 1218 or bi-directional NAT device, so long as the FTP control session 1219 employed PASV command to establish data sessions. The reason being 1220 that the address and port number specified by FTP server in the 1221 the PASV response (sent as multiple unfragmented packets) is valid 1222 to the private host, as is. The NAT device will simply view the 1223 ensuing data session (also originating from private host) as an 1224 independent TCP session. 1226 8.5. Compute intensive 1228 NAT is compute intensive even with the help of a clever checksum 1229 adjustment algorithm, as each data packet is subject to NAT 1230 lookup and modifications. As a result, router forwarding 1231 throughput could be slowed considerably. However, so long as the 1232 processing capacity of the NAT device exceeds line processing 1233 rate, this should not be a problem. 1235 9.0. Security Considerations 1237 Many people view traditional NAT router as a one-way (session) 1238 traffic filter, restricting sessions from external hosts into 1239 their machines. In addition, when address assignment in NAT router 1240 is done dynamically, that makes it harder for an attacker to point 1241 to any specific host in the NAT domain. NAT routers may be used in 1242 conjunction with firewalls to filter unwanted traffic. 1244 If NAT devices and ALGs are not in a trusted boundary, that is a 1245 major security problem, as ALGs could snoop end user traffic 1246 payload. Session level payload could be encrypted end to end, so 1247 long as the payload does not contain IP addresses and/or transport 1248 identifiers that are valid in only one of the realms. With the 1249 exception of RSIP, end-to-end IP network level security 1250 assured by current IPsec techniques is not attainable with NAT 1251 devices in between. One of the ends must be a NAT box. Refer 1252 section 7.0 for a discussion on why end-to-end IPsec security 1253 cannot be assured with NAT devices along the route. 1255 The combination of NAT functionality, ALGs and firewalls will 1256 provide a transparent working environment for a private networking 1257 domain. With the exception of RSIP, end-to-end network security 1258 assured by IPsec cannot be attained for end-hosts within the 1259 private network (Refer section 5.0 for RSIP operation). In 1260 all other cases, if you want to use end-to-end IPsec, there cannot 1261 be a NAT device in the path. If we make the assumption that NAT 1262 devices are part of a trusted boundary, tunnel mode IPsec can be 1263 accomplished with NAT router (or a combination of NAT, ALGs and 1264 firewall) serving as tunnel end point. 1266 NAT devices, when combined with ALGs, can ensure that the datagrams 1267 injected into Internet have no private addresses in headers or 1268 payload. Applications that do not meet these requirements may be 1269 dropped using firewall filters. For this reason, it is not 1270 uncommon to find NAT, ALG and firewall functions co-exist to provide 1271 security at the borders of a private network. NAT gateways can be 1272 used as tunnel end points to provide secure VPN transport of packet 1273 data across an external network domain. 1275 Below are some additional security considerations associated with 1276 NAT routers. 1278 1. UDP sessions are inherently unsafe. Responses to a datagram 1279 could come from an address different from the target address 1280 used by sender ([Ref 4]). As a result, an incoming UDP packet 1281 might match the outbound session of a traditional NAT router 1282 only in part (the destination address and UDP port number of 1283 the packet match, but the source address and port number may 1284 not). In such a case, there is a potential security compromise 1285 for the NAT device in permitting inbound packets with partial 1286 match. This UDP security issue is also inherent to firewalls. 1288 Traditional NAT implementations that do not track datagrams on 1289 a per-session basis but lump states of multiple UDP sessions 1290 using the same address binding into a single unified session 1291 could compromise the security even further. This is because, 1292 the granularity of packet matching would be further limited to 1293 just the destination address of the inbound UDP packets. 1295 2. Multicast sessions (UDP based) are another source for security 1296 weakness for traditional-NAT routers. Once again, firewalls face 1297 the same security dilemma as the NAT routers. 1299 Say, a host on private network initiated a multicast session. 1300 Datagram sent by the private host could trigger responses in the 1301 reverse direction from multiple external hosts. Traditional-NAT 1302 implementations that use a single state to track a multicast 1303 session cannot determine for certain if the incoming UDP packet 1304 is in response to an existing multicast session or the start of 1305 new UDP session initiated by an attacker. 1307 3. NAT devices can be a target for attacks. 1309 Since NAT devices are Internet hosts they can be the target of a 1310 number of different attacks, such as SYN flood and ping flood 1311 attacks. NAT devices should employ the same sort of protection 1312 techniques as Internet-based servers do. 1314 REFERENCES 1316 [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 1317 Lear, E. "Address Allocation for Private Internets", RFC 1918 1319 [2] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 1321 [3] R. Braden, "Requirements for Internet Hosts -- Communication 1322 Layers", RFC 1122 1324 [4] R. Braden, "Requirements for Internet Hosts -- Application 1325 and Support", RFC 1123 1327 [5] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 1329 [6] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL(FTP)", RFC 959 1331 [7] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 1333 [8] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATION", 1334 RFC 792 1336 [9] J. Postel, "User Datagram Protocol (UDP)", RFC 768 1338 [10] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure", 1339 RFC 950 1341 [11] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 1342 Behavior Today", RFC 2101 1344 [12] S. Kent, R. Atkinson, "Security Architecture for the Internet 1345 Protocol", RFC 2401 1347 [13] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 1348 (ESP)", RFC 2406 1350 [14] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 1352 [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1353 RFC 2409 1355 [16] D. Piper, "The Internet IP Security Domain of Interpretation 1356 for ISAKMP", RFC 2407 1358 [17] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 1359 Signature Option", RFC 2385 1361 [18] D. Eastlake, "Domain Name System Security Extensions" RFC 2535 1363 Authors' Addresses 1365 Pyda Srisuresh 1366 Lucent technologies 1367 4464 Willow Road 1368 Pleasanton, CA 94588-8519 1369 U.S.A. 1371 Voice: (925) 737-2153 1372 Fax: (925) 737-2110 1373 EMail: suresh@ra.lucent.com 1375 Matt Holdrege 1376 Ascend Communications, Inc. 1377 One Ascend Plaza 1378 1701 Harbor Bay Parkway 1379 Alameda, CA 94502 1381 Voice: (510) 769-6001 1382 Fax: (510) 814-2300 1383 EMail: matt@ascend.com