One document matched: draft-ietf-rohc-hcoipsec-03.txt
Differences from draft-ietf-rohc-hcoipsec-02.txt
Network Working Group E. Ertekin
Internet-Draft C. Christou
Intended status: Informational R. Jasani
Expires: April 25, 2007 Booz Allen Hamilton
October 22, 2006
Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-03
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 April 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 April 25, 2007 [Page 1]
Internet-Draft Integration of HC over IPsec SAs October 2006
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. HCoIPsec Summary . . . . . . . . . . . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . 14
Ertekin, et al. Expires April 25, 2007 [Page 2]
Internet-Draft Integration of HC over IPsec SAs October 2006
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 traditional HC protocols,
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
traditional 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 traditional 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 the 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. Since
compression of transport layer headers alone does not provide
substantial efficiency gains, the HCoIPsec framework outlined by this
document only concerns 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 April 25, 2007 [Page 3]
Internet-Draft Integration of HC over IPsec SAs October 2006
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 [IPSEC].
Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field (see IANA web page at
http://www.iana.org/assignments/protocol-numbers).
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, 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.
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.
Ertekin, et al. Expires April 25, 2007 [Page 4]
Internet-Draft Integration of HC over IPsec SAs October 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. 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 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 Summary
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 traditional 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 traditional 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,
Ertekin, et al. Expires April 25, 2007 [Page 5]
Internet-Draft Integration of HC over IPsec SAs October 2006
HC protocols can no longer rely on the underlying link layer for HC
parameter configuration and packet identification. Traditional 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, 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 RFC 4301).
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 outer IP 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 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
Ertekin, et al. Expires April 25, 2007 [Page 6]
Internet-Draft Integration of HC over IPsec SAs October 2006
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.
+-------------------------------+
| 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 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 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 RFC4301
Ertekin, et al. Expires April 25, 2007 [Page 7]
Internet-Draft Integration of HC over IPsec SAs October 2006
(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 (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 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). 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 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 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 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.
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
Ertekin, et al. Expires April 25, 2007 [Page 8]
Internet-Draft Integration of HC over IPsec SAs October 2006
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 HC
protocol 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 protocol's channel parameters. The specifics for
this proposal are detailed in [IKE-HC].
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
Ertekin, et al. Expires April 25, 2007 [Page 9]
Internet-Draft Integration of HC over IPsec SAs October 2006
decompressor, while the other is used to communicate feedback from
the decompressor to the compressor. Note that this requirement for
two SAs aligns with the operation of IKE, which is capable of
creating SA 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).
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
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 (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. As such, 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.
Note: As indicated in the description of HCoIPsec inbound and
outbound processing, the Next Header field is used to identify
compressed packets on an HC-enabled SA. Because the Next Header
field value is only leveraged at the IPsec implementations, an
official IANA allocation from the ProtocolID registry may not be
required. Future discussions of HCoIPsec will determine the
appropriate path forward.
6.2. HCoIPsec Framework Summary
To summarize, the following items are needed to achieve HCoIPsec:
o Extensions to traditional HC protocols which enable their
operation at IPsec SA enpoints
o Extensions to IKEv2 to Support Header Compression over IPsec
(HCoIPsec)
Ertekin, et al. Expires April 25, 2007 [Page 10]
Internet-Draft Integration of HC over IPsec SAs October 2006
o Allocation of one value for "compressed headers" from the IANA
"Protocol Numbers" registry (This specification may not be
necessary, as indicated in Section 6.1.3)
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
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
Ertekin, et al. Expires April 25, 2007 [Page 11]
Internet-Draft Integration of HC over IPsec SAs October 2006
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, 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, et al., "Robust Header Compression: A Profile
For TCP/IP (ROHC-TCP)", work in progress , January 2006.
[ROHCWEXT]
Pelletier, et al., "ROHC over Channels That Can Reorder
Packets", RFC 4224, January 2006.
[IKE-HC] Jasani, et al., "Extensions to IKEv2 to Support HCoIPsec",
work in progress , September 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.
Ertekin, et al. Expires April 25, 2007 [Page 12]
Internet-Draft Integration of HC over IPsec SAs October 2006
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS",
RFC 4247, November 2005.
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 April 25, 2007 [Page 13]
Internet-Draft Integration of HC over IPsec SAs October 2006
Full 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.
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.
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 April 25, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 09:08:23 |