diff options
Diffstat (limited to 'doc/rfc/rfc3027.txt')
| -rw-r--r-- | doc/rfc/rfc3027.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc3027.txt b/doc/rfc/rfc3027.txt new file mode 100644 index 0000000..e0f5772 --- /dev/null +++ b/doc/rfc/rfc3027.txt @@ -0,0 +1,1123 @@ + + + + + + +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. + +Abstract + + Many 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. + +Table of Contents + + 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 + + + + +Holdrege & Srisuresh Informational [Page 1] + +RFC 3027 Protocol Complications with NAT January 2001 + + +1.0 Introduction + + This document requires the reader to be familiar with the terminology + and function of NAT devices as described in [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. + +2.0 Common Characteristics of Protocols broken by NAT + + [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. + +2.1 Realm-specific IP address information in payload + + A wide range of applications fail with NAT enroute when IP packets + contain realm-specific IP address or port information in payload. An + ALG may be able to provide work around in some cases. But, if the + packet payload is IPsec secured (or secure by a transport or + application level security mechanisms), the application is bound to + fail. + +2.2 Bundled session applications + + Bundled session applications such as FTP, H.323, SIP and RTSP, which + use a control connection to establish a data flow are also usually + broken by NAT devices enroute. This is because these applications + exchange address and port parameters within control session to + establish data sessions and session orientations. NAT cannot know + the inter-dependency of the bundled sessions and would treat each + + + +Holdrege & Srisuresh Informational [Page 2] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +2.3 Peer-to-peer applications + + Peer-to-peer applications more than client-server based applications + are likely to break with NAT enroute. Unlike Client-server + applications, Peer-to-peer applications can be originated by any of + the peers. When peers are distributed across private and public + realms, a session originated from an external realm is just as likely + as the session from a host in private realm. External peers will be + able to locate their peers in private realm only when they know the + externally assigned IP address or the FQDN ahead of time. FQDN name + to assigned address mapping can happen only so long as the enroute + NAT device supports DNS-ALG. Examples of Peer-to-peer applications + include interactive games, Internet telephony and event-based + protocols (such as Instant-Messaging). + + This is particularly a problem with traditional NAT and may be less + of an issue with bi-directional NAT, where sessions are permitted in + both directions. + + A possible work-around for this type of problem with traditional-NAT + is for private hosts to maintain an outbound connection with a server + acting as their representative to the globally routed Internet. + +2.4 IP fragmentation with NAPT enroute + + IP fragmentation with NAPT enroute is not an issue with any single + application, but pervades across all TCP/UDP applications. The + problem is described in detail in [NAT-TRAD]. Briefly, the problem + goes as follows. Say, two private hosts originated fragmented + + + +Holdrege & Srisuresh Informational [Page 3] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +2.5 Applications requiring retention of address mapping + + NAT will most likely break applications that require address mapping + to be retained across contiguous sessions. These applications + require the private-to-external address mapping to be retained + between sessions so the same external address may be reused for + subsequent session interactions. NAT cannot know this requirement + and may reassign external address to different hosts between + sessions. + + Trying to keep NAT from discarding an address mapping would require a + NAT extension protocol to the application that would allow the + application to inform the NAT device to retain the mappings. + Alternately, an ALG may be required to interact with NAT to keep the + address mapping from being discarded by NAT. + +2.6 Applications requiring more public addresses than available + + This is a problem when the number of private hosts is larger than the + external addresses available to map the private addresses into. Take + for example the rlogin service initiated from a host in private realm + supported by NAPT. Rlogin service clients use well-known rlogin port + 512 as their TCP port ID. No more than one host in private realm can + initiate the service. This is a case of trying to use a service that + fundamentally requires more public addresses than are available. NAT + devices can conserve addresses, but they cannot create more + addresses. + +3.0 Protocols that cannot work with NAT enroute + +3.1 IPsec and IKE + + NAT fundamentally operates by modifying end node addresses (within + the IP header) en-route. The IPsec AH standard [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. + + + + +Holdrege & Srisuresh Informational [Page 4] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +3.2 Kerberos 4 + + Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be + written. When the KDC receives a ticket request, it includes the + source IP address in the returned ticket. Not all Kerberos 4 + services actually check source IP addresses. AFS is a good example + of a Kerberos 4 service which does not. Services which don't check + are not picky about NAT devices enroute. Kerberos tickets are tied + to the IP address that requested the ticket and the service with + which to use the ticket. + + The K4 ticket (response) contains a single IP address describing the + interface used by the client to retrieve the ticket from the TGT + from the perspective of KDC. This works fine if the KDC is across a + NAT gateway and as long as all of the Kerberos services are also + across a NAT gateway. The end user on private network will not + notice any problems. + + There is also the caveat that NAT uses the same address mapping for + the private host for the connection between the client and the KDC as + for the connection between the client and the application server. A + work around this problem would be to keep an arbitrary connection + open to remote server during throughout the ticket lifetime, so as + + + +Holdrege & Srisuresh Informational [Page 5] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +3.3 Kerberos 5 + + Just as with Kerberos 4, Kerberos 5 tickets are encrypted. + Therefore, an ALG cannot be written. + + In Kerberos 5, the client specifies a list of IP addresses which the + ticket should be valid for, or it can ask for a ticket valid for all + IP addresses. By asking for an all-IP-addresses ticket or a ticket + containing the NAPT device address, you can get krb5 to work with an + NAPT device, although it isn't very transparent (it requires the + clients to behave differently than they otherwise would). The MIT + krb5 1.0 implementation didn't have any configurability for what IP + addresses the client asked for (it always asked for the set of its + interface addresses) and did not interact well with NAT. The MIT + krb5 1.1 implementation allows you to put "noaddresses" somewhere in + krb5.conf to request all-IP-addresses-valid tickets. + + The K5 ticket (response) contains IP addresses, as requested by the + client node, from which the ticket is to be considered valid. If the + services being accessed with Kerberos authentication are on the + public side of the NAT, then the Kerberos authentication will fail + because the IP address used by the NAT (basic NAT or NAPT) is not in + the list of acceptable addresses. + + There are two workarounds in Kerberos 5 both of which reduce the + security of the tickets. The first is to have the clients in NAPT + private realm specify the public IP address of the NAPT in the + ticket's IP list. But this leads to the same security problem + detailed for K4. Plus, it is not obvious for the client in the + private domain to find out the public IP Address of the NAPT. That + would be a change of application behavior on end-host. + + + + + +Holdrege & Srisuresh Informational [Page 6] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +3.4 The X Windowing System and X-term/Telnet + + The X Windowing system is TCP based. However, the client-server + relationship with these applications is reverse compared to most + other applications. The X server or Open-windows server is the + display/mouse/keyboard unit (i.e., the one that controls the actual + Windows interface). The clients are the application programs driving + the Windows interface. + + Some machines run multiple X Windows servers on the same machine. + The first X Windows server is at TCP port 6000. The first Open + Windows server can be at port 6000 or port 2000 (more flexible). We + will mainly refer X windowing system for illustration purposes here. + + X-term Transmits IP addresses from the client to the server for the + purpose of setting the DISPLAY variable. When set the DISPLAY + variable is used for subsequent connections from X clients on the + host to an X server on the workstation. The DISPLAY variable is sent + inline during the TELNET negotiations as + + DISPLAY=<local-ip-addr>:<server>.<display> + + where the <local-ip-addr> is retrieved by looking at the local ip + address associated with the socket used to connect to <server>. The + <server> determines which port (6000 + <server>) should be used to + make the connection. <display> is used to indicate which monitor + attached to the X server should be used but is not important to this + discussion. + + The <local-ip-addr> used is not a DNS name because: + + . The is no ability for the local machine to know its DNS name + without performing a reverse DNS lookup on the local-ip-addr + + . There is no guarantee that the name returned by a reverse + DNS lookup actually maps back to the local IP address. + + . Lastly, without DNSSEC, it may not be safe to use DNS addresses + because they can easily be spoofed. NAT and DNS-ALG cannot work + unless DNSSEC is disabled. + + A common use of this application is people dialing in to corporate + offices from their X terminals at home. Say, the X client is running + on a host on the public side of the NAT and X server is running on a + + + +Holdrege & Srisuresh Informational [Page 7] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +3.5 RSH/RLOGIN + + RSH uses multiple sessions to support separate streams for stdout and + stderr. A random port number is transmitted inline from the client + to the server for use as stderr port. The stderr socket is a + connection back from the server to the client. And unlike FTP, there + is no equivalent to PASV mode. For traditional NAT, this is a + problem as traditional NAT would not permit incoming sessions. + + RLOGIN does not use multiple sessions. But the Kerberos protected + versions of RSH and RLOGIN will not work in a NAT environment due to + the ticket problems and the use of multiple sessions. + +4.0 Protocols that can work with the aid of an ALG + + This document predominantly addresses problems associated with + Traditional NAT, especially NAPT. + +4.1 FTP + + FTP is a TCP based application, used to reliably transfer files + between two hosts. FTP uses bundled session approach to accomplish + this. + + FTP is initiated by a client accessing a well-known port number 21 on + the FTP server. This is called the FTP control session. Often, an + additional data session accompanies the control session. By default, + + + +Holdrege & Srisuresh Informational [Page 8] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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". + +4.2 RSVP + + RSVP is positioned in the protocol stack at the transport layer, + operating on top of IP (either IPv4 or IPv6). However, unlike other + transport protocols, RSVP does not transport application data but + instead acts like other Internet control protocols (for example, + ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-hop + between RSVP-capable routers as raw IP datagrams using protocol + number 46. It is intended that raw IP datagrams should be used + between the end systems and the first (or last) hop router. However, + this may not always be possible as not all systems can do raw network + I/O. Because of this, it is possible to encapsulate RSVP messages + within UDP datagrams for end-system communication. UDP-encapsulated + + + +Holdrege & Srisuresh Informational [Page 9] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +4.3 DNS + + DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts + which use local DNS servers in NAT private realm. DNS name to + address mapping for hosts in private domain should be configured on + an authoritative name server within private domain. This server + would be accessed by external and internal hosts alike for name + resolutions. A DNS-ALG would be required to perform address to name + conversions on DNS queries and responses. [DNS-ALG] describes DNS- + ALG + + + + +Holdrege & Srisuresh Informational [Page 10] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +4.4 SMTP + + SMTP is a TCP based protocol ([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 fooboo@company.com), + 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. + + + + +Holdrege & Srisuresh Informational [Page 11] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +4.5 SIP + + SIP (Refer [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. + +4.6 RealAudio + + In default mode, RealAudio clients (say, in a private domain) access + TCP port 7070 to initiate conversation with a real-audio server (say, + located an external domain) and to exchange control messages during + playback (ex: pausing or stopping the audio stream). Audio session + parameters are embedded in the TCP control session as byte stream. + + + +Holdrege & Srisuresh Informational [Page 12] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +4.7 H.323 + + H.323 is complex, uses dynamic ports, and includes multiple UDP + streams. Here is a summary of the relevant issues: + + An H.323 call is made up of many different simultaneous connections. + At least two of the connections are TCP. For an audio-only + conference, there may be up to 4 different UDP 'connections' made. + + All connections except one are made to ephemeral (dynamic) ports. + + Calls can be initiated from the private as well as the external + domain. For conferencing to be useful, external users need to be + able to establish calls directly with internal users' desktop + systems. + + The addresses and port numbers are exchanged within the data stream + of the 'next higher' connection. For example, the port number for + the H.245 connection is established within the Q.931 data stream. + (This makes it particularly difficult for the ALG, which will be + required to modify the addresses inside these data streams.) To make + matters worse, it is possible in Q.931, for example, to specify that + the H.245 connection should be secure (encrypted). If a session is + encrypted, it is impossible for the ALG to decipher the data stream, + unless it has access to the shared key. + + Most of the control information is encoded in ASN.1 (only the User- + User Information within Q.931 Protocol Data Units, or PDUs, is + + + +Holdrege & Srisuresh Informational [Page 13] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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 88.88.88.88 and B's IP address is + 99.99.99.99. 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 = 88.88.88.88 + caller port = 1120 + callee address = 99.99.99.99 + callee port = 1720 + <----------------------------------------------- + Q.931 Alerting + <----------------------------------------------- + Q.931 Connect H.245 address = 99.99.99.99 + H.245 port = 1092 + + User A establishes connection to User B at + 99.99.99.99, 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 = 99.99.99.99 + RTCP port = 1093 + -----------------------------------------------> + H.245 Open Logical Channel Ack, channel = 257 + RTP address = 88.88.88.88 + RTP port = 2002 + (This is where User A would like RTP + data sent to) + + + +Holdrege & Srisuresh Informational [Page 14] + +RFC 3027 Protocol Complications with NAT January 2001 + + + RTCP address = 88.88.88.88 + RTCP port = 2003 + -----------------------------------------------> + H.245 Open Logical Channel, channel = 257 + RTCP address = 88.88.88.88 + RTCP port = 2003 + <----------------------------------------------- + H.245 Open Logical Channel Ack, channel = 257 + RTP address = 99.99.99.99 + RTP port = 1092 + (This is where User B would like RTP data + sent to) + RTCP address = 99.99.99.99 + 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. + +4.8 SNMP + + SNMP is a network management protocol based on UDP. SNMP payload may + contain IP addresses or may refer IP addresses through an index into + a table. As a result, when devices within a private network are + managed by an external node, SNMP packets transiting a NAT device may + contain information that is not relevant in external domain. In some + cases, as described in [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 + + + +Holdrege & Srisuresh Informational [Page 15] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +5.0 Protocols designed explicitly to work with NAT enroute + +5.1 Activision Games + + Activision Games were designed to be NAT-friendly so as not to + require an ALG for the games to work transparently through + traditional NAT devices. Game players within a private domain can + play with other players in the same domain or external domain. + Activision gaming protocol is proprietary and is based on UDP. The + address server uses UDP port number 21157 and is expected to be + located in the global address realm. + + Game players connect to the address server first, and send their + private IP address information (such as private IP address and UDP + port number) in the initial connect message. The server notes + private address information from the connect message and external + address information from the IP and UDP headers. The server then + sends both the private and external address information of the game + player to all the other peer players. At this point, each game + player knows the private and public address information of every + other peer. Subsequent to this, each client opens up symmetrical + direct connection to each other and uses whichever address (private + or external) works first. + + Now, the clients can have a session directly with other clients (or) + they can have session with other clients via the gaming server. The + key is to allow reuse of the same (global address, assigned UDP port) + tuple used for initial connection to the game server for all + subsequent connections to the client. A game player is recognized by + one of (private address, UDP port) or (global address, assigned UDP + port) by all other peer players. So, the binding between tuples + should remain unchanged on NAT, so long as the gaming player is in + session with one or multiple other players. + + Opening a connection to a game server in external realm from a + private host is no problem. All NAT would have to do is provide + routing transparency and retain the same private-to-external address + binding so long as there is a minimum of one gaming session with an + external node. But, an NAPT configuration must allow multiple + simultaneous UDP connections on the same assigned global + address/port. + + + +Holdrege & Srisuresh Informational [Page 16] + +RFC 3027 Protocol Complications with NAT January 2001 + + + 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. + +6.0 Acknowledgements + + The authors would like to express sincere thanks to Bernard Aboba, + Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine, + Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others + that had provided valuable input in preparing this document. Special + thanks to Dan Kegel for sharing the Activision games design + methodology. + +7.0 Security Considerations + + The security considerations outlined in [NAT-TERM] are relevant to + all NAT devices. This document does not warrant additional security + considerations. + +8.0 References + + [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. + + + + +Holdrege & Srisuresh Informational [Page 17] + +RFC 3027 Protocol Complications with NAT January 2001 + + + [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. + + + +Holdrege & Srisuresh Informational [Page 18] + +RFC 3027 Protocol Complications with NAT January 2001 + + + [ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 + Address Behaviour Today", RFC 2101, February 1997. + +Authors' Addresses + + Matt Holdrege + ipVerse + 223 Ximeno Ave. + Long Beach, CA 90803 + + EMail: matt@ipverse.com + + + Pyda Srisuresh + Jasmine Networks, Inc. + 3061 Zanker Road, Suite B + San Jose, CA 95134 + U.S.A. + + Phone: (408) 895-5032 + EMail: srisuresh@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holdrege & Srisuresh Informational [Page 19] + +RFC 3027 Protocol Complications with NAT January 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Holdrege & Srisuresh Informational [Page 20] + |