Network Working Group E. Ertekin
Internet-Draft C. Christou
Expires: December 28, 2006 R. Jasani
Booz Allen Hamilton
June 26, 2006
Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Internet Protocol security mechanisms, such as IP Security (IPsec)
[IPSEC], provide various security services for IP traffic. However,
the benefits of IPsec come at the cost of increased overhead. This
document defines a framework for integrating Header Compression (HC)
over IPsec (HCoIPsec). By compressing the inner headers of IP
packets, HCoIPsec proposes to reduce the amount of overhead
associated with the transmission of traffic over IPsec security
Ertekin, et al. Expires December 28, 2006 [Page 1]
Internet-Draft Integration of HC over IPsec SAs June 2006
associations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement: Packet Overhead Associated with
IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4
5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5
5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5
5.2. HCoIPsec Description . . . . . . . . . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Scheme Considerations . . . . . . . . . 8
6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . 14
Ertekin, et al. Expires December 28, 2006 [Page 2]
Internet-Draft Integration of HC over IPsec SAs June 2006
1. Introduction
This document identifies a framework for integrating HC over IPsec
Security Associations (SAs). The goal of integrating HC with IPsec
is to reduce the protocol overhead associated with packets traversing
between IPsec SA endpoints. This can be achieved by compressing the
transport layer header (e.g., UDP, TCP, etc.) and inner IP header of
packets at the ingress of the IPsec tunnel, and decompressing these
headers at the egress.
To realize HCoIPsec, this document proposes the use of Internet
Protocol Header Compression [IPHC], Compressed Real Time Protocol
[CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust
Header Compression [ROHC], to compress the inner headers of IP
packets traversing an IPsec tunnel. Since these traditional HC
schemes operate on a hop-by-hop basis, several extensions must be
defined to enable their operation over IPsec SAs. This document
details a framework which will allow these traditional hop-by-hop HC
schemes to be extended to operate at IPsec SA endpoints.
HCoIPsec currently targets the application of HC to tunnel mode SAs.
However, future work may extend the framework to operate over
transport mode SAs as well. Transport mode SAs only encrypt/
authenticate the payload of an IP packet, leaving the IP header
untouched. Intermediate routers subsequently use the outer IP header
to route the packet to a decryption device. Therefore, if HC
mechanisms are extended to operate between IPsec transport-mode SA
endpoints, (de)compression functionality can only be applied to the
transport layer headers, and not to the IP header. Since compression
of transport layer headers alone does not provide substantial
efficiency gains, extending the HCoIPsec framework to support
transport mode SAs is left for future work.
2. Audience
The target audience includes those who are involved with the
development of HC schemes, and IPsec implementations. Since
traditional IETF HC schemes are designed to operate on a hop-by-hop
basis, they need to be modified to operate over IPsec SAs.
Therefore, the authors target various HC and IPsec communities who
may consider extending hop-by-hop HC schemes and IPsec protocols to
meet the requirements put forward in this document. Finally, this
document is directed towards vendors developing IPsec devices which
will be deployed in bandwidth-constrained, IP networks.
Ertekin, et al. Expires December 28, 2006 [Page 3]
Internet-Draft Integration of HC over IPsec SAs June 2006
3. Terminology
Terminology specific to discussion of HCoIPsec is introduced in this
section.
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 RFC 2119.
Compressed Traffic
Traffic that is processed by the compressor. Packet headers are
compressed using a compression profile.
Uncompressed Traffic
Traffic that is not processed by the compressor. Instead, this
type of traffic bypasses the HC process.
HC Process
Generic reference to either the compressor, decompressor, or any
supporting header compression (HC) components.
IPsec Process
Generic reference to the Internet Protocol Security (IPsec)
process [IPSEC].
4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode
SAs
IPsec mechanisms provide various security services for IP networks.
The benefits of IPsec come at the cost of increased per-packet
overhead. For example, traffic flow confidentiality (generally
leveraged at security gateways) requires the tunneling of IP packets
between IPsec implementations. Although these IPsec tunnels will
effectively mask the source-destination patterns that an intruder can
ascertain, IPsec tunnels come at the cost of increased per-packet
overhead. Specifically, an ESP tunnel mode SA applied to an IPv6
flow results in at least 50 bytes of additional overhead per packet.
This additional overhead may be undesirable for many bandwidth-
constrained wireless and/or satellite communications networks, as
these types of infrastructure are not overprovisioned. Consequently,
the additional overhead incurred in an encryption-based environment
may result in the inefficient utilization of bandwidth.
Ertekin, et al. Expires December 28, 2006 [Page 4]
Internet-Draft Integration of HC over IPsec SAs June 2006
Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads. Some applications that
emanate small packet payloads include various voice codecs (e.g.,
G.729). In addition, if these small packets are afforded the
security services of an IPsec tunnel mode SA, the amount of per-
packet overhead is magnified. Thus, a mechanism is needed to reduce
the overhead associated with such flows.
5. Overview of the HCoIPsec Framework
5.1. HCoIPsec Assumptions
The goal for HCoIPsec is to provide more efficient transport of IP
packets between source and destination IPsec devices, without
compromising the security services offered by IPsec. As such, the
HCoIPsec framework was developed based on the following assumptions:
o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be
leveraged to reduce the amount of overhead associated with packets
traversing an IPsec SA
o HC algorithms will be instantiated at the IPsec SA endpoints, and
HC is applied on a per-SA basis
5.2. HCoIPsec Description
HC schemes reduce packet overhead in a network by exploiting inter-
packet redundancies of network and transport-layer header fields of a
flow to reduce the amount of redundant header data transmitted
between two nodes.
To apply traditional HC schemes over IPsec SAs, several extensions
need to be defined. Existing HC schemes compress packet headers on a
hop-by-hop basis. However, IPsec SAs are instantiated between two
IPsec implementations, with multiple hops between the IPsec
implementations. Therefore, to fully integrate HC with IPsec SAs,
traditional hop-by-hop schemes need to be extended to operate at
IPsec SA endpoints.
The migration of traditional hop-by-hop HC schemes over IPsec SAs is
straightforward, since SA endpoints provide source/destination pairs
where (de)compression operations can take place. Compression in such
a manner offers a reduction of per-packet protocol overhead between
the two SA endpoints, and does not require compression and
decompression cycles at the intermediate hops between IPsec
implementations. Since HC schemes will now essentially operate over
multiple hops, it is imperative that the performance of the HC
schemes is not severely impacted due to increased packet reordering
and/or packet loss between the compressor and decompressor.
Ertekin, et al. Expires December 28, 2006 [Page 5]
Internet-Draft Integration of HC over IPsec SAs June 2006
In addition, since HC schemes will operate at IPsec SA endpoints, HC
schemes can no longer rely on the underlying link layer for HC
parameter configuration and packet identification. Traditionally, HC
schemes use the underlying link layer to establish a set of
configuration parameters at each end of the link, and for identifying
different types of header-compressed packets. The HCoIPsec framework
proposes that HC session parameter configuration and header-
compressed packet identification is accomplished by the SA management
protocol (e.g., IKEv2) and the security protocol next header field,
respectively.
Using the HCoIPsec framework proposed below, outbound IP traffic
processing at an IPsec device is augmented to compress appropriate
packet headers, and subsequently encrypt and/or integrity-protect the
packet. For tunnel mode SAs, compression may be applied to the
transport layer protocol and the inner IP header.
Inbound IP traffic processing at an IPsec device is modified in a
similar fashion. For inbound packets, an IPsec device must first
decrypt and/or integrity-check the packet. Then, the IPsec device
determines if the packet was received on an HC-enabled SA(see section
6.1), and if the packet maintains compressed headers. If both of
these conditions are met, decompression of the inner packet headers
is performed. After decompression, the packet is checked against the
access controls imposed on all inbound traffic associated with the SA
(as specified in RFC 4301).
Note: Compression of inner headers is independent from compression
of the security protocol (e.g., ESP) and outer IP headers. HC
schemes such as ROHC and IPHC are capable of compressing these
outer headers on a hop-by-hop basis. Further discussion on the
compression of outer headers is outside the scope of this
document.
If IPsec NULL encryption is applied to packets, HC schemes may still
be applied to the inner headers at the IPsec SA endpoints. Inbound
and outbound packets are still processed as was previously described.
For scenarios where NULL-encrypted packets traverse intermediate
nodes between the IPsec SA endpoints, the intermediary nodes must not
attempt to (de)compress the inner IP and/or transport layer headers.
6. Details of the HCoIPsec Framework
6.1. HC and IPsec Integration
Based on these assumptions, Figure 1 illustrates the components
required to integrate HC with the IPsec process, i.e., HCoIPsec.
Ertekin, et al. Expires December 28, 2006 [Page 6]
Internet-Draft Integration of HC over IPsec SAs June 2006
+-------------------------------+
| HC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | HC-enabled | | | | HC | |
--| A |--------------------| B |-----| Process |------> Path 1
| | | | | | | |
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | |
| +-------------------------------+
|
| HC-disabled
+----------------------------------------------------> Path 3
Figure 1: Integration of HC with IPsec.
The process illustrated in Figure 1 augments the IPsec processing
model for outbound IP traffic(protected-to-unprotected). Initial
IPsec processing is consistent with RFC 4301 (Steps 1-2, Section
5.1). The HC data item (part of the SA state information) retrieved
from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a)
determines if the traffic traversing the SA is handed to the HC
module (Figure 1, decision block A). Packets selected to an HC-
disabled SA must follow normal IPsec processing and must not be sent
to the HC module (Figure 1, Path 3). Conversely, packets selected to
an HC-enabled SA must be sent to the HC module. The decision at
block B then determines if the packet can be compressed. If it is
determined that the packet will be compressed, the Next Header field
of the security protocol header (e.g., ESP, AH) is populated with the
"compressed headers" value, and packet headers are compressed based
on the appropriate compression profile (Figure 1, Path 1). However,
if it is determined that the packet will not be compressed, the Next
Header field is populated with the appropriate value indicating the
next level protocol (Figure 1, Path 2). After the HC process
completes, IPsec processing resumes, as described in Section 5.1,
Step3a, of RFC4301 (specifically, "IPsec processing is as previously
defined...").
The process illustrated in Figure 1 also augments the IPsec
processing model for inbound IP traffic (unprotected-to-protected).
For inbound packets, processing is performed (RFC4301, Section 5.2,
Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2,
Step 4) . After AH or ESP processing, the HC data item retrieved
from the SAD entry will indicate if traffic traversing the SA is
handed to the HC module (RFC4301, Section 5.2, Step 3a). Packets
Ertekin, et al. Expires December 28, 2006 [Page 7]
Internet-Draft Integration of HC over IPsec SAs June 2006
traversing an HC-disabled SA must follow normal IPsec processing and
must not be sent to the HC module. Conversely, packets traversing an
HC-enabled SA must be sent to the HC module. The decision at block B
then determines if the "Next Header" field contains the "compressed
header" value, which indicates that the packet's payload contains
compressed headers. If "compressed headers" is indicated, the
appropriate decompression profile is applied (Figure 1, Path 1).
However, if the packet's "Next Header" field does not contain the
"compressed headers" value, the decompressor must not attempt
decompression (Figure 1, Path 2). IPsec processing resumes once the
HC module completes processing, as described in Section 5.2, Step 4
of RFC 4301(specifically "Then match the packet against the inbound
selectors identified by the SAD ...").
6.1.1. Header Compression Scheme Considerations
Traditional hop-by-hop HC schemes must be extended to operate
efficiently over IPsec SAs. Implementation considerations for this
includes increasing tolerance to packet reordering and packet loss
between the compressor and decompressor, and minimizing the amount of
feedback sent from the decompressor to the compressor.
The ability to tolerate increased packet reordering between the
compressor and decompressor is a necessity for any HC scheme that is
extended to operate over an IPsec SA. The following provides a
summary of the candidate HC solutions, and their tolerance to packet
loss and reordering between the compressor and decompressor:
o IPHC has been identified as a HC scheme that performs poorly over
long round trip time (RTT), high BER links [ROHC]. Extensions to
IPHC to compress TCP/IP headers over an IPsec SA should take into
consideration longer RTTs, increased potential for packet
reordering and IPLR between the compressor and decompressor.
o CRTP has also been identified as a HC scheme that performs poorly
over long RTT, high BER links [CRTPE]. Recent modifications to
the CRTP scheme, such as ECRTP, enable the CRTP HC scheme to
tolerate long RTTs and packet loss between the compressor and
decompressor. However, the reordering tolerance of ECRTP still
needs to be evaluated, as detailed in [ECRTPE]. Such
implementation aspects should be taken into consideration when
extending ECRTP to operate over IPsec SAs.
o ROHC is a robust HC scheme that is designed for high BER, long RTT
links. ROHC can be used to compress not only RTP/UDP/IP headers,
but also other traffic profiles such as TCP/IP, as defined in
[ROHCTCP]. Similar to CRTP and IPHC, ROHC has been identified as
vulnerable to packet reordering events between the compressor and
decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the
implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation
Ertekin, et al. Expires December 28, 2006 [Page 8]
Internet-Draft Integration of HC over IPsec SAs June 2006
aspects should be taken into consideration when extending ROHC to
operate over IPsec SAs.
In addition, HC schemes should minimize the amount of feedback
between decompressor and compressor. If a feedback channel from the
decompressor to the compressor is not used sparingly, the overall
gains from HCoIPsec can be significantly reduced. For example,
assume that ROHC is operating in bi-directional reliable mode, and is
instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be
tunneled. As such, the additional overhead incurred by tunneling
feedback will reduce the overall benefits of HC.
6.1.2. Initialization and Negotiation of HC Channel
Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to
negotiate HC channel parameters. To remove HC scheme dependencies on
the underlying link layer, an additional mechanism is needed to
initialize a HC channel and its associated parameters prior to HC
scheme operation.
Initialization of the HC channel will either be achieved manually
(i.e., administratively configured for manual SAs), or be performed
by IPsec SA establishment protocols, e.g. IKEv2. During SA
initialization, the SA establishment protocol will be extended to
negotiate the HC scheme's channel parameters. The specifics for this
proposal are detailed in a separate spectification, "IKEv2/IPsec
Extensions to Support HCoIPsec".
If the HC scheme requires bi-directional communications, two SAs must
be instantiated between the IPsec implementations. One of the two
SAs is used for carrying traffic from the compressor to the
decompressor, while the other is used to communicate feedback from
the decompressor to the compressor. IPsec implementations will
dictate how decompressor feedback received on one SA is associated
with a compressor on the other SA.
6.1.3. Encapsulation and Identification of Header Compressed Packets
As indicated in section 6.1, new state information (i.e., a new HC
data item) is defined for each SA. The HC data item is used by the
IPsec process to determine whether it sends all traffic traversing a
given SA to the HC module (HC-enabled) or bypasses the HC module and
sends the traffic through regular IPsec processing (HC-disabled).
In addition, the "Next Header" field of the IPsec security protocol
(e.g., AH or ESP) header is used to demultiplex header-compressed
traffic from uncompressed traffic traversing an HC-enabled SA. This
Ertekin, et al. Expires December 28, 2006 [Page 9]
Internet-Draft Integration of HC over IPsec SAs June 2006
functionality is needed in situations where packets traversing an HC-
enabled SA are not compressed by the compressor. Such situations may
occur when, for example, a compressor supports strictly n compressed
flows and can not compress the n+1 flow that arrives. Another
example is when traffic (e.g., TCP/IP) is selected to an HC-enabled
SA, but cannot be compressed by the HC process (e.g., because the
compressor does not support TCP/IP compression). In these
situations, the compressor must be able to indicate that the packet
contains uncompressed headers. Similarly, the decompressor must be
able to identify packets with uncompressed headers and not attempt to
decompress them. Therefore, an allocation for "compressed headers"
will need to be reserved from the IANA "Protocol Numbers" registry,
which will be defined in a separate specification. The "compressed
headers" value will indicate that the next layer protocol header is
composed of compressed headers.
6.2. HCoIPsec Framework Summary
[Note to RFC Editor: this section may be removed on publication as an
RFC.]
To summarize, the following items are needed to achieve HCoIPsec:
o Extensions to traditional HC schemes which enable their operation
at IPsec SA enpoints
o Extensions to IKE/IPsec to support HC parameter configuration
o Allocation of one value for "compressed headers" from the IANA
"Protocol Numbers" registry
7. Security Considerations
A malfunctioning header compressor (i.e., the compressor located at
the ingress of the IPsec tunnel) has the ability to send packets to
the decompressor (i.e., the decompressor located at the egress of the
IPsec tunnel) that do not match the original packets emitted from the
end-hosts. Such a scenario will result in a decreased efficiency
between compressor and decompressor. Furthermore, this may result in
Denial of Service, as the decompression of a significant number of
invalid packets may drain the resources of an IPsec device.
8. IANA Considerations
None.
9. Acknowledgments
Ertekin, et al. Expires December 28, 2006 [Page 10]
Internet-Draft Integration of HC over IPsec SAs June 2006
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
and Ms. Linda Noone of the Department of Defense, and well as Mr.
Rich Espy of OPnet for their contributions and support in the
development of this document. In addition, the authors would like to
thank the following for their numerous reviews and comments to this
document:
o Dr. Stephen Kent
o Dr. Carsten Bormann
o Mr. Lars-Erik Jonnson
o Mr. Jan Vilhuber
o Mr. Dan Wing
o Mr. Kristopher Sandlund
Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Mr. Jonah Pezeshki of Booz
Allen Hamilton for their assistance in completing this work.
10. References
10.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
February 1999.
[ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on
Links with High Delay, Packet Loss, and Reordering",
RFC 3545, July 2003.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header
Compression Algorithm ECRTP", November 2004.
[ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A
Ertekin, et al. Expires December 28, 2006 [Page 11]
Internet-Draft Integration of HC over IPsec SAs June 2006
Profile For TCP/IP (ROHC-TCP)", work in progress ,
January 2006.
[ROHCWEXT]
Pelletier, G. and et. al, "ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
10.2. Informative References
[ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303,
December 2005.
[HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header
Compression over MPLS", April 2005.
[CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communication Magazine , Volume
7, number 4, pp. 20-25, August 2000.
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS",
RFC 4247, November 2005.
Ertekin, et al. Expires December 28, 2006 [Page 12]
Internet-Draft Integration of HC over IPsec SAs June 2006
Authors' Addresses
Emre Ertekin
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: ertekin_emre@bah.com
Chris Christou
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: christou_chris@bah.com
Rohan Jasani
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: jasani_rohan@bah.com
Ertekin, et al. Expires December 28, 2006 [Page 13]
Internet-Draft Integration of HC over IPsec SAs June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ertekin, et al. Expires December 28, 2006 [Page 14]
