draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt   draft-ietf-rohc-ipsec-extensions-hcoipsec-04.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: April 16, 2009 J. Pezeshki Expires: August 6, 2009 Booz Allen Hamilton
M. Casey
Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
October 13, 2008 February 2, 2009
IPsec Extensions to Support Robust Header Compression over IPsec IPsec Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec) (ROHCoIPsec)
draft-ietf-rohc-ipsec-extensions-hcoipsec-03 draft-ietf-rohc-ipsec-extensions-hcoipsec-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2009. This Internet-Draft will expire on August 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits
of IP security services and efficient bandwidth utilization. of IP security services and efficient bandwidth utilization.
However, extensions to the SPD and SAD are required in order to However, in order to integrate ROHC with IPsec, extensions to the SPD
integrate ROHC with IPsec. This document describes the IPsec and SAD are required. This document describes the IPsec extensions
extensions required to support ROHCoIPsec. required to support ROHCoIPsec.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 2. Extensions to IPsec Databases . . . . . . . . . . . . . . . . . 3
2.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3 2.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3
2.2. Security Association Database (SAD) . . . . . . . . . . . 4 2.2. Security Association Database (SAD) . . . . . . . . . . . . 4
3. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 5 3. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 5
3.1. Addition to the IANA Protocol Numbers Registry . . . . . . 5 3.1. Addition to the IANA Protocol Numbers Registry . . . . . . 5
3.2. Verifying the Integrity of Decompressed Packet Headers . . 5 3.2. Verifying the Integrity of Decompressed Packet Headers . . 5
3.2.1. ICV Computation and Integrity Verification . . . . . . 6 3.2.1. ICV Computation and Integrity Verification . . . . . . 6
3.3. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 6 3.3. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Using IPsec ([IPSEC]) protection offers various security services for Using IPsec ([IPSEC]) protection offers various security services for
IP traffic. However, these benefits come at the cost of additional IP traffic. However, these benefits come at the cost of additional
packet headers, which increase packet overhead. As described in packet headers, which increase packet overhead. As described in
[ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used [ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used
with IPsec to reduce the overhead associated with IPsec-protected with IPsec to reduce the overhead associated with IPsec-protected
packets. packets.
IPsec-protected traffic is carried over Security Associations (SAs), IPsec-protected traffic is carried over Security Associations (SAs),
whose parameters are negotiated on a case-by-case basis. The whose parameters are negotiated on a case-by-case basis. The
Security Policy Database (SPD) specifies the services that are to be Security Policy Database (SPD) specifies the services that are to be
offered to IP datagrams, and the parameters associated with SAs that offered to IP datagrams, and the parameters associated with SAs that
have been established are stored in the Security Association Database have been established are stored in the Security Association Database
(SAD). To integrate ROHC and IPsec, various extensions to the SPD (SAD). For ROHCoIPsec, various extensions to the SPD and SAD that
and SAD that incorporate ROHC-relevant parameters are required. incorporate ROHC-relevant parameters are required.
In addition, three extensions to IPsec processing are required. In addition, three extensions to IPsec processing are required.
First, a mechanism for identifying ROHC packets must be defined. First, a mechanism for identifying ROHC packets must be defined.
Second, a mechanism is required to ensure the integrity of the Second, a mechanism to ensure the integrity of the decompressed
decompressed packet. Finally, the order of the inbound and outbound packet is needed. Finally, the order of the inbound and outbound
processing must be enumerated when nesting IP Compression (IPComp processing must be enumerated when nesting IP Compression (IPComp
[IPCOMP]), ROHC, and IPsec processing. [IPCOMP]), ROHC, and IPsec processing.
2. Extensions to IPsec Databases 2. Extensions to IPsec Databases
The following subsections specify extensions to the SPD and the SAD The following subsections specify extensions to the SPD and the SAD
to support ROHCoIPsec. to support ROHCoIPsec.
2.1. Security Policy Database (SPD) 2.1. Security Policy Database (SPD)
In general, the SPD is responsible for specifying the security In general, the SPD is responsible for specifying the security
services that are offered to IP datagrams. Entries in the SPD services that are offered to IP datagrams. Entries in the SPD
specify how to derive the corresponding values for SAD entries. To specify how to derive the corresponding values for SAD entries. To
support ROHC, the SPD must be extended to include per-channel ROHC support ROHC, the SPD must be extended to include per-channel ROHC
parameters. Together, the existing IPsec SPD parameters and the ROHC parameters. Together, the existing IPsec SPD parameters and the ROHC
parameters will dictate the services that are provided to packets parameters will dictate the security and header compression services
protected by IPsec. that are provided to packets.
The fields contained within each SPD entry are defined in [IPSEC], The fields contained within each SPD entry are defined in [IPSEC],
Section 4.4.1.2. To support ROHC, several processing info fields Section 4.4.1.2. To support ROHC, several processing info fields
must be added to the SPD; these fields contain information regarding must be added to the SPD; these fields contain information regarding
the ROHC profiles and channel parameters supported by the local ROHC the ROHC profiles and channel parameters supported by the local ROHC
instance. instance.
The SPD specifies what services are to be offered to IP datagrams, The following ROHC channel parameters must be included if the
and in what fashion. To offer IP datagrams compression services, two
per-channel configuration parameters are added to the SPD.
Specifically, the following two parameters must be included if the
processing info field in the SPD is set to PROTECT (suggested values processing info field in the SPD is set to PROTECT (suggested values
for these parameters are consistent with [ROHCPPP]): for these parameters are consistent with [ROHCPPP]):
MAX_CID: The highest context ID number to be used by the MAX_CID: The field indicates the highest context ID that will be
compressor. MAX_CID must be at least 0 and at most 16383 (The decompressed by the local decompressor. MAX_CID must be at least
value 0 implies having one context). The suggested value for 0 and at most 16383 (The value 0 implies having one context). The
MAX_CID is 15. suggested value for MAX_CID is 15.
PROFILES: This indicates the ROHC profiles supported by the PROFILES: This field is a list of ROHC profiles supported by the
decompressor. The list of possible values this field may assume local decompressor. Possible values for this list are contained
is defined in the [ROHCPROF] registry. in the [ROHCPROF] registry.
In addition to these ROHC channel parameters, a field within the SPD In addition to these ROHC channel parameters, a field within the SPD
is required to store a list of integrity algorithms supported by the is required to store a list of integrity algorithms supported by the
ROHCoIPsec instance: ROHCoIPsec instance:
INTEGRITY ALGORITHM: a list of integrity algorithms supported by INTEGRITY ALGORITHM: This field is a list of integrity algorithms
the ROHCoIPsec instance. This will be used by the ROHC process to supported by the ROHCoIPsec instance. This will be used by the
ensure that packet headers are properly decompressed (see Section ROHC process to ensure that packet headers are properly
3.2). decompressed (see Section 3.2).
Several other ROHC channel parameters are omitted from the SPD, Several other ROHC channel parameters are omitted from the SPD,
because they are set implicitly. The ROHC channel parameters are because they are set implicitly. The omitted channel parameters are
LARGE_CIDS, MRRU, and FEEDBACK_FOR. The LARGE_CIDS channel parameter LARGE_CIDS, MRRU, and FEEDBACK_FOR. The LARGE_CIDS channel parameter
is set implicitly, based on the value of MAX_CID (e.g. if MAX_CID is is set implicitly, based on the value of MAX_CID (e.g. if MAX_CID is
<= 15, LARGE_CIDS is assumed to be 0). Furthermore, the MRRU <= 15, LARGE_CIDS is assumed to be 0). Furthermore, since in-order
parameter must be set to 0; since packets may be reordered across a delivery of ROHC packets cannot be guaranteed, the MRRU parameter
ROHCoIPsec channel, a compression session must not use segmentation. must be set to 0 (as stated in Section 5.2.5.1 of [ROHC] and Section
Finally, the ROHC FEEDBACK_FOR channel parameter is set implicitly to 6.1 of [ROHCV2]). Finally, the ROHC FEEDBACK_FOR channel parameter
the ROHC channel associated with the SA in the reverse direction. If is set implicitly to the ROHC channel associated with the SA in the
an SA in the reverse direction does not exist, ROHC must operate in reverse direction. If an SA in the reverse direction does not exist,
the Unidirectional Mode. the FEEDBACK_FOR channel parameter is not set, and ROHC must not
operate in bidirectional Mode.
2.2. Security Association Database (SAD) 2.2. Security Association Database (SAD)
Each entry within the SAD defines the parameters associated with each Each entry within the SAD defines the parameters associated with each
established SA. Unless if the "populate from packet" (PFP) flag is established SA. Unless the "populate from packet" (PFP) flag is
asserted for a particular field, SAD entries are determined by the asserted for a particular field, SAD entries are determined by the
corresponding SPD entries during the creation of the SA. corresponding SPD entries during the creation of the SA.
The data items contained within the SAD are defined in [IPSEC], The data items contained within the SAD are defined in [IPSEC],
Section 4.4.2.1. To support ROHC, this list of data items is Section 4.4.2.1. To support ROHC, this list of data items is
augmented to include a "ROHC Data Item" field that defines the ROHC augmented to include a "ROHC Data Item" that contains the parameters
parameters. These parameters (i.e., MAX_CID, PROFILES) are used by ROHC instance. The ROHC Data Item exists for both inbound
enumerated above in Section 2.1. In addition, the FEEDBACK_FOR and outbound SAs.
parameter is also included, which is associated with the SA in the
reverse direction (this data item does not need to be included in the
SPD, since its value is implicitly derived). Finally, two additional
parameters are required to store the Integrity Algorithm and
respective key that is to be used to ensure that packets are properly
decompressed (see Section 3.2).
These "ROHC Data Item" values may be initialized manually (i.e., The ROHC Data Item includes the ROHC channel parameters for the SA.
These channel parameters (i.e., MAX_CID, PROFILES) are enumerated
above in Section 2.1. For inbound SAs, the ROHC Data Item includes
ROHC channel parameters that are used by the local decompressor
instance; conversely, for outbound SAs, the ROHC Data Item includes
ROHC channel parameters that are used by local compressor instance.
In addition to these ROHC channel parameters, the ROHC Data Item for
both inbound and outbound SAs includes two additional parameters.
Specifically, these parameters store the integrity algorithm and
respective key used by ROHC (see Section 3.2). The integrity
algorithm and its associated key are used to calculate a ROHC ICV;
this ICV is used to verify the packet headers post-decompression.
Finally, for inbound SAs, the ROHC Data Item includes a FEEDBACK_FOR
parameter. The parameter is a reference to a ROHC channel in the
opposite direction (i.e., the outbound SA) between the same
compression endpoints. A ROHC channel associated with an inbound SA
and a ROHC channel associated with an outbound SA may be coupled to
form a Bi-directional ROHC channel as defined in Section 6.1 and
Section 6.2 in [ROHC-TERM].
"ROHC Data Item" values may be initialized manually (i.e.,
administratively configured for manual SAs), or initialized via a key administratively configured for manual SAs), or initialized via a key
exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to
support the negotiation of ROHC parameters [IKEV2EXT]. support the signaling of ROHC parameters [IKEV2EXT].
3. Extensions to IPsec Processing 3. Extensions to IPsec Processing
3.1. Addition to the IANA Protocol Numbers Registry 3.1. Addition to the IANA Protocol Numbers Registry
In order to demultiplex header-compressed from uncompressed traffic In order to demultiplex header-compressed from uncompressed traffic
on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA
Protocol Numbers registry. If an outbound packet has a compressed Protocol Numbers registry. If an outbound packet has a compressed
header, the Next Header field of the security protocol header (e.g., header, the Next Header field of the security protocol header (e.g.,
AH [AH], ESP [ESP]) must be set to the "ROHC" protocol identifier. AH [AH], ESP [ESP]) must be set to the "ROHC" protocol identifier.
If the packet header has not been compressed, the Next Header field If the packet header has not been compressed, the Next Header field
remains unaltered. Conversely, for an inbound packet, the value of remains unaltered. Conversely, for an inbound packet, the value of
the security protocol Next Header field is checked to determine if the security protocol Next Header field is checked to determine if
the packet includes a ROHC header. the packet includes a ROHC header, in order to determine if it
requires ROHC decompression.
3.2. Verifying the Integrity of Decompressed Packet Headers 3.2. Verifying the Integrity of Decompressed Packet Headers
Since ROHC is inherently a lossy algorithm, ROHCoIPsec may use an Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec
additional Integrity Algorithm (and respective key) to compute a may use an additional Integrity Algorithm (and respective key) to
second Integrity Check Value (ICV) for the uncompressed packet. This compute a second Integrity Check Value (ICV) for the uncompressed
ICV is computed over the uncompressed IP header, as well at the packet. This ICV is computed over the uncompressed IP header, as
higher-layer headers and the packet payload, and is appended to the well at the higher-layer headers and the packet payload, and is
ROHC-compressed packet. At the decompressor, the decompressed packet appended to the ROHC-compressed packet. At the decompressor, the
(including the uncompressed IP header, higher-layer headers, and decompressed packet (including the uncompressed IP header, higher-
packet payload; but not including the authentication data) will be layer headers, and packet payload; but not including the
used with the Integrity Algorithm (and its respective key) to compute authentication data) will be used with the integrity algorithm (and
a value that will be compared to the ICV. If these values are not its respective key) to compute a value that will be compared to the
identical, the decompressed packet must be dropped by the appended ICV. If these values are not identical, the decompressed
decompressor. packet must be dropped by the decompressor.
Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4 Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4
packet. In the example, TCP/IP compression is applied, and the packet. In the example, TCP/IP compression is applied, and the
packet is processed with tunnel mode ESP. packet is processed with tunnel mode ESP.
BEFORE COMPRESSION AND APPLICATION OF ESP BEFORE COMPRESSION AND APPLICATION OF ESP
---------------------------- ----------------------------
IPv4 |orig IP hdr | | | IPv4 |orig IP hdr | | |
|(any options)| TCP | Data | |(any options)| TCP | Data |
---------------------------- ----------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------ ------------------------------------------------------
IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP| IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV| |(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------ ------------------------------------------------------
Figure 1. Example of a ROHCoIPsec-processed packet. Figure 1. Example of a ROHCoIPsec-processed packet.
Note: The authentication data should never be included in the Note: The authentication data must not be included in the calculation
calculation of the ICV. of the ICV.
3.2.1. ICV Computation and Integrity Verification 3.2.1. ICV Computation and Integrity Verification
In order to correctly verify the integrity of the decompressed In order to correctly verify the integrity of the decompressed
packets, the processing steps for ROHCoIPsec must be implemented in a packets, the processing steps for ROHCoIPsec must be implemented in a
specific order, as given below. specific order, as given below.
For outbound packets that are to be processed by ROHC: For outbound packets that are to be processed by ROHC:
o An ICV is computed for the uncompressed packet via ROHCoIPsec's o An ICV is computed for the uncompressed packet via ROHCoIPsec's
Integrity Algorithm (and respective key) Integrity Algorithm (and respective key)
o The packet header(s) is(are) compressed by the ROHC process o The packet header(s) is(are) compressed by the ROHC process
o The ICV is appended to the end of the compressed packet o The ICV is appended to the end of the compressed packet
o The security protocol is applied to the packet o The security protocol is applied to the packet
For inbound packets that are to be decompressed by ROHC: For inbound packets that are to be decompressed by ROHC:
o A packet received on a ROHC-enabled SA is IPsec-processed o A packet received on a ROHC-enabled SA is IPsec-processed
o The packet header(s) is(are) decompressed by the ROHC process o Packet header(s) is(are) decompressed by the ROHC process
o The decompressed packet is used with the Integrity Algorithm (and o The decompressed packet is used with the integrity algorithm (and
its respective key) to compute a value that is compared to the ICV its respective key) to compute a ROHC ICV that is compared to the
(if these two values differ, the packet is dropped) appended ICV (if these two values differ, the packet is dropped)
3.3. Nested IPComp and ROHCoIPsec Processing 3.3. Nested IPComp and ROHCoIPsec Processing
IPComp ([IPCOMP]) is another mechanism that can be implemented to IPComp ([IPCOMP]) is another mechanism that can be implemented to
reduce the size of an IP datagram. If IPComp and ROHCoIPsec are reduce the size of an IP datagram. If IPComp and ROHCoIPsec are
implemented in a nested fashion, the order of the outbound and implemented in a nested fashion, the following steps must be followed
inbound processing steps must be carefully enumerated. for outbound and inbound packets.
For outbound packets that are to be processed by IPcomp and ROHC: For outbound packets that are to be processed by IPcomp and ROHC:
o The ICV is computed for the uncompressed packet, and the o The ICV is computed for the uncompressed packet, and the
appropriate ROHC compression profile is applied to the packet appropriate ROHC compression profile is applied to the packet
o IPComp is applied, and the packet is sent to the IPsec process o IPComp is applied, and the packet is sent to the IPsec process
o The security protocol is applied to the packet o The security protocol is applied to the packet
Conversely, for inbound packets that are to be both ROHC- and IPcomp- Conversely, for inbound packets that are to be both ROHC- and IPcomp-
decompressed: decompressed:
o A packet received on a ROHC-enabled SA is IPsec-processed o A packet received on a ROHC-enabled SA is IPsec-processed
o The datagram is decompressed based on the appropriate IPComp o The datagram is decompressed based on the appropriate IPComp
algorithm algorithm
skipping to change at page 7, line 25 skipping to change at page 7, line 37
o The packet is sent to the ROHC module for header decompression and o The packet is sent to the ROHC module for header decompression and
integrity verification integrity verification
4. Security Considerations 4. Security Considerations
A ROHCoIPsec implementer should consider the strength of protection A ROHCoIPsec implementer should consider the strength of protection
provided by the integrity check algorithm used to verify the valid provided by the integrity check algorithm used to verify the valid
decompression of ROHC-compressed packets. Failure to implement a decompression of ROHC-compressed packets. Failure to implement a
strong integrity check algorithm increases the probability of an strong integrity check algorithm increases the probability of an
invalidly decompressed packet to be forwarded by a ROHCoIPsec device invalidly decompressed packet to be forwarded by a ROHCoIPsec device
into a protected domain. In general, if an integrity check algorithm into a protected domain.
is used with IPsec, it is recommended that the integrity check
algorithm used by ROHC is at least the same strength.
The implementation of ROHCoIPsec may increase the susceptibility for The implementation of ROHCoIPsec may increase the susceptibility for
traffic flow analysis, where an attacker can identify new traffic traffic flow analysis, where an attacker can identify new traffic
flows by monitoring the relative size of the encrypted packets (i.e. flows by monitoring the relative size of the encrypted packets (i.e.
a group of "long" packets, followed by a long series of "short" a group of "long" packets, followed by a long series of "short"
packets may indicate a new flow for some ROHCoIPsec implementations). packets may indicate a new flow for some ROHCoIPsec implementations).
To mitigate this concern, ROHC padding mechanisms may be used to To mitigate this concern, ROHC padding mechanisms may be used to
arbitrarily add padding to transmitted packets to randomize packet arbitrarily add padding to transmitted packets to randomize packet
sizes. sizes. This technique, however, reduces the overall efficiency
benefit offered by header compression.
5. IANA Considerations 5. IANA Considerations
IANA is requested to allocate one value within the "Protocol Numbers" IANA is requested to allocate one value within the "Protocol Numbers"
registry [PROTOCOL] for "ROHC". This value will be used to indicate registry [PROTOCOL] for "ROHC". This value will be used to indicate
that the next level protocol header is a ROHC header. that the next level protocol header is a ROHC header.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of
OPnet for their contributions and support for developing this OPnet for their contributions and support for developing this
document. In addition, the authors would like to thank Mr. Rohan document.
Jasani for his valuable assistance. Finally, the authors would like
to thank the following for their numerous reviews and comments to The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A
this document: Stangarone Jr.: both served as committed document reviewers for this
specification.
Finally, the authors would like to thank the following for their
numerous reviews and comments to this document:
o Dr. Stephen Kent o Dr. Stephen Kent
o Mr. Lars-Erik Jonnson o Mr. Lars-Erik Jonsson
o Mr. Carl Knutsson
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Jonah Pezeshki
o Mr. Tero Kivinen o Mr. Tero Kivinen
o Dr. Joseph Touch o Dr. Joseph Touch
o Mr. Rohan Jasani
7. References 7. References
7.1. Normative References 7.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Header Compression (ROHC) Framework", RFC 4995, July 2007.
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Compression (ROHC): Framework and four profiles: RTP, UDP, Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
ESP, and uncompressed", RFC 3095, July 2001. UDP-Lite", RFC 5225.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001. Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCPPP] Bormann, C., "Robust Header Compression (ROHC) over PPP", [ROHCPPP] Bormann, C., "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002. RFC 3241, April 2002.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[IKEV2EXT] [IKEV2EXT]
Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to Ertekin, et al., "Extensions to IKEv2 to Support Robust
IKEv2 to Support Robust Header Compression over IPsec Header Compression over IPsec (ROHCoIPsec)", work in
(ROHCoIPsec)", work in progress , October 2008. progress , February 2009.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References 7.2. Informative References
[ROHCOIPSEC] [ROHCOIPSEC]
Ertekin, E. and C. Christou, "Integration of Header Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
Compression over IPsec Security Associations", work in "Integration of Header Compression over IPsec Security
progress , October 2008. Associations", work in progress , February 2009.
[ROHCPROF] [ROHCPROF]
"RObust Header Compression (ROHC) Profile Identifiers", "RObust Header Compression (ROHC) Profile Identifiers",
www.iana.org/assignments/rohc-pro-ids , October 2005. www.iana.org/assignments/rohc-pro-ids , October 2005.
[ROHC-TERM]
Jonsson, L-E., "Robust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
April 2004.
[PROTOCOL] [PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers". at: http://www.iana.org/assignments/protocol-numbers".
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
skipping to change at page 9, line 29 skipping to change at page 10, line 4
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
Chris Christou Chris Christou
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: christou_chris@bah.com Email: christou_chris@bah.com
Jonah Pezeshki
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: pezeshki_jonah@bah.com
Michele Casey
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: casey_michele@bah.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Email: cabo@tzi.org Email: cabo@tzi.org
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
 End of changes. 42 change blocks. 
120 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/