Internet DRAFT - draft-cao-alg-problem-statement
draft-cao-alg-problem-statement
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]
