Network Working Group J. Rosenberg Internet-Draft IAB Expires: January 3, 2005 July 5, 2004 Network Address Translator (NAT) and Firewall Application Layer Gateways (ALG) Considered Harmful draft-iab-alg-harmful-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 January 3, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Application Layer Gateways (ALGs) are application-aware components resident within Network Address Translators (NAT) and firewalls. These components typically inspect and change application data within IP datagrams, in order to provide "transparent" NAT and firewall traversal. However, ALGs introduce many problems, including degradation in security, reduction in the ability to perform network diagnostics, difficulty in deploying new applications, and reduction in service availability. For these reasons, this document concludes that ALGs are harmful to the Internet. Rosenberg Expires January 3, 2005 [Page 1] Internet-Draft ALGs Considered Harmful July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems with ALGs . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Introduction of Security Vulnerabilities . . . . . . . . . 5 3.1.1 Undermining Application Security Measures . . . . . . 5 3.1.2 Attacks Inherent in ALG . . . . . . . . . . . . . . . 7 3.1.3 Security Issues without Transparency . . . . . . . . . 8 3.2 Increased Barriers to Deployability . . . . . . . . . . . 9 3.3 Impairment of Network Diagnostics . . . . . . . . . . . . 11 3.4 Reduction in Service Availability . . . . . . . . . . . . 13 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Rosenberg Expires January 3, 2005 [Page 2] Internet-Draft ALGs Considered Harmful July 2004 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." RFC 2663 also 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. 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 change is needed in the hosts that access the application, and no configuration changes are needed anywhere except on the device running the ALG. For these reasons, ALGs have seen good deployment by enterprises and network operators. ALGs have seen the widest deployment 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. For these applications, ALGs appear to work adequately. More recently, ALGs have been developed to assist in NAT and firewall traversal for protocols such as ITU-T H.323, the Session Initiation Protocol [2] and the Real Time Streaming Protocol [3], amongst others. Unfortunately, ALGs for these protocols have introduced a number of problems. Some of these problems, most notably the security implications of ALG, have been documented [1]. However, ALGs for these more recent protocols have introduced additional problems, such as a reduction in the ability to perform network diagnostics. These problems, along with the increased importance of security in the Internet, have led us to the conclusion that ALGs are harmful to the Internet. This document focuses solely on problems specific to ALGs, as opposed to problems with NATs and firewalls in general. As such, it is not meant as an update or modification of RFC 2993 [9], but rather considers additional issues, specific to ALG, that are not discussed, or only touched on there. Rosenberg Expires January 3, 2005 [Page 3] Internet-Draft ALGs Considered Harmful July 2004 2. Terminology Many of the terms used in this document have been used throughout the literature, often in inconsistent ways. For purposes of this document, the following definitions are used: Firewall: An IP router that consults a table of permissions before deciding whether or not to forward an IP datagram across its interfaces. Firewalls are used at the periphery of networks in order to act as a security policy enforcement point. Network Address Translator (NAT): As defined in RFC 2663, a NAT is an IP router that implements a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. This mapping is performed by consulting a table of bindings. Intermediary: A firewall or NAT. Permission: The state used by a firewall for determining whether or not to forward IP datagrams. Binding: The state used by a NAT for determining how to map addresses from one address realm to another. Intermediary State: Bindings or permissions. Application Layer Gateway: An application specific translation agent, resident in a NAT or firewall, that dynamically creates bindings or permissions by inspecting and/or modifying the content of IP datagrams, based on an awareness of the protocols sending those packets. An ALG is, by definition, transparent, in that it is not addressed by participants in the application protocol, and those participants are not aware of its existence. Internet Service Provider (ISP): A provider that owns and sells IP access infrastructure to users. This includes dial-up access, Digital Subscriber Line (DSL) and Cable providers, and Wireless Fidelity (WiFi) providers. Rosenberg Expires January 3, 2005 [Page 4] Internet-Draft ALGs Considered Harmful July 2004 3. Problems with ALGs Even though they bring many benefits, ALGs introduce a number of significant problems. 3.1 Introduction of Security Vulnerabilities RFC 2663 discusses some of the security implications of NAT, and mentions briefly some of the issues specific to ALGs. We consider here the security implications specific to ALGs in general, including those present in both firewalls and NATs. 3.1.1 Undermining Application Security Measures An ALG useful in a network when a protocol cannot operate through the intermediary without some kind of change, either to participants in the protocol, or to the intermediary. The reason that the application doesn't work through the intermediary is that it requires presence of a translation or binding in the 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. The ALG therefore inspects the packets, finds the problematic addresses and hostnames, installs the neccesary permissions and bindings, and in the case of NAT, rewrites the addresses in the packet to one that is valid on the other side of the NAT. The act of reading and modifying protocol messages is not inherently problematic; most protocols that have intermediaries as parts of the protocol (such as SIP and HTTP) allow such intermediaries to inspect and modify messages. However, in these cases, the intermediaries are directly addressed by the endpoints. They are not transparent. This means that the protocols can be designed to establish security relationships between clients of the protocol and the intermediaries. In the case of ALGs, however, the opposite is true. The ALG is, by definition, transparent. The ALG does not represent a protocol level entity that is addressed by a client. It is a man-in-the-middle, inspecting and modifying protocol messages without explicit awareness or consent by the actual entities in the protocol. The implication of this is that an ALG in a firewall cannot function if the underlying protocol provides confidentiality for the parts of the message that the ALG needs to inspect. An ALG in a NAT cannot function if the underlying protocol provides either confidentiality or integrity for those parts of the message. ALGs in a firewall can Rosenberg Expires January 3, 2005 [Page 5] Internet-Draft ALGs Considered Harmful July 2004 operate even if message integrity is provided, because the firewall does not need to modify the message - only inspect it. 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 [10]. 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. Consider the case of SIP. SIP messages carry a MIME payload that describes the multimedia session being established. This payload is usually the Session Description Protocol (SDP) [4]. SDP includes IP address and port information, indicating the transport address where media packets (such as audio and video) should be sent. A SIP ALG in a NAT will require access to these addresses, so that they can be modified for SIP traversal through the NAT. However, if an attacker can access and modify these addresses, 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. ALGs therefore disallow a protocol from protecting key pieces of information from inspection and modification. There are two potential implications of this. Firstly, it is a possibility that new protocols will be designed that explicitly do not include Rosenberg Expires January 3, 2005 [Page 6] Internet-Draft ALGs Considered Harmful July 2004 security features to protect these addresses, so that the protocol can transit an intermediary with the assistance of an ALG. However, it is more likely that a protocol does include such features, but that vendors do not implement them, or users disable them, in order to allow traversal through intermediaries using ALG. Either case introduces serious security holes into the protocol which cannot be repaired. Worse still, most application protocols due not have security features to protect just the addressing information in the message. Rather, security techniques will either protect everything, since they utilize channel security (for example, securing HTTP by running it over TLS), or protect large chunks of data that include such addresses, when object security is used (for example, securing SIP by using S/MIME encryption of its bodies). Because an ALG requires such security features to be disabled, attacks on the protocol, unrelated to the addressing information it carries, are possible. Effectively, ALGs render the security features in most protocols impotent. At the time RFC 2663 was written, attacks on the Internet were relatively rare, and few protocols had extensive security capabilities built in. Both of those facts have changed, and as a result, the security holes introduced by ALG cannot be dismissed. 3.1.2 Attacks Inherent in ALG Section 3.1.1 considers security vulnerabilities introduced by ALGs because of the need to disable security features in application protocols. Another class of attacks are possible due to the inherent properties of ALG. These attacks cannot be prevented by any security properties of the application protocols. 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. This enables an attack whereby a client behind the intermediary generates a request, but places the address and port of a target behind the intermediary into the protocol packet. The intermediary then allocates a binding and/or creates a permission, permitting packets from outside the intermediary to be routed towards the attack target. Depending on the protocol in question, this can provide substantial amplification of traffic towards the target. Unfortunately, in the case of a firewall, the ALG function has effectively disabled the security properties normally enabled by the firewall. Traffic will flow freely from outside the network, through the firewall, towards the attack target. Rosenberg Expires January 3, 2005 [Page 7] Internet-Draft ALGs Considered Harmful July 2004 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. If the attacker lists a broadcast address, especially in conjunction with the echo port, and the NAT does not prohibit the usage of such addresses and ports, further amplification attacks are possible. These attacks are all possible because the ALG is creating bindings and/or permissions towards an internal address without being able to properly authorize that the host sending the request is permitted to specify that packets should be relayed towards that internal address. These are the same kinds of attacks possible in 6to4, and are possible for the same reasons [11]. These attacks can, in some cases, be mitigated by having the ALG only create bindings or permissions for internal addresses that match the source IP address and port of the packet. Unfortunately, this does not work in many situations. In the case of SIP, if the request has been relayed through a proxy, it will not work at all. 3.1.3 Security Issues without Transparency The security problems in the previous two sections are a consequence of the transparent nature of the ALG. Because the ALG is not a directly addressable entity in the protocol, it has to act as a man-in-the-middle, eavesdropping and/or modifying protocol messages. As such, one might conclude that, instead of removing the ALG, the ALG should just be elevated to a full participant in the protocol. That is, instead of removing the ALG, remove its transparency. Unfortunately, that eliminates many of the security problems identified above, but introduces even more complicated ones. In particular, it introduces another element into the application protocol, and one with whom there is a complex trust relationship. Frequently, the intermediary is owned by the access provider. Rosenberg Expires January 3, 2005 [Page 8] Internet-Draft ALGs Considered Harmful July 2004 Clients will generally trust their access provider to perform access services, but no more. The application provider often has no relationship with the access provider, and in some cases, the relationship may be antagonistic. To design a security solution for an application protocol in such a configuration is a daunting task, and is likely to be difficult at best. Another aspect of this is overall system complexity. The more components there are in a system, and the more complex their processing is, the more difficult it is to secure that system. By making ALGs full-fledged participants in the protocol, the overall system complexity increases further, making it more likely that there will be security vulnerabilities. 3.2 Increased Barriers to Deployability FTP is an example of an application that requires an ALG in order to traverse and intermediary. FTP is widely deployed, and would appear to be a good indicator that ALGs are not a barrier to deployment of applications. However, FTP (along with DNS and a handful of other protocols) are unique in that they existed before the definition and widespread deployment of intermediaries. As a result, nearly all intermediaries that were deployed included ALG functionality for these protocols, and they continued to operate properly as more and more intermediaries were deployed. However, this is not the case for protocols defined after the widespread deployment of intermediaries. Existing intermediaries would not contain an ALG function for a new protocol, and this introduces a number of deployment and operational difficulties. The scope of the problem depends in part on the type of provider that is deploying the application. We can break the problem into two cases. The first are application providers that also own the IP access infrastructure used to connect to those applications (i.e., the ISP is the application provider), and the second are application providers that do not. The second case includes traditional Application Service Providers (ASPs) but also ISPs deploying an application that requires communication with users that are customers of a different ISP. The first case includes enterprises, since the IP access is provided by the enterprises. In the first case, the application provider is faced with a network upgrade problem. To deploy the new application, it needs to upgrade any existing intermediaries to support the ALG function for the new application. Depending on the protocol, this could require a Rosenberg Expires January 3, 2005 [Page 9] Internet-Draft ALGs Considered Harmful July 2004 forklift upgrade, or possibly a gradual upgrade of intermediaries only for those customers who sign up for the new application. In either case, the underlying IP network infrastructure needs to be upgraded to support the new application. This can be expensive and time-consuming, but worse, indicates that a fundamental characteristic of the IP network has been lost - the "hourglass" model of IP, which allows new applications to be deployed ontop of a common IP layer. Indeed, the premise of ALG is that routers need to be modified to support new applications, a premise that is anathema to the end-to-end model of IP. In the second case, the ASP is faced with an impossible problem. Deployment of the new application requires ALG functions to be deployed in the intermediaries in the access network, but the ASP does not own or control those intermediaries! The result is that the ASP cannot deploy the application using ALG. In practice, there have been two results of this conondrum. Firstly, for protocols that do not inherently traverse intermediaries, ASP's have instead relied on techniques that do not require ALG to be deployed. Usually, this is done by deploying servers that are not transparent to the protocol, but otherwise perform similar functions to the ALG, or by modifying the protocol. The second result of the conundrum is that many of the new protocols that have been deployed were designed with intermediaries in mind, and do not require an ALG. Oftentimes, this is done at the expense of security or performance, since ultimately deployability trumps these concerns. In either the first or second case, there is an additional deployment problem - the availability of commercial products that implement the ALG functionality. 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. The result is a chicken-and-egg problem that further slows the deployment of new applications. As an example of these deployment problems, the deployment of Explicit Congestion Notification (ECN) for TCP [12] was hampered due to firewalls which had TCP awareness, and improperly handled the reserved bits in the TCP header [13]. Although ECN is not an application protocol per se, the problems faced in deploying ECN are the same, and for the same reasons. To fix this problem, ECN chose to modify the protocol, in order to work in the face of the broken TCP implementations in firewalls. Another example is the Internet Key Exchange (IKE) [14], used for keying of IPSec [15]. IPSec was deployed before IKE itself. As a result, ALG functionality for "IPSec helpers" was deployed. This Rosenberg Expires January 3, 2005 [Page 10] Internet-Draft ALGs Considered Harmful July 2004 made development of intermediary traversal solutions for IKE even more complex. Not only did it have to deal with intermediaries without any IPSec or IKE awareness, it had to deal with intermediaries with IPSec "helpers" that actually got in the way. In conclusion, ALGs introduce substantial barriers to deployment of new applications. Indeed, these barriers are so subtantial that most new protocols are designed to avoid the usage of an ALG at all costs, including reduction in security or performance. 3.3 Impairment of Network Diagnostics 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) [5] 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. Unfortunately, ALGs further complicate this problem. 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 Rosenberg Expires January 3, 2005 [Page 11] Internet-Draft ALGs Considered Harmful July 2004 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 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 Rosenberg Expires January 3, 2005 [Page 12] Internet-Draft ALGs Considered Harmful July 2004 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. 3.4 Reduction in Service Availability ALGs not only impair the ability of an administrator to detect problems with an application, they also increase the likelihood that such problems occur. One problem is the domain expertise problem. The manufacturers of intermediary devices 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 [6], 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. Another problem is that ALGs are not formal elements in any application protocol. As a result, there are no standards that dictate their behavior. Their functional requirements are derived entirely by the engineering team that is writing the ALG, and are extrapolated from the protocol standard, but are not dictated by the standard itself. This leaves substantial room for error, or more likely, overlooking of features that will cause failures outside of the basic "sunny day" scenarios. The ECN deployment problems are an example of this. 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 [7] 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 Rosenberg Expires January 3, 2005 [Page 13] Internet-Draft ALGs Considered Harmful July 2004 ALG will be hard to ascertain because of the diagnostic issues described above. Rosenberg Expires January 3, 2005 [Page 14] Internet-Draft ALGs Considered Harmful July 2004 4. Recommendations Unfortunately, getting applications to work through intermediaries, such as firewalls and NATs, is not a trivial problem. Many other solutions, besides ALGs, have been developed and deployed to provide such functionality. This document does not make a concrete recommendation on any of these techniques. Rather, it extracts key requirements for such a solution based on the difficulties with ALGs that are documented here. REQ 1: Techniques for traversal of a protocol through intermediaries should not require security features in that protocol to be disabled or degraded in any way. More generally, these techniques should not interfere with the underlying security properties and requirements of the protocol. REQ 2: Before an intermediary creates a dynamic binding or permission, it needs to be sure that creation of the binding or permission is authorized. REQ 3: If new network elements are deployed to provide traversal, those elements must be visible participants in the overall system, so that their behavior can be properly defined, including security, diagnostic and functional behaviors. REQ 4: Traversal solutions should have a path to deployment which does not require upgrade to all intermediaries in the access network. It is worthwhile to note that these recommendations are similar to the IAB considerations for OPES [8], which discusses a similar problem. Rosenberg Expires January 3, 2005 [Page 15] Internet-Draft ALGs Considered Harmful July 2004 5. Acknowledgements We would like to thank Cullen Jennings for identifying the attack discussed in Section 3.1.2. Rosenberg Expires January 3, 2005 [Page 16] Internet-Draft ALGs Considered Harmful July 2004 6. Security Considerations ALG's introduce serious security holes into the Internet, as discussed extensively in Section 3.1. It is for this reason, amongst others, that this memo concludes that ALGs are harmful to the Internet. Rosenberg Expires January 3, 2005 [Page 17] Internet-Draft ALGs Considered Harmful July 2004 7. 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 Jonathan Rosenberg 8 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] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [6] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [8] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Rosenberg Expires January 3, 2005 [Page 18] Internet-Draft ALGs Considered Harmful July 2004 [9] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [10] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [11] Savola, P., "Security Considerations for 6to4", draft-ietf-v6ops-6to4-security-03 (work in progress), June 2004. [12] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [13] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002. [14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [15] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Author's Address Jonathan Rosenberg, Editor IAB Rosenberg Expires January 3, 2005 [Page 19] Internet-Draft ALGs Considered Harmful July 2004 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 (2004). 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 January 3, 2005 [Page 20]