Network Working Group J. Rosenberg Internet-Draft IAB Expires: August 14, 2005 February 13, 2005 Considerations for Selection of Techniques for NAT Traversal draft-iab-nat-traversal-considerations-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract There are many protocols designed and deployed on the Internet today which do not naturally traverse Network Address Translators (NAT). In order to allow these protocols to work in the presence of NAT, additional logic needs to be added to the network. This logic modifies the behavior of the protocol in some way. There are choices where this logic can be placed in the network. It can reside in the NATs themselves, transparently altering the protocol; when this occurs, it is called an Application Layer Gateway (ALG). It can Rosenberg Expires August 14, 2005 [Page 1] Internet-Draft NAT Traversal Considerations February 2005 reside in server components, hiding the changes from NATs and clients alike, it can reside in the clients, or it can reside in a combination thereof. The choice of the placement of this logic typically has implications on many aspects of the protocol, including security, deployability, manageability and availability. This document provides a set of considerations that should be taken into account by protocol and network designers when making this choice. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Techniques for Traversal . . . . . . . . . . . . . . . . . . . 5 3.1 Modify the NAT: Application Layer Gateways (ALG) . . . . . 5 3.2 Modify the Clients: Unilaternal Self-Address Fixing (UNSAF) . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Modify the Servers: Server Involvement in NAT Navigation (SINN) . . . . . . . . . . . . . . . . . . . . 6 3.4 Modify the NAT and the Client: RSIP, NSIS . . . . . . . . 7 3.5 Modify the NAT and the Server: MIDCOM . . . . . . . . . . 7 3.6 Modify the Clients and Servers: Protocol Update . . . . . 7 3.7 Modify Everything: IPv6 . . . . . . . . . . . . . . . . . 7 4. Considerations for Selection . . . . . . . . . . . . . . . . . 8 4.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1 Undermining Application Security Measures . . . . . . 8 4.1.2 Vulnerabilities Inherent in Traversal Technique . . . 11 4.2 Deployability Considerations . . . . . . . . . . . . . . . 12 4.3 Manageability . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Avaiability . . . . . . . . . . . . . . . . . . . . . . . 16 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Rosenberg Expires August 14, 2005 [Page 2] Internet-Draft NAT Traversal Considerations February 2005 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. However, many protocols were designed and deployed before the widespread deployment of NAT. Some of these protocols cease to work correctly in the presence 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. In order for these protocols to operate on the network in the face of NAT, numerous techniques have been developed, many of which are protocol specific. These include deploying Application Layer Gateways (ALGs), upgraded clients or servers, or one of the many Unilateral Self Address Fixing (UNSAF) techniques [4], such as the Simple Traversal of UDP through NAT (STUN) [5], Traversal Using Relay NAT (TURN) [6], Teredo [7] and Interactive Connectivity Establishment (ICE) [8]. As such, network designers and operators are faced with a choice of techniques. The right choice of technique depends on a number of architectural considerations. The purpose of this specification is to provide guidance to network designers, planners and operators on the selection of general technique for NAT traversal. It is not a detailed comparison of STUN, TURN, Teredo, and ICE, but focuses on the architectural issues around the choice between modified application components, ALGs, and UNSAF techniques. Many of the considerations here also apply to the design of traversal techniques for new protocols. However, that is not the focus of this document. 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. Section 2 provides a simplified view of the network under consideration, sufficient for the purposes of demonstrating the role of each technique. Section 3 is a more detailed description of the various techniques. Section 4 discusses the key architectural Rosenberg Expires August 14, 2005 [Page 3] Internet-Draft NAT Traversal Considerations February 2005 considerations when making the choice. These include security (Section 4.1), deployability (Section 4.2), manageability (Section 4.3) and availability (Section 4.4). 2. Network Model This section provides a basic model of the network deployments under consideration. It serves several purposes in this specification: o It serves to delineate the scope of the networks and application protocols under consideration. If an application protocol cannot be mapped into this model, or if a network deployment looks different than this model, the considerations documented here may not apply. o It serves as a way to help classify the various traversal techniques in terms of their impact on components in the network. +---------+ +---------+ | | | | | Server |<------------------->| Server | | |<--\ >| | +---------+ \ / +---------+ ^ \ / ^ | \ / | | \ / | | \ / | | \ / | | \ / | +-----------+ \/ +-----------+ | NAT | /\ | NAT | +-----------+ / \ +-----------+ | / \ | | / \ | | / \ | | / \ | V / \ V +---------+ / \ +---------+ | |<--/ >| | | Client |<------------------->| Client | | | | | +---------+ +---------+ Figure 1 Rosenberg Expires August 14, 2005 [Page 4] Internet-Draft NAT Traversal Considerations February 2005 The model under consideration is shown in Figure 1 In this model, the application protocol consists of two classes of entities - clients and servers. Clients refer here to the set of protocol functions that typically reside on end user hosts. In the problem under consideration here, these clients reside behind a NAT or NAT variant, such as Network Address Port Translation (NAPT) (from this point forward, we use the term NAT to include basic NAT and all of its variations). Servers refer here to the set of protocol functions that typically reside in the network. In the problem under consideration here, the servers reside on the public side of the NAT. They are deployed and operated by the service provider. The NAT sits between the clients and servers. It may be owned and deployed by the end user, by the service provider, or by a third entity (typically, the owner of the access network used by the users). Depending on the application protocol, clients may communicate with each other directly or through servers. Servers may talk with each other or just with clients, also depending on the application protocol. This model covers application protocols such as FTP, DNS, SIP, RTSP, ITU H.323 and others. 3. Techniques for Traversal There are many techniques that have been developed to facilitate the traversal of NAT. These techniques can be classified based on the way in which they affect the network in Figure 1. The various techniques ultimately modify the behavior of one or more of the components in the network, and possibly add additional components. With three separate logical components (clients, servers and NAT), there are 7 combinations of modifications that can be made. All seven are actually possible and have been used in actual deployments. 3.1 Modify the NAT: 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 Rosenberg Expires August 14, 2005 [Page 5] Internet-Draft NAT Traversal Considerations February 2005 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. 3.2 Modify the Clients: 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. Traversal Using Relay NAT (TURN) [6] is a cousin of STUN. However, packets sent to the address provided by the TURN server are actually relayed through the TURN server. TURN is a close cousin of Virtual Private Networks (VPN), of which there are many varieties. TURN differs from VPN in that it operates at a higher layer in the protocol stack, but is similar in that it provides the client with an address and port that route to a server which forwards the packet to the client. All of the techniques in this section share the property that they require the client software to be modified so that it becomes UNSAF aware. However, this modification tends to be isolated from the application protocol processing itself, with few touch points. Indeed, VPN solutions require no change in the application software itself. 3.3 Modify the Servers: 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 Rosenberg Expires August 14, 2005 [Page 6] Internet-Draft NAT Traversal Considerations February 2005 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). 3.4 Modify the NAT and the Client: RSIP, NSIS 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. Next Steps in Signaling (NSIS) allows clients to directly signal with their NAT to obtain bindings for use in application protocols [10]. 3.5 Modify the NAT and the Server: MIDCOM Middlebox Communications (MIDCOM) [11] allows servers to communicate with the NAT using an application-independent protocol (the MIDCOM 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.6 Modify the Clients and Servers: Protocol Update In this technique, the protocol gets re-engineered so that it traverses NAT without modification to the NAT itself. This has in fact occurred for several protocols. 3.7 Modify Everything: IPv6 Finally, one can elect to modify the clients and servers, adding Rosenberg Expires August 14, 2005 [Page 7] Internet-Draft NAT Traversal Considerations February 2005 IPv6, and modify the NAT itself by literally removing it from the network based on the presumption that it is no longer needed in IPv6. 4. Considerations for Selection 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 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. 4.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. 4.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 Rosenberg Expires August 14, 2005 [Page 8] Internet-Draft NAT Traversal Considerations February 2005 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 - 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 Rosenberg Expires August 14, 2005 [Page 9] Internet-Draft NAT Traversal Considerations February 2005 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. 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 Rosenberg Expires August 14, 2005 [Page 10] Internet-Draft NAT Traversal Considerations February 2005 (the UNSAF approaches in Section 3.2) are least intrusive, and do not undermine the application protocol security. 4.1.2 Vulnerabilities Inherent in Traversal Technique Section 4.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 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 Rosenberg Expires August 14, 2005 [Page 11] Internet-Draft NAT Traversal Considerations February 2005 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 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. 4.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 Section 2, 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. Rosenberg Expires August 14, 2005 [Page 12] Internet-Draft NAT Traversal Considerations February 2005 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. 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. 4.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 Rosenberg Expires August 14, 2005 [Page 13] Internet-Draft NAT Traversal Considerations February 2005 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 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 Rosenberg Expires August 14, 2005 [Page 14] Internet-Draft NAT Traversal Considerations February 2005 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 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, Rosenberg Expires August 14, 2005 [Page 15] Internet-Draft NAT Traversal Considerations February 2005 makes it difficult for applications to be built around a service model which is then ill defined. 4.4 Avaiability The choice of a traversal technique impacts availability in many ways. Firstly, techniques which add an additional component to the 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 Rosenberg Expires August 14, 2005 [Page 16] Internet-Draft NAT Traversal Considerations February 2005 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 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 [17] 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. 5. Conclusions There are many techniques that have been described for facilitating the traversal of NAT for protocols for which that capability is not inherent. Broadly speaking, those techniques can be characterized by the set of elements which need to be modified from the "normal" behavior in order for the application to work. As such, a service provider wishing to deploy an application has a wide choice about what technique to use. There are many considerations in that selection. Foremost amongst them is security. NAT traversal techniques frequently impair the inherent security features of the application protocol, and techniques where manipulation is done on the element that is trusted to manipulate that aspect of the message are preferred. Deployability is another concern, and different techniques will only be applicable depending on the scope of control and number of elements that need to be affected. The traveral Rosenberg Expires August 14, 2005 [Page 17] Internet-Draft NAT Traversal Considerations February 2005 techniques also impact manageability, in that some techniques may be difficult to diagnose and monitor in certain deployments. Finally, availability is affected by the technique, due to assumptions on the behavior of elements that may be false, incompletely specified behavior, or incomplete implementation. 6. 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. 7. IANA Considerations There are no IANA considerations associated with this specification. 8. IAB Members Internet Architecture Board members at the time of writing of this document are: Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle Patrik Faltstrom Sally Floyd Mark Handley Bob Hinden Geoff Huston Jun-ichiro Itojun Hagino Eric Rescorla Pete Resnick Rosenberg Expires August 14, 2005 [Page 18] Internet-Draft NAT Traversal Considerations February 2005 Jonathan Rosenberg 9 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-06 (work in progress), October 2004. [7] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-04 (work in progress), January 2005. [8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-03 (work in progress), October 2004. [9] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [10] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-04 (work in progress), October 2004. [11] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [12] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", Rosenberg Expires August 14, 2005 [Page 19] Internet-Draft NAT Traversal Considerations February 2005 draft-ietf-midcom-mib-04 (work in progress), January 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-00 (work in progress), October 2004. [17] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. Author's Address Jonathan Rosenberg, Editor IAB Rosenberg Expires August 14, 2005 [Page 20] Internet-Draft NAT Traversal Considerations February 2005 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 (2005). 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 14, 2005 [Page 21]