Internet Engineering Task Force INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt I. Faynberg, S.K. Kasera, Date: February 24, 2002 S. Mizikovsky, Expires: July 2003 G.S. Sundaram, T. Woo Lucent Technologies Intermediary-Based Transport Services, Performance Optimization Mechanisms, and Relevant Requirements Status of this memo Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Network service providers are increasingly moving from providing just Internet connectivity to offering intermediary-based services and performance optimizations to enhance end user experience at reduced costs. These services and optimizations are being, or will be, offered with the help of intermediate nodes placed in the service provider network between communicating end-points. In this document, we list several intermediary-based transport services and performance optimization mechanisms that are being (or could be) provided by the intermediate nodes, and identify the requirements of any solution that securely offers these services and mechanisms. Faynberg et al Expires 07/03 [Page 1] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 Contents 1 Introduction 2 2 Terminology 3 3 Intermediary-Based Transport Services and Performance Optimization 3 4 Requirements 7 4.1 General Requirements ...................................... 7 4.2 Policy Requirements ....................................... 8 4.3 Security Requirements ..................................... 9 5 Security Considerations 10 6 Conclusion 11 7 Acknowledgments 11 1 Introduction Traditionally, network service providers have delivered Internet connectivity as a major service to individual users and enterprises. Presently, these service providers are increasingly moving from providing just Internet connectivity (a ``dumb-pipe'' to offering intermediary-based services and performance optimizations to enhance end user experience at reduced costs. These services and optimizations are being, or will be, offered with the help of intermediate nodes placed in the service provider network between communicating end-points. An intermediate node could be a router, a switch, application gateway, a middle box [1], a performance enhancing proxy [2], or a node of an overlay network. In order to provide intermediary-based services and performance optimizations, the intermediate node uses the knowledge of aggregated and per-flow traffic behavior at its location as well as its processing, caching and/or filtering capabilities. In this document, we first list several intermediary-based transport services and performance optimization mechanisms that are being (or could be) provided by the intermediate nodes. Next, we identify the requirements of any solution that offers these Faynberg et al Expires 07/03 [Page 2] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 services and mechanisms. It is important to note that not all kinds of intermediate nodes can be addressed by a single set of requirements or resulting architecture. Our focus is on requirements for only those intermediate nodes that can offer transport services, although some of these requirements may also apply to other intermediate nodes. This document, however, stops short of presenting any actual security solution that satisfies these requirements; it invites the response from the Internet community and proposes that the development of a protocol for secure end-system-intermediary interchanges on transport services, starting from the requirement set presented here, become a work item in the IETF. The rest of this draft is organized as follows: Section 2 contains the terminology; Section 3 discusses intermediary-based transport services and performance optimization mechanisms; Section 4 presents the requirements for a solution; Section 5 contains the security considerations; Section 6 contains the conclusion; Section 7 contains the acknowledgments. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. 3 Intermediary-Based Transport Services and Performance Optimization Typically, the services offered by the intermediate node include those offered by a middle box, as defined in [1], such as policy based packet filtering, network address translation (NAT), intrusion detection, load balancing and policy-based tunneling. The performance optimizations also include those offered by the performance enhancing proxies (or PEPs) such as TCP throughput enhancements for wireless links, keeping TCP connections alive during user mobility, response times reduction with the help of caching, etc. An intermediate node uses the knowledge of aggregated as well as per-flow traffic behavior at its location as well as its processing, caching and/or filtering capabilities to offer services and higher performance. The ability of an intermediate node to influence the traffic behavior and offer such services depends on its accessibility to Faynberg et al Expires 07/03 [Page 3] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 the information contained in the 1. IP header; or 2. Transport header; or 3. application header and data; or 4. a combination of some or all of the above. We now describe some intermediary-based transport services and performance optimization mechanisms and also identify which parts of the packets should be accessible to the intermediate node(s) to offer these services and mechanisms. o TCP Enhancements: Enhancements to transport protocols such as TCP over error prone and bandwidth-limited links has been an area of study for almost a decade. Particularly, when wireless links are involved, the variance in delay is found to be an important factor influencing TCP performance [4]. Large delay variance decreases the effective client throughput of all TCP-based applications. An accepted mechanism for enhancing TCP performance in such situations is the implementation of a TCP-PEP at the intermediate node. The TCP-PEP can examine, modify or generate TCP packets so as to match the characteristics of the wireline interface to that of the wireless interface thus improving end-to-end TCP performance. Figure 1 shows an example of TCP throughput enhancement for a mobile wireless user. In this figure, the mobile user is communicating with a server using TCP. An intermediate TCP-PEP regulates the acknowledgments [4] from the mobile host to account for the large variations in wireless delay experienced by data flowing towards the mobile, thereby enhancing overall TCP throughput. o QoS Provisioning, Differential Services, Packet Classification and Policy Implementation: An intermediate node could identify flows based on source and destination IP addresses, TCP/UDP source and destination port numbers, IPsec security parameter index (SPI), and next protocol identity, to offer quality of service guarantees and differentiated treatment to certain packets. It could also use the DSCP (Differentiated Faynberg et al Expires 07/03 [Page 4] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 Service Code Point) bits in the IP header or even application layer information to differentially treat packets. For example, the intermediate node, could assign lower priority to +---------------+ ---- | | / // \\ | | +------+ /--/ | TCP | | | | | / | PEP | ------------| Server | *------* | | Wireline | | /--------\ \\ // Network | | ---- | | Mobile User +---------------+ Data <-------- Acks -----> Regulated Acks -> <---------------- TCP connection -------------> Figure 1: TCP Ack Regulator non-conforming UDP traffic and a higher priority to TCP traffic during link congestion. An intermediate node could use the security parameter index in IPsec packets together with the IP destination address to identify flows for providing RSVP-based quality of service. This assumes that RSVP signaling [5] is used to create the required state in the intermediate node. These examples show that packets could be classified using multiple fields. A specific classification method and policy implementation depend on the application. Figure 2 shows an example of filtering packets based on multimedia transport information. In this figure, multi-layer video is unicast from the source to the receiver. On observing link congestion, the intermediate node, in the path from the source to receiver, selectively drops packets of lower priority layers. The identity of the layers is found in the multimedia transport header. The intermediate node performing the selective dropping must have the knowledge of the multimedia transport header format. Keller [6] has demonstrated dramatic improvements in video quality by using one such scheme. Faynberg et al Expires 07/03 [Page 5] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 +---------------+ ---- | | Congested // \\ | | +------+ Link | Packet | | | | |-------------- | Filter | ------------| Video Source | *------* | | | | /--------\ \\ // | | ---- +---------------+ Video Receiver Drop lower priority layers <-------------------------------------------------- Multi-layer Video Figure 2: Selective Video Filtering The above example is close to the boundary of not being a transport service. This document, as it develops, must define the boundary of requirements for intermediary-based transport services versus application-layer gateways. Similarly it must differentiate the requirements of the issues described here from those of OPES (Open Pluggable Edge Services) [7]. As mentioned, there may be some requirements in common, especially security, but the differentiation of the services needs to be clear. o Ingress Filtering: Intermediate nodes could be configured to filter out packets from unwanted sources to enterprise VPN clients. Enterprise VPN clients commonly establish secure sessions with their enterprise gateways for accessing their company resources (computers and servers). These clients, especially bandwidth limited wireless mobile enterprise users, can be potentially flooded with unwanted packets from IP addresses outside the enterprise or even spoofed enterprise IP addresses. These unwanted packets could be ``ingress-filtered'' at an intermediate node (e.g., a public data service node) in the path from the enterprise client to the enterprise gateway by setting up an additional authentication tunnel between the enterprise gateway and the intermediate node. On receiving packets with source addresses set to valid enterprise IP addresses, the intermediate node allows only those packets that it can authenticate and drops the rest. Faynberg et al Expires 07/03 [Page 6] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 Ingress-filtering service requires that the IP header be visible to the intermediate node. The intermediate node could also implement a stateful firewall. One example of a stateful firewall service is the enforcement of a policy that incoming (into an enterprise network) TCP packets must belong to the traffic initiated from within the enterprise. There are other ways to achieve the same effect, but their common requirement is that TCP state be maintained by the firewall (which, for the purposes of the network-based VPN services is typically implemented at the intermediate node). More generally, several firewall services may be offered at the intermediary by examining the transport and IP headers. 4 Requirements This section lists the requirements for a solution that provides intermediary-based transport services. In order to enable intermediary-based transport services and performance optimization mechanisms, the end-points and the intermediate nodes must exchange messages for configuring and requesting services. The end-points must securely and reliably communicate the necessary information to the intermediate node including service requests, packet formats and other configuration parameters. Depending on the service request, the end-points should also make certain portions of the packets (header + data) accessible to the intermediate node. The requirements associated with these functions are listed below. 4.1 General Requirements The users and the intermediate node should have a clear understanding of the services being offered, how the services can be requested, and what packet formats are used. There should be coordination between end-points and the intermediate node(s). The end-points and the intermediate nodes should have read/write access to relevant service configuration parameters. With that: o The end-points should pass service configuration information to the intermediate node including any service parameters and header formats. o The message exchange between an end-point and an Faynberg et al Expires 07/03 [Page 7] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 intermediate node as well as the message exchange among the intermediate nodes regarding configuration and service invocation and revocation, should be simple and reliable. o The security framework should support dynamic invocation/revocation of services during a session. o The solution should be extensible to including other intermediary-based transport services. o The overhead in enabling intermediary-based transport services and performance optimization mechanisms should be minimal and definitely much less than any performance benefits obtained from the network-based services and performance optimizations. o The solution should be scalable in its ability to handle service requests of a large number of users. o The security architecture should also be sensitive to the end-user limitations, especially to bandwidth-limited and battery-power-limited mobile users. o The solution should also support mobility of wireless users. o The solution should be manageable, reliable, and interoperable with existing Internet boxes. 4.2 Policy Requirements In the development and deployment of a secure solution for enabling intermediary-based transport services and performance optimization mechanisms, a number of policy decisions are required that will define how the services are to be applied, configured and used. The following are the policy requirements: o The end-points should decide what transport services and performance optimization mechanisms should be enabled, if any. The end-points should be able to negotiate between Faynberg et al Expires 07/03 [Page 8] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 themselves and decide what should be accessible to the intermediate node(s). o Depending on the nature of the service, the end-points may allow intermediate nodes to modify the portion of accessible user data or even generate new data in a controlled manner. o The end-points should be able to explicitly address the intermediate nodes at the IP layer [8]. o An intermediate node should be able to isolate different user sessions in offering services. 4.3 Security Requirements In order to enable services and performance optimizations the end-points must provide the necessary information to the intermediate node through explicit signaling messages and/or by making certain portions of the packets (header + data) visible to the intermediate nodes. The following requirements hold: o All other data that are not essential for the intermediate node must still be securely protected between end-points. o Each session end-point should invoke services from at most one intermediate node. This implies that an end-to-end session between two end-points should have at most two intermediate nodes. o All users must be authenticated by the their respective intermediate nodes. Only authorized users must be allowed to request and benefit from the services offered by the intermediate node. The end-points must also authenticate the intermediate node(s) before trusting them. Wherever applicable, a mutual authentication procedure could be adopted, and it should be accomplished using existing out-of-band mechanisms. Faynberg et al Expires 07/03 [Page 9] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 o The end-points should be able to detect any inappropriate behavior (attempts to play ``end-to-end games'' or failure to provide service) of the intermediate nodes and take corrective action [8]. o Authorized communication between the end-points and the intermediate nodes should be secure and protected from spoofing, change of content, and denial of service. The end-points should be able to ensure that even the data visible to the trusted intermediate nodes is otherwise protected in the public un-trusted transport. More specifically, 1. The end-points should establish security associations between themselves and their intermediate nodes. When both end-points use intermediate nodes then a security association between the two intermediate nodes should also be established. 2. When an end-point revokes the services of an intermediate node and invokes services of another intermediate node, the security associations involving the old intermediate node must be torn down and new security association(s) with the new intermediary should be established. This requirement also applies to mobile users as they move from within the realm of one intermediate node to another. 3. At any point in time, an end-point might decide to stop using its intermediate node. In this scenario, security associations with that intermediary must be broken and a new one may be established if required. 4. If the state or cached data associated with an ongoing end-to-end session at an intermediate node must be transferred to another intermediate node, for instance due to node failure or due to end-point mobility, it must be done securely. 5 Security Considerations Security has been discussed in all the sections especially in the previous section. Faynberg et al Expires 07/03 [Page 10] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 6 Conclusion This document has described a list of intermediary-based transport services and performance optimization mechanisms and the requirements for offering these services in a secure manner. The authors invite participation from the Internet community and propose that a protocol for secure end-system-intermediary interchanges on transport services starting from the requirement set presented in this document become a work item in the IETF. 7 Acknowledgments We would like to thank Allison Mankin, Sarit Mukherjee, Sampath Rangarajan and Matthew Udanoh of Lucent Technologies for useful discussions on this topic and comments on this draft. References [1] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan. Middlebox Communication Architecture and Framework. RFC 3303, IETF, August 2002. [2] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby. Performance Enhancing PRoxies Intended to Mitigate Link-Related Degradations. RFC 3135, IETF, June 2001. [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [4] M.C. Chan and R. Ramjee. TCP/IP performance over 3G wireless links with rate and delay variations. In Proc. of ACM Mobicom, September 2002. [5] L. Berger and T. O'Malley. RSVP Extensions for IPsec Data Flows. RFC 2702, IETF, September 1997. [6] R. Keller, S. Choi, M. Dasen, D. Decasper, and G. Frankhauser. An active router architecture for multicast video distribution. In Proc. of IEEE Infocom, Mar. 2000. [7] A. Barbir, R. Chen, M. Hofmann, H. Orman, and R. Penno. An Architecture for Open Pluggable Edge Services (OPES). Internet Draft, IETF, December 2002. draft-ietf-opes-architecture-04.txt. [8] S. Floyd and L. Daigle. IAB Architectural and Policy Considerations for Open Pluggable Edge Services. RFC 3238, IETF, January 2002. Faynberg et al Expires 07/03 [Page 11] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 Authors' Addresses I. Faynberg Lucent Technologies 101 Crawfords Corner Road, Rm 4D-601A Holmdel, NJ 07733, USA Email: faynberg@lucent.com S.K. Kasera Lucent Technologies 101 Crawfords Corner Road, Rm: 4F-537 Holmdel, NJ 07733, USA Email: kasera@research.bell-labs.com S. Mizikovsky Lucent Technologies 67 Whippany Road, Rm: 14D-314 Whippany, NJ 07981, USA Email: smizikovsky@lucent.com G.S. Sundaram Lucent Technologies 67 Whippany Road, Rm: 14D-328 Whippany, NJ 07981, USA Email: ganeshs@lucent.com T. Woo Lucent Technologies 101 Crawfords Corner Road, Rm: 4E-614 Holmdel, NJ 07733, USA Email: woo@dnrc.bell-labs.com Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative Faynberg et al Expires 07/03 [Page 12] INTERNET-DRAFT draft-faynberg-intermediary-transport-00.txt 02/24 works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Faynberg et al Expires 07/03 [Page 13]