IPsec Extensions to Support Robust Header Compression over IPsec
RFC 5858

If the compressed packet exceeds the SA PMTU, and the MRRU is non-
   zero, ROHC segmentation MAY be used to divide the packet, where each
   segment conforms to the tunnel MTU.  ROHC segmentation MUST occur
   before AH or ESP processing.  Because in-order delivery of ROHC
   segments is not guaranteed, the use of ROHC segmentation is not
   recommended.

   If segmentation is applied, the process MUST account for the
   additional overhead imposed by the IPsec process (e.g., AH or ESP
   overhead, crypto synchronization data, the additional IP header,
   etc.) such that the final IPsec-processed segments are less than the
   tunnel MTU.  After segmentation, each ROHC segment is consecutively
   processed by the appropriate security protocol (e.g., AH, ESP)
   instantiated on the ROHC-enabled SA.  Since ROHC segments are
   processed consecutively, the associated AH/ESP sequence number MUST
   be incremented by one for each segment transmitted over the ROHC
   channel.  As such, after all ROHC segments receive AH/ESP processing,
   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
   MUST re-assemble the ROHC segments that are received.  To accomplish
   this, the decompressor MUST identify the ROHC segments (as documented
   in Section 5.2 of RFC 5795 [ROHC]), and attempt reconstruction using
   the ROHC segmentation protocol (Section 5.2.5 of RFC 5795 [ROHC]).
   To assist the reconstruction process, the AH/ESP sequence number
   SHOULD be used to identify segments that may have been subject to
   reordering.  If reconstruction fails, the packet MUST be discarded.

   As stated in Section 3.2.1, if the ROHC integrity algorithm is used
   to verify the decompression of packet headers, this ICV is appended
   to the compressed packet.  If ROHC segmentation is performed, the
   segmentation algorithm is executed on the compressed packet and the
   appended ICV.  Note that the ICV is not appended to each ROHC
   segment.

   Under certain circumstances, IPsec implementations will not process
   (or receive) unprotected ICMP messages, or they will not have a Path
   MTU estimated value.  In these cases, the IPsec implementation SHOULD
   NOT attempt to segment the ROHC-compressed packet, as it does not
   have full insight into the path MTU in the unprotected domain.

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

Ertekin, et al.              Standards Track                    [Page 9]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

   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.

5.  Security Considerations

   A ROHCoIPsec implementer should consider the strength of protection
   provided by the integrity check algorithm used to verify decompressed
   headers.  Failure to implement a strong integrity check algorithm
   increases the probability for 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.

6.  IANA Considerations

   IANA has allocated the value 142 to "ROHC" within the "Protocol
   Numbers" registry [PROTOCOL].  This value will be used to indicate
   that the next-level protocol header is a ROHC header.

Ertekin, et al.              Standards Track                   [Page 10]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

7.  Acknowledgments

   The authors would like to thank Sean O'Keeffe, James Kohler, Linda
   Noone of the Department of Defense, and Rich Espy of OPnet for their
   contributions and support for developing this document.

   The authors would also like to thank Yoav Nir and 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  Magnus Westerlund

   o  Stephen Kent

   o  Lars-Erik Jonsson

   o  Carl Knutsson

   o  Pasi Eronen

   o  Jonah Pezeshki

   o  Tero Kivinen

   o  Joseph Touch

   o  Rohan Jasani

   o  Elwyn Davies

   o  Bert Wijnen

Ertekin, et al.              Standards Track                   [Page 11]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

Appendix A.  ASN.1 Representation for ROHCoIPsec

   This appendix is included as an additional way to describe the
   ROHCoIPsec parameters that are included in the IPsec SPD.  It uses
   portions of the ASN.1 syntax provided in Appendix C of RFC 4301
   [IPSEC].  In addition, several new structures are defined.

   This syntax has been successfully compiled.  However, it is merely
   illustrative and need not be employed in an implementation to achieve
   compliance.

   The "Processing" data structure, defined in Appendix C of RFC 4301,
   is augmented to include a ROHC parameters element as follows:

         Processing ::= SEQUENCE {
             extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
             seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
             fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                                  -- FALSE no stateful fragment checking
             lifetime    SALifetime,
             spi         ManualSPI,
             algorithms  ProcessingAlgs,
             tunnel      TunnelOptions OPTIONAL,
             rohc        [7] RohcParams OPTIONAL

         }

   The following data structures describe these ROHC parameters:

       RohcParams ::= SEQUENCE {
           rohcEnabled         BOOLEAN, --  TRUE, hdr compr. is enabled
                                        -- FALSE, hdr compr. is disabled
           maxCID              INTEGER (0..16383),
           mrru                INTEGER,
           profiles            RohcProfiles,
           rohcIntegAlg        RohcIntegAlgs,
           rohcIntegICVLength  INTEGER
           }

       RohcProfiles ::= SET OF RohcProfile

Ertekin, et al.              Standards Track                   [Page 12]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

       RohcProfile ::= INTEGER {
           rohcv1-rtp           (1),
           rohcv1-udp           (2),
           rohcv1-esp           (3),
           rohcv1-ip            (4),

           rohcv1-tcp           (6),
           rohcv1-rtp-udpLite   (7),
           rohcv1-udpLite       (8),

           rohcv2-rtp         (257),
           rohcv2-udp         (258),
           rohcv2-esp         (259),
           rohcv2-ip          (260),

           rohcv2-rtp-udpLite (263),
           rohcv2-udpLite     (264)

           -- values taken from [ROHCPROF]

           }

       RohcIntegAlgs ::= SEQUENCE {
           algorithm   RohcIntegAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       RohcIntegAlgType ::= INTEGER {
           none                    (0),
           auth-HMAC-MD5-96        (1),
           auth-HMAC-SHA1-96       (2),
           auth-DES-MAC            (3),
           auth-KPDK-MD5           (4),
           auth-AES-XCBC-96        (5),
           auth-HMAC-MD5-128       (6),
           auth-HMAC-SHA1-160      (7),
           auth-AES-CMAC-96        (8),
           auth-AES-128-GMAC       (9),
           auth-AES-192-GMAC      (10),
           auth-AES-256-GMAC      (11),
           auth-HMAC-SHA2-256-128 (12),
           auth-HMAC-SHA2-384-192 (13),
           auth-HMAC-SHA2-512-256 (14)
           --  tbd (15..65535)

           -- values taken from "Transform Type 3 - Integrity
           -- Algorithm Transform IDs" at [IKEV2-PARA]

           }

Ertekin, et al.              Standards Track                   [Page 13]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

8.  References

8.1.  Normative References

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

   [ROHC]        Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
                 RObust Header Compression (ROHC) Framework", RFC 5795,
                 March 2010.

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

   [BRA97]       Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [IKE-ROHC]    Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
                 C. Bormann, "IKEv2 Extensions to Support Robust Header
                 Compression over IPsec", RFC 5857, May 2010.

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

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

8.2.  Informative References

   [ROHCOIPSEC]  Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
                 "Integration of Header Compression over IPsec Security
                 Associations", RFC 5856, May 2010.

   [ROHCPROF]    IANA, "RObust Header Compression (ROHC) Profile
                 Identifiers", <http://www.iana.org>.

   [CRYPTO-ALG]  Manral, V., "Cryptographic Algorithm Implementation
                 Requirements for Encapsulating Security Payload (ESP)
                 and Authentication Header (AH)", RFC 4835, April 2007.

Ertekin, et al.              Standards Track                   [Page 14]
RFC 5858         IPsec Extensions to Support ROHCoIPsec         may 2010

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

   [PROTOCOL]    IANA, "Assigned Internet Protocol Numbers",
                 <http://www.iana.org>.

   [IKEV2-PARA]  IANA, "Internet Key Exchange Version 2 (IKEv2)
                 Parameters", <http://www.iana.org>.

Authors' Addresses

   Emre Ertekin
   Booz Allen Hamilton
   5220 Pacific Concourse Drive, Suite 200
   Los Angeles, CA  90045
   US

   EMail: ertekin_emre@bah.com

   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.              Standards Track                   [Page 15]