Internet DRAFT - draft-ertekin-rqts-hcoipsec
draft-ertekin-rqts-hcoipsec
Network Working Group E. Ertekin
Internet-Draft C. Christou
Expires: October 3, 2005 R. Jasani
Booz Allen Hamilton
April 2005
Integration of Header Compression over IPsec Security Associations
draft-ertekin-rqts-hcoipsec-01
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 October 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Internet Protocol security mechanisms, such as IP Security (IPsec)
[IPSEC], provides various security services for IP traffic. However,
the benefits offered by IPsec may come at the cost of increased
overhead. This document identifies a methodology for integrating
header compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to
reduce the amount of packet overhead associated with the transmission
of traffic over tunnel mode security associations.
Ertekin, et al. Expires October 3, 2005 [Page 1]
Internet-Draft Integration of HC over IPsec SAs April 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement: Packet Overhead Associated with IPsec
Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 3
4. The Header Compression Solution . . . . . . . . . . . . . . . 4
5. Integration Methodology . . . . . . . . . . . . . . . . . . . 6
5.1 Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6
5.2 Work Items . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1 Header Compression Scheme Specific Extensions . . . . 7
5.2.2 Initialization and Negotiation of Header
Compression Channel . . . . . . . . . . . . . . . . . 7
5.2.3 Encapsulation and Identification of Header
Compressed Packets . . . . . . . . . . . . . . . . . . 7
6. Candidate Compression Schemes . . . . . . . . . . . . . . . . 8
7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 8
8. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 10
8.1 HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 10
8.2 Multiplexing of Compressed Packets in IPsec Tunnels . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1 Normative References . . . . . . . . . . . . . . . . . . . 12
12.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 15
Ertekin, et al. Expires October 3, 2005 [Page 2]
Internet-Draft Integration of HC over IPsec SAs April 2005
1. Introduction
This document identifies a methodology for the integration of header
compression (HC) over IPsec Security Associations (SAs) which are
operating in tunnel mode. The goal of integrating HC with IPsec
mechanisms is to reduce the protocol overhead associated with packets
traversing between IPsec SA endpoints. This goal can be achieved by
compressing the upper layer protocols (e.g., RTP/UDP and TCP) and the
inner IP header of packets traversing tunnel mode SAs, before packet
encryption takes place.
To accomplish 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 within an IPsec tunnel. However, since these HC
schemes operate on a hop-by-hop basis, several extensions to need to
be defined. This document details a methodology which will enable
these traditional hop-by-hop HC schemes to be extended, and operate
end-to-end between IPsec SA endpoints.
Currently, HCoIPsec primarily targets the application of HC to tunnel
mode SAs as opposed to transport mode SAs. Transport mode SAs only
encrypt/authenticate the payload of an IP packet, and leave the
original IP header unencrypted/unauthenticated. Since intermediary
routers use the original IP header to route the packet to a
decryption device, end-to-end header (de)compression functionality at
the transport-mode SA endpoints can only be applied on the transport
layer headers and not the IP header. Since compression of transport
layer headers alone does not provide substantial efficiency gains, it
is not fully integrated into the HCoIPsec methodology.
2. Audience
The target audience includes those who are involved with the design
and development of HC schemes, and IPsec mechanisms. Since
traditional IETF HC schemes are designed to operate on a hop-by-hop
basis, they will 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 methodology put forward in this document. Finally, this
document is directed towards vendors developing IPsec encryption/
decryption devices which will be deployed in bandwidth-constrained,
IP networking environments.
3. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode
SAs
Ertekin, et al. Expires October 3, 2005 [Page 3]
Internet-Draft Integration of HC over IPsec SAs April 2005
IPsec mechanisms provide various security services for IP-based
networks. For example, ESP offers data origin authentication,
connectionless integrity, anti-replay service, and limited traffic
flow confidentiality [ESP].
The benefits of IPsec mechanisms may come at the cost of increased
overhead emanated into the network. For example, traffic flow
confidentiality, which is generally implemented at security gateways,
requires the tunneling of IP packets between the encryption/
decryption devices. Tunnels mask the source-destination patterns
that an intruder may ascertain, but the benefit comes at the cost of
extra per-packet overhead. 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 (SATCOM)
networks, as these types of infrastructure are not overprovisioned.
Consequently, the additional overhead incurred in an encryption-based
environment may hinder the efficient utilization of bandwidth.
In these bandwidth-constrained high bit error rate (BER) networks,
end-host applications may not have the luxury of sending packets with
large payloads. This is due to the fact that large packets
traversing high BER links result in high IP Packet Loss Ratio (IPLR).
To reduce IPLR, end-host devices may reduce the size of packet
payloads, which decreases the probability that a packet is lost due
to a bit error. Reducing the size of packet payloads, however,
increases the amount of overhead transmitted between the two end
hosts. Moreover, if these packets traverse over an IPsec tunnel mode
SA, the amount of overhead is further magnified. A mechanism is
needed to reduce the overhead associated with such flows.
4. The Header Compression Solution
IP HC schemes provide one such mechanism to reduce the per packet
overhead in an IP network. Schemes such as IPHC, CRTP, ECRTP and
ROHC exploit inter-packet redundancies of network and transport-layer
header fields of a flow to reduce the amount of overhead transmitted
between two nodes.
To apply HC schemes over IPsec SAs, several extensions to the
existing schemes need to be developed. Existing HC schemes such as
IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop-
by-hop basis. IPsec SAs, however, may be instantiated between IPsec
devices functioning as gateways, with multiple intermediary nodes
between the IPsec gateways. Therefore, to fully integrate HC with
IPsec SAs, traditional hop-by-hop schemes need to be extended to
operate between IPsec SA endpoints.
Ertekin, et al. Expires October 3, 2005 [Page 4]
Internet-Draft Integration of HC over IPsec SAs April 2005
The migration of traditional hop-by-hop HC schemes over IPsec SAs is
simple, as SA endpoints provide source/destination pairs where
(de)compression operations can take place. Compression in such a
manner offers both a reduction of per-packet protocol overhead
between the two SA endpoints, and does not require compression and
decompression cycles at the intermediate network nodes between the
IPsec devices. Since HC schemes will now essentially be operating
over multiple hops, it is imperative that the performance of the HC
schemes is not severely impacted due to increased packet reordering
and/or IPLR events between the compressor and decompressor. It
should be noted that the notion of extending hop-by-hop HC schemes to
operate over multiple hops is not new, as the HCoIPsec effort
parallels other efforts such as ECRTP over MPLS [HCOMPLS].
Using the proposed architecture, the order of processing for outbound
packets at an IPsec device is to compress the appropriate packet
headers, and subsequently encrypt and/or authenticate the packet.
For tunnel mode SAs, compression occurs at the ingress of the IPsec
tunnel, and is applied to the transport layer protocol and the inner
IP header.
The order of processing for inbound packets at an IPsec device is
similar. For inbound packets, an IPsec device must first decrypt the
packet. Then, the IPsec device must identify whether the packet
includes a compressed header. If the IPsec device has identified the
packet as a packet with a compressed header, the decompression
function takes place. Decompression at the egress of an IPsec tunnel
includes the decompression of IP and transport layer headers.
Note: Compression of inner headers is completely independent from
compression of the outer (e.g., ESP/IP) headers. Intermediate
network nodes between IPsec endpoints may also compress the outer
ESP/IP headers. Current HC schemes such as ROHC and IPHC contain
the ability to compress these ESP/IP headers. Further discussion
of hop-by-hop compression of the outer ESP/IP headers is out of
scope of this document.
If IPsec NULL encryption is applied on packets, HC schemes may still
be applied on the inner headers at the IPsec SA endpoints. After
IPsec processes the compressed packet (and NULL encryption is applied
on the packet), the compressed header will be sent in the clear. In
scenarios where NULL encrypted packets traverse intermediate nodes
between the IPsec SA endpoints, the intermediary nodes should not
attempt to (de)compress the inner IP and transport layer headers on a
hop-by-hop basis.
Ertekin, et al. Expires October 3, 2005 [Page 5]
Internet-Draft Integration of HC over IPsec SAs April 2005
5. Integration Methodology
The goal for HCoIPsec is to provide more efficient transport of IP
packets between source and destination IPsec devices without
compromising security services offered by IPsec.
With this general goal in mind, Section 5.1 defines a set of work
assumptions to guide the direction of the HCoIPsec solution. Based
on these work assumptions, Section 5.2 defines work items which need
to be addressed to complete the HCoIPsec solution.
5.1 Work Assumptions
a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP,
ROHC) to reduce the amount of overhead associated with packets
traversing an IPsec tunnel-mode SA.
b. HCoIPsec must execute (de)compression operations at IPsec SA
endpoints, and must not perform (de)compression cycles at
intermediate nodes between IPsec devices.
c. HCoIPsec must be independent of the underlying link layer framing
protocol (e.g., PPP).
d. HCoIPsec must allow each SA to constitute a HC channel, enabling
each SA to have its own CID space.
e. An SA with HC enabled should not deliver a larger amount of
incorrect packets than the same SA with HC disabled.
The motivation behind (c) comes from the realization that the link
layer frame will be changing between the IPsec endpoints. Therefore,
link layer dependencies exhibited by traditional hop-by-hop HC
schemes cannot be used in a HCoIPsec solution.
5.2 Work Items
This section identifies several work items that need to be addressed
to achieve HCoIPsec. The first work item encompasses the HC scheme
specific extensions needed to ensure that traditional hop-by-hop HC
schemes will operate efficiently over SA endpoints:
a. Header Compression Scheme Specific Extensions: Any modifications
needed to be made to existing HC schemes, which will facilitate
their operation over IPsec SAs. (Section 5.2.1)
Hop-by-hop HC schemes use the underlying link layer (e.g., Point to
Point Protocol) to negotiate the HC channel parameters and to
indicate the type of compressed packet the data-link layer frame is
encapsulating. To remove HC scheme dependencies on the underlying
link layer and to achieve a complete HCoIPsec solution, two
additional work items are proposed:
Ertekin, et al. Expires October 3, 2005 [Page 6]
Internet-Draft Integration of HC over IPsec SAs April 2005
b. Initialization and Negotiation of the Header Compression Channel:
Mechanisms needed to initialize a HC channel and negotiate HC
scheme parameters prior to operation. (Section 5.2.2)
c. Encapsulation and Identification of Header Compressed Packets:
Mechanisms which encapsulate and identify compressed header
packets, as well as how these mechanisms will operate. (Section
5.2.3)
5.2.1 Header Compression Scheme Specific Extensions
a. HCoIPsec should minimize HC scheme performance degradation due to
increased delays, packet loss, jitter, and reordering events
between compressor and decompressor.
b. HCoIPsec should minimize the amount of HC signaling between
compressor and decompressor.
The intention of (b) is to indicate that if a feedback channel from
the decompressor to the compressor is not used sparingly, then the
overall gains from HCoIPsec can be significantly reduced (even more
so than hop-by-hop HC). For example, take the case where ROHC in bi-
directional reliable mode is instantiated over an IPsec tunnel mode
SA. Any feedback sent from the decompressor to the compressor must
be tunneled, and therefore, the additional overhead incurred by
tunneling the feedback will reduce the overall benefits of HC.
5.2.2 Initialization and Negotiation of Header Compression Channel
Initialization of the HC channel is handed off to the IPsec SA
establishment protocols. During SA initialization, the IPsec SA
establishment protocols will identify the type of HC scheme
configured for the SA, as well as the HC scheme's channel parameters.
a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel
parameters (e.g., for ROHC, IKE(v2) shall initialize MAX_CID,
MAX_HEADER, MRRU)
b. HCoIPsec should allow compressed headers and uncompressed headers
to traverse a single SA
(b) is desirable, as IPsec devices may have limitations on the number
of IPsec SAs which may be instantiated. Therefore, (b) indirectly
implies that both uncompressed and compressed packets should be able
to be classified under the same SA. Therefore, HCoIPsec should
include a mechanism which will aid an IPsec device in identifying
whether or not an inbound packet contains a compressed header.
5.2.3 Encapsulation and Identification of Header Compressed Packets
For indication purposes, a one-byte header may be added to the
Ertekin, et al. Expires October 3, 2005 [Page 7]
Internet-Draft Integration of HC over IPsec SAs April 2005
compressed packet; this field will help the decompressor identify how
to process the compressed packet.
a. HCoIPsec may introduce a new one-byte header to indicate the type
of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8,
COMPRESSED_RTP_16, CONTEXT_STATE, etc.)
6. Candidate Compression Schemes
IPHC can be used to compress TCP/IP headers for tunnel mode SAs.
IPHC, however, has been identified as a HC scheme which performs
poorly over long round trip time (RTT), high BER links [ROHC].
Extensions to IPHC to compress TCP/IP headers over an IPsec SA need
to take into consideration longer RTTs, increased packet reordering
and IPLR between the compressor and decompressor.
CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs.
CRTP, however, has also been identified as a HC scheme which performs
poorly over long RTT, high BER links [CRTPE]. Recent modifications
to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to
tolerate long RTTs, packet loss, and packet reordering events between
compressor and decompressor. The ability to tolerate these network
characteristics is a necessity for any HC scheme, and will be a
factor in determining how efficiently the HC scheme operates over the
IPsec tunnel-mode SA.
ROHC, as defined in RFC 3095, provides a robust HC scheme which is
designed for high BER, long RTT links. This makes ROHC another
candidate header scheme to extend over IPsec tunnels. ROHC can be
used to compress not only RTP/UDP/IP headers, but also TCP/IP
headers, 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] contends
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
between IPsec SA endpoints.
7. Example Operation
The basic operation of the HCoIPsec protocol is detailed in the
following example. Assume there are two IPsec devices operating in
gateway mode. The initial step of the HCoIPsec process is to
leverage the SA establishment protocol (e.g., IKE, IKEv2) to
negotiate the HC scheme, and channel parameters. For example, the
MAX_CID, MRRU, MAX_HEADER, and PROFILES parameters will be negotiated
for each IPsec SA which is capable of ROHC. For an IPsec SA that is
ECRTP-enabled, channel parameters including F_MAX_PERIOD, F_MAX_TIME,
Ertekin, et al. Expires October 3, 2005 [Page 8]
Internet-Draft Integration of HC over IPsec SAs April 2005
and the ECRTP Compression Suboption will be initialized.
After the SA has been established, HC can take place for packets
which belong to that SA. Upon reception of an outbound packet, the
IPsec device will consult the security policy database, and associate
the packet with an SA. If the SA indicates that compression may take
place, the IPsec device will decide whether or not to compress the
packet: if it is determined that the packet will not be compressed,
then normal IPsec processing of the packet ensues; if it is
determined that the packet's header will be compressed, the HC scheme
is executed on the packet. After the packet's header is compressed,
the device must indicate what type of compressed packet it is. This
may be achieved by adding a one-byte field which indicates the type
of compressed packet (e.g., for ECRTP, this field will indicate-for
example-an 8-bit compressed RTP header). The compressed packet is
encrypted according to the SA configuration, the outer ESP/IP header
is appended, and finally, the packet is transmitted.
Upon reception of an inbound packet, an IPsec device associates the
packet with an SA, and decrypts the packet based on the SA
parameters. The IPsec device will then identify whether or not the
packet is composed of a compressed header. If a packet does not
contain a compressed header, normal IPsec processing ensues; if the
packet includes a compressed header, then the IPsec device hands the
packet to the decompressor process. The decompressor may inspect the
one-byte compressed packet type header field, and use this
information along with the HC channel parameters to decompress the
packet. When the packet decompression process completes, the packet
is handed back to the IPsec process, as the packet is then placed
through the security policy database, and is subsequently
transmitted.
Ertekin, et al. Expires October 3, 2005 [Page 9]
Internet-Draft Integration of HC over IPsec SAs April 2005
Figure 1 depicts the basic function of HCoIPsec:
-- -- -- -- -- -- -- -- -- --
| Tunnel Mode Security Association |
| |
| |
V V
+--------------+ +--------------+
|IPsec Endpoint| +--+ +--+ |IPsec Endpoint|
| | | | | | | |
+---| Compressor |-->|R1|-->|R2|-->| Decryptor |---+
| | Encryptor | | | | | | Decompressor | |
| +--------------+ +--+ +--+ +--------------+ |
| | | |
| |-----------------| |
| | |
| | |
V V V
------------------- ------------------------- -------------------
| | | | | | | | | | | |
| | UDP | | | | E | ------------- | | | UDP | |
|IP | / |Payload| |IP | S | |CID|Payload| | |IP | / |Payload|
| | RTP | | | | P | ------------- | | | RTP | |
| | | | | | | | | | | |
------------------- ------------------------- -------------------
| |
|---ENCRYPTED---|
| |
Figure 1: Example operation of HCoIPsec.
In the example scenario, note that the inbound and outbound packets
are first mapped to an SA, and then subsequently mapped to a CID.
This implies that the scope of each CID is contained within each SA.
A CID value of 1 can be associated with multiple SAs; however, the
context state information for CID 1 cannot be shared over multiple
SAs.
8. Future Work Items
8.1 HCoIPsec Transport Mode SAs
Many of the current HC profiles look to simultaneously compress
network and transport layer headers of IP packets. This makes the
extension of traditional HC schemes over transport-mode SAs more
difficult. For the application of HC over transport mode SAs,
traditional HC schemes may need to be extended to operate strictly on
layer 4 (e.g., TCP, and/or RTP/UDP) headers. The methodology and
Ertekin, et al. Expires October 3, 2005 [Page 10]
Internet-Draft Integration of HC over IPsec SAs April 2005
specification for HCoIPsec transport mode SAs is left for further
study.
8.2 Multiplexing of Compressed Packets in IPsec Tunnels
It should also be noted that a packet concatenation (or multiplexing)
scheme may be added in conjunction to HCoIPsec to further reduce the
overall overhead of packets traversing between IPsec devices. This
type of functionality is similar to AAL2 voice trunking, where voice
packets from different sources are placed into one cell [AAL2]. As
described in [AAL2], a multiplexer concatenates cells until one of
following two events occur:
o the first event indicates that the maximum size of multiplexed
cell is reached;
o the second event indicates that a timer has expired: this timer
provides an upper bound on the amount of delay a cell may exhibit.
When either of these events are triggered, the multiplexer transmits
the multiplexed cells.
[TCRTP] is one proposal to reduce the packet overhead used between
call gateways in an unencrypted network. In a similar fashion, if
multiple compressed flows are mapped to one SA between two IPsec
devices, then compressed packets MAY be concatenated with one
another, encrypted, and subsequently tunneled to the destination
IPsec device with one ESP/IP header. It should be noted, however,
that a multiplexing functionality may be undesirable for the high BER
networks, as multiplexing scheme may increase average packet sizes,
which may result in a greater IPLR. The specification of such a
protocol is left for further study.
9. Security Considerations
The extension of HC over IPsec security associations does not raise
any additional security concerns beyond the issues related to
existing IPsec protocols.
A malfunctioning header compressor (i.e., in the case of this
document, the encryption device) has the ability to send packets to
the decompressor (i.e., decryptor) which do not match the original
ones emanated from the end-hosts. In such a scenario, the invalid
packets will pass the decryption process, and will subsequently be
validly decompressed.
Furthermore, an intruder who has the ability to arbitrarily inject
packets between SA endpoints, and destines these malicious packets to
the encryption/decryption devices, has the ability to cause context
corruption between the compressor and decompressor processes
instantiated within the IPsec device (if the malicious packet passes
Ertekin, et al. Expires October 3, 2005 [Page 11]
Internet-Draft Integration of HC over IPsec SAs April 2005
through the decryption process). Such a scenario will result in a
decreased efficiency between compressor and decompressor, and
furthermore, may result in Denial of Service, as the decompression of
a significant number of invalid packets may drain the resources of an
IPsec device.
Note: It should be noted that these security issues are a direct
offset of IPsec vulnerabilities.
10. IANA Considerations
None.
11. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
of the Department of Defense, and Mr. A. Rich Espy of OPnet for their
contributions and support for developing this document. The authors
would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco
Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of
Ericsson for their valuable contributions to this document. The
authors would also like to thank Ms. Renee Esposito, Mr. Etzel
Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen
Hamilton for their assistance in completing this work.
12. References
12.1 Normative References
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[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,
Ertekin, et al. Expires October 3, 2005 [Page 12]
Internet-Draft Integration of HC over IPsec SAs April 2005
ESP, and uncompressed", RFC 3095, July 2001.
[ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A
Profile For TCP/IP (ROHC-TCP)", work in progress ,
February 2005.
[ROHCWEXT]
Pelletier, G. and et. al, "ROHC over Channels That Can
Reorder Packets", work in progress , February 2005.
12.2 Informative References
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload", RFC 2406, November 1998.
[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",
work in progress , December 2004.
[AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2 , September 1997.
[TCRTP] Thompson, B., "Tunneling of Multiplexed Compressed RTP",
work in progress , September 2004.
Authors' Addresses
Emre Ertekin
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
US
Email: ertekin_emre@bah.com
Ertekin, et al. Expires October 3, 2005 [Page 13]
Internet-Draft Integration of HC over IPsec SAs April 2005
Chris Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
US
Email: christou_chris@bah.com
Rohan Jasani
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
US
Email: jasani_rohan@bah.com
Ertekin, et al. Expires October 3, 2005 [Page 14]
Internet-Draft Integration of HC over IPsec SAs April 2005
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 (2005). 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 October 3, 2005 [Page 15]
