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