draft-ietf-rohc-ikev2-extensions-hcoipsec-04.txt   draft-ietf-rohc-ikev2-extensions-hcoipsec-05.txt 
Network Working Group J. Pezeshki Network Working Group J. Pezeshki
Internet-Draft E. Ertekin Internet-Draft E. Ertekin
Intended status: Experimental R. Jasani Intended status: Experimental R. Jasani
Expires: April 10, 2008 C. Christou Expires: July 3, 2008 C. Christou
Booz Allen Hamilton Booz Allen Hamilton
October 8, 2007 December 31, 2007
IKEv2 Extensions to Support Robust Header Compression over IPsec IKEv2 Extensions to Support Robust Header Compression over IPsec
(RoHCoIPsec) (RoHCoIPsec)
draft-ietf-rohc-ikev2-extensions-hcoipsec-04 draft-ietf-rohc-ikev2-extensions-hcoipsec-05
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 37
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 10, 2008. This Internet-Draft will expire on July 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
When using Robust Header Compression (RoHC [ROHC]) in conjunction When using Robust Header Compression (RoHC [ROHC]) in conjunction
with IPsec [IPSEC] (i.e. [RoHCOIPSEC]) a mechanism is needed to with IPsec [IPSEC] (i.e. [RoHCOIPSEC]) a mechanism is needed to
negotiate RoHC configuration parameters between end-points prior to negotiate RoHC configuration parameters between end-points prior to
skipping to change at page 2, line 15 skipping to change at page 2, line 15
RoHC and its associated configuration parameters to be negotiated for RoHC and its associated configuration parameters to be negotiated for
IPsec security associations (SAs). IPsec security associations (SAs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RoHC Channel Negotiation . . . . . . . . . . . . . . . . . . . 3 2. RoHC Channel Negotiation . . . . . . . . . . . . . . . . . . . 3
2.1. Negotiation of RoHC Channel Parameters . . . . . . . . . . 3 2.1. Negotiation of RoHC Channel Parameters . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
Increased packet header overhead due to IPsec protection can result Increased packet header overhead due to IPsec protection can result
in inefficient utilization of bandwidth. Coupling RoHC with IPsec in inefficient utilization of bandwidth. Coupling RoHC with IPsec
offers an efficient way to transfer protected IP traffic. offers an efficient way to transfer protected IP traffic.
For proper RoHCoIPsec [ROHCOIPSEC] operation, RoHC requires For proper RoHCoIPsec [ROHCOIPSEC] operation, RoHC requires
configuration parameters to be negotiated between the compressor and configuration parameters to be negotiated between the compressor and
skipping to change at page 5, line 10 skipping to change at page 5, line 10
RoHC configuration parameters will be communicated via a new Notify RoHC configuration parameters will be communicated via a new Notify
message type, denoted ROHC_SUPPORTED. The RoHC configuration message type, denoted ROHC_SUPPORTED. The RoHC configuration
parameters will be listed within the Notification Data field of the parameters will be listed within the Notification Data field of the
Notify payload, in the following format: Notify payload, in the following format:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAX_CID ! MRRU ! ! MAX_CID ! MRRU !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAX_HEADER ! ! ! MAX_HEADER ! PROFILE LENGTH !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ PROFILES... ~ ~ PROFILES... ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ INTEGRITY ALGORITHMS... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Notification Data field Figure 1: Notification Data field
MAX_CID (2 octets) MAX_CID (2 octets)
The MAX_CID field indicates the maximum value of a context The MAX_CID field indicates the maximum value of a context
identifier. This value must be at least 0 and at most 16383 (The identifier. This value must be at least 0 and at most 16383 (The
value 0 implies having one context). value 0 implies having one context).
Suggested value: 15 Suggested value: 15
skipping to change at page 5, line 47 skipping to change at page 6, line 4
protocol defined in RoHC. Since RoHCoIPsec will generally be protocol defined in RoHC. Since RoHCoIPsec will generally be
implemented across multiple link-layer "hops", segmentation will implemented across multiple link-layer "hops", segmentation will
not normally be required. In these cases the MRRU value will be not normally be required. In these cases the MRRU value will be
set to zero, indicating that no segment headers are allowed on the set to zero, indicating that no segment headers are allowed on the
channel. channel.
MAX_HEADER (2 octets) MAX_HEADER (2 octets)
The largest header size in octets that may be compressed. The largest header size in octets that may be compressed.
Suggested value: 168 octets Suggested value: 168 octets
Note: The MAX_HEADER parameter is not used for all RoHC profiles. Note: The MAX_HEADER parameter is not used for all RoHC profiles.
If none of the RoHC profiles require this field, this value is If none of the RoHC profiles require this field, this value is
ignored. ignored.
PROFILE LENGTH (2 octets)
The total number of profiles contained within the PROFILES field
(note that each RoHC profile is 2-octets in length).
PROFILES PROFILES
The set of profiles to be enabled for the RoHC process. Profiles The set of profiles to be enabled for the RoHC process. Profiles
are further detailed in [ROHC]. In addition, several common are further detailed in [ROHC]. In addition, several common
profiles are defined in [ROHCPROF]. These 16-bit profile profiles are defined in [ROHCPROF]. These 16-bit profile
identifiers are to be sent in network byte order. identifiers are to be sent in network byte order.
INTEGRITY ALGORITHMS
The set of Integrity Algorithms that may be use to ensure the
integrity of the decompressed packets (i.e. ensure that the
packets are properly decompressed). Each Integrity Algorithm is
represented by a 2-octet value that corresponds to the value
listed in [IKEV2-PARA] "For Transform Type 3 (Integrity
Algorithm)" section.
Note: The length of this field is inferred from the Notify
Payload's "Payload Length" field ([IKEV2], Section 3.10).
Note: The key for this Integrity Algorithm is computed using
the same method as is used to compute IPsec's Integrity
Algorithm key ([IKEV2], Section 2.17).
Note: When a pair of SAs are created (one in each direction), the Note: When a pair of SAs are created (one in each direction), the
RoHC channel parameter FEEDBACK_FOR is set implicitly to the other SA RoHC channel parameter FEEDBACK_FOR is set implicitly to the other SA
of the pair (i.e. the SA pointing in the reverse direction). of the pair (i.e. the SA pointing in the reverse direction).
3. Security Considerations 3. Security Considerations
The RoHC parameters negotiated via IKEv2 do not add any new The RoHC parameters negotiated via IKEv2 do not add any new
vulnerabilities beyond those associated with the normal operation of vulnerabilities beyond those associated with the normal operation of
IKEv2. IKEv2.
skipping to change at page 7, line 35 skipping to change at page 8, line 10
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.
[ROHCPROF] [ROHCPROF]
Pelletier, G. and K. Sandlund, "RObust Header Compression Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP
Lite", www.iana.org/assignments/ROHC-pro-ids , May 2007. Lite", www.iana.org/assignments/ROHC-pro-ids , May 2007.
[IKEV2PARA]
"IKEv2 Parameters",
http://www.iana.org/assignments/ikev2-parameters ,
November 2007.
Authors' Addresses Authors' Addresses
Jonah Pezeshki 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: pezeshki_jonah@bah.com Email: pezeshki_jonah@bah.com
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
Rohan Jasani Rohan Jasani
Booz Allen Hamilton Booz Allen Hamilton
 End of changes. 12 change blocks. 
10 lines changed or deleted 38 lines changed or added

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