Network Working Group F. Cao Internet-Draft B. Zhou Intended status: Informational China Mobile Expires: January 6, 2011 July 5, 2010 Application Layer Gateway Problem Statement draft-cao-alg-problem-statement-00 Abstract Application Layer Gateway (ALG) has been widely implemented and used to support address and port translation in the payload for some well- known protocols. Due to the lackness of standardization on addressing ALG related issues, a number of serious problems are faced by service deployments and upgrades. This document specifies the common problems for ALG in various aspects. In addition, some collected feedbacks are also listed as the next steps to tackle these problems. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Cao & Zhou Expires January 6, 2011 [Page 1] Internet-Draft ALG Problem Statement July 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Implementation inconsistencies among vendors . . . . . . . 4 2.2. High operation costs . . . . . . . . . . . . . . . . . . . 4 2.3. Broken services in new deployment . . . . . . . . . . . . . 4 2.4. Emerging demand on ALG in IPv6 transition . . . . . . . . . 4 2.5. Conflict with encrypted or integrity protected protocols . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Interferance with NAT traversal . . . . . . . . . . . . . . 5 2.7. Regulation restriction . . . . . . . . . . . . . . . . . . 5 3. Conclusion and Recommendation . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Cao & Zhou Expires January 6, 2011 [Page 2] Internet-Draft ALG Problem Statement July 2010 1. Introduction Application Layer Gateway (ALG) has been widely used to support address and port translation in the payload for some well-known protocols, such as o FTP (active mode) o ICMP o RTSP o XMPP o H323 o MGCP o DNS ALG is a component which may be implemented along with or inside firewall or NAT. Due to the need of address and port translation in the payload, many network devices support ALG functions for a large number of such protocols. Due to the lackness of standardization on addressing ALG related issues, a number of serious problems are faced by service deployments and upgrades. For example, there are no commonly accepted requirements for network vendors to handle common ALG functions, such as out-of-order packets and TCP reassembly, which makes service integration and deployment very difficult. There is no guideline or Best Current Practice (BCP) on ALG implementation and deployment to mitigate the risks introduced by ALG related issues. This document specifies the common problems for ALG in various perspectives. In addition, some collected feedbacks are also listed as the proposed next steps to tackle these problems. 2. Problems This section describes the common problems faced by ALG in various categories. More details are provided inside each category to reflect current status. Cao & Zhou Expires January 6, 2011 [Page 3] Internet-Draft ALG Problem Statement July 2010 2.1. Implementation inconsistencies among vendors Different vendors have their own interpretation on how ALG should behavior for certain protocols. Due to the lackness of standardization, such ALG implementation inconsistencies have a big impact on evaluation and integration. To make things worse, different product lines belonging to the same network vendor may have inconsistent ALG implementations, which can introduce more confusions and troubles on its customers. 2.2. High operation costs There are many ALG related factors that can easily increase operation costs, especially for large service providers. First, some applications need different versions of different ALGs. This can complicate the deployment on ALGs with respect to the associated applications which may or may not be in the control of the same service provider. ISP test time for updated ALG version will be influenced by new behaviors of updated ALG and the associated applications. Note that there is no standardized document to follow on new behaviors of updated ALG. In addition, network vendors' turnaround time to add new ALG may be an issue for desired new service deployment. In some cases, the turnaround time for the fix or patch on existing ALGs cannot satisfy the urgent need of restore the desired services. 2.3. Broken services in new deployment New services based on certain protocols are introduced to ISP or ASP networks by facing the challenges of compatible ALG. Some of these new services had been broken down because of ALG related issues. For example, media streaming service provided by a big ASP in USA was broken down because of ALG's misbehavior. Similarly, multimedia streaming service in another ISP in Asia found out the service disruptions to some customers due to ALG related issues. 2.4. Emerging demand on ALG in IPv6 transition IPv6 has been gaining momentum for mitigating the issue of IPv4 address exhausion. With more trial-out and build-up of IPv6 networks and devices, the communications between IPv6 networks and IPv4 networks will introduce more issues on ALG for proper address and port translations. For example, the scenario of IPv6 applications accessing IPv4 servers Cao & Zhou Expires January 6, 2011 [Page 4] Internet-Draft ALG Problem Statement July 2010 requires the correct address and port translation in the payload to set up the session for certain protocols. In the future, more deployment scenarios may be introduced to enforce the evolutions of ALG in IPv6 translation. 2.5. Conflict with encrypted or integrity protected protocols When the payload is encrypted, ALG cannot decrypt the payload and finish the replacement on the desired fields. When the payload is protected with integrity check, ALG cannot generate the new integrity check after the address and port translation. 2.6. Interferance with NAT traversal ALG can interfere with evolution of protocols to handle NAT themselves. For example, ICE can be used for NAT traversal, which can help a set of protocols to avoid ALG issues. The pros and cons with ALG and without ALG need to be studied with respect to deployment scenarios. 2.7. Regulation restriction When ISPs modify the payload of certain applications using ALGs, the changes may trigger regulation issues. For example, the address and port translation in ALG may break location awareness in a VoIP service provider, which is regulated on emergency call in USA. 3. Conclusion and Recommendation These major problems faced by ALG have been paid attention to among ISPs, ASPs, and network vendors. The conclusion is that standardization on ALG related issues will definitely benefit the community for addressing these problems. From the collected feedbacks, the next steps can be taken as follows: o Identify the key general requirements for ALG o Provide the recommendations and the common solutions to satisfying each of these requirements o Standardize the ALG behavior on some major protocols for better inter-operations Cao & Zhou Expires January 6, 2011 [Page 5] Internet-Draft ALG Problem Statement July 2010 o Recommendations or guidelines for deployment and updates of ALG o Document the non-standard implementations and provide with an ongoing registry for such non-standard implementations for new ALGs 4. Security Considerations TBD 5. IANA Considerations This memo makes no request of IANA. 6. Contributors 7. Acknowledgements This draft contains the result of discussions involving many people, including Dan Wing, Hadriel Kaplan, Bob Hinden, Bob Penfield, Dave Thaler, Reinaldo Penno, Mayuresh Bakshi, and Jari Arkko. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 8.2. Informative References [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-11 (work in progress), March 2010. [I-D.ietf-behave-ftp64] Cao & Zhou Expires January 6, 2011 [Page 6] Internet-Draft ALG Problem Statement July 2010 Beijnum, I., "IPv6-to-IPv4 translation FTP considerations", draft-ietf-behave-ftp64-04 (work in progress), July 2010. Authors' Addresses Feng Cao China Mobile 1525 McCarthy Blvd. Milpitas, California 95035 USA Email: fjscao@gmail.com URI: Bo Zhou China Mobile Unit2, 28 Xuanwumenxi Ave Xianwu, Beijing 100053 China Email: zhouboyj@gmail.com Cao & Zhou Expires January 6, 2011 [Page 7]