idnits 2.17.1 draft-ietf-nat-protocol-complications-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 control characters in the document. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 777: '...PT configuration MUST allow multiple s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 146 has weird spacing: '...on from a hos...' == Line 253 has weird spacing: '... by the clien...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2402' is mentioned on line 209, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'SNMP-APPL' is mentioned on line 734, but not defined == Unused Reference: 'SMTP' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RSVP' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'IPsec' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'PRIV-ADDR' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'ADDR-BEHA' is defined on line 836, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group Matt Holdrege 2 INTERNET-DRAFT ipVerse 3 Category: Informational Pyda Srisuresh 4 Expires as of April 9, 2001 Consultant 5 October, 2000 7 Protocol Complications with the IP Network Address Translator 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. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (US West Coast). 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract: 40 Many internet applications can be adversely affected when end nodes 41 are not in the same address realm and seek the assistance of NAT 42 enroute to bridge the realms. NAT device alone cannot provide the 43 necessary application/protocol transparency in all cases and seeks 44 the assistance of Application Level Gateways (ALGs) where possible, 45 to provide transparency. The purpose of this document is to 46 identify the protocols and applications that break with NAT enroute. 47 The document also attempts to identify any known workarounds. It is 48 impossible to capture all the applications that break with NAT in a 49 single document. This document attempts to capture as much informa- 50 tion as possible, but by no means a comprehensive coverage. We hope 51 this coverage provides clues for applications not covered here. 53 Table of Contents 55 1.0 Introduction 57 2.0 Common Characteristics of Protocols broken by NAT 59 3.0 Protocols that cannot work with NAT enroute 61 4.0 Protocols that can work with the aid of an ALG 63 5.0 Protocols designed explicitly to work with NAT enroute 65 6.0 Acknowledgements 67 7.0 Security Considerations 69 8.0 References 71 9.0 Authors Addresses 73 1.0 Introduction: 75 This document requires the reader to be familiar with the 76 terminology and function of NAT devices as described in [NAT-TERM]. 77 In a nutshell, NAT attempts to provide a transparent routing solution 78 to end hosts requiring communication to disparate address realms. NAT 79 modifies end node addresses (within the IP header of a packet) 80 en-route and maintains state for these updates so that datagrams 81 pertaining to a session are transparently routed to the right 82 end-node in either realm. Where possible, application specific 83 ALGs may be used in conjunction with NAT to provide application level 84 transparency. Unlike NAT, the function of ALG is application specific 85 and would likely require examination and recomposition of IP payload. 87 The following sections attempt to list applications that are known 88 to have been impacted by NAT devices enroute. However, this is by no 89 means a comprehensive list of all known protocols and applications 90 that have complications with NAT - rather just a subset of the list 91 gathered by the authors. It is also important to note that this 92 document is not intended to advocate NAT, but rather to point out 93 the complications with protocols and applications when NAT devices 94 are enroute. 96 2.0 Common Characteristics of Protocols broken by NAT 98 [NAT-TERM] and [NAT-TRAD] have sections listing the specific nature 99 of problems and limitations to NAT devices. Some of these limitations 100 are being restated in this section to summarize characteristics of 101 protocols that are broken by NAT. 103 2.1 Realm-specific IP address information in payload 105 A wide range of applications fail with NAT enroute when IP packets 106 contain realm-specific IP address or port information in payload. 107 An ALG may be able to provide work around in some cases. But, 108 if the packet payload is IPsec secured (or secure by a transport 109 or application level security mechanisms), the application is 110 bound to fail. 112 2.2 Bundled session applications 114 Bundled session applications such as FTP, H.323, SIP and RTSP, which 115 use a control connection to establish a data flow are also usually 116 broken by NAT devices enroute. This is because these applications 117 exchange address and port parameters within control session to 118 establish data sessions and session orientations. NAT cannot know 119 the inter-dependency of the bundled sessions and would treat each 120 session to be unrelated to one another. Applications in this case 121 can fail for a variety of reasons. Two most likely reasons for 122 failures are: (a) addressing information in control payload is 123 realm-specific and is not valid once packet crosses the originating 124 realm, (b) control session permits data session(s) to originate in 125 a direction that NAT might not permit. 127 When DNS names are used in control payload, NAT device in conjunction 128 with a DNS-ALG might be able to offer the necessary application level 129 transparency, if NAT has no contention with data session orientation. 130 However, using DNS names in place of realm-specific IP addresses may 131 not be an option to many of these applications (e.g.: FTP). 133 When realm-specific addressing is specified in payload, and the payload 134 is not encrypted, an ALG may in some cases be able to provide the work 135 around necessary to make the applications run transparently across 136 realms. The complexity of ALG depends on the application level 137 knowledge required to process payload and maintain state. 139 2.3 Peer-to-peer applications 141 Peer-to-peer applications more than client-server based applications 142 are likely to break with NAT enroute. Unlike Client-server 143 applications, Peer-to-peer applications can be originated by any of 144 the peers. When peers are distributed across private and public 145 realms, a session originated from an external realm is just as 146 likely as the session from a host in private realm. External 147 peers will be able to locate their peers in private realm only 148 when they know the externally assigned IP address or the FQDN 149 ahead of time. FQDN name to assigned address mapping can happen 150 only so long as the enroute NAT device supports DNS-ALG. Examples 151 of Peer-to-peer applications include interactive games, Internet 152 telephony and event-based protocols (such as Instant-Messaging). 154 This is particularly a problem with traditional NAT and may be less 155 of an issue with bi-directional NAT, where sessions are permitted 156 in both directions. 158 A possible work-around for this type of problem with traditional-NAT 159 is for private hosts to maintain an outbound connection with a 160 server acting as their representative to the globally routed 161 Internet. 163 2.4 IP fragmentation with NAPT enroute 165 IP fragmentation with NAPT enroute is not an issue with any single 166 application, but pervades across all TCP/UDP applications. The 167 problem is described in detail in [NAT-TRAD]. Briefly, the problem 168 goes as follows. Say, two private hosts originated fragmented 169 TCP/UDP packets to the same destination host. And, they happened to 170 use the same fragmentation identifier. When the target host receives 171 the two unrelated datagrams, carrying same fragmentation id, and 172 from the same assigned host address, the target host is unable to 173 determine which of the two sessions the datagrams belong to. 174 Consequently, both sessions will be corrupted. 176 2.5 Applications requiring retention of address mapping 178 NAT will most likely break applications that require address 179 mapping to be retained across contiguous sessions. These 180 applications require the private-to-external address mapping 181 to be retained between sessions so the same external address 182 may be reused for subsequent session interactions. NAT cannot 183 know this requirement and may reassign external address to 184 different hosts between sessions. 186 Trying to keep NAT from discarding an address mapping would 187 require the application to keep sending Keepalives - which can 188 be annoying or sometimes not even possible. Alternately, an 189 ALG may be required to interact with NAT to keep the address 190 mapping from being discarded by NAT. 192 2.6 Applications requiring more public addresses than available 194 This is a problem when the number of private hosts is larger than 195 the external addresses available to map the private addresses 196 into. Take for example the rlogin service initiated from a host 197 in private realm supported by NAPT. Rlogin service clients 198 use well-known rlogin port 512 as their TCP port ID. No more than 199 one host in private realm can initiate the service. This is a 200 case of trying to use a service that fundamentally requires more 201 public addresses than are available. NAT devices can conserve 202 addresses, but they cannot create more addresses. 204 3.0 Protocols that cannot work with NAT enroute 206 3.1 IPsec and IKE 208 NAT fundamentally operates by modifying end node addresses (within the 209 IP header) en-route. The IPsec AH standard [RFC 2402] on the other 210 hand is explicitly designed to detect alterations to IP packet 211 header. So when NAT alters the address information enroute in IP 212 header, the destination host receiving the altered packet will 213 invalidate the packet since the contents of the headers have been 214 altered. The IPsec AH secure packet traversing NAT will simply not 215 reach the target application, as a result. 217 IPsec ESP encrypted packets may be altered by NAT device enroute only 218 in a limited number of cases. In the case of TCP/UDP packets, NAT would 219 need to update the checksum in TCP/UDP headers, when an address in 220 IP header is changed. However, as the TCP/UDP header is encrypted by 221 the ESP, NAT would not be able to make this checksum update. As a 222 result, TCP/UDP packets encyrpted in transport mode ESP, traversing a 223 NAT device will fail the TCP/UDP checksum validation on the receiving 224 end and will simply not reach the target application. 226 Internet Key Exchange Protocol IKE can potentially pass IP addresses 227 as node identifiers during Main, Aggressive and Quick Modes. In order 228 for an IKE negotiation to correctly pass through a NAT, these 229 payloads would need to be modified. However, these payloads are 230 often protected by hash or obscured by encryption. Even in the 231 case where IP addresses are not used in IKE payloads and an IKE 232 negotiation could occur uninterrupted, there is difficulty with 233 retaining the private-to-external address mapping on NAT from the 234 time IKE completed negotiation to the time IPsec uses the key on 235 an application. In the end, the use of end-to-end IPsec is severely 236 hampered anyway, as described earlier. 238 For all practical purposes, end-to-end IPsec is impossible to 239 accomplish with NAT enroute. 241 3.2 Kerberos 4 243 Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be 244 written. when the KDC receives a ticket request, it includes the 245 source IP address in the returned ticket. Not all Kerberos 4 246 services actually check source IP addresses. AFS is a good 247 example of a Kerberos 4 service which does not. Services which 248 don't check are not picky about NAT devices enroute. Kerberos 249 tickets are tied to the IP address that requested the ticket and 250 the service with which to use the ticket. 252 The K4 ticket (response) contains a single IP address describing the 253 interface used by the client to retrieve the ticket from the TGT 254 from the perspective of KDC. This works fine if the KDC is across a 255 NAT gateway and as long as all of the Kerberos services are also 256 across a NAT gateway. The end user on private network will not notice 257 any problems. 259 There is also the caveat that NAT uses the same address mapping for 260 the private host for the connection between the client and the KDC 261 as for the connection between the client and the application server. 262 A work around this problem would be to keep an arbitrary connection 263 open to remote server during throughout the ticket lifetime, so as 264 not to let NAT drop the address binding. Alternately, an ALG will 265 need to be deployed to ensure that NAT would not change address 266 bindings during the lifetime of a ticket and between the time a 267 ticket is issued to private host and the time the ticket is used 268 by private host. 270 But, the ticket will be valid from any host within the private realm 271 of NAPT. Without NAPT, an attacker needs to be able to 272 spoof the source IP addresses of a connection that is being made in 273 order to use a stolen ticket on a different host. With NAPT, all 274 the attacker needs to do from the private realm of NAPT is to simply 275 gain possession of a ticket. Of course, this assumes, NAPT private 276 domain is not a trusted network - not surprisingly, since many attacks 277 occur from inside the organization. 279 3.3 Kerberos 5 281 Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, 282 an ALG cannot be written. 284 In Kerberos 5, the client specifies a list of IP addresses which the 285 ticket should be valid for, or it can ask for a ticket valid for all 286 IP addresses. By asking for an all-IP-addresses ticket or a ticket 287 containing the NAPT device address, you can get krb5 to work with an 288 NAPT device, although it isn't very transparent (it requires the 289 clients to behave differently than they otherwise would). The MIT 290 krb5 1.0 implementation didn't have any configurability for what IP 291 addresses the client asked for (it always asked for the set of its 292 interface addresses) and did not interact well with NAT. The MIT krb5 293 1.1 implementation allows you to put "noaddresses" somewhere in 294 krb5.conf to request all-IP-addresses-valid tickets. 296 The K5 ticket (response) contains IP addresses, as requested by the 297 client node, from which the ticket is to be considered valid. If the 298 services being accessed with Kerberos authentication are on the 299 public side of the NAT, then the Kerberos authentication will fail 300 because the IP address used by the NAT (basic NAT or NAPT) is not in 301 the list of acceptable addresses. 303 There are two workarounds in Kerberos 5 both of which reduce the 304 security of the tickets. The first is to have the clients in NAPT 305 private realm specify the public IP address of the NAPT in the 306 ticket's IP list. But this leads to the same security problem 307 detailed for K4. Plus, it is not obvious for the client in the 308 private domain to find out the public IP Address of the NAPT. That 309 would be a change of application behavior on end-host. 311 The second method is to remove all IP addresses from the K5 tickets 312 but this now makes theft of the ticket even worse since the tickets 313 can be used from anywhere. Not just from within the private network. 315 3.4 The X Windowing System and X-term/Telnet 317 The X Windowing system is TCP based. However, the client-server 318 relationship with these applications is reverse compared to 319 most other applications. The X server or Open-windows server is the 320 display/mouse/keyboard unit (i.e., the one that controls the actual 321 Windows interface). The clients are the application programs driving 322 the Windows interface. 324 Some machines run multiple X Windows servers on the same machine. The 325 first X Windows server is at TCP port 6000. The first Open Windows 326 server can be at port 6000 or port 2000 (more flexible). We will 327 mainly refer X windowing system for illustration purposes here. 329 X-term Transmits IP addresses from the client to the server for the 330 purpose of setting the DISPLAY variable. When set the DISPLAY 331 variable is used for subsequent connections from X clients on the 332 host to an X server on the workstation. The DISPLAY variable is 333 sent inline during the TELNET negotiations as 334 DISPLAY=:. 336 where the is retrieved by looking at the local ip 337 address associated with the socket used to connect to . The 338 determines which port (6000 + ) should be used 339 to make the connection. is used to indicate which monitor 340 attached to the X server should be used but is not important to this 341 discussion. 343 The used is not a DNS name because: 345 . The is no ability for the local machine to know its DNS name 346 without performing a reverse DNS lookup on the local-ip-addr 348 . There is no guarantee that the name returned by a reverse 349 DNS lookup actually maps back to the local IP address. 351 . Lastly, without DNSSEC, it may not be safe to use DNS addresses 352 because they can easily be spoofed. NAT and DNS-ALG cannot work 353 unless DNSSEC is disabled. 355 A common use of this application is people dialing in to corporate 356 offices from their X terminals at home. Say, the X client is running 357 on a host on the public side of the NAT and X server is running on a 358 host on the private side of the NAT. The DISPLAY variable is 359 transmitted inline to the host the X client is running in some way. 360 The process transmitting the contents of the DISPLAY variable does 361 not know the address of the NAT. 363 If the channel transmitting the DISPLAY variable is not encrypted, 364 NAT device might solicit the help of an ALG to replace the 365 IP address and configure a port in the valid display range (ports 366 6000 and higher) to act as a gateway. Alternately, NAT may be 367 configured to listen for incoming connections to provide access 368 to the X Server(s), without requiring an ALG. But, this approach 369 increases the security risk by providing access to the X server that 370 would not otherwise be available. As the ALG tampers with the 371 IP addresses it will also not be possible for X Authorization methods 372 other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the 373 least secure of all the documented X Authorization methods. 375 When START_TLS is used there may be client certificate verification 376 problems caused by the NAT depending on the information provided in 377 the certificate. 379 3.5 RSH/RLOGIN 381 RSH uses multiple sessions to support separate streams for stdout and 382 stderr. A random port number is transmitted inline from the client to 383 the server for use as stderr port. The stderr socket is a connection 384 back from the server to the client. And unlike FTP, there is no 385 equivalent to PASV mode. For traditional NAT, this is a problem 386 as traditional NAT would not permit incoming sessions. 388 RLOGIN does not use multiple sessions. But the Kerberos protected 389 versions of RSH and RLOGIN will not work in a NAT environment due 390 to the ticket problems and the use of multiple sessions. 392 4.0 Protocols that can work with the aid of an ALG 394 This document predominantly addresses problems associated with 395 Traditional NAT, especially NAPT. 397 4.1 FTP 399 FTP is a TCP based application, used to reliably transfer files between 400 two hosts. FTP uses bundled session approach to accomplish this. 402 FTP is initiated by a client accessing a well-known port number 21 on 403 the FTP server. This is called the FTP control session. Often, an 404 additional data session accompanies the control session. By default, the 405 data session would be from TCP port 20 on server to the TCP port client 406 used to initiate control session. However, the data session ports may be 407 altered within the FTP control sessions using ASCII encoded PORT and 408 PASV commands and responses. 410 Say, an FTP client is in a NAT supported private network. An FTP ALG 411 will be required to monitor the FTP control session (for both PORT and 412 PASV modes) to identify the FTP data session port numbers and modify the 413 private address and port number with the externally valid address and 414 port number. In addition, the sequence and acknowledgement numbers, TCP 415 checksum, IP packet length and checksum have to be updated. Consequently 416 the sequence numbers in all subsequent packets for that stream must be 417 adjusted as well as TCP ACK fields and checksums. 419 In rare cases, increasing the size of the packet could cause it to 420 exceed the MTU of a given transport link. The packet would then have 421 to be fragmented which could affect performance. Or, if the packet has 422 the DF bit set, it would be ICMP rejected and the originating host 423 would then have to perform Path MTU Discovery. This could have an 424 adverse effect on performance. 426 Note however, if the control command channel is secured, it will be 427 impossible for an ALG to update the IP addresses in the command 428 exchange. 430 When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same 431 problems that occur with X-Term/Telnet occur with FTP. 433 Lastly, it is of interest to note section 4 of RFC 2428 (FTP extensions 434 for IPv6 and NATs) which describes how a new FTP port command (EPSV ALL) 435 can be used to allow NAT devices to fast-track the FTP protocol, 436 eliminating further processing through ALG, if the remote server 437 accepts "EPSV ALL". 439 4.2 RSVP 441 RSVP is positioned in the protocol stack at the transport layer, 442 operating on top of IP (either IPv4 or IPv6). However, unlike other 443 transport protocols, RSVP does not transport application data but 444 instead acts like other Internet control protocols (for example, ICMP, 445 IGMP, routing protocols). RSVP messages are sent hop-by-hop between 446 RSVP-capable routers as raw IP datagrams using protocol number 46. It is 447 intended that raw IP datagrams should be used between the end systems 448 and the first (or last) hop router. However, this may not always be 449 possible as not all systems can do raw network I/O. Because of this, it 450 is possible to encapsulate RSVP messages within UDP datagrams for end- 451 system communication. UDP-encapsulated RSVP messages are sent to either 452 port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP- 453 enabled router). For more information concerning UDP encapsulation of 454 RSVP messages; consult Appendix C of RFC 2205. 456 An RSVP session, a data flow with a particular destination and 457 transport-layer protocol, is defined by: 459 Destination Address - the destination IP address for the data packets. 460 This may be either a unicast or a multicast address. 462 Protocol ID - the IP protocol ID (for example, UDP or TCP). 464 Destination Port - a generalized destination port that is used for 465 demultiplexing at a layer above the IP layer. 467 NAT devices are presented with unique problems when it comes to 468 supporting RSVP. Two issues are: 470 1. RSVP message objects may contain IP addresses. The result is that an 471 RSVP-ALG must be able to replace the IP addresses based upon the 472 direction and type of the message. For example, if an external sender 473 were to send an RSVP Path message to an internal receiver, the RSVP 474 session will specify the IP address that the external sender believes is 475 the IP address of the internal receiver. However, when the RSVP Path 476 message reaches the NAT device, the RSVP session must be changed to 477 reflect the IP address that is used internally for the receiver. Similar 478 actions must be taken for all message objects that contain IP addresses. 480 2. RSVP provides a means, the RSVP Integrity object, to guarantee the 481 integrity of RSVP messages. The problem is that because of the first 482 point, a NAT device must be able to change IP addresses within the RSVP 483 messages. However, when this is done, the RSVP Integrity object is no 484 longer valid as the RSVP message has been changed. Therefore an RSVP-ALG 485 will not work when RSVP Integrity Object is used. 487 4.3 DNS 489 DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts 490 which use local DNS servers in NAT private realm. DNS name to address 491 mapping for hosts in private domain should be configured on an 492 authoritative name server within private domain. This server would 493 be accessed by external and internal hosts alike for name 494 resolutions. A DNS-ALG would be required to perform address to name 495 conversions on DNS queries and responses. RFC 2694 describes DNS-ALG 496 in detail. If DNS packets are encrypted/authenticated per DNSSEC, 497 then DNS_ALG will fail because it won't be able to perform payload 498 modifications. 500 Applications using DNS resolver to resolve a DNS name into an 501 IP address, assume availability of address assignment for reuse 502 by the application specific session. As a result, DNS-ALG will 503 be required to keep the address assignment (between private and 504 external addresses) valid for a pre-configured period of time, 505 past the DNS query. 507 Alternately, if there isn't a need for a name server within private 508 domain, private domain hosts could simply point to an external name 509 server for external name lookup. No ALG is required when the name 510 server is located in external domain. 512 4.4 SMTP 514 SMTP is a TCP based protocol (Refer RFC 821), used by Internet 515 email programs such as sendmail to send TCP-based email messages 516 to well-known port 25. The mail server may be located within or 517 outside private domain. But, the server must be assigned a global 518 name and address, accessible by external hosts. When mail server 519 is located within private domain, inbound SMTP sessions must be 520 redirected to the private host from its externally assigned 521 address. No special mapping is required when Mail server is 522 located in external domain. 524 Generally speaking, mail systems are configured such that all 525 users specify a single centralized address (such as 526 fooboo@company.com), instead of including individual hosts (such 527 as fooboo@hostA.company.com). The central address must have an MX 528 record specified in the DNS name server accessible by external 529 hosts. 531 In the majority of cases, mail messages do not contain reference 532 to private IP addresses or links to content data via names that 533 are not visible to outside. However, some mail messages do contain 534 IP addresses of the MTAs that relay the message in the "Received: " 535 field. Some mail messages use IP addresses in place of FQDN for 536 debug purposes or due to lack of a DNS record, in "Mail From: " 537 field. 539 If one or more MTAs were to be located behind NAT in a private 540 domain, and the mail messages are not secured by signature or 541 cryptographic keys, an SMTP-ALG may be used to translate the 542 IP address information registered by the MTAs. If the MTAs 543 have static address mapping, the translation would be valid 544 across realms for long periods of time. 546 The ability to trace the mail route may be hampered or prevented 547 by NAT alone, without the ALG. This can cause problems when 548 debugging mail problems or tracking down abusive users of mail. 550 4.5 SIP 552 SIP (Refer [SIP]) can run on either TCP or UDP, but by default on 553 the same port 5060. 555 When used with UDP, a response to a SIP request does not go to the 556 source port the request came from. Rather the SIP message contains 557 the port number the response should be sent to. SIP makes use of 558 ICMP port unreachable errors in the response to request 559 transmissions. Request messages are usually sent on the connected 560 socket. If responses are sent to the source port in the request, 561 each thread handling a request would have to listen on the socket 562 it sent the request on. However, by allowing responses to come to 563 a single port, a single thread can be used for listening instead. 565 A server may prefer to place the source port of each connected 566 socket in the message. Then each thread can listen for responses 567 separately. Since the port number for a response may not go to 568 the source port of the request, SIP will not normally traverse 569 a NAT and would require a SIP-ALG. 571 SIP messages carry arbitrary content, which is defined by a MIME type. 573 For multimedia sessions, this is usually the Session Description 574 Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be 575 used for the exchange of multimedia. These may loose significance when 576 traversing a NAT. Thus a SIP-ALG would need the intelligence to 577 decipher and translate realm-relevant information. 579 SIP carries URL's in its Contact, To and From fields that specify 580 signaling addresses. These URL's can contain IP addresses or domain 581 names in the host port portion of the URL. These may not be valid 582 once they traverse a NAT. 584 As an alternative to an SIP-ALG, SIP supports a proxy server which 585 could co-reside with NAT and function on the globally significant 586 NAT port. Such a proxy would have a locally specific configuration. 588 4.6 RealAudio 590 In default mode, RealAudio clients (say, in a private domain) 591 access TCP port 7070 to initiate conversation with a real-audio server 592 (say, located an external domain) and to exchange control messages 593 during playback (ex: pausing or stopping the audio stream). Audio 594 session parameters are embedded in the TCP control session as 595 byte stream. 597 The actual audio traffic is carried in the opposite direction on 598 incoming UDP based packets (originated from the server) directed 599 to ports in the range of 6970-7170. 601 As a result, RealAudio is broken by default on a traditional NAT 602 device. A work around for this would be for the ALG to examine the 603 TCP traffic to determine the audio session parameters and 604 selectively enable inbound UDP sessions for the ports agreed upon 605 in the TCP control session. Alternately, the ALG could simply 606 redirect all inbound UDP sessions directed to ports 6970-7170 to 607 the client address in the private domain. 609 For bi-Directional NAT, you will not need an ALG. Bi-directional NAT 610 could simply treat each of the TCP and UDP sessions as 2 unrelated 611 sessions and perform IP and TCP/UDP header level translations. 613 The readers may contact RealNetworks, Inc. for detailed guidelines 614 on how their applications can be made to work, traversing through NAT 615 and firewall devices. 617 4.7 H.323 619 H.323 is complex, uses dynamic ports, and includes multiple UDP streams. 620 Here is a summary of the relevant issues: 622 An H.323 call is made up of many different simultaneous connections. At 623 least two of the connections are TCP. For an audio-only conference, 624 there may be up to 4 different UDP 'connections' made. 626 All connections except one are made to ephemeral (dynamic) ports. 628 Calls can be initiated from the private as well as the external domain. 629 For conferencing to be useful, external users need to be able to 630 establish calls directly with internal users' desktop systems. 632 The addresses and port numbers are exchanged within the data stream of 633 the 'next higher' connection. For example, the port number for the H.245 634 connection is established within the Q.931 data stream. (This makes it 635 particularly difficult for the ALG, which will be required to modify the 636 addresses inside those data streams.) To make matters worse, it is 637 possible in Q.931, for example, to specify that the H.245 connection 638 should be secure (encrypted). If a session is encrypted, it is 639 impossible for the ALG to decipher 640 the data stream, unless it has access to the shared key. 642 Most of the control information is encoded in ASN.1 (only the User-User 643 Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded 644 (other parts of each Q.931 PDU are not encoded). For those unfamiliar 645 with ASN.1, suffice it to say that it is a complex encoding scheme, 646 which does not end up with fixed byte offsets for address information. 647 In fact, the same version of the same application connecting to the same 648 destination may negotiate to include different options, changing the 649 byte offsets. 651 Below is the protocol exchange for a typical H.323 call between User A 652 and User B. A's IP address is 88.88.88.88 and B's IP address is 653 99.99.99.99. Note that the Q.931 and H.245 messages are encoded in 654 ASN.1 in the payload of an RTP packet. So to accomplish a connection 655 through a NAT device, an H.323-ALG will be required to examine the 656 packet, decode the ASN.1, and translate the various H.323 control IP 657 addresses. 659 User A User B 660 A establishes connection to B on well- 661 known Q.931 port (1720) 663 -----------------------------------------------> 664 Q.931 Setup caller address = 88.88.88.88 665 caller port = 1120 666 callee address = 99.99.99.99 667 callee port = 1720 669 <----------------------------------------------- 670 Q.931 Alerting 671 <----------------------------------------------- 672 Q.931 Connect H.245 address = 99.99.99.99 673 H.245 port = 1092 675 User A establishes connection to User B at 676 99.99.99.99, port 1092 678 <----------------------------------------------> 679 Several H.245 messages are exchanged (Terminal 680 Capability Set, Master Slave Determination and 681 their respective ACKs) 683 <----------------------------------------------- 684 H.245 Open Logical Channel, channel = 257 685 RTCP address = 99.99.99.99 686 RTCP port = 1093 687 -----------------------------------------------> 688 H.245 Open Logical Channel Ack, channel = 257 689 RTP address = 88.88.88.88 690 RTP port = 2002 691 (This is where User A would like RTP 692 data sent to) 693 RTCP address = 88.88.88.88 694 RTCP port = 2003 695 -----------------------------------------------> 696 H.245 Open Logical Channel, channel = 257 697 RTCP address = 88.88.88.88 698 RTCP port = 2003 699 <----------------------------------------------- 700 H.245 Open Logical Channel Ack, channel = 257 701 RTP address = 99.99.99.99 702 RTP port = 1092 703 (This is where User B would like RTP data 704 sent to) 705 RTCP address = 99.99.99.99 706 RTP port = 1093 708 Also note that if an H.323 Gateway resided inside a NAT boundary, the 709 ALG would have to be cognizant of the various gateway discovery schemes 710 and adapt to those schemes as well. Or if just the H.323 host/terminal 711 was inside the NAT boundary and tried to register with a Gatekeeper, the 712 IP information in the registration messages would have to be translated 713 by NAT. 715 4.8 SNMP 717 SNMP is a network management protocol based on UDP. SNMP payload may 718 contain IP addresses or may refer IP addresses through an index 719 into a table. As a result, when devices within a private network 720 are managed by an external node, SNMP packets transiting a NAT 721 device may contain information that is not relevant in external 722 domain. In some cases, as described in [SNMP-ALG], an SNMP ALG may 723 be used to transparently convert realm-specific addresses into 724 globally unique addresses. Such an ALG assumes static address 725 mapping and can only work in conjunction with SNMPv1 or SNMPv2c 726 protocols and bi-directional NAT. 728 Making SNMP ALGs completely transparent to all management 729 applications is not an achievable task. The ALGs will run into 730 problems with SNMPv3 security features, when authentication (and 731 optionally privacy) is enabled, unless the ALG has access to 732 security keys. 734 Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used 735 in conjunction with NAT to forward SNMP messages to external SNMP 736 engines (and vice versa). SNMP proxies are tailored to the private 737 domain context and can hence operate independent of the specific 738 managed object types being accessed. The proxy solution will require 739 the external management application to be aware of the proxy 740 forwarder and the individual nodes being managed will need to be 741 configured to direct their SNMP traffic (notifications and requests) 742 to the proxy forwarder. 744 [NAT-ARCH] also refers to limitations with running centralized SNMP 745 based applications, controlling devices/networks in multiple address 746 realms. Such an application would require context specific SNMP 747 packets to transit NAT devices. 749 5.0 Protocols designed explicitly to work with NAT enroute 751 5.1 Activision Games 753 Activision Games were designed to be NAT-friendly so as not to require 754 an ALG for the games to work transparently through traditional NAT 755 devices. Game players within a private domain can play with other 756 players in the same domain or external domain. Activision gaming 757 protocol is proprietary and is based on UDP. The server uses UDP 758 port no. 21157. 760 All peers are somehow informed of each others' public and private 761 addresses, and each client opens up symmetrical direct connection to 762 each other and use whichever address (private or external) works first. 763 Now, the clients can have a session directly with other clients directly 764 (or) they can have session with other clients via the gaming server. 765 The key is to allow the reuse of the tuple of the same (global 766 address, assigned UDP port) for initial connection to the game server 767 (helper) and the subsequent connection to the client. A game player is 768 recognized by one of (private address, UDP port) or (Assigned global 769 address, assigned UDP port) by all other peer players. So, the binding 770 between tuples should remain unchanged so long as the gaming player is 771 in session with one or multiple other players. 773 Opening a connection to a game server in external realm from a private 774 host is no problem. All NAT would have to do is provide routing 775 transparency. 777 But, an NAPT configuration MUST allow multiple simultaneous UDP 778 connections on the same assigned global address/port. 780 The readers may refer Activision for the proprietary, detailed 781 information on the function and design of this protocol. 783 6.0. Acknowledgements 785 The authors would like to express sincere thanks to Bernard Aboba, 786 Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine, 787 Jeffrey Altman, Keith Moore, Vernon Shryver and others that had 788 provided valuable input in preparing this draft. 790 7.0. Security considerations 792 The security considerations outlined in [NAT-TERM] are relevant to 793 all NAT devices. This draft does not warrant additional security 794 considerations. 796 8.0 References 798 [NAT-TERM] Srisuresh, P., Holdrege, M. "IP Network Address Translator 799 (NAT) Terminology and Considerations", RFC 2663 801 [NAT-TRAD] Srisuresh, P., Egevang, K. "Traditional IP Network Address 802 Translator(Traditional NAT)", 803 804 [H.323] ITU-T SG16 H.323, Intel white paper, H.323 and 805 Firewalls; Dave Chouinard, John Richardson, Milind Khare 806 (with further assistance from Jamie Jason). 808 [SNMP-ALG] Raz, D., Schoenwaelder, J., and Sugla, B. "An SNMP 809 Application Level Gateway for Payload Address Translation", 810 812 [SNMP_APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", 813 RFC 2573 815 [NAT-ARCH] Hain, T. "Architectural Implications of NAT", 816 818 [SMTP] RFC 821 820 [FTP] RFC 959 822 [SIP] RFC 2543 824 [X Windows] RFC 1198 826 [RSVP] RFC 2205 828 [DNS] RFC 1034, RFC 1035, RFC 2694 830 [IPsec] RFC 2401, RFC 2402, RFC 2406, RFC 2411, RFC 2709 832 [PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, 833 and, Lear, E. "Address Allocation for Private Internets", 834 RFC 1918 836 [ADDR-BEHA] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 837 Address Behaviour Today", RFC 2101 838 Authors Addresses: 840 Matt Holdrege 841 ipVerse 842 223 Ximeno Ave. 843 Long Beach, CA 90803 844 EMail: matt@ipverse.com 846 Pyda Srisuresh 847 Consultant 848 849 Erie Circle 849 Milpitas, CA 95035 850 U.S.A. 851 Voice: (408) 263-7527 852 EMail: srisuresh@yahoo.com