Network Working Group M. Holdrege Request for Comments: 3027 ipVerse Category: Informational P. Srisuresh Jasmine Networks January 2001 Protocol Complications with the IP Network Address Translator Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractMany internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IP Network Address Translator (NAT) enroute to bridge the realms. The NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered. 1.0 Introduction .............................................. 2 2.0 Common Characteristics of Protocols broken by NAT ......... 2 3.0 Protocols that cannot work with NAT enroute ............... 4 4.0 Protocols that can work with the aid of an ALG ............ 8 5.0 Protocols designed explicitly to work with NAT enroute .... 16 6.0 Acknowledgements .......................................... 17 7.0 Security Considerations ................................... 17 8.0 References ................................................ 17 9.0 Authors' Addresses ........................................ 19 10.0 Full Copyright Statement ................................ 20
NAT-TERM]. In a nutshell, NAT attempts to provide a transparent routing solution to end hosts requiring communication to disparate address realms. NAT modifies end node addresses (within the IP header of a packet) en- route and maintains state for these updates so that datagrams pertaining to a session are transparently routed to the right end- node in either realm. Where possible, application specific ALGs may be used in conjunction with NAT to provide application level transparency. Unlike NAT, the function of ALG is application specific and would likely require examination and recomposition of IP payload. The following sections attempt to list applications that are known to have been impacted by NAT devices enroute. However, this is by no means a comprehensive list of all known protocols and applications that have complications with NAT - rather just a subset of the list gathered by the authors. It is also important to note that this document is not intended to advocate NAT, but rather to point out the complications with protocols and applications when NAT devices are enroute. NAT-TERM] and [NAT-TRAD] have sections listing the specific nature of problems and limitations to NAT devices. Some of these limitations are being restated in this section to summarize characteristics of protocols that are broken by NAT.
session to be unrelated to one another. Applications in this case can fail for a variety of reasons. Two most likely reasons for failures are: (a) addressing information in control payload is realm-specific and is not valid once packet crosses the originating realm, (b) control session permits data session(s) to originate in a direction that NAT might not permit. When DNS names are used in control payload, NAT device in conjunction with a DNS-ALG might be able to offer the necessary application level transparency, if NAT has no contention with data session orientation. However, using DNS names in place of realm-specific IP addresses may not be an option to many of these applications (e.g., FTP). When realm-specific addressing is specified in payload, and the payload is not encrypted, an ALG may in some cases be able to provide the work around necessary to make the applications run transparently across realms. The complexity of ALG depends on the application level knowledge required to process payload and maintain state. NAT-TRAD]. Briefly, the problem goes as follows. Say, two private hosts originated fragmented
TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, the target host is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted. IPsec-AH] on the other hand is explicitly designed to detect alterations to IP packet header. So when NAT alters the address information enroute in IP header, the destination host receiving the altered packet will invalidate the packet since the contents of the headers have been altered. The IPsec AH secure packet traversing NAT will simply not reach the target application, as a result.
IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by NAT device enroute only in a limited number of cases. In the case of TCP/UDP packets, NAT would need to update the checksum in TCP/UDP headers, when an address in IP header is changed. However, as the TCP/UDP header is encrypted by the ESP, NAT would not be able to make this checksum update. As a result, TCP/UDP packets encrypted in transport mode ESP, traversing a NAT device will fail the TCP/UDP checksum validation on the receiving end and will simply not reach the target application. Internet Key Exchange Protocol IKE can potentially pass IP addresses as node identifiers during Main, Aggressive and Quick Modes. In order for an IKE negotiation to correctly pass through a NAT, these payloads would need to be modified. However, these payloads are often protected by hash or obscured by encryption. Even in the case where IP addresses are not used in IKE payloads and an IKE negotiation could occur uninterrupted, there is difficulty with retaining the private-to-external address mapping on NAT from the time IKE completed negotiation to the time IPsec uses the key on an application. In the end, the use of end-to-end IPsec is severely hampered anyway, as described earlier. For all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute.
not to let NAT drop the address binding. Alternately, an ALG will need to be deployed to ensure that NAT would not change address bindings during the lifetime of a ticket and between the time a ticket is issued to private host and the time the ticket is used by private host. But, the ticket will be valid from any host within the private realm of NAPT. Without NAPT, an attacker needs to be able to spoof the source IP addresses of a connection that is being made in order to use a stolen ticket on a different host. With NAPT, all the attacker needs to do from the private realm of NAPT is to simply gain possession of a ticket. Of course, this assumes, NAPT private domain is not a trusted network - not surprisingly, since many attacks occur from inside the organization.
The second method is to remove all IP addresses from the K5 tickets but this now makes theft of the ticket even worse since the tickets can be used from anywhere. Not just from within the private network.
host on the private side of the NAT. The DISPLAY variable is transmitted inline to the host the X client is running in some way. The process transmitting the contents of the DISPLAY variable does not know the address of the NAT. If the channel transmitting the DISPLAY variable is not encrypted, NAT device might solicit the help of an ALG to replace the IP address and configure a port in the valid display range (ports 6000 and higher) to act as a gateway. Alternately, NAT may be configured to listen for incoming connections to provide access to the X Server(s), without requiring an ALG. But, this approach increases the security risk by providing access to the X server that would not otherwise be available. As the ALG tampers with the IP addresses it will also not be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the least secure of all the documented X Authorization methods. When START_TLS is used there may be client certificate verification problems caused by the NAT depending on the information provided in the certificate.
the data session would be from TCP port 20 on server to the TCP port client used to initiate control session. However, the data session ports may be altered within the FTP control sessions using ASCII encoded PORT and PASV commands and responses. Say, an FTP client is in a NAT supported private network. An FTP ALG will be required to monitor the FTP control session (for both PORT and PASV modes) to identify the FTP data session port numbers and modify the private address and port number with the externally valid address and port number. In addition, the sequence and acknowledgement numbers, TCP checksum, IP packet length and checksum have to be updated. Consequently the sequence numbers in all subsequent packets for that stream must be adjusted as well as TCP ACK fields and checksums. In rare cases, increasing the size of the packet could cause it to exceed the MTU of a given transport link. The packet would then have to be fragmented which could affect performance. Or, if the packet has the DF bit set, it would be ICMP rejected and the originating host would then have to perform Path MTU Discovery. This could have an adverse effect on performance. Note however, if the control command channel is secured, it will be impossible for an ALG to update the IP addresses in the command exchange. When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same problems that occur with X-Term/Telnet occur with FTP. Lastly, it is of interest to note section 4 of RFC 2428 (FTP extensions for IPv6 and NATs) which describes how a new FTP port command (EPSV ALL) can be used to allow NAT devices to fast-track the FTP protocol, eliminating further processing through ALG, if the remote server accepts "EPSV ALL".
RSVP messages are sent to either port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP-enabled router). For more information concerning UDP encapsulation of RSVP messages; consult Appendix C of RFC 2205. An RSVP session, a data flow with a particular destination and transport-layer protocol, is defined by: Destination Address - the destination IP address for the data packets. This may be either a unicast or a multicast address. Protocol ID - the IP protocol ID (for example, UDP or TCP). Destination Port - a generalized destination port that is used for demultiplexing at a layer above the IP layer. NAT devices are presented with unique problems when it comes to supporting RSVP. Two issues are: 1. RSVP message objects may contain IP addresses. The result is that an RSVP-ALG must be able to replace the IP addresses based upon the direction and type of the message. For example, if an external sender were to send an RSVP Path message to an internal receiver, the RSVP session will specify the IP address that the external sender believes is the IP address of the internal receiver. However, when the RSVP Path message reaches the NAT device, the RSVP session must be changed to reflect the IP address that is used internally for the receiver. Similar actions must be taken for all message objects that contain IP addresses. 2. RSVP provides a means, the RSVP Integrity object, to guarantee the integrity of RSVP messages. The problem is that because of the first point, a NAT device must be able to change IP addresses within the RSVP messages. However, when this is done, the RSVP Integrity object is no longer valid as the RSVP message has been changed. Therefore an RSVP-ALG will not work when RSVP Integrity Object is used. DNS-ALG] describes DNS- ALG
in detail. If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail because it won't be able to perform payload modifications. Applications using DNS resolver to resolve a DNS name into an IP address, assume availability of address assignment for reuse by the application specific session. As a result, DNS-ALG will be required to keep the address assignment (between private and external addresses) valid for a pre-configured period of time, past the DNS query. Alternately, if there isn't a need for a name server within private domain, private domain hosts could simply point to an external name server for external name lookup. No ALG is required when the name server is located in external domain. SMTP]), used by Internet email programs such as sendmail to send TCP-based email messages to well- known port 25. The mail server may be located within or outside private domain. But, the server must be assigned a global name and address, accessible by external hosts. When mail server is located within private domain, inbound SMTP sessions must be redirected to the private host from its externally assigned address. No special mapping is required when Mail server is located in external domain. Generally speaking, mail systems are configured such that all users specify a single centralized address (such as firstname.lastname@example.org), instead of including individual hosts (such as fooboo@hostA.company.com). The central address must have an MX record specified in the DNS name server accessible by external hosts. In the majority of cases, mail messages do not contain reference to private IP addresses or links to content data via names that are not visible to outside. However, some mail messages do contain IP addresses of the MTAs that relay the message in the "Received: " field. Some mail messages use IP addresses in place of FQDN for debug purposes or due to lack of a DNS record, in "Mail From: " field. If one or more MTAs were to be located behind NAT in a private domain, and the mail messages are not secured by signature or cryptographic keys, an SMTP-ALG may be used to translate the IP address information registered by the MTAs. If the MTAs have static address mapping, the translation would be valid across realms for long periods of time.
The ability to trace the mail route may be hampered or prevented by NAT alone, without the ALG. This can cause problems when debugging mail problems or tracking down abusive users of mail. SIP]) can run on either TCP or UDP, but by default on the same port 5060. When used with UDP, a response to a SIP request does not go to the source port the request came from. Rather the SIP message contains the port number the response should be sent to. SIP makes use of ICMP port unreachable errors in the response to request transmissions. Request messages are usually sent on the connected socket. If responses are sent to the source port in the request, each thread handling a request would have to listen on the socket it sent the request on. However, by allowing responses to come to a single port, a single thread can be used for listening instead. A server may prefer to place the source port of each connected socket in the message. Then each thread can listen for responses separately. Since the port number for a response may not go to the source port of the request, SIP will not normally traverse a NAT and would require a SIP-ALG. SIP messages carry arbitrary content, which is defined by a MIME type. For multimedia sessions, this is usually the Session Description Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be used for the exchange of multimedia. These may loose significance when traversing a NAT. Thus a SIP-ALG would need the intelligence to decipher and translate realm-relevant information. SIP carries URL's in its Contact, To and From fields that specify signaling addresses. These URL's can contain IP addresses or domain names in the host port portion of the URL. These may not be valid once they traverse a NAT. As an alternative to an SIP-ALG, SIP supports a proxy server which could co-reside with NAT and function on the globally significant NAT port. Such a proxy would have a locally specific configuration.
The actual audio traffic is carried in the opposite direction on incoming UDP based packets (originated from the server) directed to ports in the range of 6970-7170. As a result, RealAudio is broken by default on a traditional NAT device. A work around for this would be for the ALG to examine the TCP traffic to determine the audio session parameters and selectively enable inbound UDP sessions for the ports agreed upon in the TCP control session. Alternately, the ALG could simply redirect all inbound UDP sessions directed to ports 6970-7170 to the client address in the private domain. For bi-Directional NAT, you will not need an ALG. Bi-directional NAT could simply treat each of the TCP and UDP sessions as 2 unrelated sessions and perform IP and TCP/UDP header level translations. The readers may contact RealNetworks for detailed guidelines on how their applications can be made to work, traversing through NAT and firewall devices.
ASN.1-encoded (other parts of each Q.931 PDU are not encoded). For those unfamiliar with ASN.1, suffice it to say that it is a complex encoding scheme, which does not end up with fixed byte offsets for address information. In fact, the same version of the same application connecting to the same destination may negotiate to include different options, changing the byte offsets. Below is the protocol exchange for a typical H.323 call between User A and User B. A's IP address is 22.214.171.124 and B's IP address is 126.96.36.199. Note that the Q.931 and H.245 messages are encoded in ASN.1 in the payload of an RTP packet. So to accomplish a connection through a NAT device, an H.323-ALG will be required to examine the packet, decode the ASN.1, and translate the various H.323 control IP addresses. User A User B A establishes connection to B on well- known Q.931 port (1720) -----------------------------------------------> Q.931 Setup caller address = 188.8.131.52 caller port = 1120 callee address = 184.108.40.206 callee port = 1720 <----------------------------------------------- Q.931 Alerting <----------------------------------------------- Q.931 Connect H.245 address = 220.127.116.11 H.245 port = 1092 User A establishes connection to User B at 18.104.22.168, port 1092 <----------------------------------------------> Several H.245 messages are exchanged (Terminal Capability Set, Master Slave Determination and their respective ACKs) <----------------------------------------------- H.245 Open Logical Channel, channel = 257 RTCP address = 22.214.171.124 RTCP port = 1093 -----------------------------------------------> H.245 Open Logical Channel Ack, channel = 257 RTP address = 126.96.36.199 RTP port = 2002 (This is where User A would like RTP data sent to)
RTCP address = 188.8.131.52 RTCP port = 2003 -----------------------------------------------> H.245 Open Logical Channel, channel = 257 RTCP address = 184.108.40.206 RTCP port = 2003 <----------------------------------------------- H.245 Open Logical Channel Ack, channel = 257 RTP address = 220.127.116.11 RTP port = 1092 (This is where User B would like RTP data sent to) RTCP address = 18.104.22.168 RTP port = 1093 Also note that if an H.323 Gateway resided inside a NAT boundary, the ALG would have to be cognizant of the various gateway discovery schemes and adapt to those schemes as well. Or if just the H.323 host/terminal was inside the NAT boundary and tried to register with a Gatekeeper, the IP information in the registration messages would have to be translated by NAT. SNMP-ALG], an SNMP ALG may be used to transparently convert realm-specific addresses into globally unique addresses. Such an ALG assumes static address mapping and bi- directional NAT. It can only work for the set of data types (textual conventions) understood by the SNMP-ALG implementation and for a given set of MIB modules. Furthermore, replacing IP addresses in the SNMP payload may lead to communication failures due to changes in message size or changes in the lexicographic ordering. Making SNMP ALGs completely transparent to all management applications is not an achievable task. The ALGs will run into problems with SNMPv3 security features, when authentication (and optionally privacy) is enabled, unless the ALG has access to security keys. [NAT-ARCH] also hints at potential issues with SNMP management via NAT. Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used in conjunction with NAT to forward SNMP messages to external SNMP engines (and vice versa). SNMP proxies are tailored to the private
domain context and can hence operate independent of the specific managed object types being accessed. The proxy solution will require the external management application to be aware of the proxy forwarder and the individual nodes being managed will need to be configured to direct their SNMP traffic (notifications and requests) to the proxy forwarder.
The above approach has some problems. For example, a client could try contacting a private address, but that private address could be in use locally, when the private address at some other realm is meant. If the node that was contacted wrongfully has some other service or no service registered for the UDP port, the Activision connect messages are expected to be simply dropped. In the unlikely event, a registered application chooses to interpret the message, the results can be unpredictable. The readers may refer to Activision for the proprietary, detailed information on the function and design of this protocol. NAT-TERM] are relevant to all NAT devices. This document does not warrant additional security considerations. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [H.323] ITU-T SG16 H.323, Intel white paper, "H.323 and Firewalls", Dave Chouinard, John Richardson, Milind Khare (with further assistance from Jamie Jason). [SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000. [SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993, November 2000. [SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10, RFC 821, August 1982. [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [SIP] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC 1198, January 1991. [RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999. [PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.