Network Working Group J. Rosenberg Internet-Draft IAB Expires: August 5, 2006 February 1, 2006 Considerations for Selection of Techniques for NAT Traversal draft-iab-nat-traversal-considerations-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract When designing protocols, engineers are frequently faced with the question of how to make the protocol operate in the face of Network Address Translation (NAT). There are many techniques that have been defined to facilitate NAT traversal, including Application Layer Gateways (ALGs), Simple Traversal of UDP through NAT (STUN), and Middlebox Communications (MIDCOM). This document provides a set of guidelines on how to best deal with the NAT traversal problem in protocol design. Rosenberg Expires August 5, 2006 [Page 1] Internet-Draft NAT Traversal Considerations February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Techniques for Traversal . . . . . . . . . . . . . . . . . . . 3 2.1 Application Layer Gateways (ALG) . . . . . . . . . . . . . 4 2.2 Unilaternal Self-Address Fixing (UNSAF) . . . . . . . . . 4 2.3 Network Relay . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Server Involvement in NAT Navigation (SINN) . . . . . . . 5 2.5 RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6 NSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.7 MIDCOM . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Guidelines for New Protocols . . . . . . . . . . . . . . . . . 6 3.1 Client-Server Protocols . . . . . . . . . . . . . . . . . 6 3.2 Push Protocols . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Connection . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Registration . . . . . . . . . . . . . . . . . . . . . 9 3.2.3 Keepalives . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4 Notifications . . . . . . . . . . . . . . . . . . . . 11 3.3 Session Protocols . . . . . . . . . . . . . . . . . . . . 11 4. Existing Protocols . . . . . . . . . . . . . . . . . . . . . . 12 5. ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 Undermining Application Security Measures . . . . . . 13 5.1.2 Vulnerabilities Inherent in Traversal Technique . . . 15 5.2 Deployability Considerations . . . . . . . . . . . . . . . 17 5.3 Manageability . . . . . . . . . . . . . . . . . . . . . . 18 5.4 Avaiability . . . . . . . . . . . . . . . . . . . . . . . 20 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Informative References . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 Rosenberg Expires August 5, 2006 [Page 2] Internet-Draft NAT Traversal Considerations February 2006 1. Introduction A Network Address Translator (NAT) is defined in RFC 2663 [1] as "a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts." NAT and its many variations have seen widespread deployment over the past few years. Unfortunately, NAT makes fundamental changes in the nature of the service provided by IP networks. These changes have had the impact of breaking many protocols designed prior to the deployment of NAT. These include the File Transfer Protocol (FTP), the Domain Name System (DNS), the Session Initiation Protocol (SIP) [2], and the Real Time Streaming Protocol (RTSP) [3] amongst others. NAT also continues to provide a challenge in the design of new protocols. To combat these problems, numerous techniques have been developed, many of which are protocol specific. These include Application Layer Gateways (ALGs), Unilateral Self Address Fixing (UNSAF) techniques [4], such as the Simple Traversal of UDP through NAT (STUN) [5], and Teredo [7], relay techniques such as Traversal Using Relay NAT (TURN) [6], and peer-to-peer techniques, such as Interactive Connectivity Establishment (ICE) [8]. IPv6 itself has also been promoted as a cure for the NAT problem, as its large address space will, in principal, obviate the need for NAT. Given this dizzying array of technologies, it is difficult to know what the right solution is for a particular protocol. This document is aimed at designers of protocols and network architectures, and gives a set of guidelines on the appropriate set of techniques to use under different conditions. Firewalls play a related role to NAT. A NAT itself provides a form of firewall - it prevents inbound communications unless there was a matching outbound communications first. However, firewalls allow a nearly infinite set of policies about whether a packet will traverse or not. This means that a so-called firewall traversal technique may or may not work depending on the firewall policies. Because of this, the considerations described here are applicable to firewall traversal techniques to the degree that the firewall policy would permit the technique to work. That said, the focus of the document is on NAT, not firewall. 2. Techniques for Traversal There are many techniques that have been developed to facilitate the traversal of NAT. This section provides an overview of these techniques. Rosenberg Expires August 5, 2006 [Page 3] Internet-Draft NAT Traversal Considerations February 2006 2.1 Application Layer Gateways (ALG) RFC 2663 [1] defines an Application Layer Gateway (ALG) as "application specific translation agents that allow an application on a host in one address realm to connect to its counterpart running on a host in different realm transparently". ALGs are also used to refer to application specific agents in firewalls that allow an application on a host in one network to talk to its counterpart running on a host in another network. One of the key characteristics of the ALG is that it is transparent. It operates without explicit awareness from, or consent by, other entities involved in the application layer protocol. ALGs appear to have many benefits. By placing them in a small number of locations in a network, they allow a large number of hosts to use an application which, before deployment of the ALG, did not function. No change is required in the protocols used by those applications. No changes are needed in the clients, and no changes are needed in the servers. The only element that is modified is the element that introduced the problem in the first place - the NAT. ALGs have seen substantial deployment by enterprises and network operators, particularly for a small number of protocols that were already defined at the time that NAT and firewall usage became commonplace, most notably FTP and DNS. 2.2 Unilaternal Self-Address Fixing (UNSAF) RFC 3424 defines UNSAF as a technique by which a client behind a NAT attempts to discover its address as would be seen in the address realm on the public side of the NAT, and then use that address within application layer protocols instead of its actual IP address. This is done by adding a new element, an "UNSAF server", on the public side of the NAT, and then modifying the client so that it knows how to use the UNSAF server. The actual application protocol server remains unchanged, as does the NAT. The Simple Traversal of UDP Through NAT [5] is one example of an UNSAF protocol. Teredo [7] is similar to STUN, but focuses on v6 hosts behind a v4 network with NAT that wish to obtain v6 connectivity. 2.3 Network Relay Network relay solutions, like UNSAF techniques, involve a server on the public side of the network. Clients behind the NAT connect to this server, and obtain from it an IP address (and possibly port) which reside on that server. The server then relays packets to and Rosenberg Expires August 5, 2006 [Page 4] Internet-Draft NAT Traversal Considerations February 2006 from the client over that connection. Network relays include Virtual Private Networks (VPNs), which provide the client with an IP address, along with protocols such as Traversal Using Relay NAT (TURN) [6]. TURN, unlike traditional VPN, allocates both an address and port to the client, so that it operates at the application layer, rather than the IP layer. There are numerous other differences between TURN and traditional VPN, but both use a packet relay as the essential technique for NAT traversal. 2.4 Server Involvement in NAT Navigation (SINN) The SINN technique involves modifying the servers so that their actual application processing changes, possibly in violation of the specifications they are implementing. However, for some application protocols, the SINN technique allows for NAT traversal without modifying the clients or the NATs - only the servers. Whether this technique is possible or not depends entirely on the application layer protocol, and usually involves assumptions on client behavior. One example of the SINN technique are the so-called Session Border Controllers (SBC) in SIP. An SBC operates by ignoring IP addresses and ports provided by the client in its SIP messages, and modifying the IP addresses and ports in SIP messages sent to the clients. These modifications force the media traffic for the session through the SBC, making the SIP network look more like a pure client/server network. SBCs operate only when certain assumptions about client behavior are met - that the client sends and receives its media traffic from the same IP address and port, and that it sends and receives its SIP signaling traffic from the same IP address and port (SIP does not require send and receive address/ports to be the same, though this is common practice). 2.5 RSIP Realm Specific IP (RSIP) [9] can be considered a variant on the UNSAF technique. However, instead of the UNSAF server being outside of the NAT, it is part of the NAT. It is also like VPN in that the client modifications reside below the application processing layer. 2.6 NSIS Next Steps in Signaling (NSIS) allows clients to directly signal with their NAT to obtain bindings for use in application protocols [10]. 2.7 MIDCOM Middlebox Communications (MIDCOM) [11] allows servers to communicate with the NAT using an application-independent protocol (the MIDCOM Rosenberg Expires August 5, 2006 [Page 5] Internet-Draft NAT Traversal Considerations February 2006 protocol [12]) to create and remove NAT bindings. The server can then use the bindings it learned from the NAT to modify the application packets in much the same way an ALG would. In fact, MIDCOM represents a way to build a distributed ALG, by placing the ALG functionality in a protocol server, separate from the NAT itself. In that regards, MIDCOM is a mix between an ALG solution and a SINN solution. 3. Guidelines for New Protocols The appropriate solutions to use depend on whether the problem at hand is the design of a new protocol, or whether it involves "fixing" an existing protocol to work in the face of NAT. For new protocols, the situation is much simpler. The right approach is to design the protocols to be NAT friendly at their core, rather than designing them in ignorance of NAT, and then trying to apply a separate NAT traversal solution to allow them to work through NAT. This guidance is similar to the way security is viewed in the context of protocol design. It is not something you can just sprinkle on when you are done, it is something that must be considered in the design of the protocol. Doing this allows the technique to be tuned to the specific needs of the protocol. Protocols vary in their needs for availability, scale, responsiveness and use differing namespaces, transport protocols and syntax. A single common NAT traversal technique is therefore difficult to provide. Mechanisms such as shim6 [18], which insert a shim layer above IP that provide a separation between a host identifier and locator, show promise as such a universal technique. However, a new protocol meant for broad usage on the Internet cannot rely on such techniques until they are widely deployed. In the interim, the best solution is to make the protocol NAT friendly to start with. Fortunately, there are well known techniques that can be applied to broad classes of protocols. In the sections that follow, we consider several protocol patterns that are common in protocol design. Each of these patterns has a specific solution which can be applied to the design of the protocol. A specific protocol may exhibit multiple patterns, in which case solutions for each of them would need to be incorporated into the design of the protocol. 3.1 Client-Server Protocols Client-Server protocols involve a host, called the client, wishing to access the resources available on another host, called the server. The client learns, through some means typically outside of the scope of the protocol itself, the address of the server to be contacted. The client makes a request to the server, and the server provides a Rosenberg Expires August 5, 2006 [Page 6] Internet-Draft NAT Traversal Considerations February 2006 response. Examples of client-server protocols include HTTP [21], the Post Office Protocol (POP) [22] and the Simple Mail Transfer Protocol (SMTP) [23]. +-----------+ | | | Server | | | | | +-----------+ ^ | | pub +---------------+ | | +---------------+ | priv | +-----------+ | | | Client | | | | | +-----------+ Figure 1 There are two possible topologies for NAT in client-server protocols. The most common one is when the client is behind the private side of the NAT, and the server is on the public side. This is illustrated in Figure 1. In this configuration, client-server protocols tend to work "naturally" through the NAT; that is, a client-server protocol designed without NAT consideration is likely to work in this environment. In order to guarantee that the protocol will work, it must be designed such that the server sends responses to the client at the source IP address and port of the client request, and sends them from the same IP address and port where the request was receive on. For TCP, this means simply sending the response over the same connection. Depending on the type of NAT, it may be possible that variations on this will work; for example, it might be OK to send the response from a different port than the request was received on. However, though guidelines are being produced which would codify NAT behaviors so that this works consistently [17], the highest robustness is achieved by following these guidelines. Rosenberg Expires August 5, 2006 [Page 7] Internet-Draft NAT Traversal Considerations February 2006 An additional consideration comes into play when the server may be significantly delayed in generating its response. When the request passes through the NAT, it creates a binding to an IP address and port on the public side of the NAT. This binding will time out after a short period of time if not refreshed by the client. As a consequence, if the protocol allows for responses that can be delayed by more than 20 seconds or so, the protocols need to include a keepalive mechanism. This mecahnism should involve a short packet sent from the client to the server, followed by a packet in response from the server back towards the client. An interval of larger than 20 seconds may be possible, particularly for TCP, but maximum robustness is achieved by following this guideline. The situation is substantially different when the server appears on the private side of the NAT, and the client on the public side. Indeed, such deployment topologies are fundamentally at odds with NAT. In order to work, the server needs to somehow obtain an address that is reachable by the client. Typically, this happens through the configuration of static bindings in the NAT, giving the server a permanent public IP address and port. 3.2 Push Protocols Many protocols fit under the broad umbrella of push protocols. In these protocols, a client is interested in receiving notifications about certain events. In order to receive these notifications, the client registers interest in these events with a server. When the events occur, the server sends a notification to the client. Examples of push protocols include SIP [2], which uses push to deliver call setup messages and instant messages [24], and XMPP [25]. Note that, in both cases, these protocols include client-server patterns, and in the case of SIP, peer-to-peer patterns, in addition to push. Many protocols exemplify more than one pattern. Like client-server protocols, there are two possible topologies when NAT is introduced. In the most common case, the client is behind the private side of the NAT, and the server is on the public side. This is identical to the situation in Figure 1. Push protocols must be designed carefully to operate in this topology. Prior to the advent of NAT, the registration aspect of these protocols could be only loosely coupled with the notification delivery. All that was required was a means to provide the server with the IP address of the client. This could be done through a web page, or more commonly, through static configuration or provisioning systems. Notifications could then be sent to the IP address that had been "registered" at any time. With NAT, this approach no longer works. Instead, push protocols Rosenberg Expires August 5, 2006 [Page 8] Internet-Draft NAT Traversal Considerations February 2006 require four protocol components in order to operate in the face of NAT. 3.2.1 Connection First, the client must connect to the server. This can involve opening a TCP or TCP/TLS connection, but can also involve sending a UDP packet as part of the registration operation. Because this connection is the only vehicle by which the client can receive notifications, liveliness of the connection directly impacts service availability. Failures of the server, failures of intervening NAT, or packet loss conditions that cause loss of connectivity will all directly impact service availability until the client reconnects. As a consequence, in systems where availability is critical, it may be necessary for the client to maintain multiple, parallel connections to different servers. 3.2.2 Registration Once the client connects, it must identify itself to the server. Because of NAT, the source IP address is not a meaningful identifer of the client any longer. Push protocols will need to provide a way for the client to provide its identity, within a namespace appropriate for the protocol, to the server, and for the server to cryptographically verify this identity. The registration message also serves the purpose of binding that identity to the connection on which the registration was received. In the case of UDP, the connection refers to the 5-tuple used for the register message. 3.2.3 Keepalives Because notifications can come at any time, the NAT bindings in the intervening NAT must be kept alive. Should the bindings expire, the notification message from the server to the client will be dropped at the NAT. To keep them alive, the client needs to generate periodic keepalive messages over its connection. These keepalives should be generated from the client towards the server, followed by a response from the server towards the client. Keepalives in the reverse direction (from the server to the client) are not as effective, since many NAT will only refresh bindings for traffic from the private side of the NAT to the public side. It is also essential that this keepalives be sent on the same connection as the register message was sent. In the case of UDP, this means that they are sent from the same IP address and port on the client, to the same IP address and port on the server. In addition to keeping the NAT bindings active, the keepalives serve the purpose of detecting failures of the server itself. Although Rosenberg Expires August 5, 2006 [Page 9] Internet-Draft NAT Traversal Considerations February 2006 many systems typically provide redundancy and state replication in order to be robust against failure, they often do not replicate actual connection states, and often, do not provide IP address takeover (such that the backup has the same IP address as the primary). Absent IP takeover and connection state replication, the backup server will not be able to reach the client unless the client reaches out to the backup and connects to it. For this reason, in protocols where availability is important, the client will need to rapidly detect server failures and then reconnect. If the keepalive is designed as a lightweight request/response mechanism, it can be sent frequently, and thus serve as double duty for detecting failure of the server. With UDP, the keepalives must be sent approximately once every 20 seconds in order to keep the NAT bindings alive, and with TCP, every 10 minutes or so. Availability constraints may require this to be even more frequent. Care must be taken, however, in guarding against the avalanche restart problem. If the server fails, severing all connections, this failure will be detected by all connected clients within a keepalive interval. If they all immediately reconnect, this will cause a storm of register messages to the server. Protocol designers should carefully consider this problem. There are numerous remedies to it, which trade off availability for reduction in load, or increase the amount of hardware required under normal operation. One common solution is to have clients wait a random period of time after detection of failure prior to re-registration. The interval to wait needs to scale with the size of the client population that will be attached to the server. Another solution is to have the client maintain two connections, each to a different server. If one fails, the client can wait a very long time before attempting to reconnect, since it can receive notifications through the second. Another condition that needs to be taken into consideration is restart of the NAT itself. In the case of TCP connections, the next keepalive message from the client will not match any connection state in the NAT and be discarded. This will cause the client to detect the NAT failure and then reconnect. However, in the case of UDP, the NAT will assign a new binding, and pass the UDP message to the server. The server will generate a response. However, the server still has stale information about the 5-tuple needed to reach the client. To fix this problem, a good solution is to have the server echo the source IP address and port of the keepalive request into its response. WHen the client gets this response, if it sees a change in IP address and port from what it had previously, the client can re- register. There are two choices for designing the keepalive mechanism. One is Rosenberg Expires August 5, 2006 [Page 10] Internet-Draft NAT Traversal Considerations February 2006 to use a native protocol message. For performance reasons, it is often a good idea to use a special message just for the purposes of keepalives, whose processing can be kept to a minimum at the server. Another choice is to use a separate lightweight keepalive protocol that is multiplexed on the same connection. A good choice for such a keepalive is STUN [16], which provides all of the necessary properties. It is easily multiplexed with other protocols over TCP and UDP, it provides a basic request/response transaction, it is very lightweight, and it provides a way for the server to echo the source IP address and port to the client. SIP, for example, uses STUN to keepalive its connection to the server [19]. 3.2.4 Notifications The last component of the protocol is the notification messages themselves. These must be sent over the same TCP connection that the client has registered on, and been sending keepalives on. For UDP, the notifications are sent on the same 5-tuple as the registration and keepalive messages. 3.3 Session Protocols Session protocols involve the use of a message exchange, called the control channel, whose primary purpose is the establishment of a separate protocol session, called the data channel. Examples of session protocols include the File Transfer Protocol and the Session Initiation Protocol (SIP). In the most complex case, the purpose of the session protocol is to setup a direct data channel between two clients, using a control channel that routes through intermediate servers on the network. This is shown pictorially in Figure 2. Rosenberg Expires August 5, 2006 [Page 11] Internet-Draft NAT Traversal Considerations February 2006 +----------+ | | | | | Server | | | | | +----------+ / \ / \ Control/ \ Control Channel / \ Channel / \ / \ / \ / \ / \ / \ +----------+ +----------+ | | | | | | | | | Client |------------------- | Client | | | | | | | Data Channel | | +----------+ +----------+ Figure 2 NATs can exist in many places in such a system. They can exist between the clients, and between the clients and the server. Since the purpose of the server in this case is to facilitate discovery of the client, the server is typically located on the public side of any NAT. If it isn't, static NAT bindings need to be put in place to allow the server to be reachable via a public IP address and port, as in the client server case. 4. Existing Protocols General recommendation is for client-based fixes, stun first, vpn/ relay ones next. 5. ALGs Need to rework and shorten existing text, back to more of the 'algs considered harmful' bit. There are many considerations that must take into account when making a choice. Many of these considerations are not architectural in nature - cost, for example, is a major consideration, but not an Rosenberg Expires August 5, 2006 [Page 12] Internet-Draft NAT Traversal Considerations February 2006 architectural one. There are many considerations around selection of a technique within a specific class (i.e., choosing one UNSAF technique over another). These kinds of considerations are important but are difficult to discuss in general, and out of scope for this document. Rather, this section discusses the general architectural considerations around the selection of one of the classes of techniques - ALG, UNSAF, RSIP, NSIS, SINN, MIDCOM, protocol updates and IPv6. 5.1 Security Security is one of the most important considerations when selecting a technique, and it is one of the biggest differences amongst the techniques. Security issues can be broken broadly into impacts that the technique has on application security, and security concerns from the technique itself. 5.1.1 Undermining Application Security Measures The reason that the application doesn't work through the NAT is that the application assumes uniquess and reachability properties for its IP addresses. However, the intermediary has broken those properties. Furthermore, reachability through the intermediary requires creation of a translation or binding in that intermediary, which doesn't normally exist based on the application-unaware processing logic in the intermediary. This condition arises when an application protocol includes IP addresses or hostnames within its payloads, and those addresses or hostnames are used by the application protocol as a destination for messages. For such messages to flow, appropriate permissions and/or bindings need to be in place. Thus, all NAT traversal techniques ultimately involve the installation of bindings in the NAT, and the modification of the application protocol messages to reflect the bindings created by the NAT. In all techniques, the NAT is responsible for installing the needed bindings. However, the various traversal techniques differ in which entities are responsible for modifying the application protocol messages. Performing this modification requires the entity doing so to be able to inspect them and then change them. If the entity that needs to do the inspection and modification is not trusted to do so by the application protocol, the application protocol itself might provide security techniques which would prohibit the entity from doing so. As such, the technique may require those application security techniques to be disabled, thus undermining the security provided overall. Unfortunately, these portions of the message - the IP addresses or domain names of hosts to which protocol messages need to be addressed Rosenberg Expires August 5, 2006 [Page 13] Internet-Draft NAT Traversal Considerations February 2006 - are exactly the parts of the message that are most critical to protect. Indeed, in the case of DNS, a DNS ALG modifies the primary piece of information that protocols such as DNSSEC were designed to protect [13]. Generally speaking, several classes of attacks can be introduced if these addresses are not protected: Denial-of-Service: If an attacker can modify these addresses as they transit the network, the attacker can set them to point to a target of a denial-of-service attack. Recipients of these modified messages will direct subsequent messages to this target. Depending on the protocol, this may result in substantial message amplification properties. Eavesdropping: Instead of modifying the addresses to point to a DoS target, the attacker can modify them to point to themself. Once it receives these messages, the attacker can forward them to the proper recipient. This allows an attacker to eavesdrop the protocol. Service Disruption: An attacker can modify the addresses so that they route to nowhere (for example, a non-existent IP host). This will likely disrupt operation of the protocol, so that the client receives no service. Other types of attacks might be possible, depending on the specific protocol. Worse yet, many application protocols do not provide security that protects only the IP address and port information in a protocol message. Rather, larger parts of the message, if not the entire message, is usually protected. As a result, if the security techniques protecting the IP address and port information are disabled, this will usually disable protection over other, perhaps more critical, parts of the message. Generally speaking then, the extent to which the traversal technique undermines application layer protocol security measures depends on two factors - whether or not the IP address and port information is protected by security measures in the protocol, and the degree to which the protocol entity is allowed by those measures to modify those parts of message. In this regard, the entity which should ideally modify the protocol message is the "natural" one - the entity which is responsible for the creation of those parts of the message in the first place. When the "natural" entity modifies the message, its not really a modification at all; the message is created properly in the first place with the IP addresses and ports on the public side of the NAT. Rosenberg Expires August 5, 2006 [Page 14] Internet-Draft NAT Traversal Considerations February 2006 This makes ALGs particularly problematic. Since ALGs reside in the network, as opposed to in the clients or servers, they are never the "natural" entity to modify the protocol message. It is a man-in-the- middle, inspecting and modifying protocol messages without explicit awareness or consent by the actual entities in the protocol. In order for them to function, any application protocol security measures protecting those parts of the message will need to be disabled. The nature of the security functions that need to be disabled differ between firewall and NAT. NAT requires the protocol to be inspected and modified. As such, any security mechanisms providing confidentiality or integrity must be disabled. For firewalls, only inspection is needed. This means that confidentiality mechanisms must be disabled; integrity mechanisms can still function. Consider the example of SIP. SIP messages carry a MIME payload that describes the multimedia session being established. This payload is usually the Session Description Protocol (SDP) [14]. SDP includes IP address and port information, indicating the transport address where media packets (such as audio and video) should be sent. The SDP is protected by SIP's TLS mechanism, SIP S/MIME, and even digest authentication with the auth-int quality of protection. If these are disabled, SIP's security becomes almost impotent, and many attacks are opened up. For example, if an attacker can access and modify the addresses in the SDP, serious security holes are introduced. The attacker can modify the address to direct the media stream to themself, allowing for eavesdropping of a phone call. Worse yet, an attacker can modify the address across several SIP messages, changing them to point to a target of a distributed denial-of-service attack. This target will receive a steady stream of media packets from the recipients of the modified SIP messages. As such, ALGs are only appropriate in protocols that lack security in the first place, or in environments where the security measures in a protocol are not needed, such as a closed network environment. For those protocols where the client is responsible for generating the IP address and port information in the protocol messages (such as for SIP, RTSP, and FTP), and where the application protocol security measures are desired, techniques involving modification of the client (the UNSAF approaches in Section 2.2) are least intrusive, and do not undermine the application protocol security. 5.1.2 Vulnerabilities Inherent in Traversal Technique Section 5.1.1 considers security vulnerabilities introduced by NAT traversal techniques because of the need to disable security features in application protocols. Another class of attacks are possible Rosenberg Expires August 5, 2006 [Page 15] Internet-Draft NAT Traversal Considerations February 2006 depending on the way in which the traversal technique works. When the traversal technique is accomplished using a protocol, such as STUN, TURN, ICE, RSIP and MIDCOM, the specifications for those techniques include their security considerations. Many of these security considerations are around secure creation of bindings in a NAT. The bindings are what permit packets from the outside to be routed to a particular host on the inside. They represent the principal resource that needs to be protected by traversal security techniques. Attacks become possible when bindings can be created by unauthorized entities. Denial of service attacks can be launched if the port space in a NAT is exhausted with unauthorized bindings, for example. Numerous attacks are possible when a client believes it has obtained a binding that maps to itself, when it fact it maps to another client. These attacks are discussed in Section 12.1 of RFC 3489 [5]. Generally speaking, the attacks documented in Section 12.1 of RFC 3489 are applicable to any traversal technique where the IP address and port provided to the client are obtained from the source address and port seen by the server, and where the address cannot be security verified before use. This applies to STUN and Teredo, though the usage of these techniques with ICE obviates this risk, since they are validated before use. UNSAF techniques using relays, such as VPN and TURN, do not suffer from these attacks. These attacks may also be possible in SINN techniques depending on the application protocol. In the case of SIP, SINN is susceptible to these same attacks. The server determines the IP address and port to send media traffic to by using the source IP and port of media it receives from the client. A user eavesdropping a call setup request could inject packets with the IP address and port of the target, creating the attacks. These can also be mitigated with ICE, or through the usage of secure media. ALGs are also susceptible to these attacks, but they are particularly vulnerable since the attacks are easy to launch. An ALG looks for IP addresses present in a protocol message, and allocates a binding or permission that will allow packets from the outside to traverse the intermediary, and be delivered to the address present in the protocol message. Creation of a binding to an arbitrary address is accomplished by placing that address into the protocol payload. Thus, source address spoofing is not required, as it is for other traversal techniques. This attack is particularly easy to launch. Consider a client who is browsing the web behind a firewall. The user goes to a website of a malicious provider. That website provides the user with a java Rosenberg Expires August 5, 2006 [Page 16] Internet-Draft NAT Traversal Considerations February 2006 application implementing a basic SIP client. This application generates a SIP INVITE message, and sends it back to the web server. The INVITE message has, within its SDP, the IP address and port of a mail server behind the firewall. The ALG within the firewall creates a permission, allowing traffic from the outside, towards the mail server. The provider can then inject a flood of packets towards the mail server, disabling it. In a similar attack, if an internal server has vulnerable ports - for example, a port used for telnet-based CLI access - the INVITE request can contain the IP address and port of that service on the server. Rather than launching a DoS attack, the malicious provider can then attempt to telnet into the server. MIDCOM, like ALGs, create the binding based on the IP address and port in the protocol messages, and thus have similar security considerations. For protocols like RSIP and NSIS, the bindings are created based on protocol exchanges with the NAT. These exchanges generally require return routability to the IP address and port of the client, and thus provide a means to validate the private addresses used in the binding. As such, they do not suffer from these attacks. 5.2 Deployability Considerations The various techniques differ in their deployability. The primary factors influencing deployability are the ability of the service provider to modify parts of the system, and the number of such elements that need to be modified. As discussed in, the assumption here is that the service provider owns the servers. They may or may not own the NATs in the network, and they may or may not have any ability to affect the clients. As such, traversal techniques that only involve modifying the servers (the SINN technique) are the easiest to deploy. Those which require modifying the clients (the UNSAF techniques) may be feasible depending on whether the service provider can specify to its customers a particular version of client software that needs to be used. However, techniques which require modification of the NAT itself can be very hard to deploy. In many situations, the service provider is not the same as the operator of the access network used by its customers. In such cases, the access provider may be using NAT, and the service provider has no ability to influence the features or configuration of the device. It may be possible that the device supports the needed capabilities (ALG, NSIS, RSIP, or MIDCOM) anyway. Rosenberg Expires August 5, 2006 [Page 17] Internet-Draft NAT Traversal Considerations February 2006 This is more likely for those traversal techniques where the logic in the NAT is not application-specific - NSIS, RSIP, MIDCOM and similar protocols. However, in those cases, those capabilities in the NAT need to be activated, and permissions set up for the application component (the client in the case of NSIS and RSIP, or the proxy server in MIDCOM) to control the NAT. The existence of these permissions may hinge on a business relationship between the service provider and the owner of the NAT. When the customers for a service provider come from many different access networks, and thus many different access network providers, this may be difficult to establish. For ALGs, there is a chicken and egg problem. Typically, vendors of such devices build functions based on customer demand. A large driver for demand is customer deployment and usage of a new application. However, the application cannot be deployed or used without the ALG that the vendor needs to build. Thus, the application doesn't get deployed and the demand for the ALG never manifests. This is a non-issue for protocols with ALGs widely supported in NAT, including FTP and DNS. Control is not the only factor impacting deployability; the number of such components is also a factor. For example, if a service provider is offering services to large enterprises, the enterprise is the owner of the NAT. However, the service provider may have a relatively small number of enterprise customers, and thus it may not be unreasonable to require them to use a particular version of a NAT product from a particular vendor in order to get services. As such, the barriers to deploying solutions that require changes in NAT is not as high. The problem becomes amplified for a service provider offering services to small enterprises, of which there are a lot more. 5.3 Manageability When a failure occurs in the usage of an application (for example, a network timeout or other problem), it will often fall on the shoulders of the application provider to determine the cause of the problem. Diagnosing such difficulties in an operational network is a complex problem. As a result, many application layer protocols contain built in features that allow a provider to trace a problem after it has occurred. As an example, the Real Time Transport Protocol (RTP) [15] provides a feedback mechanism that allows a participant in a media session to track packet loss and latency as received by the recipient. As another example, SIP provides message header fields, such as Via and Warning, that allow for a trace of the flow of a message through a series of elements, along with an indication of detailed error conditions. Such diagnostic indications Rosenberg Expires August 5, 2006 [Page 18] Internet-Draft NAT Traversal Considerations February 2006 become increasingly important as the application protocol involves a large number of network elements or domains; the more entities in the picture, the more places something can go wrong, and the more important the need to find out where it went wrong. Diagnosing network faults is only one aspect of manageability; managing configuations, accounting, performance and security are also key parts of operating a network. The ability of the service provider to manage the service they are providing is dependent on their ability to collect information from the various elements on the way in which the service is operating, and to correlate that information together for a coherent view on the state of the network. The selection of a NAT traversal technique impacts manageability of the network primarily due to the differing levels of visibility that the service provider will have on the operation of that aspect of the service. Visibility is based on the level of transparency of operation. Transparency is primarily an issue for ALGs. They represent yet another entity that is application aware, and involved in the processing of an application protocol. It is possible for failures to occur at these elements, just like they can occur within actual elements of the application protocol. When such failures do occur, the transparent nature of the ALGs makes network diagnostics an almost impossible task. Firstly, it becomes hard to determine where the failure occurred. Because the ALG is transparent, its operation is invisible to protocol entities on either side of it. Indeed, there may even be multiple ALGs inserted between legitimate protocol entities, and this is often undetectable. No logging information or application protocol features would be able to help pinpoint the location (in terms of IP address or network provider) of the element that generated the errored message. With some application protocols, it might be possible for the ALG to only be "partly transparent", which means that it might attempt to make its presence known to other protocol entities. While this may seem at first glance to be a good idea, it only further complicates the problem. It results in entities that are now participants in the application protocol for some aspects of the protocol, but not others. This will likely lead to interoperability problems and additional failure cases, because the behavior of the ALG is not actually compliant to the full requirements outlined by the protocol specification. ALGs also make it hard to determine when a failure occurs. For Rosenberg Expires August 5, 2006 [Page 19] Internet-Draft NAT Traversal Considerations February 2006 example, when an application provider deploys a new protocol element, such as a server or intermediary, it knows that such an element has been deployed, and can therefore look for correlations in errors. Thus, if an operator deploys a new server on Wednesday, and it sees a steep rise in support calls that very same day, there is a good chance that the new server is at fault. However, such correlations become impossible with ALGs. The reason is that, in the problematic cases, the ALGs will be deployed by different organizations than the provider of the application. As an example, if an application provider deploys a Voice over IP application using SIP, its customer might be an enterprise. One of the routers buried deep within the enterprise network might have a SIP ALG which is turned on one day by an enterprise administrator. This represents a change in the application deployment topology, but not one that is known to the application provider. If that ALG introduces errors into the network, the VoIP provider will begin to see problems and receive customer support calls, but have no idea why, all of a sudden, errors started to happen. Of course, an application provider is dependent on the enterprise for deployment of normal IP infrastructure in order for the VoIP application to work. It is also possible that the enterprise administrator might deploy a traditional router which introduces packet loss, thereby affecting the VoIP application as well. However, this represents a fundamentally different case. Why? Because the router provides a service (routing of IP datagrams) which is well defined and understood by the developers of applications and application protocols. As a result, those protocols are designed to take into account the known failure modes of those elements (packet loss and jitter, for example), and either recover from them, or allow them to be detected so that further diagnosis can occur. An ALG is different. It doesnt provide a well known service, and its failure modes are not well understood, nor can they be taken into account as part of the design of the application protocol. In essence, the problem is that an ALG runs counter to the very notion of the end-to-end principle. The end-to-end principle pushes intelligence to the edges of the network. However, an ALG places application intelligence back into the network. This alters the very service model provided by the underlying IP network, and as a result, makes it difficult for applications to be built around a service model which is then ill defined. 5.4 Avaiability The choice of a traversal technique impacts availability in many ways. Firstly, techniques which add an additional component to the Rosenberg Expires August 5, 2006 [Page 20] Internet-Draft NAT Traversal Considerations February 2006 network add an additional point of failure. This is primarily an issue with the UNSAF techniques, all of which use an additional server of some sort to support traversal through the NAT. Secondly, network availability depends on the proper functioning of the technique itself. For a technique to function, the essential algorithm and protocol needs to be sound, and its implementation needs to be correct. Both of these can be an issue. Why would the algorithm and protocol be unsound? There are two reasons. The first is that the technique may make assumptions that prove to be untrue in the actual deployment. Second, the technique may not be sufficiently well specified and may miss corner cases not conceived by the designers. Let us consider both of these in turn. Many of the traversal algorithms and techniques are built around assumptions that they make. Frequently, these assumptions are around behaviors in other components in the system. For example, the SINN techniques make assumptions about the behavior of the clients. The UNSAF techniques make assumptions about the operation of the NAT. These assumptions can be wrong, resulting in brittle operation and failure of the network to operate. STUN is particularly sensitive in this regard; its NAT detection algorithm makes many assumptions about the behavior of a NAT and then tries to validate that behavior by black box testing. This has been addressed in a revision of STUN [16], and when used in conjunction with other techniques, such as ICE [8], the overall system makes fewer assumptions about operation of components in the network, and it is therefore less brittle. service providers should carefully consider the assumptions made by the technique, and validate that these assumptions are correct to the greatest extent possible. Even if the assumptions are sound, the technique can still fail if the technique has not been fully specified. This problem arises for ALGs, since they are not "first class citizens" in the application protocols they are interacting with. As such, their role in the processing of the protocol is not well defined by specifications, leading to the possibility that corner cases are missed, or that the ALG has interactions with the protocol that cannot be easily resolved. Similar issues arise in the SINN-based solutions, as these are based on non-standard behaviors from elements in the network. Operators should carefully consider that the various cases of interest are fully supported by the traversal technique. As an example, SIP describes numerous ways in which SDP can be exchanged during a SIP call in the process of negotiation of codec types and parameters. In the vast majority of calls, a basic exchange occurs - one SDP is sent in the SIP INVITE message (this SDP is called the offer), and a SDP in response (called an answer) in the Rosenberg Expires August 5, 2006 [Page 21] Internet-Draft NAT Traversal Considerations February 2006 SIP 200 OK message. However, the spec allows numerous other cases that are far less common, and as a result, likely to be overlooked by ALG implementors. Furthermore, extensions to SIP, such as UPDATE [20] add additional cases. Even if both endpoints in a call support this specification, they will not be able to implement it if the ALG does not support it. Of course, the fact that it is not supported by the ALG will be hard to ascertain because of the diagnostic issues described above. Finally, the implementation of the technique may not be sound. This is an issue not specific to NAT traversal, of course, but there are some considerations, specifically for ALGs. The manufacturers of intermediary devices housing the ALG are typically router and switch vendors. Building such devices requires expertise at the IP layer, and not for any specific application protocol. However, an ALG is fundamentally an application protocol component, and to develop one properly, requires expertise in that application protocol. This would not be a problem if there was only one application protocol. However, the intermediary vendor needs to have expertise for all application protocols for which ALG support is needed. That is a far more daunting task. Indeed, this problem is identified in the Midcom Architecture [11], which attempts to extract the ALG functionality from the intermediary, place it into an application layer entity, and use a protocol (the MIDCOM protocol) to control the intermediary. 6. Conclusions 7. Security Considerations Security is a critical consideration when selecting a technique for NAT traversal. The various techniques differ substantially in the impact on overall network security. Service providers should consider carefully their security needs when selecting a technique. 8. IANA Considerations There are no IANA considerations associated with this specification. 9. IAB Members Internet Architecture Board members at the time of writing of this document are: Bernard Aboba Rosenberg Expires August 5, 2006 [Page 22] Internet-Draft NAT Traversal Considerations February 2006 Harald Alvestrand Rob Austein Leslie Daigle Patrik Faltstrom Sally Floyd Mark Handley Bob Hinden Geoff Huston Jun-ichiro Itojun Hagino Eric Rescorla Pete Resnick Jonathan Rosenberg 10. Informative References [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [4] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [6] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress), September 2005. Rosenberg Expires August 5, 2006 [Page 23] Internet-Draft NAT Traversal Considerations February 2006 [7] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-05 (work in progress), April 2005. [8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in progress), October 2005. [9] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [10] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress), July 2005. [11] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [12] Quittek, J., "Definitions of Managed Objects for Middlebox Communication", draft-ietf-midcom-mib-05 (work in progress), March 2005. [13] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [14] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [16] Rosenberg, J., "Simple Traversal of UDP Through Network Address Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work in progress), July 2005. [17] Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp-04 (work in progress), September 2005. [18] Nordmark, E., "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-01 (work in progress), October 2005. [19] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-00 (work in progress), July 2005. Rosenberg Expires August 5, 2006 [Page 24] Internet-Draft NAT Traversal Considerations February 2006 [20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [21] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [22] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [23] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [25] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. Author's Address Jonathan Rosenberg, Editor IAB Rosenberg Expires August 5, 2006 [Page 25] Internet-Draft NAT Traversal Considerations February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires August 5, 2006 [Page 26]