draft-ietf-rohc-ipsec-extensions-hcoipsec-01.txt   draft-ietf-rohc-ipsec-extensions-hcoipsec-02.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft M. Casey Internet-Draft J. Pezeshki
Expires: July 3, 2008 J. Pezeshki Expires: February 16, 2009 M. Casey
C. Christou C. Christou
Booz Allen Hamilton Booz Allen Hamilton
December 31, 2007 C. Bormann
Universitaet Bremen TZI
August 15, 2008
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-01 draft-ietf-rohc-ipsec-extensions-hcoipsec-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 39
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 July 3, 2008. This Internet-Draft will expire on February 16, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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. Before of IP security services and efficient bandwidth utilization.
this can be realized, however, several extensions to the Security However, extensions to the SPD and SAD are required in order to
Policy Database (SPD), the Security Association Database (SAD), and integrate RoHC with IPsec. This document describes the IPsec
the IPsec process are required. This document describes the IPsec
extensions required to support RoHCoIPsec. extensions 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 . . . . . . 5 3.2.1. ICV Computation and Integrity Verification . . . . . . 6
3.3. Nested IPComp and RoHCoIPsec Processing . . . . . . . . . 6 3.3. Nested IPComp and RoHCoIPsec Processing . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 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, for tunnel-mode security associations, these IP traffic. However, these benefits come at the cost of additional
benefits come at the cost of additional packet headers, which packet headers, which increase packet overhead. As described in
increase packet overhead. As described in [ROHCOIPSEC], Robust [ROHCOIPSEC], Robust Header Compression (RoHC [ROHC]) can be used
Header Compression (RoHC [ROHC]) can be used with IPsec to reduce the with IPsec to reduce the overhead associated with IPsec-protected
overhead associated with IPsec-protected packets. packets.
IPsec-protected traffic is carried between peers by Security IPsec-protected traffic is carried over Security Associations (SAs),
Associations (SAs), whose parameters are negotiated on a case-by-case whose parameters are negotiated on a case-by-case basis. The
basis. The Security Policy Database (SPD) specifies the services Security Policy Database (SPD) specifies the services that are to be
that are to be offered to IP datagrams, and the parameters associated offered to IP datagrams, and the parameters associated with SAs that
with SAs that have been established are stored in the Security have been established are stored in the Security Association Database
Association Database (SAD). To fully integrate RoHC and IPsec, (SAD). To integrate RoHC and IPsec, various extensions to the SPD
various extensions to the SPD and SAD that incorporate RoHC-relevant and SAD that incorporate RoHC-relevant parameters are required.
parameters are required.
In addition, three extensions to the IPsec processing methodology are In addition, three extensions to IPsec processing are required.
required. First, a mechanism for identifying RoHC packets must be First, a mechanism for identifying RoHC packets must be defined.
defined. Second, a mechanism is required to ensure the integrity of Second, a mechanism is required to ensure the integrity of the
the decompressed packet. Finally, the order of the inbound and decompressed packet. Finally, the order of the inbound and outbound
outbound processing must be enumerated when nesting IP Compression processing must be enumerated when nesting IP Compression (IPComp
(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 packet disposition for traffic that is to be parameters will dictate the services that are provided to packets
compressed, and subsequently protected by IPsec. protected by IPsec.
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. In addition, a field within the SPD entry is required to instance.
store a list of integrity algorithms, supported by the RoHCoIPsec
instance. This field will be used to negotiate an integrity
algorithm to ensure that packet headers are properly decompressed
(see Section 3.2).
The per-channel configuration parameters required for RoHC in the SPD The SPD specifies what services are to be offered to IP datagrams,
are as follows (note that this information must only be included in and in what fashion. To offer IP datagrams compression services, the
the SPD if the processing info field is set to PROTECT, and if the per-channel configuration parameters, defined in [ROHC], are added to
IPsec mode is set to tunnel mode): the SPD. Specifically, the following parameters must be included if
the processing info field in the SPD is set to PROTECT (suggested
values for these parameters are consistent with [ROHCPPP]):
MAX_CID: The highest context ID number to be used by the MAX_CID: The highest context ID number to be used by the
compressor. MAX_CID must be at least 0 and at most 16383 (The compressor. MAX_CID must be at least 0 and at most 16383 (The
value 0 implies having one context). The suggested value for value 0 implies having one context). The suggested value for
MAX_CID is 15. MAX_CID is 15.
PROFILES: This indicates the RoHC profiles supported by the PROFILES: This indicates the RoHC profiles supported by the
decompressor. The list of possible values this field may assume decompressor. The list of possible values this field may assume
is defined in the [ROHCPROF] registry. is defined in the [ROHCPROF] registry.
MRRU: The size of the largest reconstructed unit that the MRRU: The size of the largest reconstructed unit that the
decompressor is expected to reassemble from segments. In general, decompressor is expected to reassemble from segments. In general,
is not anticipated that a RoHC over IPsec instance will use RoHC it is not anticipated that a RoHCoIPsec instance will use RoHC
segmentation features. Consequently, the suggested value for MRRU segmentation. Consequently, the suggested value for MRRU is 0.
is 0.
MAX_HEADER: The largest header size (in octets) that can be MAX_HEADER: The largest header size (in octets) that can be
compressed. Note that the four RoHC profiles defined in RFC 3095 compressed. Note that the four RoHC profiles defined in RFC 3095
do not provide for a MAX_HEADER parameter. The parameter do not provide for a MAX_HEADER parameter. The parameter
MAX_HEADER is therefore without consequence in these profiles. MAX_HEADER is therefore without consequence in these profiles.
Other profiles (e.g., ones based on RFC 2507) can make use of the Other profiles (e.g., ones based on RFC 2507) can make use of the
parameter by explicitly referencing it. parameter by explicitly referencing it.
Note: The RoHC LARGE_CIDS channel parameter is set implicitly, based Note: The RoHC LARGE_CIDS channel parameter is set implicitly, based
on the value of MAX_CID. Furthermore, the RoHC FEEDBACK_FOR channel on the value of MAX_CID. Furthermore, if a SA in the reverse
parameter is set implicitly to the RoHC channel associated with the direction exists, the RoHC FEEDBACK_FOR channel parameter is set
SA in the reverse direction. Because both of these RoHC channel implicitly to the RoHC channel associated with the SA in the reverse
parameters are set implicitly, they are not stored in the SPD. direction. If a SA in the reverse direction does not exist, RoHC
must operate in the Unidirectional Mode. Because both of these RoHC
channel parameters are set implicitly, they are not stored in the
SPD.
In addition to these RoHC channel parameters, a field within the SPD
entry is required to store a list of integrity algorithms supported
by the RoHCoIPsec instance. This integrity algorithm will be used by
the RoHC process to ensure that packet headers are properly
decompressed (see Section 3.2).
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 if 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" field that defines the RoHC
parameters. These parameters (i.e., MAX_CID, PROFILES, MRRU, and parameters. These parameters (i.e., MAX_CID, PROFILES, MRRU, and
MAX_HEADER) are enumerated above in Section 2.1. In addition, the MAX_HEADER) are enumerated above in Section 2.1. In addition, the
FEEDBACK_FOR parameter is also included, which is associated with the FEEDBACK_FOR parameter is also included, which is associated with the
SA in the reverse direction. Furthermore, two additional datas items SA in the reverse direction (this data item does not need to be
are required to store the Integrity Algorithm and respective key that included in the SPD, since its value is implicitly derived).
is to be used to ensure that packets are properly decompressed (see Finally, two additional data items are required to store the
Section 3.2). These "RoHC Data Item" values may be initialized Integrity Algorithm and respective key that is to be used to ensure
manually (i.e., administratively configured for manual SAs), or that packets are properly decompressed (see Section 3.2).
initialized via a key exchange protocol (e.g. IKEv2 [IKEV2]) that
has been extended to support the negotiation of RoHC parameters These "RoHC Data Item" values may be initialized manually (i.e.,
[IKEV2EXT]. administratively configured for manual SAs), or initialized via a key
exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to
support the negotiation 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 identifer. If AH [AH], ESP [ESP]) must be set to the "RoHC" protocol identifer. If
the packet header has not been compressed, the Next Header field 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 maintains a RoHC header. the packet includes a RoHC header.
3.2. Verifying the Integrity of Decompressed Packet Headers 3.2. Verifying the Integrity of Decompressed Packet Headers
In order to ensure that the RoHC compressed packet is decompressed Since RoHC is inherently a lossy algorithm, RoHCoIPsec will use an
correctly, RoHCoIPsec will use an Integrity Algorithm (and respective additional Integrity Algorithm (and respective key) to compute a
key) to compute a second Integrity Check Value (ICV) for the second Integrity Check Value (ICV) for the uncompressed packet.
uncompressed packet. This ICV will be prepended to the header- Specifically, this ICV will be computed for the uncompressed IP
compressed RoHC-compressed packet. At the decompresser, the header, as well at the higher-layer headers and the packet payload.
decompressed packet will be used with the Integrity Algorithm (and This ICV will be appended to the RoHC-compressed packet. At the
its respective key) to compute a value that will be compared to the decompressor, the decompressed packet (including the uncompressed IP
ICV. If these values are not identical, the decompressed packet must header, higher-layer headers, and packet payload; but not including
be dropped by the decompressor. the authentication data) will be used with the Integrity Algorithm
(and its respective key) to compute a value that will be compared to
the ICV. If these values are not identical, the decompressed packet
must be dropped by the decompressor.
Figure 1 illustrates the composition of a RoHCoIPsec-processed IPv4
packet. In the example, TCP/IP compression is applied, and the
packet is processed with tunnel mode ESP.
BEFORE COMPRESSION AND APPLICATION OF ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------
IPv4 | new IP hdr | | Cmpr | | RoHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------
Figure 1. Example of a RoHCoIPsec-processed packet.
Note: The authentication data should never be included in the
calculation 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 is compressed by the RoHC process o The packet is compressed by the RoHC process
o The ICV is prepended to the beginning of the compressed packet (in o The ICV is appended to the end of the compressed packet
front of the RoHC header)
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 is decompressed by the RoHC process o The packet is 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 value that is compared to the ICV
(if these two values differ, the packet is dropped) (if these two values differ, the packet is dropped)
3.3. Nested IPComp and RoHCoIPsec Processing 3.3. Nested IPComp and RoHCoIPsec Processing
skipping to change at page 6, line 39 skipping to change at page 7, line 21
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
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 malfunctioning RoHC compressor (i.e., the compressor located at the A RoHCoIPsec implementer should consider the strength of protection
ingress of the IPsec tunnel) has the ability to send packets to the provided by the integrity check algorithm used to verify the valid
decompressor (i.e., the decompressor located at the egress of the decompression of RoHC-compressed packets. Failure to implement a
IPsec tunnel) that do not match the original packets emitted from the strong integrity check algorithm increases the probability of an
end-hosts. Such a scenario will result in a decreased efficiency invalidly decompressed packet to be forwarded by a RoHCoIPsec device
between compressor and decompressor. Furthermore, this may result in into a protected domain. In general, if an integrity check algorithm
Denial of Service, as the decompression of a significant number of is used with IPsec, it is recommended that the integrity check
invalid packets may drain the resources of an IPsec device. algorithm used by RoHC is at least the same strength.
In addition, some RoHCoIPsec implementations may allow an attacker to The implementation of RoHCoIPsec may increase the susceptibility for
identify new traffic flows by monitoring the relative size of the traffic flow analysis, where an attacker can identify new traffic
encrypted packets (i.e. a group of "long" packets, followed by a long flows by monitoring the relative size of the encrypted packets (i.e.
series of "short" packets may indicate a new flow for some RoHCoIPsec a group of "long" packets, followed by a long series of "short"
implementations). To mitigate this concern, RoHC padding mechanisms packets may indicate a new flow for some RoHCoIPsec implementations).
may be used to arbitrarily add padding to transmitted packets to To mitigate this concern, RoHC padding mechanisms may be used to
randomize packet sizes. arbitrarily add padding to transmitted packets to randomize packet
sizes.
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,
skipping to change at page 7, line 29 skipping to change at page 8, line 13
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. In addition, the authors would like to thank Mr. Rohan
Jasani for his valuable assistance. Finally, the authors would like Jasani for his valuable assistance. Finally, the authors would like
to thank the following for their numerous reviews and comments to to thank the following for their numerous reviews and comments to
this document: this document:
o Dr. Stephen Kent o Dr. Stephen Kent
o Dr. Carsten Bormann o Dr. Carsten Bormann
o Mr. Lars-Erik Jonnson o Mr. Lars-Erik Jonnson
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Joseph Touch
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.
[ROHCOIPSEC]
Ertekin, E. and C. Christou, "Integration of Header
Compression over IPsec Security Associations", work in
progress , February 2007.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[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",
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 Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to
IKEv2 to Support Robust Header Compression over IPsec IKEv2 to Support Robust Header Compression over IPsec
(RoHCoIPsec)", work in progress , February 2007. (RoHCoIPsec)", work in progress , August 2008.
[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]
Ertekin, E. and C. Christou, "Integration of Header
Compression over IPsec Security Associations", work in
progress , August 2008.
[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.
[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
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
Michele Casey Jonah Pezeshki
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: casey_michele@bah.com Email: pezeshki_jonah@bah.com
Jonah Pezeshki
Michele Casey
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: pezeshki_jonah@bah.com Email: casey_michele@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
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Email: cabo@tzi.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 10, line 44 skipping to change at line 442
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 33 change blocks. 
104 lines changed or deleted 144 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/