Network Working Group                                         E. Ertekin
Internet-Draft                                               C. Christou
Expires: August December 28, 2006                                     R. Jasani
                                                     Booz Allen Hamilton
                                                       February 24,
                                                           June 26, 2006

   Integration of Header Compression over IPsec Security Associations
                      draft-ietf-rohc-hcoipsec-01
                      draft-ietf-rohc-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 August December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Internet Protocol security mechanisms, such as IP Security (IPsec)
   [IPSEC], provides provide various security services for IP traffic.  However,
   the benefits offered by of IPsec come at the cost of increased overhead.  This
   document identifies defines a set of work items that need to be
   completed to achieve the integration of header compression framework for integrating Header Compression (HC)
   over IPsec (HCoIPsec).  By compressing the inner headers of IP
   packets, HCoIPsec proposes to reduce the amount of packet overhead
   associated with the transmission of traffic over tunnel mode IPsec security
   associations.

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Audience . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   4.      Problem Statement: Packet Overhead Associated with
           IPsec Tunnel-Mode SAs  . . . . . . . . . . . . . . . . . .  4
   5.      Overview of the HCoIPsec Framework . . . . .  4
   5.  The Header Compression Solution . . . . . . .  5
   5.1.    HCoIPsec Assumptions . . . . . . . .  5
   6.  Integration Methodology . . . . . . . . . . .  5
   5.2.    HCoIPsec Description . . . . . . . .  6
     6.1.  Work Assumptions . . . . . . . . . . .  5
   6.      Details of the HCoIPsec Framework  . . . . . . . . . .  6
     6.2.  Work Items . .  6
   6.1.    HC and IPsec Integration . . . . . . . . . . . . . . . . .  6
   6.1.1.  Header Compression Scheme Considerations . . . . .  7
       6.2.1.  Header Compression Scheme-Specific Extensions . . . .  8
       6.2.2.
   6.1.2.  Initialization and Negotiation of Header
               Compression HC Channel . . . . . . . . . . . . . . . . .  8
       6.2.3.  9
   6.1.3.  Encapsulation and Identification of Header Compressed
           Packets  . . . . . . . . . . . . . . . . . .  9
   7.  Candidate Compression Schemes  . . . . . . . . . . . . . . . .  9
   8.  Example Operation  . . . . . .
   6.2.    HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
   9.  Future Work Items  . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  HCoIPsec Transport Mode SAs  . . . . . . . . . . . . . . . 12
   10.
   7.      Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   11. 10
   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   12. 10
   9.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   13. 10
   10.     References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1. 11
   10.1.   Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2. 11
   10.2.   Informative References . . . . . . . . . . . . . . . . . . 14 12
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 13
           Intellectual Property and Copyright Statements . . . . . . . . . . 17 14

1.  Introduction

   This document identifies a set of work items that need to be
   completed in order to achieve the integration of header compression
   (HC) framework for integrating HC over IPsec
   Security Associations (SAs) operating in tunnel mode. (SAs).  The goal of integrating HC with IPsec
   is to reduce the protocol overhead associated with packets traversing
   between IPsec SA endpoints.  This goal can be achieved by compressing the upper
   transport layer
   protocols header (e.g., RTP/UDP and TCP) UDP, TCP, etc.) and the inner IP header of packets,
   packets at the ingress of the IPsec tunnel, and decompression decompressing these
   headers at the egress.

   To accomplish realize HCoIPsec, this document proposes the use of Internet
   Protocol Header Compression [IPHC], Compressed Real Time Protocol
   [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust
   Header Compression [ROHC], to compress the inner headers of IP
   packets traversing within an IPsec tunnel.  However, since  Since these traditional HC
   schemes operate on a hop-by-hop basis, several extensions need to must be
   defined.  This document details a technique which will
   defined to enable their operation over IPsec SAs.  This document
   details a framework which will allow these traditional hop-by-hop HC
   schemes to be extended, and extended to operate between at IPsec SA endpoints.

   Currently,

   HCoIPsec primarily currently targets the application of HC to tunnel mode SAs as opposed SAs.
   However, future work may extend the framework to operate over
   transport mode SAs. SAs as well.  Transport mode SAs
   encrypt/authenticate only encrypt/
   authenticate the payload of an IP packet, leaving the
   original IP header
   untouched.  Intermediate routers subsequently use the original outer IP header
   to route the packet to a decryption device.  Therefore, if HC were
   mechanisms are extended to operate between IPsec transport-
   mode transport-mode SA
   endpoints, (de)compression functionality can only be applied only to the
   transport layer headers headers, and not to the IP header.  Since compression
   of transport layer headers alone does not provide substantial
   efficiency gains, it extending the HCoIPsec framework to support
   transport mode SAs is not integrated into HCoIPsec. left for future work.

2.  Audience

   The target audience includes those who are involved with the design
   and
   development of HC schemes, and IPsec mechanisms. implementations.  Since
   traditional IETF HC schemes are designed to operate on a hop-by-hop
   basis, they need to be modified to operate over IPsec SAs.
   Therefore, the authors target various HC and IPsec communities who
   may consider extending hop-by-hop HC schemes and IPsec protocols to
   meet the requirements put forward in this document.  Finally, this
   document is directed towards vendors developing IPsec devices which
   will be deployed in bandwidth-constrained, IP networks.

3.  Terminology

   Terminology specific to discussion of HCoIPsec is introduced in this
   section.

   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.

   Compressed Traffic

      Traffic that is processed by the compressor (compressed) using one
      of the existing profiles.  Note: This includes packets that might
      be compressor.  Packet headers are
      compressed using an "uncompressed" a compression profile.

   Uncompressed Traffic

      Traffic that is not processed by the compressor.  Instead, this
      type of traffic is bypassed by bypasses the HC process.

   HC Process

      Generic reference to either the compressor, decompressor, and or any
      supporting header compression (HC) components.

   IPsec Process

      Generic reference to the Internet Protocol Security (IPsec)
      process [IPSEC].

4.  Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode
    SAs

   IPsec mechanisms provide various security services for IP-based IP networks.  For example, ESP offers data origin authentication,
   connectionless integrity, anti-replay service, and limited traffic
   flow confidentiality [ESP].
   The benefits of IPsec mechanisms come at the cost of increased per-
   packet overhead in the network. per-packet
   overhead.  For example, traffic flow
   confidentiality, which is generally implemented confidentiality (generally
   leveraged at security gateways, gateways) requires the tunneling of IP packets
   between the IPsec devices. implementations.  Although these IPsec tunnels may will
   effectively mask the source-destination patterns that an intruder may can
   ascertain, but the benefit comes IPsec tunnels come at the cost of extra increased per-packet
   overhead.  An  Specifically, an 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 bandwidth-
   constrained wireless and/or Satellite Communications (SATCOM) satellite communications networks, as
   these types of infrastructure are not overprovisioned.  Consequently,
   the additional overhead incurred in an encryption-based environment
   may
   hinder result in the efficient inefficient utilization of bandwidth.

   In bandwidth-constrained, high bit error rate (BER) networks, IP

   Packet Loss Ratio (IPLR) can severely degrade end-host application
   performance.  The traditional means for combating IPLR on high BER
   links has been Error Correction Codes (ECC).  In addition, end-host
   applications may not have the luxury of sending packets with large
   payloads.  This overhead is due to the fact that large packets traversing high
   BER links result in high IP Packet Loss Ratio (IPLR).  To reduce
   IPLR, end-host devices may reduce the size of particularly significant for traffic profiles
   characterized by small packet payloads, which
   decreases the probability payloads.  Some applications that a
   emanate small packet is lost due to a bit error.
   Reducing the size of packet payloads, however, increases the amount
   of overhead transmitted between the two end hosts.  Moreover, payloads include various voice codecs (e.g.,
   G.729).  In addition, if these small packets traverse over are afforded the
   security services of an IPsec tunnel mode SA, the amount of per-
   packet overhead is further magnified.  A  Thus, a mechanism is needed to reduce
   the overhead associated with such flows.

5.  Overview of the HCoIPsec Framework

5.1.  HCoIPsec Assumptions

   The Header Compression Solution

   IP HC schemes provide one mechanism goal for HCoIPsec is to reduce packet overhead in an
   IP network.  Schemes such as IPHC, CRTP, ECRTP and ROHC exploit
   inter-packet redundancies provide more efficient transport of network IP
   packets between source and destination IPsec devices, without
   compromising the security services offered by IPsec.  As such, the
   HCoIPsec framework was developed based on the following assumptions:
   o  Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be
      leveraged to reduce the amount of overhead associated with packets
      traversing an IPsec SA
   o  HC algorithms will be instantiated at the IPsec SA endpoints, and
      HC is applied on a per-SA basis

5.2.  HCoIPsec Description

   HC schemes reduce packet overhead in a network by exploiting inter-
   packet redundancies of network and transport-layer header fields of a
   flow to reduce the amount of redundant header data transmitted
   between two nodes.

   To apply traditional HC schemes over IPsec SAs, several extensions to the
   existing schemes
   need to be developed. defined.  Existing HC schemes such as
   IPHC, CRTP, ECRTP and ROHC are designed to compress packet headers on a hop-
   by-hop
   hop-by-hop basis.  However, IPsec SAs, however, may be SAs are instantiated between two
   IPsec
   devices functioning as gateways, implementations, with multiple intermediary nodes hops between the IPsec gateways.
   implementations.  Therefore, to fully integrate HC with IPsec SAs,
   traditional hop-by-hop schemes need to be extended to operate between at
   IPsec SA endpoints.

   The migration of traditional hop-by-hop HC schemes over IPsec SAs is
   simple, as
   straightforward, since SA endpoints provide source/destination pairs
   where (de)compression operations can take place.  Compression in such
   a manner offers both a reduction of per-packet protocol overhead between
   the two SA endpoints, and does not require compression and
   decompression cycles at the intermediate network nodes hops between the IPsec devices.
   implementations.  Since HC schemes will now essentially operate over
   multiple hops, it is imperative that the performance of the HC
   schemes is not severely impacted due to increased packet reordering
   and/or IPLR events packet loss between the compressor and decompressor.  It
   should be noted that

   In addition, since HC schemes will operate at IPsec SA endpoints, HC
   schemes can no longer rely on the notion of extending hop-by-hop underlying link layer for HC
   parameter configuration and packet identification.  Traditionally, HC
   schemes use the underlying link layer to
   operate over multiple hops is not new, as establish a set of
   configuration parameters at each end of the link, and for identifying
   different types of header-compressed packets.  The HCoIPsec effort
   parallels other efforts such as ECRTP over MPLS [HCOMPLS]. framework
   proposes that HC session parameter configuration and header-
   compressed packet identification is accomplished by the SA management
   protocol (e.g., IKEv2) and the security protocol next header field,
   respectively.

   Using the HCoIPsec framework proposed architecture, below, outbound IP traffic
   processing at an IPsec device is augmented to 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 protocol and the inner IP header.

   Inbound IP traffic processing at an IPsec device is modified in a
   similar fashion.  For inbound packets, an IPsec device must first
   decrypt and/or integrity-check the packet.  Then, the IPsec device
   implicitly
   determines whether if the packet was received on a an HC-enabled
   SA. SA(see section
   6.1), and if the packet maintains compressed headers.  If both of
   these conditions are met, decompression of the inner packet was received over a HC-enabled SA, headers
   is performed.  After decompression, the
   decompression function takes place. packet is checked against the
   access controls imposed on all inbound traffic associated with the SA
   (as specified in RFC 4301).

      Note: Compression of inner headers is completely independent from compression
      of the outer security protocol (e.g., ESP/IP) headers.  Intermediate
      network nodes between IPsec endpoints may also compress the ESP) and outer
      ESP/IP IP headers.  Current  HC
      schemes such as ROHC and IPHC contain
      the ability to compress are capable of compressing these ESP/IP headers.
      outer headers on a hop-by-hop basis.  Further discussion
      of hop-by-hop on the
      compression of the outer ESP/IP headers is out of outside the scope of this
      document.

   If IPsec NULL encryption is applied on to packets, HC schemes may still
   be applied on to the inner headers at the IPsec SA endpoints.  Inbound
   and outbound packets are still processed as described previously.  In was previously described.
   For scenarios where NULL-encrypted packets traverse intermediate
   nodes between the IPsec SA endpoints, the intermediary nodes must not
   attempt to (de)compress the inner IP and/or transport layer headers
   on a hop-by-hop basis. headers.

6.  Integration Methodology

   The goal for HCoIPsec is to provide more efficient transport  Details of IP
   packets between source the HCoIPsec Framework

6.1.  HC and destination IPsec devices, via tunnel mode
   SAs, without compromising security services offered by Integration

   Based on these assumptions, Figure 1 illustrates the components
   required to integrate HC with the IPsec process, i.e., HCoIPsec.

                             +-------------------------------+
                             | HC Module                     |
                             |                               |
                             |                               |
        +-----+              |     +-----+     +---------+   |
        |     | HC-enabled   |     |     |     |    HC   |   |
      --|  A  |--------------------|  B  |-----| Process |------> Path 1
        |     |              |     |     |     |         |   |
        +-----+              |     +-----+     +---------+   |
           |                 |        |                      |
           |                 |        |-------------------------> Path 2
           |                 |                               |
           |                 +-------------------------------+
           |
           | HC-disabled
           +----------------------------------------------------> Path 3

   Figure 1: Integration of HC with IPsec.

   With this general goal

   The process illustrated in mind, Figure 1 augments the IPsec processing
   model for outbound IP traffic(protected-to-unprotected).  Initial
   IPsec processing is consistent with RFC 4301 (Steps 1-2, Section 5.1 defines a set
   5.1).  The HC data item (part of work
   assumptions to guide the direction of SA state information) retrieved
   from the HCoIPsec solution.  Based
   on these work assumptions, "relevant SAD entry" (RFC4301, Section 5.2 defines work items which need
   to be addressed 5.1, Step3a)
   determines if the traffic traversing the SA is handed to achieve the HCoIPsec solution.

6.1.  Work Assumptions

   a.  HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP,
       ROHC)
   module (Figure 1, decision block A).  Packets selected to reduce the amount of overhead associated with packets
       traversing an IPsec tunnel-mode SA.

   b.  HCoIPsec HC-
   disabled SA must execute (de)compression operations at follow normal IPsec SA
       endpoints, processing and must not perform (de)compression cycles at
       intermediate nodes between IPsec devices.
   c.  HCoIPsec must be independent of the underlying link layer framing
       protocol (e.g., PPP).
   d.  HCoIPsec must allow each SA sent
   to constitute a the HC channel, enabling
       each SA module (Figure 1, Path 3).  Conversely, packets selected to have its own CID space.
   e.  An
   an HC-enabled SA with HC enabled should not deliver a larger number of
       erroneous packets than must be sent to the same SA with HC disabled. module.  The motivation behind (c) comes from decision at
   block B then determines if the realization that an SA may
   traverse multiple links, employing various framing protocols, and packet can be compressed.  If it is
   determined that the set of links (and thus framing protocols) may change during packet will be compressed, the lifetime Next Header field
   of an SA.  Therefore, link layer dependencies exhibited
   by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec
   solution.

6.2.  Work Items

   This section identifies several work items that need to be addressed
   to achieve HCoIPsec.  The first work item encompasses security protocol header (e.g., ESP, AH) is populated with the HC scheme-
   specific extensions needed to ensure
   "compressed headers" value, and packet headers are compressed based
   on the appropriate compression profile (Figure 1, Path 1).  However,
   if it is determined that traditional hop-by-hop HC
   schemes the packet will operate efficiently over IPsec SA endpoints:

   a. Header Compression Scheme-Specific Extensions: Any modifications
      needed to not be made to existing compressed, the Next
   Header field is populated with the appropriate value indicating the
   next level protocol (Figure 1, Path 2).  After the HC schemes, which will facilitate
      their operation over process
   completes, IPsec SAs.  (Section 5.2.1)

   Hop-by-hop processing resumes, as described in Section 5.1,
   Step3a, of RFC4301 (specifically, "IPsec processing is as previously
   defined...").

   The process illustrated in Figure 1 also augments the IPsec
   processing model for inbound IP traffic (unprotected-to-protected).
   For inbound packets, processing is performed (RFC4301, Section 5.2,
   Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2,
   Step 4) .  After AH or ESP processing, the HC schemes use data item retrieved
   from the underlying link layer (e.g., PPP) SAD entry will indicate if traffic traversing the SA is
   handed to
   negotiate the HC channel parameters module (RFC4301, Section 5.2, Step 3a).  Packets
   traversing an HC-disabled SA must follow normal IPsec processing and
   must not be sent to indicate the type of
   compressed packet HC module.  Conversely, packets traversing an
   HC-enabled SA must be sent to the data-link layer frame is encapsulating.  To
   remove HC scheme dependencies on module.  The decision at block B
   then determines if the underlying link layer, two
   additional work items are proposed:

   b. Initialization and Negotiation of "Next Header" field contains the Header Compression Channel:
      Mechanisms needed to initialize a HC channel and negotiate HC
      scheme parameters prior to operation.  (Section 5.2.2)
   c. Encapsulation and Identification of Header Compressed Packets:
      Mechanisms "compressed
   header" value, which indicates that encapsulate and identify the packet's payload contains
   compressed header
      packets, as well as how these mechanisms will operate.  (Section
      5.2.3)

   Note: (c) headers.  If "compressed headers" is still being discussed within indicated, the community and
   appropriate decompression profile is
   subject to change.  More information about (c) can be found in applied (Figure 1, Path 1).
   However, if the
   "Alternatives to Achieving HCoIPsec" internet-draft, a document being
   used to help resolve HCoIPsec discussions and issues packet's "Next Header" field does not contain the
   "compressed headers" value, the decompressor must not attempt
   decompression (Figure 1, Path 2).  IPsec processing resumes once the
   HC module completes processing, as described in order to
   stabilize Section 5.2, Step 4
   of RFC 4301(specifically "Then match the HCoIPsec draft.

6.2.1. packet against the inbound
   selectors identified by the SAD ...").

6.1.1.  Header Compression Scheme-Specific Extensions

   a.  HCoIPsec should minimize Scheme Considerations

   Traditional hop-by-hop HC scheme performance degradation due schemes must be extended to operate
   efficiently over IPsec SAs.  Implementation considerations for this
   includes increasing tolerance to
       increased delays, packet loss, jitter, and reordering events and packet loss
   between the compressor and decompressor.
   b.  HCoIPsec should minimize decompressor, and minimizing the amount of HC signaling between
       compressor and decompressor.
   c.  HCoIPsec should support bi-directional communications
       functionality, used by certain HC schemes (e.g.  ROHC bi-
       directional mode).

   The intention of (b) is to indicate that if a
   feedback channel sent from the decompressor to the compressor.

   The ability to tolerate increased packet reordering between the
   compressor and decompressor is not used sparingly, then the
   overall gains from HCoIPsec can be significantly reduced (even more
   so than hop-by-hop HC).  For example, take the case where ROHC in bi-
   directional reliable mode a necessity for any HC scheme that is instantiated
   extended to operate over an IPsec tunnel mode SA.  Any feedback sent from  The following provides a
   summary of the decompressor candidate HC solutions, and their tolerance to packet
   loss and reordering between the compressor may be
   tunneled, and therefore, the additional overhead incurred by
   tunneling the feedback will reduce the overall benefits of HC.

   Note that if a HCoIPsec session requires bidirectional communication
   between the compressor and the decompressor (e.g., a ROHC session
   operating in bidirectional-reliable mode, or bidirectional-optimistic
   mode, or ECRTP and CONTEXT_STATE packets), this may pose an issue,
   given that SAs are unidirectional, and that HCoIPsec defines decompressor:
   o  IPHC has been identified as a HC
   context scheme that performs poorly over
      long round trip time (RTT), high BER links [ROHC].  Extensions to be specific
      IPHC to a given SA.  Any feedback compress TCP/IP headers over an IPsec SA should take into
      consideration longer RTTs, increased potential for packet
   communicated from the HCoIPsec decompressor to
      reordering and IPLR between the HCoIPsec compressor is over and decompressor.
   o  CRTP has also been identified as a separate SA back HC scheme that performs poorly
      over long RTT, high BER links [CRTPE].  Recent modifications to
      the original IPsec device.
   To identify the stale context, the feedback packet must contain the
   context ID as well CRTP scheme, such as an indication of the SA that ECRTP, enable the decompressor
   is associated to.  This poses a problem for current CRTP HC algorithm
   feedback packets, which are not structured scheme to carry
      tolerate long RTTs and packet loss between the additional SA
   indication information.  For example, current ECRTP feedback
   mechanisms (e.g., CONTEXT_STATE) only list compressor and
      decompressor.  However, the CIDs for which
   synchronization has been lost.  If a bidirectional HC algorithm is reordering tolerance of ECRTP still
      needs to be integrated with IPsec, additional HC scheme-specific extensions
   must evaluated, as detailed in [ECRTPE].  Such
      implementation aspects should be defined taken into consideration when
      extending ECRTP to resolve this issue.

6.2.2.  Initialization and Negotiation of Header Compression Channel

   Initialization of the operate over IPsec SAs.
   o  ROHC is a robust HC channel will be achieved manually (i.e.,
   administratively configured scheme that is designed for manual SAs), or will be performed by
   IPsec SA establishment protocols, e.g.  IKE.  During SA
   initialization, the type of HC scheme configured for the SA, as well
   as the HC scheme's channel parameters will high BER, long RTT
      links.  ROHC can be identified.

   a.  HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel
       parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES,
       MAX_CID, MAX_HEADER, MRRU).
   b.  HCoIPsec must allow packets with uncompressed headers and packets
       with compressed headers to traverse a single SA.  "Packets with
       compressed headers" refer to packets which are selected to an HC-
       enabled SA, are passed to the compressor, and are actually
       compressed; "packets with uncompressed headers" refer to packets
       which are selected used to an HC-enabled SA, are passed compress not only RTP/UDP/IP headers,
      but also other traffic profiles such as TCP/IP, as defined in
      [ROHCTCP].  Similar to the
       compressor, CRTP and are not "compressed" (e.g., IPHC, ROHC compressor
       processes a has been identified as
      vulnerable to packet with reordering events between the uncompressed profile).

   Note: (b) is necessary in situations where a compressor--can not
   compress a flow (e.g., a compressor supports strictly n compressed
   flows, and can not compress the n+1 flow
      decompressor[ROHCE].  Recent work [ROHCWEXT] suggests that arrives).

   Note: (b) is still being discussed within the community and is
   subject to change.  More information about (b)
      implementation aspects of ROHC can be found in the
   "Alternatives modified to Achieving HCoIPsec" internet-draft, a document being
   used achieve
      tolerance to help resolve HCoIPsec discussions and issues in order packet reordering events.  Such implementation
      aspects should be taken into consideration when extending ROHC to
   stabilize
      operate over IPsec SAs.

   In addition, HC schemes should minimize the HCoIPsec draft.

6.2.3.  Encapsulation and Identification amount of Header Compressed Packets

   For indication purposes, feedback
   between decompressor and compressor.  If a one-byte header may be added to the
   compressed packet; this field will help feedback channel from the
   decompressor identify how
   to process the compressed packet.  This one-byte header is only
   relevant to the HC compression and decompression processes, and compressor is not used by IPsec..

   a.  HCoIPsec must indicate sparingly, the type of compressed packet (e.g., for
       ECRTP, COMPRESSED_RTP_8, COMPRESSED_RTP_16, CONTEXT_STATE, etc.)
       on a per packet basis.

   Note overall
   gains from HCoIPsec can be significantly reduced.  For example,
   assume that ROHC indicates its own packet type within the protocol, is operating in bi-directional reliable mode, and
   does not require a new one-byte header to indicate is
   instantiated over an IPsec tunnel mode SA.  In this scenario, any
   feedback sent from the type of
   compressed packet.

   Note: Alternatives decompressor to using a "one-byte header" are still being
   discussed within the community, thus this section may change.  More
   information can compressor must be found in
   tunneled.  As such, the "Alternatives to Achieving HCoIPsec"
   internet-draft, a document being used to help resolve HCoIPsec
   discussions additional overhead incurred by tunneling
   feedback will reduce the overall benefits of HC.

6.1.2.  Initialization and issues in order to stabilize Negotiation of HC Channel

   Hop-by-hop HC schemes use the HCoIPsec draft.

7.  Candidate Compression Schemes

   IPHC can be used underlying link layer (e.g., PPP) to compress TCP/IP headers for tunnel mode SAs.

   IPHC, however, has been identified as a
   negotiate HC channel parameters.  To remove HC scheme that performs
   poorly over long round trip time (RTT), high BER links [ROHC].
   Extensions to IPHC to compress TCP/IP headers over an IPsec SA need
   to take into consideration longer RTTs, increased potential for
   packet reordering and IPLR between dependencies on
   the compressor and decompressor.

   CRTP can be used underlying link layer, an additional mechanism is needed to compress RTP/UDP/IP headers for tunnel mode SAs.
   CRTP, however, has also been identified as
   initialize a HC scheme that performs
   poorly over long RTT, high BER links [CRTPE].  Recent modifications channel and its associated parameters prior to the CRTP scheme, such as ECRTP, enables the CRTP HC
   scheme to
   tolerate long RTTs, packet loss, between compressor and decompressor.
   The reordering tolerance operation.

   Initialization of ECRTP, however, needs to the HC channel will either be evaluated, as
   detailed in [ECRTPE].  Such implementation aspects should achieved manually
   (i.e., administratively configured for manual SAs), or be taken
   into consideration when extending ECRTP to operate between performed
   by IPsec SA
   endpoints.

   ROHC, as defined in RFC 3095, provides a robust HC scheme that is
   designed for high BER, long RTT links.  This makes ROHC another
   candidate header scheme to operate over IPsec tunnels.  ROHC can be
   used to compress not only RTP/UDP/IP headers, but also TCP/IP
   headers, as defined in [ROHCTCP].  Similar to CRTP and IPHC, ROHC has
   been identified as vulnerable to packet reordering events between the
   compressor and decompressor[ROHCE].  Recent work [ROHCWEXT] suggests
   that establishment protocols, e.g.  IKEv2.  During SA
   initialization, the implementation aspects of ROHC can be modified to achieve
   tolerance to packet reordering events.  Such implementation aspects
   should SA establishment protocol will be taken into consideration when extending ROHC extended to operate
   between IPsec SA endpoints.
   negotiate the HC scheme's channel parameters.  The ability to tolerate these network characteristics is a necessity specifics for any HCoIPsec scheme, and will be a factor this
   proposal are detailed in determining how
   efficiently a separate spectification, "IKEv2/IPsec
   Extensions to Support HCoIPsec".

   If the HC scheme operates over requires bi-directional communications, two SAs must
   be instantiated between the IPsec tunnel-mode SAs.

8.  Example Operation

   The basic operation implementations.  One of the HCoIPsec protocol two
   SAs is detailed in used for carrying traffic from the
   following example.  Assume there are two IPsec devices operating as
   security gateways.  HCoIPsec leverages an SA establishment protocol
   (e.g., IKE, IKEv2) compressor to negotiate the HC scheme, and channel
   parameters.  For example,
   decompressor, while the MAX_CID, MRRU, MAX_HEADER, and PROFILES
   parameters will be negotiated for each IPsec SA which other is capable of
   ROHC.  For an used to communicate feedback from
   the decompressor to the compressor.  IPsec implementations will
   dictate how decompressor feedback received on one SA that is ECRTP-enabled, channel parameters
   including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression
   Suboption will be initialized.  For associated
   with a compressor on the following example, assume
   that other SA.

6.1.3.  Encapsulation and Identification of Header Compressed Packets

   As indicated in section 6.1, new state information (i.e., a SA has been established.

   Outbound packet processing new HC
   data item) is as follows. defined for each SA.  The packet HC data item is initially
   processed as described in Steps 1-2, Section 5.1 of RFC 4301.  The
   SPD cache entry then maps used by the packet
   IPsec process to determine whether it sends all traffic traversing a
   given SAD entry, which
   indicates the HC protocol enabled on the SA (in addition to mode,
   cryptographic algorithms, keys, etc.).  If the SAD entry indicates
   that compression is disabled, then standard IPsec processing ensues,
   as described in Steps 3-4, Section 5.1 of RFC 4301.  If the SAD entry
   indicates that compression is enabled, the packet must be handed to the appropriate compressor, which executes the compression process.
   After HC module (HC-enabled) or bypasses the packet's header is compressed, HC module and
   sends the packet resumes IPsec
   processing as described in Step 3a, where standard traffic through regular IPsec ESP processing ensues (including packet encryption according to the SAD
   entry parameters, packet encapsulation with the outer ESP/IP header)
   and is subsequently passed to (HC-disabled).

   In addition, the outbound forwarding function, as
   described in Step 4 of RFC 4301.

   Inbound packet processing is as follows.  The packet is initially
   processed as described in Steps 1-3, Section 5.2 "Next Header" field of RFC 4301;
   subsequently (using the SAD entry selected in Step 3a), ESP
   processing IPsec security protocol
   (e.g., AH or ESP) header is applied.  Based on information retrieved used to demultiplex header-compressed
   traffic from the SAD
   entry, it can also be determined whether uncompressed traffic traversing the SA an HC-enabled SA.  This
   functionality is
   compressed or needed in situations where packets traversing an HC-
   enabled SA are not compressed.  If compressed by the SAD entry indicates that
   compression is compressor.  Such situations may
   occur when, for example, a compressor supports strictly n compressed
   flows and can not enabled on the SA, then standard IPsec processing
   of compress the packet ensues, as described in Step 4, Section 5.2 of RFC
   4301.  If compression n+1 flow that arrives.  Another
   example is enabled on the SA, the packet when traffic (e.g., TCP/IP) is handed selected to
   the decompressor for "decompression".  Once the packet is
   decompressed, the processing as described in Step 4, Section 5.2 of
   RFC 4301 resumes (specifically "Then match the packet against the
   inbound selectors identified an HC-enabled
   SA, but cannot be compressed by the SAD...").

   Figure 1 depicts HC process (e.g., because the basic function of HCoIPsec:

                  -- --  --  --  --  --  --  --  -- --
                 |ESP Tunnel Mode Security Association|
                 |                                    |
                 |                                    |
                 V                                    V
            +--------------+                 +--------------+
            | IPsec Device |   +--+   +--+   | IPsec Device |
            |              |   |  |   |  |   |              |
        +---|  Compressor  |-->|R1|-->|R2|-->| Decompressor |---+
        |   |              |   |  |   |  |   |              |   |
        |   +--------------+   +--+   +--+   +--------------+   |
        |                  |                 |                  |
        |                  |-----------------|                  |
        |                           |                           |
        |                           |                           |
        V                           V                           V
   +-----------------+  +-----------------------+  +-----------------+
   |   |     |       |  |   |   |               |  |   |     |       |
   |   | UDP |       |  |   | E | ------------- |  |   | UDP |       |
   |IP |  /  |Payload|  |IP | S | |CID|Payload| |  |IP |  /  |Payload|
   |   | RTP |       |  |   | P | ------------- |  |   | RTP |       |
   |   |     |       |  |   |   |               |  |   |     |       |
   +-----------------+  +-----------------------+  +-----------------+
                                |               |
                                |---ENCRYPTED---|
                                |               |

   Figure 1: Example operation of HCoIPsec.
   compressor does not support TCP/IP compression).  In these
   situations, the example scenario, note compressor must be able to indicate that the inbound and outbound packet
   contains uncompressed headers.  Similarly, the decompressor must be
   able to identify packets
   are first mapped with uncompressed headers and not attempt to
   decompress them.  Therefore, an SA, and then subsequently mapped allocation for "compressed headers"
   will need to be reserved from the IANA "Protocol Numbers" registry,
   which will be defined in a CID.
   This implies separate specification.  The "compressed
   headers" value will indicate that the scope of each CID next layer protocol header is contained within each SA.
   A CID value
   composed of 1 can be associated with multiple SAs; however, the
   context state information for CID 1 cannot be shared over multiple
   SAs.

9.  Future Work Items

9.1. compressed headers.

6.2.  HCoIPsec Transport Mode SAs

   Many of the current HC profiles look Framework Summary

   [Note to simultaneously compress
   network and transport layer headers of IP packets.  This makes the
   extension of traditional HC schemes over transport-mode SAs more
   difficult.  For RFC Editor: this section may be removed on publication as an
   RFC.]

   To summarize, the application of HC over transport mode SAs, following items are needed to achieve HCoIPsec:
   o  Extensions to traditional HC schemes may need which enable their operation
      at IPsec SA enpoints
   o  Extensions to be extended IKE/IPsec to operate strictly on
   layer 4 (e.g., TCP, and/or RTP/UDP) headers.  The specification for
   HCoIPsec transport mode SAs is left support HC parameter configuration
   o  Allocation of one value for further study.

10. "compressed headers" from the IANA
      "Protocol Numbers" registry

7.  Security Considerations

   A malfunctioning header compressor (i.e., the compressor located at
   the ingress of the IPsec tunnel; used during outbound processing) tunnel) has the ability to send packets to
   the decompressor (i.e., the decompressor located at the egress of the
   IPsec tunnel; used during
   inbound processing) tunnel) that do not match the original packets emitted from the
   end-hosts.  In such a scenario, the invalid packets will
   pass through inbound IPsec processing, and will subsequently be
   validly decompressed.

   Furthermore, an intruder who has the ability to arbitrarily inject
   packets between SA endpoints, and addresses these malicious packets
   to the encryption/decryption devices, has the ability to cause
   context corruption between the compressor and decompressor processes
   instantiated within the IPsec device (if the malicious packet passes
   through the decryption process).  Such a scenario will result in a decreased efficiency
   between compressor and decompressor, and
   furthermore, decompressor.  Furthermore, this may result in
   Denial of Service, as the decompression of a significant number of
   invalid packets may drain the resources of an IPsec device.

      Note: It should be noted, however, that these security issues are
      a direct result of IPsec vulnerabilities.

11.

8.  IANA Considerations

   None.

12.

9.  Acknowledgments
   The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
   and Ms. Linda Noone of the Department of Defense, and well as Mr. A.
   Rich Espy of OPnet for their contributions and support for developing in the
   development of this document.  The  In addition, the authors would also 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. Jan Vilhuber, Vilhuber
   o  Mr. Dan Wing, of Cisco
   Systems, Mr. Lars-Erik Jonsson and Wing
   o  Mr. Kristopher Sandlund of
   Ericsson for their valuable contributions to this document.  The

   Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
   Renee Esposito, Mr. Etzel Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin Jonah Pezeshki of Booz
   Allen Hamilton for their assistance in completing this work.

13.

10.  References

13.1.

10.1.  Normative References

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

   [IPHC]     Nordgren, M., Pink, B., and S. Pink, "IP Header
              Compression", RFC 2507, February 1999.

   [CRTP]     Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              February 1999.

   [ECRTP]    Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on
              Links with High Delay, Packet Loss, and Reordering",
              RFC 3545, July 2003.

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

   [ECRTPE]   Knutsson, C., "Evaluation and Implemenation[sic] of Header
              Compression Algorithm ECRTP", November 2004.

   [ROHCTCP]  Pelletier, G. and et. al, "Robust Header Compression: A
              Profile For TCP/IP (ROHC-TCP)", work in progress ,
              January 2006.

   [ROHCWEXT]
              Pelletier, G. and et. al, "ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.

13.2.

10.2.  Informative References

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

   [HCOMPLS]  Ash, J. and et. al, "Protocol Extensions for Header
              Compression over MPLS", April 2005.

   [CRTPE]    Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
              "Evaluation of CRTP Performance over Cellular Radio
              Networks", IEEE Personal Communication Magazine , Volume
              7, number 4, pp. 20-25, August 2000.

   [ROHCE]    Ash, J. and et. al, "Requirements for ECRTP over MPLS",
              RFC 4247, November 2005.

   [AAL2]     ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
              AAL", I.363.2 , September 1997.

Authors' Addresses

   Emre Ertekin
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: ertekin_emre@bah.com

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

   Email: christou_chris@bah.com

   Rohan Jasani
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: jasani_rohan@bah.com

Intellectual Property Statement

   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.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.