[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ertekin-rohc-ipsec-extensions-hcoipsec) 00 01 02 03 04 05 06 07 08 RFC 5858

Network Working Group                                         E. Ertekin
Internet-Draft                                               C. Christou
Expires: August 6, 2009                              Booz Allen Hamilton
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                        February 2, 2009


    IPsec Extensions to Support Robust Header Compression over IPsec
                              (ROHCoIPsec)
              draft-ietf-rohc-ipsec-extensions-hcoipsec-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 6, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.





Ertekin, et al.          Expires August 6, 2009                 [Page 1]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


Abstract

   Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits
   of IP security services and efficient bandwidth utilization.
   However, in order to integrate ROHC with IPsec, extensions to the SPD
   and SAD are required.  This document describes the IPsec extensions
   required to support ROHCoIPsec.


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.  Verifying the Integrity of Decompressed Packet Headers  . . 5
       3.2.1.  ICV Computation and Integrity Verification  . . . . . . 6
     3.3.  Nested IPComp and ROHCoIPsec Processing . . . . . . . . . . 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
























Ertekin, et al.          Expires August 6, 2009                 [Page 2]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


1.  Introduction

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

   IPsec-protected traffic is carried over 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).  For ROHCoIPsec, various extensions to the SPD and SAD that
   incorporate ROHC-relevant parameters are required.

   In addition, three extensions to IPsec processing are required.
   First, a mechanism for identifying ROHC packets must be defined.
   Second, a mechanism to ensure the integrity of the decompressed
   packet is needed.  Finally, the order of the inbound and outbound
   processing must be enumerated when nesting IP Compression (IPComp
   [IPCOMP]), ROHC, and IPsec processing.


2.  Extensions to IPsec Databases

   The following subsections specify extensions to the SPD and the SAD
   to support ROHCoIPsec.

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 ROHC, the SPD must be extended to include per-channel ROHC
   parameters.  Together, the existing IPsec SPD parameters and the ROHC
   parameters will dictate the security and header compression services
   that are provided to packets.

   The fields contained within each SPD entry are defined in [IPSEC],
   Section 4.4.1.2.  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 following ROHC channel parameters must be included if the
   processing info field in the SPD is set to PROTECT (suggested values



Ertekin, et al.          Expires August 6, 2009                 [Page 3]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


   for these parameters are consistent with [ROHCPPP]):

      MAX_CID: The field indicates the highest context ID that will be
      decompressed by the local decompressor.  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: This field is a list of ROHC profiles supported by the
      local decompressor.  Possible values for this list are contained
      in the [ROHCPROF] registry.

   In addition to these ROHC channel parameters, a field within the SPD
   is required to store a list of integrity algorithms supported by the
   ROHCoIPsec instance:

      INTEGRITY ALGORITHM: This field is a list of integrity algorithms
      supported by the ROHCoIPsec instance.  This will be used by the
      ROHC process to ensure that packet headers are properly
      decompressed (see Section 3.2).

   Several other ROHC channel parameters are omitted from the SPD,
   because they are set implicitly.  The omitted channel parameters are
   LARGE_CIDS, MRRU, and FEEDBACK_FOR.  The LARGE_CIDS channel parameter
   is set implicitly, based on the value of MAX_CID (e.g. if MAX_CID is
   <= 15, LARGE_CIDS is assumed to be 0).  Furthermore, since in-order
   delivery of ROHC packets cannot be guaranteed, the MRRU parameter
   must be set to 0 (as stated in Section 5.2.5.1 of [ROHC] and Section
   6.1 of [ROHCV2]).  Finally, the ROHC FEEDBACK_FOR channel parameter
   is set implicitly to the ROHC channel associated with the SA in the
   reverse direction.  If an SA in the reverse direction does not exist,
   the FEEDBACK_FOR channel parameter is not set, and ROHC must not
   operate in bidirectional Mode.

2.2.  Security Association Database (SAD)

   Each entry within the SAD defines the parameters associated with each
   established SA.  Unless the "populate from packet" (PFP) flag is
   asserted for a particular field, SAD entries are determined by the
   corresponding SPD entries during the creation of the SA.

   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
   augmented to include a "ROHC Data Item" that contains the parameters
   used by ROHC instance.  The ROHC Data Item exists for both inbound
   and outbound SAs.

   The ROHC Data Item includes the ROHC channel parameters for the SA.
   These channel parameters (i.e., MAX_CID, PROFILES) are enumerated



Ertekin, et al.          Expires August 6, 2009                 [Page 4]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


   above in Section 2.1.  For inbound SAs, the ROHC Data Item includes
   ROHC channel parameters that are used by the local decompressor
   instance; conversely, for outbound SAs, the ROHC Data Item includes
   ROHC channel parameters that are used by local compressor instance.

   In addition to these ROHC channel parameters, the ROHC Data Item for
   both inbound and outbound SAs includes two additional parameters.
   Specifically, these parameters store the integrity algorithm and
   respective key used by ROHC (see Section 3.2).  The integrity
   algorithm and its associated key are used to calculate a ROHC ICV;
   this ICV is used to verify the packet headers post-decompression.

   Finally, for inbound SAs, the ROHC Data Item includes a FEEDBACK_FOR
   parameter.  The parameter is a reference to a ROHC channel in the
   opposite direction (i.e., the outbound SA) between the same
   compression endpoints.  A ROHC channel associated with an inbound SA
   and a ROHC channel associated with an outbound SA may be coupled to
   form a Bi-directional ROHC channel as defined in Section 6.1 and
   Section 6.2 in [ROHC-TERM].

   "ROHC Data Item" values may be initialized manually (i.e.,
   administratively configured for manual SAs), or initialized via a key
   exchange protocol (e.g.  IKEv2 [IKEV2]) that has been extended to
   support the signaling of ROHC parameters [IKEV2EXT].


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" protocol identifier.
   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
   the packet includes a ROHC header, in order to determine if it
   requires ROHC decompression.

3.2.  Verifying the Integrity of Decompressed Packet Headers

   Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec
   may use an additional Integrity Algorithm (and respective key) to
   compute a second Integrity Check Value (ICV) for the uncompressed
   packet.  This ICV is computed over the uncompressed IP header, as
   well at the higher-layer headers and the packet payload, and is



Ertekin, et al.          Expires August 6, 2009                 [Page 5]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


   appended to the ROHC-compressed packet.  At the decompressor, the
   decompressed packet (including the uncompressed IP header, higher-
   layer headers, and packet payload; but not including the
   authentication data) will be used with the integrity algorithm (and
   its respective key) to compute a value that will be compared to the
   appended 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 must not be included in the calculation
   of the ICV.

3.2.1.  ICV Computation and Integrity Verification

   In order to correctly verify the integrity of the decompressed
   packets, the processing steps for ROHCoIPsec must be implemented in a
   specific order, as given below.

   For outbound packets that are to be processed by ROHC:
   o  An ICV is computed for the uncompressed packet via ROHCoIPsec's
      Integrity Algorithm (and respective key)
   o  The packet header(s) is(are) compressed by the ROHC process
   o  The ICV is appended to the end of the compressed packet
   o  The security protocol is applied to the packet

   For inbound packets that are to be decompressed by ROHC:
   o  A packet received on a ROHC-enabled SA is IPsec-processed





Ertekin, et al.          Expires August 6, 2009                 [Page 6]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


   o  Packet header(s) is(are) decompressed by the ROHC process
   o  The decompressed packet is used with the integrity algorithm (and
      its respective key) to compute a ROHC ICV that is compared to the
      appended ICV (if these two values differ, the packet is dropped)

3.3.  Nested IPComp and ROHCoIPsec Processing

   IPComp ([IPCOMP]) is another mechanism that can be implemented to
   reduce the size of an IP datagram.  If IPComp and ROHCoIPsec are
   implemented in a nested fashion, the following steps must be followed
   for outbound and inbound packets.

   For outbound packets that are to be processed by IPcomp and ROHC:
   o  The ICV is computed for the uncompressed packet, and the
      appropriate ROHC compression profile is applied to the packet
   o  IPComp is applied, and the packet is sent to the IPsec process
   o  The security protocol is applied to the packet

   Conversely, for inbound packets that are to be both ROHC- and IPcomp-
   decompressed:
   o  A packet received on a ROHC-enabled SA is IPsec-processed
   o  The datagram is decompressed based on the appropriate IPComp
      algorithm
   o  The packet is sent to the ROHC module for header decompression and
      integrity verification


4.  Security Considerations

   A ROHCoIPsec implementer should consider the strength of protection
   provided by the integrity check algorithm used to verify the valid
   decompression of ROHC-compressed packets.  Failure to implement a
   strong integrity check algorithm increases the probability of an
   invalidly decompressed packet to be forwarded by a ROHCoIPsec device
   into a protected domain.

   The implementation of ROHCoIPsec may increase the susceptibility for
   traffic flow analysis, where an attacker can identify new traffic
   flows by monitoring the relative size of the encrypted packets (i.e.
   a group of "long" packets, followed by a long series of "short"
   packets may indicate a new flow for some ROHCoIPsec implementations).
   To mitigate this concern, ROHC padding mechanisms may be used to
   arbitrarily add padding to transmitted packets to randomize packet
   sizes.  This technique, however, reduces the overall efficiency
   benefit offered by header compression.






Ertekin, et al.          Expires August 6, 2009                 [Page 7]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


5.  IANA Considerations

   IANA is requested to allocate one value within the "Protocol Numbers"
   registry [PROTOCOL] for "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.

   The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A
   Stangarone Jr.: both served as committed document reviewers for this
   specification.

   Finally, the authors would like to thank the following for their
   numerous reviews and comments to this document:

   o  Dr. Stephen Kent
   o  Mr. Lars-Erik Jonsson
   o  Mr. Carl Knutsson
   o  Mr. Pasi Eronen
   o  Dr. Jonah Pezeshki
   o  Mr. Tero Kivinen
   o  Dr. Joseph Touch
   o  Mr. Rohan Jasani


7.  References

7.1.  Normative References

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

   [ROHC]     Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
              Header Compression (ROHC) Framework", RFC 4995, July 2007.

   [ROHCV2]   Pelletier, G. and K. Sandlund, "RObust Header Compression
              Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
              UDP-Lite", RFC 5225.

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




Ertekin, et al.          Expires August 6, 2009                 [Page 8]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


   [ROHCPPP]  Bormann, C., "Robust Header Compression (ROHC) over PPP",
              RFC 3241, April 2002.

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

   [IKEV2EXT]
              Ertekin, et al., "Extensions to IKEv2 to Support Robust
              Header Compression over IPsec (ROHCoIPsec)", work in
              progress , February 2009.

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

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

7.2.  Informative References

   [ROHCOIPSEC]
              Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
              "Integration of Header Compression over IPsec Security
              Associations", work in progress , February 2009.

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

   [ROHC-TERM]
              Jonsson, L-E., "Robust Header Compression (ROHC):
              Terminology and Channel Mapping Examples", RFC 3759,
              April 2004.

   [PROTOCOL]
              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
   US

   Email: ertekin_emre@bah.com




Ertekin, et al.          Expires August 6, 2009                 [Page 9]

Internet-Draft   IPsec Extensions to Support ROHCoIPsec    February 2009


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

   Email: christou_chris@bah.com


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28334
   Germany

   Email: cabo@tzi.org



































Ertekin, et al.          Expires August 6, 2009                [Page 10]


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