Network Working Group E. Ertekin
Internet-Draft C. Christou
Intended status: Informational R. Jasani
Expires: February 28, 2008 J. Pezeshki
Booz Allen Hamilton
August 27, 2007
Integration of Robust Header Compression (RoHC) over IPsec Security
Associations
draft-ietf-rohc-hcoipsec-06
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 February 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for
integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec).
By compressing the inner headers of IP packets, RoHCoIPsec proposes
Ertekin, et al. Expires February 28, 2008 [Page 1]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4
5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 4
5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5
5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5
6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6
6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8
6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . 14
Ertekin, et al. Expires February 28, 2008 [Page 2]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
1. Introduction
This document outlines a framework for integrating RoHC [ROHC] over
IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec 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.
For RoHCoIPsec, this document assumes that RoHC will be used to
compress the inner headers of IP packets traversing an IPsec tunnel.
However, since current specifications for RoHC detail its operation
on a hop-by-hop basis, it may require extensions to enable its
operation over IPsec SAs. This document outlines a framework for
extending the usage of RoHC to operate at IPsec SA endpoints.
RoHCoIPsec targets the application of RoHC to tunnel mode SAs.
Transport mode SAs only encrypt/authenticate the payload of an IP
packet, leaving the IP header untouched. Intermediate routers
subsequently use this IP header to route the packet to a decryption
device. Therefore, if RoHC is to operate over IPsec transport-mode
SAs, (de)compression functionality can only be applied to the
transport layer headers, and not to the IP header. Because current
RoHC specifications do not include support for the compression of
transport layer headers alone, the RoHCoIPsec framework outlined by
this document describes the application of RoHC to tunnel mode SAs.
2. Audience
The authors target members of both the RoHC and IPsec communities who
may consider extending the RoHC and IPsec protocols to meet the
requirements put forth in this document. In addition, this document
is directed towards vendors developing IPsec devices that will be
deployed in bandwidth-constrained IP networks.
3. Terminology
Terminology specific to RoHCoIPsec is introduced in this section.
Compressed Traffic
Traffic that is processed by a RoHC compressor. Packet headers
are compressed using a RoHC profile.
Uncompressed Traffic
Ertekin, et al. Expires February 28, 2008 [Page 3]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
Traffic that is not processed by the RoHC compressor. Instead,
this type of traffic bypasses the RoHC process.
RoHC Process
Generic reference to either the ROHC compressor or decompressor.
IPsec Process
Generic reference to the IPsec process defined in [IPSEC].
Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field.
4. Problem Statement: IPsec Packet Overhead
IPsec mechanisms provide various security services for IP networks.
However, 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, tunneling comes 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.
RoHC applied on a per-hop basis over bandwidth-constrained links will
also suffer from reduced performance when encryption is used on the
tunneled header, since encrypted headers can not be compressed.
Consequently, the additional overhead incurred by an IPsec tunnel may
result in the inefficient utilization of bandwidth.
Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads (e.g. various voice codecs).
In addition, if these small packets are afforded the security
services of an IPsec tunnel mode SA, the amount of per-packet
overhead is increased. Thus, a mechanism is needed to reduce the
overhead associated with such flows.
5. Overview of the RoHCoIPsec Framework
Ertekin, et al. Expires February 28, 2008 [Page 4]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
5.1. RoHCoIPsec Assumptions
The goal of RoHCoIPsec is to provide efficient transport of IP
packets between IPsec devices, without compromising the security
services offered by IPsec. As such, the RoHCoIPsec framework has
been developed based on the following assumptions:
o RoHC will be leveraged to reduce the amount of overhead associated
with packets traversing an IPsec SA
* Support for legacy HC algorithms (e.g. IPHC, CRTP, ECRTP) over
IPsec may be provided through the specification of new RoHC
profiles (e.g. [ROHC-CRTP])
o RoHC will be instantiated at the IPsec SA endpoints, and will be
applied on a per-SA basis
5.2. Summary of the RoHCoIPsec Framework
RoHC reduces packet overhead in a network by exploiting intra- and
inter-packet redundancies of network and transport-layer header
fields of a flow.
Current RoHC protocol specifications 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, various extensions to both RoHC and
IPsec may need to be defined to ensure its successful operation at
IPsec SA endpoints.
The migration of RoHC 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 RoHC
will now essentially operate over multiple hops, it is imperative to
ensure that its performance will not be severely impacted due to
increased packet reordering and/or packet loss between the compressor
and decompressor.
In addition, RoHC can no longer rely on the underlying link layer for
RoHC parameter configuration and packet identification. The
RoHCoIPsec framework proposes that RoHC channel parameter
configuration is accomplished by an SA management protocol (e.g.,
IKEv2 [IKEV2]), while identification of compressed header packets is
achieved through the Next Header field of the security protocol
(e.g., AH [AH], ESP [ESP]) header.
Using the RoHCoIPsec framework proposed below, outbound IP traffic
processing at an IPsec device is augmented to compress appropriate
Ertekin, et al. Expires February 28, 2008 [Page 5]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
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 RoHC-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 [IPSEC]).
Note: Compression of inner headers is independent from compression
of the security protocol (e.g., ESP) and outer IP headers. RoHC
is capable of compressing the security protocol and the outer IP
header on a hop-by-hop basis.
If IPsec NULL encryption is applied to packets, RoHC may still be
applied to the inner headers at the IPsec SA endpoints. Inbound and
outbound packets are still processed as was previously described.
6. Details of the RoHCoIPsec Framework
6.1. RoHC and IPsec Integration
Figure 1 illustrates the components required to integrate RoHC with
the IPsec process, i.e., RoHCoIPsec.
Ertekin, et al. Expires February 28, 2008 [Page 6]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
+-------------------------------+
| RoHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | RoHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (RoHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (RoHC-enabled SA)
| +-------------------------------+
|
|
|
|
+-----------------------------------------> Path 3
(RoHC-disabled SA)
Figure 1: Integration of RoHC 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 [IPSEC] (Steps 1-2, Section 5.1).
The RoHC data item (part of the SA state information) retrieved from
the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
the traffic traversing the SA is handed to the RoHC module (Figure 1,
decision block A). Packets selected to a RoHC-disabled SA must
follow normal IPsec processing and must not be sent to the RoHC
module (Figure 1, Path 3). Conversely, packets selected to a RoHC-
enabled SA must be sent to the RoHC 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 a "RoHC"
identifier, and packet headers are compressed (Figure 1, Path 1).
However, if it is determined that the packet will not be compressed
(e.g., due to one the reasons described in Section 6.1.3), the Next
Header field is populated with the appropriate value indicating the
next level protocol (Figure 1, Path 2). After the RoHC process
completes, IPsec processing resumes, as described in Section 5.1,
Step3a, of [IPSEC] (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, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
Ertekin, et al. Expires February 28, 2008 [Page 7]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
5.2, Step 4) . After AH or ESP processing, the RoHC data item
retrieved from the SAD entry will indicate if traffic traversing the
SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing an RoHC-disabled SA must follow normal IPsec
processing and must not be sent to the RoHC module. Conversely,
packets traversing an RoHC-enabled SA must be sent to the RoHC
module. The decision at block B is determined by the value of the
Next Header field of the security protocol header. If a RoHC header
is indicated, decompression is applied (Figure 1, Path 1). However,
if the Next Header field does not indicate a RoHC header, the
decompressor must not attempt decompression (Figure 1, Path 2). Once
the RoHC module completes processing, IPsec processing resumes, as
described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match
the packet against the inbound selectors identified by the SAD ...").
Note that to further reduce the size of an IPsec-protected packet,
RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.
6.1.1. Header Compression Protocol Considerations
The initial specification of RoHC [ROHC] may need to be extended to
operate efficiently over IPsec SAs. Specifically, compressor and
decompressor implementations must account for increased tolerance to
packet reordering and packet loss, and should minimize the amount of
feedback sent from the decompressor to the compressor. To address
this need, [ROHC-RODR] provides guidelines on how to implement
existing profiles over reordering channels, and RoHCv2 [ROHCV2]
profiles include various mechanisms that provide increased robustness
over reordering channels. Furthermore, a RoHC decompressor
implemented within IPsec architecture may leverage additional
mechanisms to improve performance over reordering channels (either
due to random events, or to an attacker intentionally reordering
packets). Specifically, IPsec's sequence number may be used by the
decompressor to identify a packet as "sequentially late". This
knowledge will increase the likelihood of successful decompression of
a reordered packet.
Additionally, RoHCoIPsec implementations should minimize the amount
of feedback sent from the decompressor to the compressor. If a ROHC
feedback channel is not used sparingly, the overall gains from
RoHCoIPsec can be significantly reduced. For example, assume that
RoHC is operating in bi-directional Reliable mode (R-mode), and is
instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be
processed by IPsec, and tunneled back to the compressor (as
designated by the SA associated with FEEDBACK_FOR). To address this
need, several implementation considerations are offered:
Ertekin, et al. Expires February 28, 2008 [Page 8]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
o Eliminate feedback traffic altogether by operating only in RoHC
Unidirectional mode (U-mode)
o Piggyback RoHC feedback messages on traffic that normally
traverses the SA designated by FEEDBACK_FOR.
Finally, it should be noted that all RoHCoIPsec implementations that
intend to reuse CIDs (i.e. remap a previously used but now retired
CID value in order to conserve CID space) must support the ROHC-DOWN
profile, as defined in [ROHC-DOWN]. This profile requires that a CID
value is shut-down before it is reused.
6.1.2. Initialization and Negotiation of the RoHC Channel
RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC
channel parameters. In the case of RoHCoIPsec, channel parameters
are negotiated by another mechanism. Specifically, initialization of
the RoHC channel is either achieved manually (i.e., administratively
configured for manual SAs), or is performed by IPsec SA establishment
protocols. The extensions required for IKEv2 to support RoHC
parameter negotiation are detailed in [IKE-ROHC].
If the RoHC protocol requires bi-directional communications, two SAs
must be instantiated between the IPsec implementations. One of the
two SAs is used for carrying RoHC-traffic from the compressor to the
decompressor, while the other is used to communicate RoHC-feedback
from the decompressor to the compressor. Note that the requirement
for two SAs aligns with the operation of IKE, which creates SAs in
pairs. However, 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 RoHC
data item) is defined for each SA. The RoHC data item is used by the
IPsec process to determine whether it sends all traffic traversing a
given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC
module and sends the traffic through regular IPsec processing (RoHC-
disabled).
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 RoHC-enabled SA. This
functionality is needed in situations where packets traversing a
RoHC-enabled SA do not contain compressed headers. 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 (by IPsec)
Ertekin, et al. Expires February 28, 2008 [Page 9]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
to a RoHC-enabled SA, but cannot be compressed by the RoHC process
(e.g., because the compressor does not support TCP/IP compression).
In these situations, the compressor must 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. The Next Header field is used to demultiplex these
header-compressed versus uncompressed packets, as a RoHC protocol
identifier will indicate the packet contains compressed headers. To
accomplish this, an official IANA allocation from the ProtocolID
registry [PROTOCOL] is required.
The RoHC Data Item, IANA ProtocolID allocation, and other IPsec
extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC].
6.2. RoHCoIPsec Framework Summary
To summarize, the following items are needed to achieve RoHCoIPsec:
o IKEv2 Extensions to Support RoHCoIPsec
o IPsec Extensions to Support RoHCoIPsec
7. Security Considerations
A malfunctioning RoHC 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.
In addition, some RoHCoIPsec implementations may allow an attacker to
identify new traffic flows by monitoring the relative size of the
encrypted packets (i.e. a group of "long" packets, followed by a long
series of "short" packets may indicate a new flow for some RoHCoIPsec
implementations). To mitigate this concern, RoHC padding mechanisms
may be used to arbitrarily add padding to transmitted packets to
randomize packet sizes.
8. IANA Considerations
None.
Ertekin, et al. Expires February 28, 2008 [Page 10]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
9. Acknowledgments
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. Tero Kivinen
o Mr. Lars-Erik Jonsson
o Mr. Jan Vilhuber
o Mr. Dan Wing
o Mr. Kristopher Sandlund
o Mr. Ghyslain Pelletier
o Mr. Pasi Eronen
Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work.
10. Informative References
[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.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ROHC-CRTP]
Bormann, et al., "A RoHC Profile for CRTP (RoHC-CRTP)",
work in progress , February 2007.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
Ertekin, et al. Expires February 28, 2008 [Page 11]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and
UDP-Lite", work in progress , May 2007.
[IKE-ROHC]
Pezeshki, et al., "IKEv2 Extensions to Support
RoHCoIPsec", work in progress , August 2007.
[ROHC-RODR]
Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
[ROHC-DOWN]
Bormann, C., "A ROHC Profile for CID shutdown (ROHC-
DOWN)", work in progress , July 2007.
[PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers",
February 2007.
[IPSEC-ROHC]
Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec",
work in progress , August 2007.
Authors' Addresses
Emre Ertekin
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: ertekin_emre@bah.com
Ertekin, et al. Expires February 28, 2008 [Page 12]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
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
Jonah Pezeshki
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: pezeshki_jonah@bah.com
Ertekin, et al. Expires February 28, 2008 [Page 13]
Internet-Draft Integration of RoHC over IPsec SAs August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ertekin, et al. Expires February 28, 2008 [Page 14]
