[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                                               J. Pezeshki
Expires: February 16, 2009                                      M. Casey
                                                             C. Christou
                                                     Booz Allen Hamilton
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                         August 15, 2008


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

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-
   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 February 16, 2009.

Abstract

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





Ertekin, et al.         Expires February 16, 2009               [Page 1]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


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  . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 11
































Ertekin, et al.         Expires February 16, 2009               [Page 2]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


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).  To integrate RoHC and IPsec, 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 is required to ensure the integrity of the
   decompressed packet.  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 services that are provided to packets
   protected by IPsec.

   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 SPD specifies what services are to be offered to IP datagrams,
   and in what fashion.  To offer IP datagrams compression services, the



Ertekin, et al.         Expires February 16, 2009               [Page 3]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   per-channel configuration parameters, defined in [ROHC], are added to
   the SPD.  Specifically, the following parameters must be included if
   the processing info field in the SPD is set to PROTECT (suggested
   values for these parameters are consistent with [ROHCPPP]):

      MAX_CID: The 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: This 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,
      it is not anticipated that a RoHCoIPsec instance will use RoHC
      segmentation.  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.  Furthermore, if a SA in the reverse
   direction exists, the RoHC FEEDBACK_FOR channel parameter is set
   implicitly to the RoHC channel associated with the SA in the reverse
   direction.  If a SA in the reverse direction does not exist, RoHC
   must operate in the Unidirectional Mode.  Because both of these RoHC
   channel parameters are set implicitly, they are not stored in the
   SPD.

   In addition to these RoHC channel parameters, a field within the SPD
   entry is required to store a list of integrity algorithms supported
   by the RoHCoIPsec instance.  This integrity algorithm will be used by
   the RoHC process to ensure that packet headers are properly
   decompressed (see Section 3.2).

2.2.  Security Association Database (SAD)

   Each entry within the SAD defines the parameters associated with each
   established SA.  Unless if 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.




Ertekin, et al.         Expires February 16, 2009               [Page 4]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   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" field that defines the RoHC
   parameters.  These parameters (i.e., MAX_CID, PROFILES, MRRU, and
   MAX_HEADER) are enumerated above in Section 2.1.  In addition, the
   FEEDBACK_FOR parameter is also included, which is associated with the
   SA in the reverse direction (this data item does not need to be
   included in the SPD, since its value is implicitly derived).
   Finally, two additional data items are required to store the
   Integrity Algorithm and respective key that is to be used to ensure
   that packets are properly decompressed (see Section 3.2).

   These "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 negotiation 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 identifer.  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.

3.2.  Verifying the Integrity of Decompressed Packet Headers

   Since RoHC is inherently a lossy algorithm, RoHCoIPsec will use an
   additional Integrity Algorithm (and respective key) to compute a
   second Integrity Check Value (ICV) for the uncompressed packet.
   Specifically, this ICV will be computed for the uncompressed IP
   header, as well at the higher-layer headers and the packet payload.
   This ICV will be 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 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



Ertekin, et al.         Expires February 16, 2009               [Page 5]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   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 should never 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 is 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
   o  The packet is decompressed by the RoHC process
   o  The decompressed packet is used with the Integrity Algorithm (and
      its respective key) to compute a value that is compared to the 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 order of the outbound and
   inbound processing steps must be carefully enumerated.



Ertekin, et al.         Expires February 16, 2009               [Page 6]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   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.  In general, if an integrity check algorithm
   is used with IPsec, it is recommended that the integrity check
   algorithm used by RoHC is at least the same strength.

   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.


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



Ertekin, et al.         Expires February 16, 2009               [Page 7]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   document.  In addition, the authors would like to thank Mr. Rohan
   Jasani for his valuable assistance.  Finally, the authors would like
   to thank the following for their numerous reviews and comments to
   this document:

   o  Dr. Stephen Kent
   o  Dr. Carsten Bormann
   o  Mr. Lars-Erik Jonnson
   o  Mr. Pasi Eronen
   o  Dr. Joseph Touch


7.  References

7.1.  Normative References

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

   [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.

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

   [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]
              Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to
              IKEv2 to Support Robust Header Compression over IPsec
              (RoHCoIPsec)", work in progress , August 2008.

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

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






Ertekin, et al.         Expires February 16, 2009               [Page 8]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


7.2.  Informative References

   [ROHCOIPSEC]
              Ertekin, E. and C. Christou, "Integration of Header
              Compression over IPsec Security Associations", work in
              progress , August 2008.

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

   [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


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

   Email: pezeshki_jonah@bah.com


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

   Email: casey_michele@bah.com








Ertekin, et al.         Expires February 16, 2009               [Page 9]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


   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 February 16, 2009              [Page 10]

Internet-Draft   IPsec Extensions to Support RoHCoIPsec      August 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.











Ertekin, et al.         Expires February 16, 2009              [Page 11]


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