[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-rohc-ipsec-extensions-hcoipsec

Network Working Group                                         E. Ertekin
Internet-Draft                                                  M. Casey
Expires: August 30, 2007                                     J. Pezeshki
                                                             C. Christou
                                                     Booz Allen Hamilton
                                                       February 26, 2007

  IPsec Extensions to Support Header Compression over IPsec (HCoIPsec)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   Integrating Header Compression with IPsec (HCoIPsec) offers the
   combined benefits of IP security services and efficient bandwidth
   utilization.  Before this can be realized, however, several
   extensions to the Security Policy Database (SPD), the Security
   Association Database (SAD), and the IPsec process are required.  This
   document describes the IPsec extensions required to enable HCoIPsec.

Ertekin, et al.          Expires August 30, 2007                [Page 1]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Extensions to IPsec Databases . . . . . . . . . . . . . . . . . 3
     2.1.  Security Policy Database (SPD)  . . . . . . . . . . . . . . 3
     2.2.  Security Association Database (SAD) . . . . . . . . . . . . 4
   3.  Extensions to IPsec Processing  . . . . . . . . . . . . . . . . 5
     3.1.  Addition to the IANA Protocol Numbers Registry  . . . . . . 5
     3.2.  Nested IPComp and HCoIPsec Processing . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Ertekin, et al.          Expires August 30, 2007                [Page 2]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

1.  Introduction

   Using IPsec ([IPSEC]) protection offers various security services for
   IP traffic.  However, for tunnel-mode security associations, these
   benefits come at the cost of additional packet headers, which
   increase packet overhead.  As described in [HCOIPSEC], Header
   Compression (HC) algorithms can be used with IPsec to reduce the
   overhead associated with IPsec-protected packets.

   IPsec-protected traffic is carried between peers by Security
   Associations (SAs), whose parameters are negotiated on a case-by-case
   basis.  The Security Policy Database (SPD) specifies the services
   that are to be offered to IP datagrams, and the parameters associated
   with SAs that have been established are stored in the Security
   Association Database (SAD).  To fully integrate HC and IPsec, various
   extensions to the SPD and SAD that incorporate HC-relevant parameters
   are required.

   In addition, two extensions to the IPsec processing methodology are
   required.  First, a mechanism for differentiating HC packets from
   non-HC packets must be defined.  Second, the order of the inbound and
   outbound processing must be enumerated when nesting IP Compression
   (IPComp [IPCOMP]), HC, and IPsec processing.

2.  Extensions to IPsec Databases

   The following subsections specify extensions to the SPD and the SAD
   to support HCoIPsec.  We assume that Robust Header Compression (ROHC
   [ROHC]) is used as the HC protocol.

2.1.  Security Policy Database (SPD)

   In general, the SPD is responsible for specifying the security
   services that are offered to IP datagrams.  Entries in the SPD
   specify how to derive the corresponding values for SAD entries.  To
   support HC, the SPD must be extended to include per-channel HC
   parameters.  Together, the existing IPsec SPD parameters and the HC
   parameters will dictate packet disposition for traffic that is to be
   compressed, and subsequently protected by IPsec.

   The fields contained within each SPD entry are defined in [IPSEC],
   section  To support ROHC, several processing info fields
   must be added to the SPD; these fields contain information regarding
   the ROHC profiles and channel parameters supported by the local ROHC
   instance.  The per-channel configuration parameters required for ROHC
   in the SPD are as follows (note that this information must only be
   included in the SPD if the processing info field is set to PROTECT,

Ertekin, et al.          Expires August 30, 2007                [Page 3]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

   and if the IPsec mode is set to tunnel mode):

      MAX_CID: highest context ID number to be used by the compressor.
      MAX_CID must be at least 0 and at most 16383 (The value 0 implies
      having one context).  The suggested value for MAX_CID is 15.

      PROFILES: indicates the ROHC profiles supported by the
      decompressor.  The list of possible values this field may assume
      is defined in the [ROHCPROF] registry.

      MRRU: the size of the largest reconstructed unit that the
      decompressor is expected to reassemble from segments.  In general,
      is not anticipated that a ROHC over IPsec instance will use ROHC
      segmentation features.  Consequently, the suggested value for MRRU
      is 0.

      MAX_HEADER: the largest header size (in octets) that can be
      compressed.  Note that the four ROHC profiles defined in RFC 3095
      do not provide for a MAX_HEADER parameter.  The parameter
      MAX_HEADER is therefore without consequence in these profiles.
      Other profiles (e.g., ones based on RFC 2507) can make use of the
      parameter by explicitly referencing it.

   Note: The ROHC LARGE_CIDS channel parameter is set implicitly based
   on the value of MAX_CID after the SA is established.  Furthermore,
   the ROHC FEEDBACK_FOR channel parameter is set implicitly to the ROHC
   channel associated with the SA in the reverse direction.  Because
   both of these ROHC channel parameters are set implicitly, they are
   not stored in the SPD or SAD.

2.2.  Security Association Database (SAD)

   Each entry within the SAD defines the parameters associated with each
   established SA.  These entries are primarily determined by the
   corresponding SPD entries during the creation of the SA.  An
   exception to this occurs when a "populate from packet" (PFP) flag is
   asserted for a particular field; the flag indicates that the SA
   should take its value for that particular field from the packet

   The data items that are contained in the SAD are defined in [IPSEC],
   Section  To support ROHC, this list of data items is
   augmented to include a "ROHC Data Item" field that defines the ROHC
   parameters.  These parameters (i.e., MAX_CID, PROFILES, MRRU, and
   MAX_HEADER) are enumerated above in Section 2.1.  The ROHC parameters
   used for a given SA are usually initialized via a key exchange
   protocol (e.g.  IKEv2 [IKEV2]) that has been extended to support the
   negotiation of ROHC parameters [IKEV2EXT].

Ertekin, et al.          Expires August 30, 2007                [Page 4]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

3.  Extensions to IPsec Processing

3.1.  Addition to the IANA Protocol Numbers Registry

   In order to demultiplex header-compressed from uncompressed traffic
   on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA
   Protocol Numbers registry.  If an outbound packet has a compressed
   header, the Next Header field of the security protocol header (e.g.,
   AH [AH], ESP [ESP]) must be set to the "ROHC" value.  If the packet
   header has not been compressed, the Next Header field remains
   unaltered.  Conversely, for an inbound packet, the value of the
   security protocol Next Header field is checked to determine if its
   header is compressed or not.

3.2.  Nested IPComp and HCoIPsec Processing

   IPComp ([IPCOMP]) is another mechanism that can be implemented in
   conjunction to reduce the size of an IP datagram.  If IPComp and
   HCoIPsec are implemented in a nested fashion, however, the order of
   the outbound and inbound processing steps must be carefully

   For outbound packets that are to be processed by IPcomp and ROHC:
   o  IPComp is applied, and the packet is sent to ROHC module
   o  The appropriate ROHC compression profile (e.g., ROHC IP-only) 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-
   o  A packet from a ROHC-enabled SA is IPsec-processed
   o  Subsequently, the packet is sent to the ROHC module for header
   o  The datagram is decompressed based on the appropriate IPComp

4.  Security Considerations

   A malfunctioning header compressor (i.e., the compressor located at
   the ingress of the IPsec tunnel) has the ability to send packets to
   the decompressor (i.e., the decompressor located at the egress of the
   IPsec tunnel) that do not match the original packets emitted from the
   end-hosts.  Such a scenario will result in a decreased efficiency
   between compressor and decompressor.  Furthermore, this may result in
   Denial of Service, as the decompression of a significant number of
   invalid packets may drain the resources of an IPsec device.

Ertekin, et al.          Expires August 30, 2007                [Page 5]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

5.  IANA Considerations

   If this proposal is accepted, IANA will be requested to allocate one
   value within the "Protocol Numbers" registry [PROTOCOL], named
   "ROHC".  This value will be used to indicate that the next level
   protocol header is a ROHC header.

6.  Acknowledgments

   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
   OPnet for their contributions and support for developing this
   document.  In addition, the authors would like to thank Mr. Rohan
   Jasani for his valuable assistance.

7.  References

7.1.  Normative References

   [IPSEC]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

              Ertekin, E. and C. Christou, "Integration of Header
              Compression over IPsec Security Associations", work in
              progress , February 2007.

   [IPCOMP]   Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
              Compression Protocol (IPComp)", RFC 3173, September 2001.

   [ROHC]     Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
              Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [IKEV2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

              Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to
              IKEv2 to Support Header Compression over IPsec
              (HCoIPsec)", work in progress , February 2007.

   [AH]       Kent, S., "IP Authentication Header", RFC 4302,

Ertekin, et al.          Expires August 30, 2007                [Page 6]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

              December 2005.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

7.2.  Informative References

              "RObust Header Compression (ROHC) Profile Identifiers",
              www.iana.org/assignments/rohc-pro-ids , October 2005.

              IANA, ""Assigned Internet Protocol Numbers", IANA registry
              at: http://www.iana.org/assignments/protocol-numbers".

Authors' Addresses

   Emre Ertekin
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171

   Email: ertekin_emre@bah.com

   Michele Casey
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171

   Email: casey_michele@bah.com

   Jonah Pezeshki
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171

   Email: pezeshki_jonah@bah.com

Ertekin, et al.          Expires August 30, 2007                [Page 7]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

   Chris Christou
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171

   Email: christou_chris@bah.com

Ertekin, et al.          Expires August 30, 2007                [Page 8]

Internet-Draft    IPsec Extensions to Support HCoIPsec     February 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Ertekin, et al.          Expires August 30, 2007                [Page 9]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/