One document matched: draft-blumenthal-intermediary-transport-01.txt
Differences from draft-blumenthal-intermediary-transport-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:45 |