Internet Engineering Task Force INTERNET-DRAFT U. Blumenthal, I. Faynberg, draft-blumenthal-intermediary-transport-01.txt S.K. Kasera, 10/27 S. Mizikovsky,S.Norden, Expires: April 2004 G.S. Sundaram, T. Woo 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 INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 2 Terminology 3 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 19 6 Related Work 19 7 Conclusions 19 8 Acknowledgments 19 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, Blumenthal et al Expires 4/04 [Page 2] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 and obtain the services of intermediaries, and to minimize the impact of intermediaries on end-to-end security. 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. Blumenthal et al Expires 4/04 [Page 3] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 o Service negotiation: The end-points should be able to 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, Blumenthal et al Expires 4/04 [Page 4] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 for load balancing or due to user mobility. Although intermediaries might voluntarily offer some services without requiring any explicit communication with the 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 Blumenthal et al Expires 4/04 [Page 5] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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 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 Blumenthal et al Expires 4/04 [Page 6] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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 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. Blumenthal et al Expires 4/04 [Page 7] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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 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 Blumenthal et al Expires 4/04 [Page 8] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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 3. Application Layer Proxy 4. Stateful Firewall 5. Qos Provisioning 6. Prevention of Denial-of-Service 7. Network Address Translation 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. More details on performance enhancing proxies that mitigate link degradations are presented in [2]. 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 - A problem with IP over cellular links Blumenthal et al Expires 4/04 [Page 9] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 +---------------+ ---- | | / // \\ | | +------+ /--/ | TCP | | | | | / | PEP | ------------ | Server | *------* | | Wireline | | /--------\ \\ // Network | | ---- | | Mobile User +---------------+ Data <-------- Acks -----> Regulated Acks -> <---------------- TCP connection -------------> Figure 1: TCP Ack Regulator when used for interactive voice conversations is the large header overhead. Speech data for IP telephony will most likely be carried by RTP. A packet will then, in addition to link layer framing, have an IP [IPv4] header (20 octets), a UDP header (8 octets), and an RTP header (12 octets) for a total of 40 octets. With IPv6, the IP header is 40 octets for a total of 60 octets. The size of the payload depends on the speech coding and frame sizes being used and may be as low as 15-20 octets. 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 scheme. Achieving header compression and decompression close to a congested link with the help of an Blumenthal et al Expires 4/04 [Page 10] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 intermediary could help in improving performance of the header compression schemes. One might argue that if the last hop wireless link is the only congested link that contributes most of the loss and delay, then an intermediary based header compression mechanim will not necessarily improve performance over end-to-end header compression. This is not the case when both the end-points are wireless users. Single wireless links are also being increasingly replaced by a multi-hop paths where multiple bandwidth-limited and lossy links might be present. Implementing end-to-end header compression in such situations will result in partial gains only. An intermediary-based header compression scheme with an intermediary assisting every wireless or bandwidth-limited link will immensely help in improving the performance of header compression due to lower loss and delay. One can use multiple protocols, to achieve intermediary-based header compression in an efficient manner. For example, the Secure Real-time Transport Protocol (SRTP) [13] could be used to secure the Real-time Transport Protocol (RTP) payload, while leaving the IP/UDP/RTP headers accessible to the intermediary allowing header compression using Robust header compression (ROHC) [10] for example, at the intermediary. Robust Header Compression (ROHC) [10] has been proposed as a means to effectively compress headers at all layers upto and including the IP Layer. ROHC is a stateful compression mechanism relying on state maintained at the compressor/decompressor to maximize the compression efficiency of packets exchanged while tolerating lossy and high-latency links. ROHC is a hop-by-hop compression mechanism where a hop could be a physical link or a virtual link spanning multiple physical links (path). The use of end-to-end IPSec would reduce the efficiency drastically due to encryption of the IP payload via ESP. In such an environment, compression must be performed before encryption for any benefit. In such cases, compression can be applied only to the IP payload, not including the ESP and AH headers that are added by IPSec. These headers contribute an additional 20 bytes of overhead that is still significant compared to the payload especially for VoIP applications. A trusted intermediary instead could perform IPSec so as to avoid this overhead on bandwidth-constrained links. Blumenthal et al Expires 4/04 [Page 11] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 An additional problem with stateful compression schemes like ROHC is that they do not tolerate reordering of packets. UDP is a connection-less model whereby packets can come out of order due to the random routing of packets. ROHC is intended to be applied hop-by-hop where there is less likelihood of packet reordering. Thus, end-to-end header compression would not work well unless there is an additional reordering mechanism that is enabled before packets reach the decompressor. The routes need to be pre-configured for compressed packets which is not a viable alternative in an end-to-end approach. However, an intermediary router could assist in such cases by negotiating, for example, an MPLS label switched path such that all compressed packets are assigned the same label. An intermediary could also assist in ordering packets at the penultimate hop before the decompressor, so that they can be delivered in-order to the decompressor. Alternative compression mechanisms are IP payload compression (IPComp) [14] which compresses the entire IP payload in a stateless manner as compared to ROHC. This scheme does not suffer from the reordering problems of ROHC but is not as efficient as ROHC since each packet is compressed independently. It should be noted end-to-end header compression is not a viable alternative if intermediate routers are not aware of the compression. Compressing TCP headers at the end-host makes it difficult for firewalls or border routers to classify and route packets using the 5-tuple filtering (IP source and destination addresses, TCP protocol, source and destination ports) since none of the header fields can be inspected after compression unless the intermediaries are part of an SA with the end-host. Since intermediaries need to be trusted anyway, it might be beneficial to place some of the functionality with the intermediaries so as to improve the performance. Essentially, there is a tradeoff between performance and security, whereby leaving the headers open to an intermediary allows header compression for performance, but requires a separate ``trust'' relationship between the end-point and the intermediary. Blumenthal et al Expires 4/04 [Page 12] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 o Application Layer Proxy - Application proxies are entities that look specifically at application headers and payload in order to improve performance, as well as perfom application specific functionality such as buffering and forwarding application packets. This would require that the application-specific headers be left in the open. A popular example is a proxy for the Session Initiation Protocol (SIP). SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP signaling requires that a user contact a SIP proxy in order to initiate and maintain the SIP connection. Specifically, the ``to'' and ``Via'' header fields in SIP requests need to be visible to SIP proxies to allow correct routing. Also, SIP provides a registration function that allows users to upload their current locations with proxy servers, so that proxy servers can route requests to the user's current location. SIP requires a tight integration with any IPSec implementation, with a pre-configured SA between the user and the proxy server. While SIP can be used with IPSec, there is the additional overhead of creating a separate tunnel between the end-host and the SIP proxy, in order to allow the SIP proxy to process signaling packets from the end-user. Creating tunnels at each hop leads to a significant overhead and is not the intended objective of the end-to-end IPSec. A secure version of SIP (SIPS) relies on Transport Layer Security (TLS) to encrypt signaling messages over TCP. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association and differs from end-to-end IPSec. Thus, an intermediary assisting in SIP signaling without the overhead of IPSec would use a more appropriate hop-by-hop scheme like TLS for better peformance. However, TLS does leave the TCP header in the open, which potentially compromises security. Additionally, QoS can also be specified in the SIP requests using the session description protocol (SDP) payload of SIP messages [15] and the UPDATE request [16]. The SIP proxy aids in the negotiation of QoS and actually can be allowed to Blumenthal et al Expires 4/04 [Page 13] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 modify the SDP payloads in SIP message bodies. However, if end-to-end authentication/encryption is used, SIP proxies are not allowed to alter the SIP message bodies according to [17], primarily due to the end-to-end security feature offered by the secure version of SIP. In order to overcome the restrictions on the proxy, there have been several recent IETF drafts [18, 19] proposing new SIP headers that can carry QoS information regarding the session. SIP proxies can change SIP headers during the QoS negotiation phase instead of modifying SDPs complying with RFC 3261. However, if the headers are encrypted by IPSec, this would thwart any useful processing by the intermediary SIP proxy. o Stateful Firewall - Stateful firewalls such as those from Checkpoint [20] are tightly integrated with applications and can function as application/transport proxies as well. Thus, they are capable of checking for violations in upper layer protocols such as TCP connection state, full packet header information (source address, destination address, protocol, source port, destination port, packet length), TCP/IP fragmentation data (fragment number, sequence number), packet reassembly, application type, among others. For example, TCP packet reassembly is a popular functionality of most stateful firewalls. Without this capability, an attack can conceal malicious code or viruses in fragmented packets causing severe damage to the network as well as the users. Most of this information will be hidden to the firewall if IPSec with ESP is in use, potentially compromising the security of the application. It is unlikely that a ``weak'' entity such as a mobile phone can ever perform the type of checks that a stateful firewall is capable of. Furthermore, Intrusion detection systems also benefit by looking at such information in order to detect DoS attacks. All these security mechanisms would be rendered useless if an end-to-end security mechanism like IPSec is used. Note that IPSec provides a semantic of end-to-end security but does not really guarantee it. It is upto the end-points to ensure that they follow the guidelines. If end-points do not follow the IPSec guidelines, the concept of end-to-end security becomes moot. It is more reliable to rely on a trusted intermediary such as a corporate firewall to protect a corporate network rather than to expect each user to Blumenthal et al Expires 4/04 [Page 14] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 follow the security guidelines to the letter. o QoS Provisioning, Differentiated 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. It should be noted that IPSec in tunnel mode copies the ToS byte to the outer header potentially allowing modifications by intermediaries. The TOS byte can be used to store the DSCP and enable packet classification. For 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 [21] 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 one such scheme. o Prevention of Denial-of-Service (DoS) - There are a variety of DoS attacks that can be launched against end-hosts, and the impact is particularly severe on wireless endpoints due to the Blumenthal et al Expires 4/04 [Page 15] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 +---------------+ ---- | | Congested // \\ | | +------+ Link | Packet | | | | |-------------- | Filter | ------------ | Video Source | *------* | | | | /--------\ \\ // | | ---- +---------------+ Video Receiver Drop lower priority layers <-------------------------------------------------- Multi-layer Video Figure 2: Selective Video Filtering limited wireless link bandwidth, processing power of mobiles and the battery lifetimes of these nodes. It is significantly easier for an attacker to launch a wireless DoS attack with much less traffic affecting more end-points compared to a wire-line DoS attack. Thus, the use of firewalls and other security mechanisms such as VPNs is an absolute necessity. 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). However, if one relies on IPSec, this would prevent the correct operation of firewalls since there is no mechanism to inspect the encrypted IP payload for IPSec packets unless the firewall is co-located with the IPSec gateway. 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 via IPSec tunnels. Once the packet reaches the mobiles, the attacker has already succeeded in launching a DoS, by congesting the wireless infrastructure including the processing elements such as RNC, PDSN, base stations as well Blumenthal et al Expires 4/04 [Page 16] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 +---------+ 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 as attacking the end-points (by draining the battery on mobiles). Instead, 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. o Network Address Translation - IPv4 has a limited range of addresses which are rapidly being exhausted. As a result, mechanisms such as Network Address Translation (NAT) [22] are Blumenthal et al Expires 4/04 [Page 17] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 becoming increasingly popular, allowing a single IP address to be multiplexed among different end-hosts. However, NAT requires separate address translation to be performed before the packet leaves or after it enters a domain. ISPs often use NAT to maximize their use of internet addresses. NAT also provides a degree of security against DoS attacks since the attacker does not know the real IP address of the end-host. Unfortunately, IPSec technigues which are intended to preserve the end-point addresses of an IP packet will not work with NAT en-route for most applications in practice. The address translation requires the NAT translator to modify the IP addresses for all packets. In a typical IPSec with ESP implementation, this would be impossible since the IP header is encrypted. Decrypting this would require an SA to be pre-configured between the NAT proxy and the end-user requiring ``trust'' relationships to be established. In the first five 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 DoS 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. In stateful firewalls, all packets pass through the firewall and are mandatorily examined. Note that the intermediary does not require any special access to end-to-end encrypted payload in the Stateful firewall, DoS and NAT scenarios. Bandwidth-constrained wireless networks in particular, are incapable of handling the overhead introduced by IPSec due to the scarce bandwidth and lossy links with long RTTs. Instead of an IPSec implementation, users may alternately choose to rely on link layer encryption,and/or transport layer security solutions such as TLS, while allowing compression of headers. The use of an intermediary would greatly increase the performance, without compromising security, assuming that the intermediary can be trusted. Blumenthal et al Expires 4/04 [Page 18] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 It should be noted that introducing intermediaries does potentially open up new points of attack, namely the intermediaries themselves. An attacker could simply flood the intermediary itself to bring it down. This is an inherent drawback of any centralised, stateful system and is orthogonal to the issues described in this document. Scalability is another orthogonal issue that arise if the intermediary is centralised or co-located with a firewall, for example. Finally, the trust relationship as introduced in Section 3.3 is hard to define. The trust can be abused in indirect ways (For example, the intermediary could inspect addresses from the user packets and determine the location leading to privacy issues). 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 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 to thank our colleagues from Lucent Technologies for their helpful suggestions and comments in preparing the draft. Blumenthal et al Expires 4/04 [Page 19] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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-01.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. [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 and 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. Blumenthal et al Expires 4/04 [Page 20] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 [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] A. Shacham, R. Monsour, R. Pereira, and M. Thomas. IP Payload Compression Protocol (IPComp). RFC 2393, IETF, December 1998. [15] M. Handley and V. Jacobson. SIP: Session Initiation Protocol. RFC 2327, IETF, April 1998. [16] J. Rosenberg. The Session Initiation Protocol (SIP) UPDATE method. RFC 3261, IETF, June 2003. [17] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol. RFC 3261, IETF, June 2003. [18] J. Rosenberg. Requirements for sesssion policy for the session initiation protocol (SIP). Internet Draft, IETF, June 2003. [19] Volker Hilt and J. Rosenberg. Supporting intermediate session policies in SIP. Work in Progress, Internet Draft, IETF, October 2003. [20] Checkpoint Inc. Why all stateful firewalls are not created equal. http://www.checkpoint.com, 2002. [21] L. Berger and T. O'Malley. RSVP Extensions for IPsec Data Flows. RFC 2702, IETF, September 1997. [22] P. Srisuresh and M. Holdrege. IP Network Address Translator (NAT) Terminology and Considerations. RFC 2663, IETF, August 1999. 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 Blumenthal et al Expires 4/04 [Page 21] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 Email: faynberg@lucent.com S.K. Kasera School of Computing, University of Utah 50 South Central Campus Dr, Rm 3190 Salt Lake City, Utah 84112 Email: kasera@cs.utah.edu S. Mizikovsky Lucent Technologies 67 Whippany Road, Rm: 14D-314 Whippany, NJ 07981, USA Email: smizikovsky@lucent.com S. Norden Lucent Technologies 101 Crawfords Corner Road, Rm: 4F-529 Holmdel, NJ 07733, USA Email: norden@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 Blumenthal et al Expires 4/04 [Page 22] INTERNET-DRAFT draft-blumenthal-intermediary-transport-01.txt 10/27 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 4/04 [Page 23]