Internet Engineering Task Force INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt U. Blumenthal, Date: June 20, 2003 I. Faynberg, Expires: December 2003 S.K. Kasera, S. Mizikovsky, G.S. Sundaram, T. Woo Lucent Technologies Securely Enabling Intermediary-based Transport Services 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 The growth of the Internet has witnessed an emergence of transport services that rely on or can benefit from assistance of network intermediaries between communicating end-points. Such services, for example, include TCP performance enhancements, multimedia packet filtering, header compression, and prevention of Denial-of-Service. In this draft, we describe some of the important aspects of the problem of securely enabling intermediary-based services. We also present several scenarios where this problem is manifested. Contents 1 Introduction 2 2 Terminology 3 Blumenthal et al Expires 12/03 [Page 2] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 3 Problem Description 3 3.1 Communication Between End-points and Intermediary ........ 3 3.2 Exposing Information ..................................... 5 3.3 Preserving Security ...................................... 7 4 Problem Manifestations 8 5 Security Considerations 12 6 Related Work 12 7 Conclusions 13 8 Acknowledgments 13 1 Introduction The growth of the Internet has witnessed an emergence of transport services that rely on or can benefit from assistance of network intermediaries between communicating end-points [1, 2, 3]. Such services, for example, include TCP performance enhancements, multimedia packet filtering, header compression, and prevention of Denial-of-Service. As for network intermediaries, they could be routers, switches, application gateways, middle boxes [1], performance enhancing proxies [2], or nodes of an overlay network. To provide intermediary-based services they may make use of the knowledge of aggregated and per-flow traffic behavior at its location as well as their processing, caching and/or filtering capabilities. There are two important components of the problem of enabling intermediary-based services. First, end users may need to communicate with the network intermediaries for configuration and solicitation of service. Second, the end users must make any information available to the intermediary that might be necessary for them to offer the requested services. The second problem is especially challenging when an end-to-end security solution such as IPsec is used. Using IPsec, an end-user cannot contract value-added services from a network intermediary unless it fully sacrifices end-to-end security. Overall, we believe work is necessary to determine how to request, authenticate, authorize, and obtain the services of intermediaries, and to minimize the impact of intermediaries on end-to-end security. Blumenthal et al Expires 12/03 [Page 2] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 Depending on the intermediaries and the services offered by them, the problem of securely enabling intermediary-based services could have various aspects. In this draft, we describe some of the important aspects of the problem. We also present several scenarios where the problem of securely enabling intermediary-based services is manifested. This document invites the response from the Internet community and proposes that the problem of securely enabling intermediary-based services should become a work item in the IETF. 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 [4]. o End-point: An end-user node including a PC, a laptop, a hand-held device, etc. running user applications. o Intermediary: A network node including a router, a switch, an application gateway, a middle box [1], a performance enhancing proxy [2], or a node of an overlay network. 3 Problem Description In this document we focus on the problem of securely enabling and using intermediary-based services. We identify the key components of this problem, and describe them in the following subsections. 3.1 Communication Between End-points and Intermediary The end-points and the intermediary may need to communicate with each other to request and control intermediary-based services. In particular, the communication may serve functions such as the ones described below. o Service discovery: The end-point might need to discover the services that are available from the intermediary. Service discovery might be especially important in the case of mobile users. The mobile users could roam into a foreign network and might need to discover what intermediary-based services are available. o Service negotiation: The end-points should be able to Blumenthal et al Expires 12/03 [Page 3] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 negotiate services and service options with the intermediary. Service renegotiation might also be required due to any changing requirements of the end-points and due to changing conditions at the intermediary. o Service consent: The end-points must consent to the services they are offered. There are two important reasons why this consent must be made by the end-points. First, the end-points should allow access to and possibly modification of end-to-end data. This is discussed in details in the next section. Second, there might be a charge associated with the services that an end-point must pay for receiving the services. o Service configuration: The end-points and the intermediary need to exchange appropriate parameters for configuring the intermediary-based services. Some of these parameters could be header formats, estimates of (or actual) resources required for offering a service, identity of data flows etc. o Setting up trust relationships and security associations: The end-points and the intermediary must be able to mutually authenticate each other. This mutual authentication process might involve other nodes such as a home agent or a home location register in the case of mobile users. The end-points and the intermediary will also need to exchange keys and set up security associations to communicate securely. Separate security associations will be required between each end-point and the intermediary offering services and potentially between intermediaries if multiple intermediaries are involved in offering services. The end-points and the intermediary should tear down security associations when intermediary services are completed, revoked, or in the event of failures of the intermediary or the end-points. o Transfer of state: The intermediary might need to transfer state information associated with the services it has negotiated and is currently offering or any other security related information (cryptographic counters, keys, etc.) to another intermediary in the case of an impending failure, for load balancing or due to user mobility. Although intermediaries might voluntarily offer some services without requiring any explicit communication with the Blumenthal et al Expires 12/03 [Page 4] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 end-points, this will not be true when end-to-end security (e.g. IPsec) is used. When end-to-end security is used, end-points must explicitly communicate with the intermediary for setting up services and assist an intermediary with the information required to offer services. In this document, we are interested in only those services that require explicit communication between end-points and the intermediary. 3.2 Exposing Information Another extremely important aspect of enabling intermediary-based services is selective exposure of information to an intermediary by the end-points. This information might be required by the intermediary to provide the requested services to the end-points. Typically, in order to provide service, an intermediary may need to access protocol headers of the data packets. Exposing information to an intermediary becomes complex when end-to-end security (such as IPsec) is used. When IPsec ESP [5] is used between two end-points, the entire IP packet except for the outer IP header might be encrypted using keys known only to the end-points and none of the upper layer headers (including the inner IP header in the case of IP encapsulation) is accessible to the intermediary. How to expose information to an intermediary while maintaining an acceptable level of end-to-end security is a very challenging problem. Currently, there is no standard way of exposing and accessing protocol headers when an end-to-end security protocol such as IPsec ESP is used. There are several critical dimensions of the problem of selectively exposing information. These are described below. o Information that can be exposed: The information that could be exposed to an intermediary will depend upon the nature of the requested service. In some cases only the transport and network layer information will need to be exposed to the intermediary. For example, an intermediary providing a TCP PEP service [2] will need access to the TCP headers. In other cases upper layer information might be required at the intermediary to offer services. For example, when an intermediary is providing a service to filter out low priority multimedia packets during network congestion [6], it might require access to the multimedia transport headers to find out the packet priority. o Where the required information is located: It is not enough to agree upon what information will be exposed to the intermediary. The intermediary may not know where to find Blumenthal et al Expires 12/03 [Page 5] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 it in the packet. The end-points may have to help the intermediary find the exposed information. o Who decides what information can be exposed: One of the important questions in relation to exposing information is who decides what information could be exposed. We believe that in most of the cases the end-points will decide what information should be exposed to an intermediary. This is because, based on the services they require, the end-points are in the best position to decide what should be exposed to the intermediary. o Access rights to exposed information: A very important issue associated with exposing information is what access rights should be given to the intermediary. In many situations it might be enough to allow the intermediary to inspect the exposed information and provide the services based on that information. This situation arises commonly when an intermediary is used to offer some sort of filtering services (e.g., filtering of low priority multimedia packets in the presence of network congestion). In other cases it might be necessary to allow the intermediary to inspect and also modify the exposed information. Such an inspect-modify capability will be required at an intermediary offering TCP PEP services [2]. In some cases an intermediary might need to inspect and then not just modify exposed information but also generate new packets. This situation arises when an intermediary offering TCP PEP services is required to generate ``local'' TCP acknowledgements. o Method for exposing information: The end-points will need new methods for selectively exposing information to an intermediary. The end-points must assist the intermediary in finding the exposed information. Current security standards (such as IPsec) allow either full exposure of all the data from the end-points or no exposure of any end-point data other than the outer IP headers. All the above issues related to exposing information are dependent upon the services offered by the intermediary and the service and security requirements of the end user application. It is very important to note that not all intermediary-based services require exposing end-to-end information to the intermediary. Some services could be built by using Blumenthal et al Expires 12/03 [Page 6] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 information that is usually visible even when end-to-end security mechanisms are used. An example of such a service is described in Section 4. Based on the discussion in this subsection, the problem of exposing information could be categorized as follows: 1. All communications between end-points are end-to-end encrypted. 2. Communications between end-points are end-to-end authenticated but not encrypted, thereby allowing inspection but not modification of information. 3. Some of the information exchanged between end-points is exposed to the intermediary for inspection as well as modification and the end-points assist the intermediary in finding that information. 3.3 Preserving Security Preserving acceptable security and allowing an intermediary to perform its services, while selectively exposing information to an intermediary is a challenging task. Once again, this aspect of the problem is also multi-dimensional. These dimensions are discussed below: o Trust between End-points and the Intermediary: A trust relationship between the end-points and the intermediary is one of the most fundamental issues in enabling intermediary-based services. The end-points and the intermediary must trust each other with the information that is exposed and the services that are offered and obtained. Mechanisms necessary to build and maintain this trust must be investigated. o Detecting and Responding to Any Inappropriate Behavior of Intermediary: The trust model between the end-points and the intermediary requires that the intermediary would not use the information exposed to it for obtaining services to attack the end-points or play ``end-to-end'' games. An example of an end-to-end game that could be played by an intermediary is as follows. An intermediary with access to Blumenthal et al Expires 12/03 [Page 7] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 TCP headers could change the ordering of TCP packets even when the TCP payload is encrypted. Trusting the intermediary does not imply that the end-points do not detect and respond to inappropriate actions of the intermediary. The questions of how do end-points detect any inappropriate behavior of the intermediary and how do they respond to the inappropriate behavior need to be addressed. o Exposed information Accessible only to intended recipients: An important dimension of the problem of preserving acceptable end-to-end security is how should the information exposed to the intermediary be secured from the rest of the network. Additional security layers might be required to achieve this. One potentially serious problem with exposing information to an intermediary is how to prevent it from sharing the exposed information with other entities in the network. Unfortunately it does not seem that this problem can be solved. o Security Associations: The end-points and the intermediary need to set up security associations among themselves for secure communication. One approach to setting up security associations is to set them one-to-one, i.e., only two nodes (among the two-end points and the intermediary) are part of a single security association. Alternately, as proposed in [7], it is possible to have, composite security associations or one-to-many security associations that involve more than two nodes, e.g., both end-points and the intermediary. As before, how the security is preserved will depend upon the nature of the end-user applications and offered intermediary-based services. 4 Problem Manifestations The problem described in the previous section is manifests itself in several intermediary-based transport services. We now present four representative scenarios of intermediary-based services. 1. TCP Performance Enhancing Proxy (PEP) 2. Header compression/decompression Blumenthal et al Expires 12/03 [Page 8] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 3. QoS Provisioning 4. Prevention of Denial-of-Service 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 [8]. 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 [8] 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 Header Compression - Compressing protocol headers over wireless access links will help save precious wireless bandwidth [9, 10]. Even though, it is possible to achieve header compression between two end-points of an IP tunnel or two adjacent IP hops, most of the header compression schemes are sensitive to delays and loss between the end-points. [11] shows that the average header size increases significantly at high loss. In [12] the authors show the impact of delay on the efficiency of their header compression +----------------+ ---- | | / // \\ | | +------+ /--/ | TCP | | | | | / | PEP | ------------| Server | *------* | | Wireline | | /--------\ \\ // Network | | ---- | | Mobile User +----------------+ Blumenthal et al Expires 12/03 [Page 9] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 Data <-------- Acks -----> Regulated Acks -> <---------------- TCP connection -------------> Figure 1: TCP Ack Regulator scheme. Achieving header compression and decompression close to a congested link with the help of an intermediary could help in improving performance of the header compression schemes. Multiple protocols, including some existing ones, could be potentially used to achieve intermediary-based header compression. For example, the Secure Real-time Transport Protocol (SRTP) [13] could be used to secure the Real-time Transport Protocol (RTP) payload but leave the IP/UDP/RTP headers accessible to the intermediary allowing header compression at the intermediary. 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 Service Code Point) bits in the IP header or even application layer information to differentially treat packets. For +----------------+ ---- | | Congested // \\ | | +------+ Link | Packet | | | | |-------------- | Filter | ------------ | Video Source | *------* | | | | /--------\ \\ // | | ---- +----------------+ Video Receiver Drop lower priority layers <-------------------------------------------------- Multi-layer Video Figure 2: Selective Video Filtering Blumenthal et al Expires 12/03 [Page 10] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 example, the intermediate node, could assign lower priority to ``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 [14] 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 will 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 +---------+ Attacker sends address-spoofed, | | IPsec encrypted packets to the VPN Client | Attacker| | | +---------+ Wireless | Access | Network | ------ ------- | +-----+ // \\ // |\ | | / | +------+ | | | | | +---+ /--/ | |Packet|<---|----------- | | | | | / | |Filter|---| |--| | *---* | | | | | | | /-----\ | +------+ | | | | \\ // \\ // | | ------ ------- +-----+ VPN Client Internet Enterprise VPN Gateway ----------------------------------------------------- End-to-End IPsec Tunnel ----------------------------------------------------- Figure 3: Prevention of Denial-of-Service Blumenthal et al Expires 12/03 [Page 11] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 one such scheme. o Prevention of Denial-of-Service (DoS) - Intermediate nodes could be configured to filter out packets from unwanted sources to enterprise Virtual Private Network (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. In the first three scenarios, an intermediary accesses the protocol headers (TCP, RTP/UDP/IP) for offering the services. If end-to-end security solutions such as IPsec ESP [5] are used, the protocol headers are not accessible to the intermediary. The problem here is to enable the end-points and the intermediary to negotiate services and configure services, as well as allowing the intermediary secure access to the protocol headers. In the last scenario, the problem is to set up the additional authentication tunnels with the help of a communication protocol between the intermediary and the end-points to prevent denial-of-service attacks. Note that, unlike the other three examples, in this scenario, the intermediary does not require any special access to end-to-end encrypted payload or header. 5 Security Considerations This document discusses the problem of ``securely enabling intermediary based services'' and as such does not require any additional discussion on security considerations. 6 Related Work The problem of ``trusted'' middle boxes performing policy decisions has been considered in [1] but instead of a MIDCOM Blumenthal et al Expires 12/03 [Page 12] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 protocol that opens a pin-hole in a middle box to permit sessions through a firewall or a NAT middlebox, intermediary-based transport services authorize an intermediary to have access to packets for offering services. More generally, we argue the need for secure enablers in various transport intermediary services in order for trusted middle boxes to inspect, and/or modify transport headers. 7 Conclusions We have presented the problem of securely enabling intermediary-based services. The various components of this problem have been identified and discussed. We also presented scenarios where this problem is manifested. We propose that the problem of securely enabling intermediary-based services becomes a work item in the IETF. 8 Acknowledgments We would like our colleagues from Lucent Technologies for their helpful suggestions and comments in preparing the 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] I. Faynberg, S. Kasera, S. Mizikovsky, G. Sundaram, and T. Woo. Intermediary-Based Transport Services, Performance Optimization Mechanisms, and Relevant Requirements. Internet Draft, IETF, February 2003. draft-faynberg-intermediary-transport-00.txt. [4] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [5] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, IETF, November 1998. [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. Blumenthal et al Expires 12/03 [Page 13] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 [7] Y. Zhang and B. Singh. A multi-layer ipsec protocol. In Proc. 9th Usenix Security Symposium, Aug. 2000. [8] M.C. Chan and R. Ramjee. Tcp/ip performance over 3g wireless links with rate and delay variations. In Proc. of ACM Mobicom, Sep. 2002. [9] V. Jacobson. Compressing TCP/IP Headers for Low-Speed Serial Links. RFC 1144, IETF, February 1990. [10] C. Bormann et al. Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. RFC 3095, IETF, July 2001. [11] M. Degermark, H. Hannu, L. Jonsson, and K. Svanbro. Evaluation of crtp performance over cellular radio links. In IEEE Pesonal Communications, Aug. 2000. [12] S. Dorward and S. Quinlan. Robust data compression of network packets, 2000. http://www.cs.bell-labs.com/cm/cs/who/seanq/networkcomp.pdf. [13] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman. Secure Real-time Transport Protocol. Internet Draft, IETF, May 2003. draft-ietf-avt-srtp-08.txt. [14] L. Berger and T. O'Malley. RSVP Extensions for IPsec Data Flows. RFC 2702, IETF, September 1997. Authors' Addresses U. Blumenthal Lucent Technologies 67 Whippany Road, Rm: 14D-318 Whippany, NJ 07981, USA Email: uri@lucent.com 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 Blumenthal et al Expires 12/03 [Page 14] INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20 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 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. Blumenthal et al Expires 12/03 [Page 15]