draft-ietf-rohc-ipsec-extensions-hcoipsec-07.txt   draft-ietf-rohc-ipsec-extensions-hcoipsec-08.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Intended status: Standards Track Booz Allen Hamilton Intended status: Standards Track Booz Allen Hamilton
Expires: August 6, 2010 C. Bormann Expires: August 19, 2010 C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
February 2, 2010 February 15, 2010
IPsec Extensions to Support Robust Header Compression over IPsec IPsec Extensions to Support Robust Header Compression over IPsec
draft-ietf-rohc-ipsec-extensions-hcoipsec-07 draft-ietf-rohc-ipsec-extensions-hcoipsec-08
Abstract Abstract
Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec)
offers the combined benefits of IP security services and efficient offers the combined benefits of IP security services and efficient
bandwidth utilization. However, in order to integrate ROHC with bandwidth utilization. However, in order to integrate ROHC with
IPsec, extensions to the SPD and SAD are required. This document IPsec, extensions to the SPD and SAD are required. This document
describes the IPsec extensions required to support ROHCoIPsec. describes the IPsec extensions required to support ROHCoIPsec.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 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 August 6, 2010. This Internet-Draft will expire on August 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 4 3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3
3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 5 3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 4
3.2. Security Association Database (SAD) . . . . . . . . . . . 6 3.2. Security Association Database (SAD) . . . . . . . . . . . 5
4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 7 4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 6
4.1. Identification of Header-Compressed Traffic . . . . . . . 7 4.1. Identification of Header-Compressed Traffic . . . . . . . 6
4.2. Verifying the Integrity of Decompressed Packet Headers . . 7 4.2. Verifying the Integrity of Decompressed Packet Headers . . 6
4.2.1. ICV Computation and Integrity Verification . . . . . . 8 4.2.1. ICV Computation and Integrity Verification . . . . . . 7
4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 9 4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 8
4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 10 4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 12 Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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. By compressing the packet headers, which increase packet overhead. By compressing the
inner headers of these packets, the integration of Robust Header inner headers of these packets, the integration of Robust Header
Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can
reduce the packet overhead associated with IPsec-protected flows. reduce the packet overhead associated with IPsec-protected flows.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
and send a PMTU ICMP message. and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation should fragment (before or bit clear. The implementation should fragment (before or
after encryption per its configuration) and then forward after encryption per its configuration) and then forward
the fragments. It should not send a PMTU ICMP message. the fragments. It should not send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation Case 3: Original (cleartext) packet is IPv6. The implementation
should discard the packet and send a PMTU ICMP message. should discard the packet and send a PMTU ICMP message.
For ROHCoIPsec, Cases 1 and 3, and the post-encryption fragmentation For the ROHCoIPsec processing model, there is one minor change to the
for Case 2 are employed. However, since current ROHC compression procedure stated above. This change applies to pre-encryption
profiles do not support the compression of IP packet fragments, pre- fragmentation for Case 2. Since current ROHC compression profiles do
encryption fragmentation is not compatible with the current set of not support compression of IP packet fragments, pre-encryption
ROHC profiles. In place of pre-encryption fragmentation, ROHC fragmentation MUST NOT occur before ROHC processing.
segmentation MAY be used at the compressor to divide the packet,
where each segment conforms to the tunnel MTU. However, because in-
order delivery of ROHC segments is not guaranteed, the use of ROHC
segmentation is not recommended.
If the compressor determines that the compressed packet exceeds the If the compressed packet exceeds the SA PMTU, and the MRRU is non-
tunnel MTU, ROHC segmentation MAY be applied to the compressed packet zero, ROHC segmentation MAY be used to divide the packet, where each
before AH or ESP processing. This determination can be made by segment conforms to the tunnel MTU. ROHC segmentation MUST occur
comparing the anticipated ROHCoIPsec packet size to the Path MTU data before AH or ESP processing. Because in-order delivery of ROHC
item specified in the SAD entry. If the MRRU for the channel is non- segments is not guaranteed, the use of ROHC segmentation is not
zero, the compressor applies ROHC segmentation. If segmentation is recommended.
applied, the process MUST account for the additional overhead imposed
by IPsec process (e.g., AH or ESP overhead, crypto synchronization If segmentation is applied, the process MUST account for the
data, the additional IP header, etc.) such that the final IPsec- additional overhead imposed by the IPsec process (e.g., AH or ESP
processed segments are less than the tunnel MTU. After segmentation, overhead, crypto synchronization data, the additional IP header,
each ROHC segment is consecutively processed by the appropriate etc.) such that the final IPsec-processed segments are less than the
security protocol (e.g., AH, ESP) instantiated on the ROHC-enabled tunnel MTU. After segmentation, each ROHC segment is consecutively
SA. Since ROHC segments are processed consecutively, the associated processed by the appropriate security protocol (e.g., AH, ESP)
AH/ESP sequence number MUST be incremented by one for each segment instantiated on the ROHC-enabled SA. Since ROHC segments are
transmitted over the ROHC channel. As such, after all ROHC segments processed consecutively, the associated AH/ESP sequence number MUST
receive AH/ESP processing, these segments can be identified (at the be incremented by one for each segment transmitted over the ROHC
remote IPsec implementation) by a range of contiguous AH/ESP sequence channel. As such, after all ROHC segments receive AH/ESP processing,
numbers. these segments can be identified (at the remote IPsec implementation)
by a range of contiguous AH/ESP sequence numbers.
For channels where the MRRU is non-zero, the ROHCoIPsec decompressor For channels where the MRRU is non-zero, the ROHCoIPsec decompressor
MUST re-assemble the ROHC segments that are received. To accomplish MUST re-assemble the ROHC segments that are received. To accomplish
this, the decompressor MUST identify the ROHC segments (as documented this, the decompressor MUST identify the ROHC segments (as documented
in Section 5.2.6 of RFC 4995 [ROHC]), and attempt reconstruction in Section 5.2.6 of RFC 4995 [ROHC]), and attempt reconstruction
using the ROHC segmentation protocol (Section 5.2.5 of RFC 4995 using the ROHC segmentation protocol (Section 5.2.5 of RFC 4995
[ROHC]). To assist the reconstruction process, the AH/ESP sequence [ROHC]). To assist the reconstruction process, the AH/ESP sequence
number SHOULD be used to identify segments that may have been subject number SHOULD be used to identify segments that may have been subject
to reordering. If reconstruction fails, the packet MUST be to reordering. If reconstruction fails, the packet MUST be
discarded. discarded.
 End of changes. 7 change blocks. 
50 lines changed or deleted 47 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/