One document matched: draft-blumenthal-intermediary-transport-00.txt
Internet Engineering Task Force
INTERNET-DRAFT
draft-blumenthal-intermediary-transport-00.txt U. Blumenthal,
Date: June 20, 2003 I. Faynberg,
Expires: December 2003 S.K. Kasera,
S. Mizikovsky, G.S. Sundaram, T. Woo
Lucent Technologies
Securely Enabling Intermediary-based Transport Services
Status of this memo
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
The growth of the Internet has witnessed an emergence of transport
services that rely on or can benefit from assistance of network
intermediaries between communicating end-points. Such services,
for example, include TCP performance enhancements, multimedia
packet filtering, header compression, and prevention of
Denial-of-Service. In this draft, we describe some of the
important aspects of the problem of securely enabling
intermediary-based services. We also present several scenarios
where this problem is manifested.
Contents
1 Introduction 2
2 Terminology 3
Blumenthal et al Expires 12/03 [Page 2]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
3 Problem Description 3
3.1 Communication Between End-points and Intermediary ........ 3
3.2 Exposing Information ..................................... 5
3.3 Preserving Security ...................................... 7
4 Problem Manifestations 8
5 Security Considerations 12
6 Related Work 12
7 Conclusions 13
8 Acknowledgments 13
1 Introduction
The growth of the Internet has witnessed an emergence of transport
services that rely on or can benefit from assistance of network
intermediaries between communicating end-points [1, 2, 3]. Such
services, for example, include TCP performance enhancements,
multimedia packet filtering, header compression, and prevention of
Denial-of-Service. As for network intermediaries, they could be
routers, switches, application gateways, middle boxes [1],
performance enhancing proxies [2], or nodes of an overlay network.
To provide intermediary-based services they may make use of the
knowledge of aggregated and per-flow traffic behavior at its
location as well as their processing, caching and/or filtering
capabilities.
There are two important components of the problem of enabling
intermediary-based services. First, end users may need to
communicate with the network intermediaries for configuration and
solicitation of service. Second, the end users must make any
information available to the intermediary that might be necessary
for them to offer the requested services. The second problem is
especially challenging when an end-to-end security solution such
as IPsec is used. Using IPsec, an end-user cannot contract
value-added services from a network intermediary unless it fully
sacrifices end-to-end security. Overall, we believe work is
necessary to determine how to request, authenticate, authorize,
and obtain the services of intermediaries, and to minimize the
impact of intermediaries on end-to-end security.
Blumenthal et al Expires 12/03 [Page 2]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
Depending on the intermediaries and the services offered by them,
the problem of securely enabling intermediary-based services could
have various aspects. In this draft, we describe some of the
important aspects of the problem. We also present several
scenarios where the problem of securely enabling
intermediary-based services is manifested. This document invites
the response from the Internet community and proposes that the
problem of securely enabling intermediary-based services should
become a work item in the IETF.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [4].
o End-point: An end-user node including a PC, a laptop, a
hand-held device, etc. running user applications.
o Intermediary: A network node including a router, a switch, an
application gateway, a middle box [1], a performance enhancing
proxy [2], or a node of an overlay network.
3 Problem Description
In this document we focus on the problem of securely enabling and
using intermediary-based services. We identify the key components
of this problem, and describe them in the following subsections.
3.1 Communication Between End-points and Intermediary
The end-points and the intermediary may need to communicate
with each other to request and control intermediary-based
services. In particular, the communication may serve functions
such as the ones described below.
o Service discovery: The end-point might need to discover the
services that are available from the intermediary. Service
discovery might be especially important in the case of
mobile users. The mobile users could roam into a foreign
network and might need to discover what intermediary-based
services are available.
o Service negotiation: The end-points should be able to
Blumenthal et al Expires 12/03 [Page 3]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
negotiate services and service options with the
intermediary. Service renegotiation might also be required
due to any changing requirements of the end-points and due
to changing conditions at the intermediary.
o Service consent: The end-points must consent to the
services they are offered. There are two important reasons
why this consent must be made by the end-points. First, the
end-points should allow access to and possibly modification
of end-to-end data. This is discussed in details in the
next section. Second, there might be a charge associated
with the services that an end-point must pay for receiving
the services.
o Service configuration: The end-points and the intermediary
need to exchange appropriate parameters for configuring the
intermediary-based services. Some of these parameters could
be header formats, estimates of (or actual) resources
required for offering a service, identity of data flows etc.
o Setting up trust relationships and security associations:
The end-points and the intermediary must be able to mutually
authenticate each other. This mutual authentication process
might involve other nodes such as a home agent or a home
location register in the case of mobile users. The
end-points and the intermediary will also need to exchange
keys and set up security associations to communicate
securely. Separate security associations will be required
between each end-point and the intermediary offering
services and potentially between intermediaries if multiple
intermediaries are involved in offering services. The
end-points and the intermediary should tear down security
associations when intermediary services are completed,
revoked, or in the event of failures of the intermediary or
the end-points.
o Transfer of state: The intermediary might need to transfer
state information associated with the services it has
negotiated and is currently offering or any other security
related information (cryptographic counters, keys, etc.) to
another intermediary in the case of an impending failure,
for load balancing or due to user mobility.
Although intermediaries might voluntarily offer some services
without requiring any explicit communication with the
Blumenthal et al Expires 12/03 [Page 4]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
end-points, this will not be true when end-to-end security
(e.g. IPsec) is used. When end-to-end security is used,
end-points must explicitly communicate with the intermediary
for setting up services and assist an intermediary with the
information required to offer services. In this document, we
are interested in only those services that require explicit
communication between end-points and the intermediary.
3.2 Exposing Information
Another extremely important aspect of enabling
intermediary-based services is selective exposure of
information to an intermediary by the end-points. This
information might be required by the intermediary to provide
the requested services to the end-points. Typically, in order
to provide service, an intermediary may need to access protocol
headers of the data packets. Exposing information to an
intermediary becomes complex when end-to-end security (such as
IPsec) is used. When IPsec ESP [5] is used between two
end-points, the entire IP packet except for the outer IP header
might be encrypted using keys known only to the end-points and
none of the upper layer headers (including the inner IP header
in the case of IP encapsulation) is accessible to the
intermediary. How to expose information to an intermediary
while maintaining an acceptable level of end-to-end security is
a very challenging problem. Currently, there is no standard
way of exposing and accessing protocol headers when an
end-to-end security protocol such as IPsec ESP is used.
There are several critical dimensions of the problem of
selectively exposing information. These are described below.
o Information that can be exposed: The information that could
be exposed to an intermediary will depend upon the nature of
the requested service. In some cases only the transport and
network layer information will need to be exposed to the
intermediary. For example, an intermediary providing a TCP
PEP service [2] will need access to the TCP headers. In
other cases upper layer information might be required at the
intermediary to offer services. For example, when an
intermediary is providing a service to filter out low
priority multimedia packets during network congestion [6],
it might require access to the multimedia transport headers
to find out the packet priority.
o Where the required information is located: It is not enough
to agree upon what information will be exposed to the
intermediary. The intermediary may not know where to find
Blumenthal et al Expires 12/03 [Page 5]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
it in the packet. The end-points may have to help the
intermediary find the exposed information.
o Who decides what information can be exposed: One of the
important questions in relation to exposing information is
who decides what information could be exposed. We believe
that in most of the cases the end-points will decide what
information should be exposed to an intermediary. This is
because, based on the services they require, the end-points
are in the best position to decide what should be exposed to
the intermediary.
o Access rights to exposed information: A very important
issue associated with exposing information is what access
rights should be given to the intermediary. In many
situations it might be enough to allow the intermediary to
inspect the exposed information and provide the services
based on that information. This situation arises commonly
when an intermediary is used to offer some sort of filtering
services (e.g., filtering of low priority multimedia packets
in the presence of network congestion). In other cases it
might be necessary to allow the intermediary to inspect and
also modify the exposed information. Such an inspect-modify
capability will be required at an intermediary offering TCP
PEP services [2]. In some cases an intermediary might need
to inspect and then not just modify exposed information but
also generate new packets. This situation arises when an
intermediary offering TCP PEP services is required to
generate ``local'' TCP acknowledgements.
o Method for exposing information: The end-points will need
new methods for selectively exposing information to an
intermediary. The end-points must assist the intermediary
in finding the exposed information. Current security
standards (such as IPsec) allow either full exposure of all
the data from the end-points or no exposure of any end-point
data other than the outer IP headers.
All the above issues related to exposing information are
dependent upon the services offered by the intermediary and the
service and security requirements of the end user application.
It is very important to note that not all intermediary-based
services require exposing end-to-end information to the
intermediary. Some services could be built by using
Blumenthal et al Expires 12/03 [Page 6]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
information that is usually visible even when end-to-end
security mechanisms are used. An example of such a service is
described in Section 4.
Based on the discussion in this subsection, the problem of
exposing information could be categorized as follows:
1. All communications between end-points are end-to-end
encrypted.
2. Communications between end-points are end-to-end
authenticated but not encrypted, thereby allowing inspection
but not modification of information.
3. Some of the information exchanged between end-points is
exposed to the intermediary for inspection as well as
modification and the end-points assist the intermediary in
finding that information.
3.3 Preserving Security
Preserving acceptable security and allowing an intermediary to
perform its services, while selectively exposing information to
an intermediary is a challenging task. Once again, this aspect
of the problem is also multi-dimensional. These dimensions are
discussed below:
o Trust between End-points and the Intermediary: A trust
relationship between the end-points and the intermediary is
one of the most fundamental issues in enabling
intermediary-based services. The end-points and the
intermediary must trust each other with the information that
is exposed and the services that are offered and obtained.
Mechanisms necessary to build and maintain this trust must
be investigated.
o Detecting and Responding to Any Inappropriate Behavior of
Intermediary: The trust model between the end-points and
the intermediary requires that the intermediary would not
use the information exposed to it for obtaining services to
attack the end-points or play ``end-to-end'' games. An
example of an end-to-end game that could be played by an
intermediary is as follows. An intermediary with access to
Blumenthal et al Expires 12/03 [Page 7]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
TCP headers could change the ordering of TCP packets even
when the TCP payload is encrypted. Trusting the
intermediary does not imply that the end-points do not
detect and respond to inappropriate actions of the
intermediary. The questions of how do end-points detect any
inappropriate behavior of the intermediary and how do they
respond to the inappropriate behavior need to be addressed.
o Exposed information Accessible only to intended recipients:
An important dimension of the problem of preserving
acceptable end-to-end security is how should the information
exposed to the intermediary be secured from the rest of the
network. Additional security layers might be required to
achieve this. One potentially serious problem with exposing
information to an intermediary is how to prevent it from
sharing the exposed information with other entities in the
network. Unfortunately it does not seem that this problem
can be solved.
o Security Associations: The end-points and the intermediary
need to set up security associations among themselves for
secure communication. One approach to setting up security
associations is to set them one-to-one, i.e., only two nodes
(among the two-end points and the intermediary) are part of
a single security association. Alternately, as proposed
in [7], it is possible to have, composite security
associations or one-to-many security associations that
involve more than two nodes, e.g., both end-points and the
intermediary.
As before, how the security is preserved will depend upon the
nature of the end-user applications and offered
intermediary-based services.
4 Problem Manifestations
The problem described in the previous section is manifests itself
in several intermediary-based transport services. We now present
four representative scenarios of intermediary-based services.
1. TCP Performance Enhancing Proxy (PEP)
2. Header compression/decompression
Blumenthal et al Expires 12/03 [Page 8]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
3. QoS Provisioning
4. Prevention of Denial-of-Service
o TCP Enhancements - Enhancements to transport protocols such as
TCP over error prone and bandwidth-limited links has been an
area of study for almost a decade. Particularly, when
wireless links are involved, the variance in delay is found to
be an important factor influencing TCP performance [8]. Large
delay variance decreases the effective client throughput of
all TCP-based applications. An accepted mechanism for
enhancing TCP performance in such situations is the
implementation of a TCP-PEP at the intermediate node. The
TCP-PEP can examine, modify or generate TCP packets so as to
match the characteristics of the wireline interface to that of
the wireless interface thus improving end-to-end TCP
performance.
Figure 1 shows an example of TCP throughput enhancement for a
mobile wireless user. In this figure, the mobile user is
communicating with a server using TCP. An intermediate TCP-PEP
regulates the acknowledgments [8] from the mobile host to
account for the large variations in wireless delay experienced
by data flowing towards the mobile, thereby enhancing overall
TCP throughput.
o Header Compression - Compressing protocol headers over
wireless access links will help save precious wireless
bandwidth [9, 10]. Even though, it is possible to achieve
header compression between two end-points of an IP tunnel or
two adjacent IP hops, most of the header compression schemes
are sensitive to delays and loss between the end-points.
[11] shows that the average header size increases
significantly at high loss. In [12] the authors show the
impact of delay on the efficiency of their header compression
+----------------+
---- | |
/ // \\ | |
+------+ /--/ | TCP | | |
| | / | PEP | ------------| Server |
*------* | | Wireline | |
/--------\ \\ // Network | |
---- | |
Mobile User +----------------+
Blumenthal et al Expires 12/03 [Page 9]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
Data
<--------
Acks
-----> Regulated Acks ->
<---------------- TCP connection ------------->
Figure 1: TCP Ack Regulator
scheme. Achieving header compression and decompression close
to a congested link with the help of an intermediary could
help in improving performance of the header compression
schemes. Multiple protocols, including some existing ones,
could be potentially used to achieve intermediary-based header
compression. For example, the Secure Real-time Transport
Protocol (SRTP) [13] could be used to secure the Real-time
Transport Protocol (RTP) payload but leave the IP/UDP/RTP
headers accessible to the intermediary allowing header
compression at the intermediary.
o QoS Provisioning, Differential Services, Packet Classification
and Policy Implementation - An intermediate node could
identify flows based on source and destination IP addresses,
TCP/UDP source and destination port numbers, IPsec security
parameter index (SPI), and next protocol identity, to offer
quality of service guarantees and differentiated treatment to
certain packets. It could also use the DSCP (Differentiated
Service Code Point) bits in the IP header or even application
layer information to differentially treat packets. For
+----------------+
---- | |
Congested // \\ | |
+------+ Link | Packet | | |
| |-------------- | Filter | ------------ | Video Source |
*------* | | | |
/--------\ \\ // | |
---- +----------------+
Video Receiver Drop lower
priority layers
<--------------------------------------------------
Multi-layer Video
Figure 2: Selective Video Filtering
Blumenthal et al Expires 12/03 [Page 10]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
example, the intermediate node, could assign lower priority to
``non-conforming'' UDP traffic and a higher priority to TCP
traffic during link congestion. An intermediate node could
use the security parameter index in IPsec packets together
with the IP destination address to identify flows for
providing RSVP-based quality of service. This assumes that
RSVP signaling [14] is used to create the required state in
the intermediate node. These examples show that packets could
be classified using multiple fields. A specific
classification method and policy implementation will depend on
the application.
Figure 2 shows an example of filtering packets based on
multimedia transport information. In this figure, multi-layer
video is unicast from the source to the receiver. On
observing link congestion, the intermediate node, in the path
from the source to receiver, selectively drops packets of
lower priority layers. The identity of the layers is found in
the multimedia transport header. The intermediate node
performing the selective dropping must have the knowledge of
the multimedia transport header format. Keller [6] has
demonstrated dramatic improvements in video quality by using
+---------+
Attacker sends address-spoofed, | |
IPsec encrypted packets to the VPN Client | Attacker|
| |
+---------+
Wireless |
Access |
Network |
------ ------- | +-----+
// \\ // |\ | |
/ | +------+ | | | | |
+---+ /--/ | |Packet|<---|----------- | | |
| | / | |Filter|---| |--| |
*---* | | | | | | |
/-----\ | +------+ | | | |
\\ // \\ // | |
------ ------- +-----+
VPN Client Internet Enterprise
VPN Gateway
-----------------------------------------------------
End-to-End IPsec Tunnel
-----------------------------------------------------
Figure 3: Prevention of Denial-of-Service
Blumenthal et al Expires 12/03 [Page 11]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
one such scheme.
o Prevention of Denial-of-Service (DoS) - Intermediate nodes
could be configured to filter out packets from unwanted
sources to enterprise Virtual Private Network (VPN) clients.
Enterprise VPN clients commonly establish secure sessions with
their enterprise gateways for accessing their company
resources (computers and servers). These clients, especially
bandwidth limited wireless mobile enterprise users, can be
potentially flooded with unwanted packets from IP addresses
outside the enterprise or even spoofed enterprise IP
addresses. These unwanted packets could be 'ingress-filtered'
at an intermediate node (e.g., a public data service node) in
the path from the enterprise client to the enterprise gateway
by setting up an additional authentication tunnel between the
enterprise gateway and the intermediate node. On receiving
packets with source addresses set to valid enterprise IP
addresses, the intermediate node allows only those packets
that it can authenticate and drops the rest.
In the first three scenarios, an intermediary accesses the
protocol headers (TCP, RTP/UDP/IP) for offering the services. If
end-to-end security solutions such as IPsec ESP [5] are used, the
protocol headers are not accessible to the intermediary. The
problem here is to enable the end-points and the intermediary to
negotiate services and configure services, as well as allowing the
intermediary secure access to the protocol headers. In the last
scenario, the problem is to set up the additional authentication
tunnels with the help of a communication protocol between the
intermediary and the end-points to prevent denial-of-service
attacks. Note that, unlike the other three examples, in this
scenario, the intermediary does not require any special access to
end-to-end encrypted payload or header.
5 Security Considerations
This document discusses the problem of ``securely enabling
intermediary based services'' and as such does not require any
additional discussion on security considerations.
6 Related Work
The problem of ``trusted'' middle boxes performing policy
decisions has been considered in [1] but instead of a MIDCOM
Blumenthal et al Expires 12/03 [Page 12]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
protocol that opens a pin-hole in a middle box to permit sessions
through a firewall or a NAT middlebox, intermediary-based
transport services authorize an intermediary to have access to
packets for offering services. More generally, we argue the need
for secure enablers in various transport intermediary services in
order for trusted middle boxes to inspect, and/or modify transport
headers.
7 Conclusions
We have presented the problem of securely enabling
intermediary-based services. The various components of this
problem have been identified and discussed. We also presented
scenarios where this problem is manifested. We propose that the
problem of securely enabling intermediary-based services becomes a
work item in the IETF.
8 Acknowledgments
We would like our colleagues from Lucent Technologies for their
helpful suggestions and comments in preparing the draft.
References
[1] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and
A. Rayhan. Middlebox Communication Architecture and Framework.
RFC 3303, IETF, August 2002.
[2] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby.
Performance Enhancing PRoxies Intended to Mitigate Link-Related
Degradations. RFC 3135, IETF, June 2001.
[3] I. Faynberg, S. Kasera, S. Mizikovsky, G. Sundaram, and T. Woo.
Intermediary-Based Transport Services, Performance Optimization
Mechanisms, and Relevant Requirements. Internet Draft, IETF,
February 2003. draft-faynberg-intermediary-transport-00.txt.
[4] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF, March 1997.
[5] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. RFC 2401, IETF, November 1998.
[6] R. Keller, S. Choi, M. Dasen, D. Decasper, and G. Frankhauser.
An active router architecture for multicast video distribution.
In Proc. of IEEE Infocom, Mar. 2000.
Blumenthal et al Expires 12/03 [Page 13]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
[7] Y. Zhang and B. Singh. A multi-layer ipsec protocol. In Proc.
9th Usenix Security Symposium, Aug. 2000.
[8] M.C. Chan and R. Ramjee. Tcp/ip performance over 3g wireless
links with rate and delay variations. In Proc. of ACM Mobicom,
Sep. 2002.
[9] V. Jacobson. Compressing TCP/IP Headers for Low-Speed Serial
Links. RFC 1144, IETF, February 1990.
[10] C. Bormann et al. Robust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed.
RFC 3095, IETF, July 2001.
[11] M. Degermark, H. Hannu, L. Jonsson, and K. Svanbro. Evaluation
of crtp performance over cellular radio links. In IEEE Pesonal
Communications, Aug. 2000.
[12] S. Dorward and S. Quinlan. Robust data compression of network
packets, 2000.
http://www.cs.bell-labs.com/cm/cs/who/seanq/networkcomp.pdf.
[13] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman.
Secure Real-time Transport Protocol. Internet Draft, IETF, May
2003. draft-ietf-avt-srtp-08.txt.
[14] L. Berger and T. O'Malley. RSVP Extensions for IPsec Data
Flows. RFC 2702, IETF, September 1997.
Authors' Addresses
U. Blumenthal
Lucent Technologies
67 Whippany Road, Rm: 14D-318
Whippany, NJ 07981, USA
Email: uri@lucent.com
I. Faynberg
Lucent Technologies
101 Crawfords Corner Road, Rm 4D-601A
Holmdel, NJ 07733, USA
Email: faynberg@lucent.com
S.K. Kasera
Lucent Technologies
101 Crawfords Corner Road, Rm: 4F-537
Holmdel, NJ 07733, USA
Email: kasera@research.bell-labs.com
Blumenthal et al Expires 12/03 [Page 14]
INTERNET-DRAFT draft-blumenthal-intermediary-transport-00.txt 06/20
S. Mizikovsky
Lucent Technologies
67 Whippany Road, Rm: 14D-314
Whippany, NJ 07981, USA
Email: smizikovsky@lucent.com
G.S. Sundaram
Lucent Technologies
67 Whippany Road, Rm: 14D-328
Whippany, NJ 07981, USA
Email: ganeshs@lucent.com
T. Woo
Lucent Technologies
101 Crawfords Corner Road, Rm: 4E-614
Holmdel, NJ 07733, USA
Email: woo@dnrc.bell-labs.com
Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Blumenthal et al Expires 12/03 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 02:52:01 |