GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5856

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc5856.txt · Last modified: 2010/05/14 19:59 (external edit)