Network Working Group E. Ertekin
Internet-Draft C. Christou
Intended status: Informational R. Jasani
Expires: August 28, 2007 Booz Allen Hamilton
February 24, 2007
Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-04
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 August 28, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
IP Security (IPsec) [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 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 Associations (SAs).
Ertekin, et al. Expires August 28, 2007 [Page 1]
Internet-Draft Integration of HC over IPsec SAs February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4
5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5
5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5
5.2. Summary of the HCoIPsec Framework . . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8
6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
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 August 28, 2007 [Page 2]
Internet-Draft Integration of HC over IPsec SAs February 2007
1. Introduction
This document outlines a framework for integrating HC over IPsec
(HCoIPsec). The goal of HCoIPsec 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 HCoIPsec, this document assumes that existing HC protocols, such
as Internet Protocol Header Compression [IPHC], Compressed Real Time
Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and
Robust Header Compression [ROHC], will be used to compress the inner
headers of IP packets traversing an IPsec tunnel. Since these HC
protocols are designed to operate on a hop-by-hop basis, they may
require extensions to enable their operation over IPsec SAs. This
document outlines a framework for extending the usage of these hop-
by-hop HC protocols to operate at IPsec SA endpoints.
HCoIPsec targets the application of HC 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 traditional HC protocols were 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 specifications for HC protocols do not include support for
the compression of transport layer headers alone, the HCoIPsec
framework outlined by this document describes the application of HC
to tunnel mode SAs.
2. Audience
The target audience includes those who are involved with the
development of HC protocols, and IPsec implementations. Since
traditional HC protocols have been designed to operate on a hop-by-
hop basis, they may need to be modified or extended to be operational
over IPsec SAs. Therefore, the authors target various HC and IPsec
communities who may consider extending existing HC and IPsec
protocols to meet the requirements put forth in this document.
Finally, this document is directed towards vendors developing IPsec
devices that will be deployed in bandwidth-constrained IP networks.
3. Terminology
Terminology specific to HCoIPsec is introduced in this section.
Ertekin, et al. Expires August 28, 2007 [Page 3]
Internet-Draft Integration of HC over IPsec SAs February 2007
Compressed Traffic
Traffic that is processed by the compressor. Packet headers are
compressed using a specific header compression protocol.
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, as defined in [IPSEC].
Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field [PROTOCOL].
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 ([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.
HC applied on a per-hop basis over bandwidth-constrained link
technologies 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
Ertekin, et al. Expires August 28, 2007 [Page 4]
Internet-Draft Integration of HC over IPsec SAs February 2007
characterized by small packet payloads. Some applications that
generate small packet payloads include 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 HCoIPsec Framework
5.1. HCoIPsec Assumptions
The goal of HCoIPsec is to provide 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. Summary of the HCoIPsec Framework
HC protocols reduce packet overhead in a network by exploiting intra-
and inter-packet redundancies of network and transport-layer header
fields of a flow.
Existing HC protocols 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 protocols may need to be extended to operate
at IPsec SA endpoints.
The migration of hop-by-hop HC protocols 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 existing HC protocols will now essentially
operate over multiple hops, it is imperative that their performance
is not severely impacted due to increased packet reordering and/or
packet loss between the compressor and decompressor.
In addition, since HC protocols will operate at IPsec SA endpoints,
HC protocols can no longer rely on the underlying link layer for HC
Ertekin, et al. Expires August 28, 2007 [Page 5]
Internet-Draft Integration of HC over IPsec SAs February 2007
parameter configuration and packet identification. Existing HC
protocols use the underlying link layer to establish a set of
configuration parameters at each end of the link, and some HC
protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link
layer framing for identifying different types of header-compressed
packets. The HCoIPsec framework proposes that HC channel parameter
configuration is accomplished by the SA management protocol (e.g.,
IKEv2), while identification of compressed header packets (in
contrast to uncompressed packets) is provided through the Next Header
field of the security protocol (e.g., AH [AH], ESP). In addition, HC
protocols that require the identification of different types of
header-compressed packets will have to be extended with such a
mechanism.
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 [IPSEC]).
Note: Compression of inner headers is independent from compression
of the security protocol (e.g., ESP) and outer IP headers. HC
protocols such as ROHC are 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, HC protocols 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 HCoIPsec Framework
6.1. HC and IPsec Integration
Figure 1 illustrates the components required to integrate HC with the
IPsec process, i.e., HCoIPsec.
Ertekin, et al. Expires August 28, 2007 [Page 6]
Internet-Draft Integration of HC over IPsec SAs February 2007
+-------------------------------+
| HC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | HC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (HC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (HC-enabled SA)
| +-------------------------------+
|
|
|
|
+-----------------------------------------> Path 3
(HC-disabled SA)
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 [IPSEC] (Steps 1-2, Section 5.1).
The HC 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 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 a "compressed headers"
value, and packet headers are compressed based on the compression
protocol (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 HC 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 August 28, 2007 [Page 7]
Internet-Draft Integration of HC over IPsec SAs February 2007
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 ([IPSEC], Section 5.2, Step 3a).
Packets 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 is determined by the value of the Next Header
field. If "compressed headers" is indicated, decompression is
applied using the appropriate HC protocol (Figure 1, Path 1).
However, if the Next Header field does not contain the "compressed
headers" value, the decompressor must not attempt decompression
(Figure 1, Path 2). Once the HC 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,
HCoIPsec and IPcomp [IPCOMP] can be implemented in a nested fashion.
For an outbound packet, IPcomp is initially applied. Following the
application of IPcomp, the packet is sent to the HC module. Then,
the HC module may compress the headers (e.g., the IP header) of the
IPcomp-processed packet. After the HC process completes, IPsec
processing resumes. For inbound packets, these steps are reversed:
first, the packet is IPsec-processed; then, headers are decompressed;
last, the payload of the packet is decompressed based on the
appropriate IPcomp algorithm.
6.1.1. Header Compression Protocol Considerations
Traditional hop-by-hop HC protocols must be extended to operate
efficiently over IPsec SAs. Compressor and decompressor
implementation considerations therefore must account for increased
tolerance to packet reordering and packet loss between the compressor
and decompressor, and must minimize 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 protocol 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 protocol 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 packet loss between the compressor and
decompressor.
Ertekin, et al. Expires August 28, 2007 [Page 8]
Internet-Draft Integration of HC over IPsec SAs February 2007
o CRTP has also been identified as a HC protocol that performs
poorly over long RTT, high BER links [CRTPE]. Recent
modifications to the CRTP protocol, such as ECRTP, enable the CRTP
HC protocol 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 protocol 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
aspects should be taken into consideration when extending ROHC to
operate over IPsec SAs.
Note that additional techniques may be used to augment a traditional
HC protocol's tolerance to packet reordering. For example, various
security protocols are equipped with a sequence number; this value
may be used by the decompressor to identify a packet as "sequentially
late". This knowledge can increase the likelihood of successful
decompression of a reordered packet.
In addition, HC protocols 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 protocols use the underlying link layer (e.g., PPP) to
negotiate HC channel parameters. To remove HC protocol dependencies
on the underlying link layer, an additional mechanism is needed to
initialize a HC channel and its associated parameters prior to
HCoIPsec 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. The extensions required for
IKEv2 to support HC parameter negotiation are detailed in [IKE-HC].
Ertekin, et al. Expires August 28, 2007 [Page 9]
Internet-Draft Integration of HC over IPsec SAs February 2007
If the HC protocol 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. 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 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).
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 functionality
is needed in situations where packets traversing an HC-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) 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 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 "compressed
header" value will indicate the packet contains compressed headers.
Therefore, an official IANA allocation from the ProtocolID registry
is required. The request for a ProtocolID allocation, in addition to
IPsec extensions to support HCoIPsec, are specified in [IPSEC-HC].
6.2. HCoIPsec Framework Summary
To summarize, the following items are needed to achieve HCoIPsec:
o IKEv2 Extensions to Support HCoIPsec
o IPsec Extensions to Support HCoIPsec
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
Ertekin, et al. Expires August 28, 2007 [Page 10]
Internet-Draft Integration of HC over IPsec SAs February 2007
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
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
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,
Ertekin, et al. Expires August 28, 2007 [Page 11]
Internet-Draft Integration of HC over IPsec SAs February 2007
February 1999.
[ECRTP] Koren, 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.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile
For TCP/IP (ROHC-TCP)", work in progress , February 2007.
[IKE-HC] Pezeshki, et al., "IKEv2 Extensions to Support HCoIPsec",
work in progress , February 2007.
[IPSEC-HC]
Ertekin, et al., "IPsec Extensions to Support HCoIPsec",
work in progress , February 2007.
10.2. Informative References
[PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers".
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 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.
[ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header
Compression Algorithm ECRTP", November 2004.
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS",
RFC 4247, November 2005.
Ertekin, et al. Expires August 28, 2007 [Page 12]
Internet-Draft Integration of HC over IPsec SAs February 2007
[ROHCWEXT]
Pelletier, et al., "ROHC over Channels That Can Reorder
Packets", RFC 4224, January 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 August 28, 2007 [Page 13]
Internet-Draft Integration of HC over IPsec SAs February 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 August 28, 2007 [Page 14]
