draft-ietf-rohc-ipsec-extensions-hcoipsec-06.txt   draft-ietf-rohc-ipsec-extensions-hcoipsec-07.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: June 7, 2010 Booz Allen Hamilton Intended status: Standards Track Booz Allen Hamilton
C. Bormann Expires: August 6, 2010 C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
December 4, 2009 February 2, 2010
IPsec Extensions to Support Robust Header Compression over IPsec IPsec Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec) draft-ietf-rohc-ipsec-extensions-hcoipsec-07
draft-ietf-rohc-ipsec-extensions-hcoipsec-06
Abstract Abstract
Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec)
of IP security services and efficient bandwidth utilization. offers the combined benefits of IP security services and efficient
However, in order to integrate ROHC with IPsec, extensions to the SPD bandwidth utilization. However, in order to integrate ROHC with
and SAD are required. This document describes the IPsec extensions IPsec, extensions to the SPD and SAD are required. This document
required to support ROHCoIPsec. describes the IPsec extensions required to support ROHCoIPsec.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 43 skipping to change at page 1, line 42
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 June 7, 2010. This Internet-Draft will expire on August 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 4
3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3 3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 5
3.2. Security Association Database (SAD) . . . . . . . . . . . 5 3.2. Security Association Database (SAD) . . . . . . . . . . . 6
4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 6 4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 7
4.1. Addition to the IANA Protocol Numbers Registry . . . . . . 6 4.1. Identification of Header-Compressed Traffic . . . . . . . 7
4.2. Verifying the Integrity of Decompressed Packet Headers . . 6 4.2. Verifying the Integrity of Decompressed Packet Headers . . 7
4.2.1. ICV Computation and Integrity Verification . . . . . . 7 4.2.1. ICV Computation and Integrity Verification . . . . . . 8
4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 7 4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 9
4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9 4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 10 Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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. By compressing the
[ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used inner headers of these packets, the integration of Robust Header
with IPsec to reduce the overhead associated with IPsec-protected Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can
packets. reduce the packet overhead associated with IPsec-protected flows.
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). For ROHCoIPsec, various extensions to the SPD and SAD that (SAD). For ROHCoIPsec, various extensions to the SPD 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.
skipping to change at page 4, line 38 skipping to change at page 4, line 38
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [BRA97]. document are to be interpreted as described in RFC 2119 [BRA97].
3. Extensions to IPsec Databases 3. 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
that MUST be supported for ROHCoIPsec. Appendix A provides an that MUST be supported for ROHCoIPsec. The ROHCoIPsec fields in the
example ASN.1 representation of the ROHC parameters that are included SPD are used to populate the ROHCoIPsec parameters in the SAD during
in the SPD. the initialization or rekey of a child SA.
It is noted that these extensions do not have any implications on
existing SPD fields or SAD parameters. Therefore, a ROHCoIPsec
implementation is backwards-compatible with an IPsec implementation
that does not support header compression.
Appendix A provides an example ASN.1 representation of a SPD that is
extended to support ROHC.
3.1. Security Policy Database (SPD) 3.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 is extended to include per-channel ROHC support ROHC, the SPD is 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 security and header compression services parameters will dictate the security and header compression services
that are provided to packets. that are provided to packets.
skipping to change at page 7, line 7 skipping to change at page 7, line 16
coupled to form a Bi-directional ROHC channel as defined in Section coupled to form a Bi-directional ROHC channel as defined in Section
6.1 and Section 6.2 in RFC 3759 [ROHC-TERM]. 6.1 and Section 6.2 in RFC 3759 [ROHC-TERM].
"ROHC Data Item" values MAY be initialized manually (i.e., "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 signaling of ROHC parameters [IKEV2EXT]. support the signaling of ROHC parameters [IKEV2EXT].
4. Extensions to IPsec Processing 4. Extensions to IPsec Processing
4.1. Addition to the IANA Protocol Numbers Registry 4.1. Identification of Header-Compressed Traffic
In order to demultiplex header-compressed from uncompressed traffic A "ROHC" protocol identifier is used to identify header-compressed
on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA traffic on a ROHC-enabled SA. 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 by ROHC, the Next Header If the packet header has not been compressed by ROHC, the Next Header
field does not contain the "ROHC" protocol identifier. Conversely, field does not contain the "ROHC" protocol identifier. Conversely,
for an inbound packet, the value of the security protocol Next Header for an inbound packet, the value of the security protocol Next Header
field MUST be checked to determine if the packet includes a ROHC field MUST be checked to determine if the packet includes a ROHC
header, in order to determine if it requires ROHC decompression. header, in order to determine if it requires ROHC decompression.
Use of the "ROHC" protocol identifier for purposes other than Use of the "ROHC" protocol identifier for purposes other than
ROHCOIPsec is currently not defined. Future protocols that make use ROHCoIPsec is currently not defined. Future protocols that make use
of the allocation (e.g., other applications of ROHC in multi-hop of the allocation (e.g., other applications of ROHC in multi-hop
environments) require specification of the logical compression environments) require specification of the logical compression
channel between the ROHC compressor and decompressor. In addition, channel between the ROHC compressor and decompressor. In addition,
these specifications will require the investigation of the security these specifications will require the investigation of the security
considerations associated with use of the "ROHC" protocol identifier considerations associated with use of the "ROHC" protocol identifier
outside the context of the next-header field of security protocol outside the context of the next-header field of security protocol
headers. headers.
4.2. Verifying the Integrity of Decompressed Packet Headers 4.2. Verifying the Integrity of Decompressed Packet Headers
Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec As documented in Section 6.1.4 of [ROHCOIPSEC], ROHC is inherently a
MAY use an additional Integrity Algorithm (and respective key) to lossy compression algorithm: the consequences of significant packet
compute a second Integrity Check Value (ICV) for the uncompressed reordering or loss between ROHC peers may include undetected
packet. This ICV MUST be computed over the uncompressed IP header, decompression failures, where erroneous packets are forwarded into
as well at the higher-layer headers and the packet payload. When the protected domain.
To ensure that a decompressed header is identical to the original
header, ROHCoIPsec MAY use an additional Integrity Algorithm (and
respective key) to compute a second Integrity Check Value (ICV).
This ROHC ICV MUST be computed over the uncompressed IP header, as
well at the higher-layer headers and the packet payload. When
computed, the ICV is appended to the ROHC-compressed packet. At the computed, the ICV is appended to the ROHC-compressed packet. At the
decompressor, the decompressed packet (including the uncompressed IP decompressor, the decompressed packet (including the uncompressed IP
header, higher-layer headers, and packet payload; but not including header, higher-layer headers, and packet payload; but not including
the authentication data) will be used with the integrity algorithm the authentication data) will be used with the integrity algorithm
(and its respective key) to compute a value that will be compared to (and its respective key) to compute a value that will be compared to
the appended ICV. If these values are not identical, the the appended ICV. If these values are not identical, the
decompressed packet MUST be dropped. decompressed packet MUST be dropped.
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
skipping to change at page 11, line 41 skipping to change at page 12, line 14
o Mr. Magnus Westerlund o Mr. Magnus Westerlund
o Dr. Stephen Kent o Dr. Stephen Kent
o Mr. Lars-Erik Jonsson o Mr. Lars-Erik Jonsson
o Mr. Carl Knutsson o Mr. Carl Knutsson
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Jonah Pezeshki o Dr. Jonah Pezeshki
o Mr. Tero Kivinen o Mr. Tero Kivinen
o Dr. Joseph Touch o Dr. Joseph Touch
o Mr. Rohan Jasani o Mr. Rohan Jasani
o Mr. Elwyn Davies
o Mr. Bert Wijnen
Appendix A. ASN.1 representation for ROHCoIPsec Appendix A. ASN.1 representation for ROHCoIPsec
This appendix is included as an additional way to describe the This appendix is included as an additional way to describe the
ROHCoIPsec parameters that are included in the IPsec SPD. It uses ROHCoIPsec parameters that are included in the IPsec SPD. It uses
portions of the ASN.1 syntax provided in Appendix C of RFC 4301 portions of the ASN.1 syntax provided in Appendix C of RFC 4301
[IPSEC]. In addition, several new structures are defined. [IPSEC]. In addition, several new structures are defined.
This syntax has been successfully compiled. However, it is merely This syntax has been successfully compiled. However, it is merely
illustrative and need not be employed in an implementation to achieve illustrative and need not be employed in an implementation to achieve
skipping to change at page 14, line 16 skipping to change at page 14, line 35
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225. UDP-Lite", RFC 5225.
[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]
Ertekin, et al., "Extensions to IKEv2 to Support Robust Ertekin, et al., "IKEv2 Extensions to Support Robust
Header Compression over IPsec (ROHCoIPsec)", work in Header Compression over IPsec (ROHCoIPsec)", work in
progress , December 2009. progress , February 2010.
[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.
8.2. Informative References 8.2. Informative References
[ROHCOIPSEC] [ROHCOIPSEC]
Ertekin, E., Jasani, R., Christou, C., and C. Bormann, Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
"Integration of Header Compression over IPsec Security "Integration of Header Compression over IPsec Security
Associations", work in progress , December 2009. Associations", work in progress , February 2010.
[ROHCPROF] [ROHCPROF]
"RObust Header Compression (ROHC) Profile Identifiers", "RObust Header Compression (ROHC) Profile Identifiers",
www.iana.org/assignments/rohc-pro-ids , May 2008. www.iana.org/assignments/rohc-pro-ids , May 2008.
[CRYPTO-ALG] [CRYPTO-ALG]
Manral, V., "Cryptographic Algorithm Implementation Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
 End of changes. 17 change blocks. 
51 lines changed or deleted 65 lines changed or added

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