doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5856.txt b/doc/rfc/rfc5856.txt
new file mode 100644
index 0000000..167068c
--- /dev/null
+++ b/doc/rfc/rfc5856.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        E. Ertekin
+Request for Comments: 5856                                     R. Jasani
+Category: Informational                                      C. Christou
+ISSN: 2070-1721                                      Booz Allen Hamilton
+                                                              C. Bormann
+                                                 Universitaet Bremen TZI
+                                                                May 2010
+
+
+             Integration of Robust Header Compression over
+                      IPsec Security Associations
+
+Abstract
+
+   IP Security (IPsec) provides various security services for IP
+   traffic.  However, the benefits of IPsec come at the cost of
+   increased overhead.  This document outlines a framework for
+   integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).
+   By compressing the inner headers of IP packets, ROHCoIPsec proposes
+   to reduce the amount of overhead associated with the transmission of
+   traffic over IPsec Security Associations (SAs).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Not all documents approved by the
+   IESG are a candidate for any level of Internet Standard; see Section
+   2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5856.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.  Code Components extracted from this document must
+
+
+
+Ertekin, et al.               Informational                     [Page 1]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Audience ........................................................3
+   3. Terminology .....................................................3
+   4. Problem Statement: IPsec Packet Overhead ........................4
+   5. Overview of the ROHCoIPsec Framework ............................5
+      5.1. ROHCoIPsec Assumptions .....................................5
+      5.2. Summary of the ROHCoIPsec Framework ........................5
+   6. Details of the ROHCoIPsec Framework .............................7
+      6.1. ROHC and IPsec Integration .................................7
+           6.1.1. Header Compression Protocol Considerations ..........9
+           6.1.2. Initialization and Negotiation of the ROHC Channel ..9
+           6.1.3. Encapsulation and Identification of Header
+                  Compressed Packets .................................10
+           6.1.4. Motivation for the ROHC ICV ........................11
+           6.1.5. Path MTU Considerations ............................11
+      6.2. ROHCoIPsec Framework Summary ..............................12
+   7. Security Considerations ........................................12
+   8. IANA Considerations ............................................12
+   9. Acknowledgments ................................................13
+   10. Informative References ........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ertekin, et al.               Informational                     [Page 2]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+1.  Introduction
+
+   This document outlines a framework for integrating ROHC [ROHC] over
+   IPsec [IPSEC] (ROHCoIPsec).  The goal of ROHCoIPsec is to reduce the
+   protocol overhead associated with packets traversing between IPsec SA
+   endpoints.  This can be achieved by compressing the transport layer
+   header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
+   ingress of the IPsec tunnel, and decompressing these headers at the
+   egress.
+
+   For ROHCoIPsec, this document assumes that ROHC will be used to
+   compress the inner headers of IP packets traversing an IPsec tunnel.
+   However, since current specifications for ROHC detail its operation
+   on a hop-by-hop basis, it requires extensions to enable its operation
+   over IPsec SAs.  This document outlines a framework for extending the
+   usage of ROHC to operate at IPsec SA endpoints.
+
+   ROHCoIPsec targets the application of ROHC to tunnel mode SAs.
+   Transport mode SAs only protect the payload of an IP packet, leaving
+   the IP header untouched.  Intermediate routers subsequently use this
+   IP header to route the packet to a decryption device.  Therefore, if
+   ROHC is to operate over IPsec transport-mode SAs, (de)compression
+   functionality can only be applied to the transport layer headers, and
+   not to the IP header.  Because current ROHC specifications do not
+   include support for the compression of transport layer headers alone,
+   the ROHCoIPsec framework outlined by this document describes the
+   application of ROHC to tunnel mode SAs.
+
+2.  Audience
+
+   The authors target members of both the ROHC and IPsec communities who
+   may consider extending the ROHC and IPsec protocols to meet the
+   requirements put forth in this document.  In addition, this document
+   is directed towards vendors developing IPsec devices that will be
+   deployed in bandwidth-constrained IP networks.
+
+3.  Terminology
+
+   ROHC Process
+
+      Generic reference to a ROHC instance (as defined in RFC 3759
+      [ROHC-TERM]) or any supporting ROHC components.
+
+   Compressed Traffic
+
+      Traffic that is processed through the ROHC compressor and
+      decompressor instances.  Packet headers are compressed and
+      decompressed using a specific header compression profile.
+
+
+
+Ertekin, et al.               Informational                     [Page 3]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   Uncompressed Traffic
+
+      Traffic that is not processed by the ROHC compressor instance.
+      Instead, this type of traffic bypasses the ROHC process.
+
+   IPsec Process
+
+      Generic reference to the Internet Protocol Security (IPsec)
+      process.
+
+   Next Header
+
+      Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
+      field.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [BRA97].
+
+4.  Problem Statement: IPsec Packet Overhead
+
+   IPsec mechanisms provide various security services for IP networks.
+   However, the benefits of IPsec come at the cost of increased per-
+   packet overhead.  For example, traffic flow confidentiality
+   (generally leveraged at security gateways) requires the tunneling of
+   IP packets between IPsec implementations.  Although these IPsec
+   tunnels will effectively mask the source-destination patterns that an
+   intruder can ascertain, tunneling comes at the cost of increased
+   packet overhead.  Specifically, an Encapsulating Security Payload
+   (ESP) tunnel mode SA applied to an IPv6 flow results in at least 50
+   bytes of additional overhead per packet.  This additional overhead
+   may be undesirable for many bandwidth-constrained wireless and/or
+   satellite communications networks, as these types of infrastructure
+   are not overprovisioned.  ROHC applied on a per-hop basis over
+   bandwidth-constrained links will also suffer from reduced performance
+   when encryption is used on the tunneled header, since encrypted
+   headers cannot be compressed.  Consequently, the additional overhead
+   incurred by an IPsec tunnel may result in the inefficient utilization
+   of bandwidth.
+
+   Packet overhead is particularly significant for traffic profiles
+   characterized by small packet payloads (e.g., various voice codecs).
+   If these small packets are afforded the security services of an IPsec
+   tunnel mode SA, the amount of per-packet overhead is increased.
+   Thus, a mechanism is needed to reduce the overhead associated with
+   such flows.
+
+
+
+
+
+Ertekin, et al.               Informational                     [Page 4]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+5.  Overview of the ROHCoIPsec Framework
+
+5.1.  ROHCoIPsec Assumptions
+
+   The goal of ROHCoIPsec is to provide efficient transport of IP
+   packets between IPsec devices without compromising the security
+   services offered by IPsec.  The ROHCoIPsec framework has been
+   developed based on the following assumptions:
+
+   o  ROHC will be leveraged to reduce the amount of overhead associated
+      with unicast IP packets traversing an IPsec SA.
+
+   o  ROHC will be instantiated at the IPsec SA endpoints, and it will
+      be applied on a per-SA basis.
+
+   o  Once the decompression operation completes, decompressed packet
+      headers will be identical to the original packet headers before
+      compression.
+
+5.2.  Summary of the ROHCoIPsec Framework
+
+   ROHC reduces packet overhead in a network by exploiting intra- and
+   inter-packet redundancies of network and transport-layer header
+   fields of a flow.
+
+   Current ROHC protocol specifications compress packet headers on a
+   hop-by-hop basis.  However, IPsec SAs are instantiated between two
+   IPsec endpoints.  Therefore, various extensions to both ROHC and
+   IPsec need to be defined to ensure the successful operation of the
+   ROHC protocol at IPsec SA endpoints.
+
+   The specification of ROHC over IPsec SAs is straightforward, since SA
+   endpoints provide source/destination pairs where (de)compression
+   operations can take place.  Compression of the inner IP and upper
+   layer protocol headers in such a manner offers a reduction of packet
+   overhead between the two SA endpoints.  Since ROHC will now operate
+   between IPsec endpoints (over multiple intermediate nodes that are
+   transparent to an IPsec SA), it is imperative to ensure that its
+   performance will not be severely impacted due to increased packet
+   reordering and/or packet loss between the compressor and
+   decompressor.
+
+   In addition, ROHC can no longer rely on the underlying link layer for
+   ROHC channel parameter configuration and packet identification.  The
+   ROHCoIPsec framework proposes that ROHC channel parameter
+   configuration is accomplished by an SA management protocol (e.g.,
+   Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while
+   identification of compressed header packets is achieved through the
+
+
+
+Ertekin, et al.               Informational                     [Page 5]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   Next Header field of the security protocol (e.g., Authentication
+   Header (AH) [AH], ESP [ESP]) header.
+
+   Using the ROHCoIPsec framework proposed below, outbound and inbound
+   IP traffic processing at an IPsec device needs to be modified.  For
+   an outbound packet, a ROHCoIPsec implementation will compress
+   appropriate packet headers, and subsequently encrypt and/or integrity
+   protect the packet.  For tunnel mode SAs, compression may be applied
+   to the transport layer and the inner IP headers.  For inbound
+   packets, an IPsec device must first decrypt and/or integrity check
+   the packet.  Then, decompression of the inner packet headers is
+   performed.  After decompression, the packet is checked against the
+   access controls imposed on all inbound traffic associated with the SA
+   (as specified in RFC 4301 [IPSEC]).
+
+      Note: Compression of inner headers is independent from compression
+      of the security protocol (e.g., ESP) and outer IP headers.  ROHC
+      profiles have been defined to allow for the compression of the
+      security protocol and the outer IP header on a hop-by-hop basis.
+      The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4
+      ESP-processed packet [ESP] is shown below in Figure 1.
+
+             -----------------------------------------------------------
+       IPv4  | new IP hdr  |     | orig IP hdr   |   |    | ESP   | ESP|
+             |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
+             -----------------------------------------------------------
+             |<-------(1)------->|<------(2)-------->|
+
+             (1) Compressed hop-by-hop by the ROHC [ROHC]
+                 ESP/IP profile
+             (2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC]
+                 TCP/IP profile
+
+      Figure 1.  Applicability of hop-by-hop ROHC and ROHCoIPsec on an
+      IPv4 ESP-processed packet.
+
+   If IPsec NULL encryption is applied to packets, ROHC may still be
+   used to compress the inner headers at IPsec SA endpoints.  However,
+   compression of these inner headers may pose challenges for
+   intermediary devices (e.g., traffic monitors, sampling/management
+   tools) that are inspecting the contents of ESP-NULL packets.  For
+   example, policies on these devices may need to be updated to ensure
+   that packets that contain the "ROHC" protocol identifier are not
+   dropped.  In addition, intermediary devices may require additional
+   functionality to determine the content of the header compressed
+   packets.
+
+
+
+
+
+Ertekin, et al.               Informational                     [Page 6]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   In certain scenarios, a ROHCoIPsec implementation may encounter UDP-
+   encapsulated ESP or IKE packets (i.e., packets that are traversing
+   NATs).  For example, a ROHCoIPsec implementation may receive a UDP-
+   encapsulated ESP packet that contains an ESP/UDP/IP header chain.
+   Currently, ROHC profiles do not support compression of the entire
+   header chain associated with this packet; only the UDP/IP headers can
+   be compressed.
+
+6.  Details of the ROHCoIPsec Framework
+
+6.1.  ROHC and IPsec Integration
+
+   Figure 2 illustrates the components required to integrate ROHC with
+   the IPsec process, i.e., ROHCoIPsec.
+
+                  +-------------------------------+
+                  | ROHC Module                   |
+                  |                               |
+                  |                               |
+        +-----+   |     +-----+     +---------+   |
+        |     |   |     |     |     |  ROHC   |   |
+      --|  A  |---------|  B  |-----| Process |------> Path 1
+        |     |   |     |     |     |         |   |   (ROHC-enabled SA)
+        +-----+   |     +-----+     +---------+   |
+           |      |        |                      |
+           |      |        |-------------------------> Path 2
+           |      |                               |   (ROHC-enabled SA,
+           |      +-------------------------------+  but no compression)
+           |
+           |
+           |
+           |
+           +-----------------------------------------> Path 3
+                                                      (ROHC-disabled SA)
+
+                 Figure 2.  Integration of ROHC with IPsec
+
+   The process illustrated in Figure 2 augments the IPsec processing
+   model for outbound IP traffic (protected-to-unprotected).  Initial
+   IPsec processing is consistent with RFC 4301 [IPSEC] (Section 5.1,
+   Steps 1-2).
+
+   Block A: The ROHC data item (part of the SA state information)
+   retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1,
+   Step3a) determines if the traffic traversing the SA is handed to the
+   ROHC module.  Packets selected to a ROHC-disabled SA MUST follow
+   normal IPsec processing and MUST NOT be sent to the ROHC module
+
+
+
+
+Ertekin, et al.               Informational                     [Page 7]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   (Figure 2, Path 3).  Conversely, packets selected to a ROHC-enabled
+   SA MUST be sent to the ROHC module.
+
+   Block B: This step determines if the packet can be compressed.  If
+   the packet is compressed, an integrity algorithm MAY be used to
+   compute an Integrity Check Value (ICV) for the uncompressed packet
+   ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1).  The Next
+   Header field of the security protocol header (e.g., ESP, AH) MUST be
+   populated with a "ROHC" protocol identifier [PROTOCOL], inner packet
+   headers MUST be compressed, and the computed ICV MAY be appended to
+   the packet (Figure 2, Path 1).  However, if it is determined that the
+   packet will not be compressed (e.g., due to one of the reasons
+   described in Section 6.1.3), the Next Header field MUST be populated
+   with the appropriate value indicating the next-level protocol (Figure
+   2, Path 2), and ROHC processing MUST NOT be applied to the packet.
+
+   After the ROHC process completes, IPsec processing resumes, as
+   described in Section 5.1, Step3a, of RFC 4301 [IPSEC].
+
+   The process illustrated in Figure 2 also augments the IPsec
+   processing model for inbound IP traffic (unprotected-to-protected).
+   For inbound packets, IPsec processing is performed ([IPSEC], Section
+   5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
+   5.2, Step 4).
+
+   Block A: After AH or ESP processing, the ROHC data item retrieved
+   from the SAD entry will indicate if traffic traversing the SA is
+   processed by the ROHC module ([IPSEC], Section 5.2, Step 3a).
+   Packets traversing a ROHC-disabled SA MUST follow normal IPsec
+   processing and MUST NOT be sent to the ROHC module.  Conversely,
+   packets traversing a ROHC-enabled SA MUST be sent to the ROHC module.
+
+   Block B: The decision at Block B is made using the value of the Next
+   Header field of the security protocol header.  If the Next Header
+   field does not indicate a ROHC header, the decompressor MUST NOT
+   attempt decompression (Figure 2, Path 2).  If the Next Header field
+   indicates a ROHC header, decompression is applied.  After
+   decompression, the signaled ROHCoIPsec integrity algorithm MAY be
+   used to compute an ICV value for the decompressed packet.  This ICV,
+   if present, is compared to the ICV that was calculated at the
+   compressor.  If the ICVs match, the packet is forwarded by the ROHC
+   module (Figure 2, Path 1); otherwise, the packet MUST be dropped.
+   Once the ROHC module completes processing, IPsec processing resumes,
+   as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].
+
+   When there is a single SA between a compressor and decompressor, ROHC
+   MUST operate in unidirectional mode, as described in Section 5 of RFC
+   3759 [ROHC-TERM].  When there is a pair of SAs instantiated between
+
+
+
+Ertekin, et al.               Informational                     [Page 8]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   ROHCoIPsec implementations, ROHC MAY operate in bi-directional mode,
+   where an SA pair represents a bi-directional ROHC channel (as
+   described in Sections 6.1 and 6.2 of RFC 3759 [ROHC-TERM]).
+
+   Note that to further reduce the size of an IPsec-protected packet,
+   ROHCoIPsec and IPComp [IPCOMP] can be implemented in a nested
+   fashion.  This process is detailed in [IPSEC-ROHC], Section 4.4.
+
+6.1.1.  Header Compression Protocol Considerations
+
+   ROHCv2 [ROHCV2] profiles include various mechanisms that provide
+   increased robustness over reordering channels.  These mechanisms
+   SHOULD be adopted for ROHC to operate efficiently over IPsec SAs.
+
+   A ROHC decompressor implemented within IPsec architecture MAY
+   leverage additional mechanisms to improve performance over reordering
+   channels (either due to random events or to an attacker intentionally
+   reordering packets).  Specifically, IPsec's sequence number MAY be
+   used by the decompressor to identify a packet as "sequentially late".
+   This knowledge will increase the likelihood of successful
+   decompression of a reordered packet.
+
+   Additionally, ROHCoIPsec implementations SHOULD minimize the amount
+   of feedback sent from the decompressor to the compressor.  If a ROHC
+   feedback channel is not used sparingly, the overall gains from
+   ROHCoIPsec can be significantly reduced.  More specifically, any
+   feedback sent from the decompressor to the compressor MUST be
+   processed by IPsec and tunneled back to the compressor (as designated
+   by the SA associated with FEEDBACK_FOR).  As such, some
+   implementation alternatives can be considered, including the
+   following:
+
+   o  Eliminate feedback traffic altogether by operating only in ROHC
+      Unidirectional mode (U-mode).
+
+   o  Piggyback ROHC feedback messages within the feedback element
+      (i.e., on ROHC traffic that normally traverses the SA designated
+      by FEEDBACK_FOR).
+
+6.1.2.  Initialization and Negotiation of the ROHC Channel
+
+   Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP)
+   to negotiate ROHC channel parameters.  In the case of ROHCoIPsec,
+   channel parameters can be set manually (i.e., administratively
+   configured for manual SAs) or negotiated by IKEv2.  The extensions
+   required for IKEv2 to support ROHC channel parameter negotiation are
+   detailed in [IKE-ROHC].
+
+
+
+
+Ertekin, et al.               Informational                     [Page 9]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   If the ROHC protocol requires bi-directional communications, two SAs
+   MUST be instantiated between the IPsec implementations.  One of the
+   two SAs is used for carrying ROHC-traffic from the compressor to the
+   decompressor, while the other is used to communicate ROHC-feedback
+   from the decompressor to the compressor.  Note that the requirement
+   for two SAs aligns with the operation of IKE, which creates SAs in
+   pairs by default.  However, IPsec implementations will dictate how
+   decompressor feedback received on one SA is associated with a
+   compressor on the other SA.  An IPsec implementation MUST relay the
+   feedback received by the decompressor on an inbound SA to the
+   compressor associated with the corresponding outbound SA.
+
+6.1.3.  Encapsulation and Identification of Header Compressed Packets
+
+   As indicated in Section 6.1, new state information (i.e., a new ROHC
+   data item) is defined for each SA.  The ROHC data item MUST be used
+   by the IPsec process to determine whether it sends all traffic
+   traversing a given SA to the ROHC module (ROHC-enabled) or bypasses
+   the ROHC module and sends the traffic through regular IPsec
+   processing (ROHC-disabled).
+
+   The Next Header field of the IPsec security protocol (e.g., AH or
+   ESP) header MUST be used to demultiplex header-compressed traffic
+   from uncompressed traffic traversing a ROHC-enabled SA.  This
+   functionality is needed in situations where packets traversing a
+   ROHC-enabled SA contain uncompressed headers.  Such situations may
+   occur when, for example, a compressor only supports up to n
+   compressed flows and cannot compress a flow number n+1 that arrives.
+   Another example is when traffic is selected to a ROHC-enabled SA, but
+   cannot be compressed by the ROHC process because the appropriate ROHC
+   Profile has not been signaled for use.  As a result, the decompressor
+   MUST be able to identify packets with uncompressed headers and MUST
+   NOT attempt to decompress them.  The Next Header field is used to
+   demultiplex these header-compressed and uncompressed packets where
+   the "ROHC" protocol identifier will indicate that the packet contains
+   compressed headers.  To accomplish this, IANA has allocated value 142
+   to "ROHC" from the Protocol ID registry [PROTOCOL].
+
+   It is noted that the use of the "ROHC" protocol identifier for
+   purposes other than ROHCoIPsec is currently not defined.  In other
+   words, the "ROHC" protocol identifier is only defined for use in the
+   Next Header field of security protocol headers (e.g., ESP, AH).
+
+   The ROHC Data Item, IANA Protocol ID allocation, and other IPsec
+   extensions to support ROHCoIPsec are specified in [IPSEC-ROHC].
+
+
+
+
+
+
+Ertekin, et al.               Informational                    [Page 10]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+6.1.4.  Motivation for the ROHC ICV
+
+   Although ROHC was designed to tolerate packet loss and reordering,
+   the algorithm does not guarantee that packets reconstructed at the
+   decompressor are identical to the original packet.  As stated in
+   Section 5.2 of RFC 4224 [REORDR], the consequences of packet
+   reordering between ROHC peers may include undetected decompression
+   failures, where erroneous packets are constructed and forwarded to
+   upper layers.  Significant packet loss can have similar consequences.
+
+   When using IPsec integrity protection, a packet received at the
+   egress of an IPsec tunnel is identical to the packet that was
+   processed at the ingress (given that the key is not compromised,
+   etc.).
+
+   When ROHC is integrated into the IPsec processing framework, the ROHC
+   processed packet is protected by the AH/ESP ICV.  However, bits in
+   the original IP header are not protected by this ICV; they are
+   protected only by ROHC's integrity mechanisms (which are designed for
+   random packet loss/reordering, not malicious packet loss/reordering
+   introduced by an attacker).  Therefore, under certain circumstances,
+   erroneous packets may be constructed and forwarded into the protected
+   domain.
+
+   To ensure the integrity of the original IP header within the
+   ROHCoIPsec-processing model, an additional integrity check MAY be
+   applied before the packet is compressed.  This integrity check will
+   ensure that erroneous packets are not forwarded into the protected
+   domain.  The specifics of this integrity check are documented in
+   Section 4.2 of [IPSEC-ROHC].
+
+6.1.5.  Path MTU Considerations
+
+   By encapsulating IP packets with AH/ESP and tunneling IP headers,
+   IPsec increases the size of IP packets.  This increase may result in
+   Path MTU issues in the unprotected domain.  Several approaches to
+   resolving these path MTU issues are documented in Section 8 of RFC
+   4301 [IPSEC]; approaches include fragmenting the packet before or
+   after IPsec processing (if the packet's Don't Fragment (DF) bit is
+   clear), or possibly discarding packets (if the packet's DF bit is
+   set).
+
+   The addition of ROHC within the IPsec processing model may result in
+   similar path MTU challenges.  For example, under certain
+   circumstances, ROHC headers are larger than the original uncompressed
+   headers.  In addition, if an integrity algorithm is used to validate
+   packet headers, the resulting ICV will increase the size of packets.
+   Both of these properties of ROHCoIPsec increase the size of packets,
+
+
+
+Ertekin, et al.               Informational                    [Page 11]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+   and therefore may result in additional challenges associated with
+   path MTU.
+
+   Approaches to addressing these path MTU issues are specified in
+   Section 4.3 of [IPSEC-ROHC].
+
+6.2.  ROHCoIPsec Framework Summary
+
+   To summarize, the following items are needed to achieve ROHCoIPsec:
+
+   o  IKEv2 Extensions to Support ROHCoIPsec
+
+   o  IPsec Extensions to Support ROHCoIPsec
+
+7.  Security Considerations
+
+   Several security considerations associated with the use of ROHCoIPsec
+   are covered in Section 6.1.4.  These considerations can be mitigated
+   by using a strong integrity-check algorithm to ensure the valid
+   decompression of packet headers.
+
+   A malfunctioning or malicious ROHCoIPsec compressor (i.e., the
+   compressor located at the ingress of the IPsec tunnel) has the
+   ability to send erroneous 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 may result in decreased efficiency between compressor and
+   decompressor, or may cause the decompressor to forward erroneous
+   packets into the protected domain.  A malicious compressor could also
+   intentionally generate a significant number of compressed packets,
+   which may result in denial of service at the decompressor, as the
+   decompression of a significant number of invalid packets may drain
+   the resources of an IPsec device.
+
+   A malfunctioning or malicious ROHCoIPsec decompressor has the ability
+   to disrupt communications as well.  For example, a decompressor may
+   simply discard a subset of (or all) the packets that are received,
+   even if packet headers were validly decompressed.  Ultimately, this
+   could result in denial of service.  A malicious decompressor could
+   also intentionally indicate that its context is not synchronized with
+   the compressor's context, forcing the compressor to transition to a
+   lower compression state.  This will reduce the overall efficiency
+   gain offered by ROHCoIPsec.
+
+8.  IANA Considerations
+
+   All IANA considerations for ROHCoIPsec are documented in [IKE-ROHC]
+   and [IPSEC-ROHC].
+
+
+
+Ertekin, et al.               Informational                    [Page 12]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+9.  Acknowledgments
+
+   The authors would like to thank Sean O'Keeffe, James Kohler, and
+   Linda Noone of the Department of Defense, as well as Rich Espy of
+   OPnet for their contributions and support in the development of 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.
+
+   In addition, the authors would like to thank the following for their
+   numerous reviews and comments to this document:
+
+   o  Magnus Westerlund
+
+   o  Stephen Kent
+
+   o  Pasi Eronen
+
+   o  Joseph Touch
+
+   o  Tero Kivinen
+
+   o  Jonah Pezeshki
+
+   o  Lars-Erik Jonsson
+
+   o  Jan Vilhuber
+
+   o  Dan Wing
+
+   o  Kristopher Sandlund
+
+   o  Ghyslain Pelletier
+
+   o  David Black
+
+   o  Tim Polk
+
+   o  Brian Carpenter
+
+   Finally, the authors would also like to thank Tom Conkle, Renee
+   Esposito, Etzel Brower, and Michele Casey of Booz Allen Hamilton for
+   their assistance in completing this work.
+
+
+
+
+
+
+Ertekin, et al.               Informational                    [Page 13]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+10.  Informative References
+
+   [ROHC]        Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
+                 RObust Header Compression (ROHC) Framework", RFC 5795,
+                 March 2010.
+
+   [IPSEC]       Kent, S. and K. Seo, "Security Architecture for the
+                 Internet Protocol", RFC 4301, December 2005.
+
+   [ROHC-TERM]   Jonsson, L-E., "Robust Header Compression (ROHC):
+                 Terminology and Channel Mapping Examples", RFC 3759,
+                 April 2004.
+
+   [BRA97]       Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IKEV2]       Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+                 RFC 4306, December 2005.
+
+   [ESP]         Kent, S., "IP Encapsulating Security Payload (ESP)",
+                 RFC 4303, December 2005.
+
+   [AH]          Kent, S., "IP Authentication Header", RFC 4302,
+                 December 2005.
+
+   [IPSEC-ROHC]  Ertekin, E., Christou, C., and C. Bormann, "IPsec
+                 Extensions to Support Robust Header Compression over
+                 IPsec", RFC 5858, May 2010.
+
+   [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.
+
+   [PROTOCOL]    IANA, "Assigned Internet Protocol Numbers",
+                 <http://www.iana.org>.
+
+   [IPCOMP]      Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
+                 "IP Payload Compression Protocol (IPComp)", RFC 3173,
+                 September 2001.
+
+   [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.
+
+   [REORDR]      Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
+                 Header Compression (ROHC): ROHC over Channels That Can
+                 Reorder Packets", RFC 4224, January 2006.
+
+
+
+
+Ertekin, et al.               Informational                    [Page 14]
+
+RFC 5856           Integration of ROHC over IPsec SAs           May 2010
+
+
+Authors' Addresses
+
+   Emre Ertekin
+   Booz Allen Hamilton
+   5220 Pacific Concourse Drive, Suite 200
+   Los Angeles, CA  90045
+   US
+
+   EMail: ertekin_emre@bah.com
+
+
+   Rohan Jasani
+   Booz Allen Hamilton
+   13200 Woodland Park Dr.
+   Herndon, VA  20171
+   US
+
+   EMail: ro@breakcheck.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.               Informational                    [Page 15]
+