[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                        J. Vilhuber
INTERNET DRAFT                                        Cisco Systems Inc.
Expire in December, 2004                                       January, 2003



                   IP header compression in IPsec ESP
                     <draft-vilhuber-hcoesp-01.txt>





Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.


   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/1id-abstracts.html


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


   Distribution of this memo is unlimited.


Abstract


   This draft outlines how to use IP Header compression over IP tunnels
   [HCOIP] inside IPsec ESP [ESP].




















Vilhuber                                                        [Page 1]


INTERNET DRAFT               July, 2004         Expires December, 2004



1.  Introduction


   [HCOIP] defines a new IP protocol number (and IPv6 Next Header) value
   for IP Header Compressed payloads for use in tunneling protocols over
   IP. This draft outlines exactly how to encapsulate IP Header
   Compressed packets into an ESP packet.


   In this document, the key words "MAY", "MUST", "optional",
   "recommended", "required", "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [RFC2119].


2. IP header compressed packets in ESP


   [HCOIP] defines a number-space for the "Header Compression Payload
   Type" as well as a new IP protocol number, which can be used to
   indicate that a packet inside ESP has been previously header
   compressed.


   Note that not all packets that fall under a certain ESP SA may be
   header compressed. Whether a packet is header compressed or not
   depends on whether the compressor has an empty slot for a flow, and
   whether the packet is deemed compressible by the compressor. Hence,
   we can not simply assume that all packets under an ESP SA with header
   compression will be compressed. We need an explicit indication, hence
   the need for the new IP protocol number in [HCOIP].


2.1. Order of processing of outbound packets


   On outbound processing, the relevant SA bundle is found in whatever
   manner the implementation uses. The SA bundle MUST indicate that
   header compression needs to be attempted for this packet. The SA
   should contain enough information to retrieve the relevant
   compression context for this flow.


   Header compression MUST be done before any other ESP or IPCOMP
   processing. Any fragmentation decisions MUST be made on the result of
   the header-compressed packet, rather than on the original (un-header-
   compressed packet).


   Original (pre-IPsec packet):


     +-------------+
     |  IP  | Data |
     +-------------+


   Header Compression is done, which removes the IP (and possibly other)
   headers, replacing it with the appropriate compression context as
   defined by [IPHC], [CRTP], and/or [ECRTP]:


     +----------------------------+
     | Comp ID and context | Data |
     +----------------------------+


   [HCOIP] header is prepended:




Vilhuber                                                        [Page 2]


INTERNET DRAFT               July, 2004         Expires December, 2004



     +---------------------------------+
     | Comp Type | Comp context | Data |
     +---------------------------------+


   [ESP] is performed (including fragmentation decisions and possibly
   [IPCOMP]) as usual, with next header set to IPHC:


     +---------------------------------------------------------------------+
     | IP | ESP-SPI | SEQ | IV | Comp Type | Comp context | Data | Trailer |
     +---------------------------------------------------------------------+


   An example of an ESP packet carrying a header compressed packet is as
   follows:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Security Parameters Index (SPI)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
   |         IV (depends on the cipher used; variable)             | ^ ESP
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload
   |   Comp Type   |    Header Compressed Data (variable)          | | Data
   +-+-+-+-+-+-+-+-+                                               + |
   ~                                                               ~ |
   |                                                               | |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |               |     Padding (0-255 bytes)                     | v
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
   |                               |  Pad Length   |  IPHC Proto   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Authentication Data (variable)                |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Depending on the cipher used, the start of the ESP Payload data is
   used as the IV. The length (and presence or absence) of the IV is
   implicit knowledge, known to both sides.


   "Comp Type" is the [HCOIP] header, and will be the first byte of the
   plaintext payload. The rest of the Payload Data is the compressed
   packet, the format of which conforms to the relevant RFC that covers
   the type indicated in Comp Type (see [HCOIP] table 1).



2.2. Order of processing of inbound packets


   On receiving an IPsec packet, the regular SA-lookup is used to
   determine the SA bundle needed for decryption (decapsulation and
   decompression). The SA bundle should carry enough information to
   retrieve the decompression context.





Vilhuber                                                        [Page 3]


INTERNET DRAFT               July, 2004         Expires December, 2004



   If the receiver gets a packet with IP protocol IPHC, but the SA
   bundle does not indicate that compression has been negotiated for
   this SA, the packet MUST be dropped.


   Since Header compression is the first thing done during
   encryption/encapsulation, decompression is the last thing done. After
   decapsulation and decryption (and maybe IPCOMP decompression), if the
   resulting packet has a protocol type of IPHC, then the [HCOIP] header
   is removed, and the packet along with the [HCOIP] type (from the
   header), along with the decompression context stored with the IPsec
   SA, MUST be handed to the decompressor.


   After decompression, the decompressed packet MUST be checked against
   the SADB as normal, and dropped, if the packet does not match the
   SADB.


2.3. Decompressor Error handling


   In the event that the decompressor has no appropriate compression
   slot (as identified by the compression ID; see [IPHC]) for the packet
   handed to it, the packet MUST be dropped. There is no error
   indication that can be communicated to the peer.


   In the event that the decompressor is out of sync with the compressor
   (i.e. a decompression context for this Compression ID exists, but
   packet loss has occurred), the decompressor may need to communicate a
   CONTEXT_STATE packet back to the compressor. This packet MUST be sent
   back through the IPsec Tunnel, i.e. must be encrypted and
   encapsulated using the correct SA, i.e. the SA we would use to send
   ESP packets to the peer. The out-of-sync packet MUST be dropped.


   Should the Compressor receive a CONTEXT_STATE packet that has not
   been authenticated via IPsec, then, as per [SECARCH], the packet MUST
   be dropped and ignored.


   On receipt of a valid CONTEXT_STATE packet, the receiver, who was the
   sender of the packet that failed to decompress, will invalidate any
   contexts listed in the CONTEXT_STATE packet, as per [RFC2507] (and
   various addenda in [RFC2508] and [ECRTP]).



3.  Security Considerations



3.1. Removing plain-text


   Omitting the IP (as well as TCP or UDP/RTP) header removes a large
   amount of known (or guess-able) plaintext from the to-be-encrypted
   payload. While this can benefit security it still should not be
   relied upon as a replacement for a strong cryptographic mechanism.








Vilhuber                                                        [Page 4]


INTERNET DRAFT               July, 2004         Expires December, 2004



3.2. Active Attack Analysis


   There is some concern about what an attacker can or can not do to the
   decompressor, even when protected with ESP. We assume that an
   attacker can not modify packets, because of ESP protection. For this
   reason, it is recommended that ESP not be run without authentication,
   even when esp-null is used.


   Whether an attacker can look at the packets (i.e. a passive attacker)
   has no immediate relevance to header compression.


   An active attacker can drop packets, or insert fake ones. Fake ones
   will be discarded by IPsec, but dropped packets can have an influence
   on the decompressor as outlined in the following sections.



3.2.1 COMPRESSED_TCP, COMPRESSED_UDP, and COMPRESSED_RTP packets



   DELTA fields depend on the number of packets we receive and send,
   i.e. DELTA fields depend on the value of sent in the preceding
   FULL_HEADER packet, and we increment the field value by a fixed,
   known delta for each packet received. There are well-defined
   algorithms that try to help detect dropped packets and correct in
   those situations. However, to be conservative, we should assume that
   dropped packets MAY influence DELTA fields (however, see below).


   Likewise, any INFERRED fields that depend on DELTA fields could be
   decompressed wrong (but most INFERRED fields do not, in fact, depend
   on DELTA fields).


   An attacker can NOT influence any NOCHANGE fields, as those are
   explicitely copied from the compression context set up (and
   refreshed) via FULL_HEADER packets, which can not be tampered with.
   Examples of NOCHANGE fields are IP addresses (src and dst), protocol,
   and src and dst ports. RANDOM fields are carried explicitely in the
   compressed packet and thus can not be tampered with, either. Examples
   of RANDOM fields are checksums.


   An attacker can also not change any of the data in the packet by
   selectively dropping packets, as the header compression mechanisms do
   not affect the data.


   So the best an attacker could do is influence DELTA fields, which are
   generally sequence numbers, by selectively and intelligently dropping
   packets. If the higher level protocol uses checksums (as TCP does,
   and, mostly, UDP as well), then mis-decompression due to dropped
   packets will be detected by the recipient of the mis-decompressed
   packet.


   For TCP packets, it is presumed that the end-host will detect and
   discard any "off-by-k" sequence numbers via the TCP checksum. Neither
   TCP nor UDP checksums cover anything in the IP header other than the
   pseudo-header, which doesn't cover parts of the IPv4 header, nor




Vilhuber                                                        [Page 5]


INTERNET DRAFT               July, 2004         Expires December, 2004



   large parts of the IPv6 headers.


   [CRTP] contains a 4 bit sequence number, to detect dropped packets
   within a 16 packet window.


   As long as the affected DELTA fields are covered by a higher level
   checksum (i.e. UDP or TCP checksum), then attacking the data-stream
   by selectively dropping some packets amounts to a denial of service
   attack, which the attacker could perpetrate anyway, if he can drop
   packets at will.


   If the DELTA fields are not covered by a higher level i.e. UDP or
   TCP) checksum, then these fields could be wrong after decompression
   and the recipient may not notice. A new kind of HDRCKSUM similar to
   the one defined in [ECRTP] should be devised to counteract this.



3.2.2 COMPRESSED_NON_TCP and COMPRESSED_TCP_NODELTA



   As per [RFC2507], COMPRESSED_NON_TCP packets do not use differential
   coding, and all fields are assumed to be NOCHANGE. If a NOCHANGE
   field changes, a FULL_HEADER packet is sent, instead. Thus dropping
   packets in this case has no effect on the values of the decompressed
   packets.


   COMPRESSED_TCP_NODELTA "is only sent in response to a header request
   from the decompressor" [RFC2507]. Since there are no DELTA fields in
   this packet type, dropping this packet (which, in any case is not
   sent during normal operation) has no effect (except causing more
   drops, i.e. more denial of service).



3.2.3 Future compressed headers


   This analysis covers only known header-compression types known at the
   time of this writing  (see section 6. References). Any future new
   compressed types of additional compressed headers should consider the
   impact separately, following a similar analysis as in the previous
   sections.


   NOCHANGE and RANDOM fields can be safely ignored. They are safe.
   INFERRED fields are safe as long as they do not depend on DELTA
   fields. DELTA fields need to be considered on a case by case basis,
   and should be covered by some checksum.


   Checksums should never be optional. Alternatively, a scheme like
   [ECRTP]'s HDRCKSUM should be used (see 3.2.3 as well).


3.2.3 Future work


   As eluded to earlier, a simple way to fix this entire dilemma of
   DELTA headers and decompression, is to define a checksum similar to
   [ECRTP] HDRCKSUM, which covers the entire header that was compressed,




Vilhuber                                                        [Page 6]


INTERNET DRAFT               July, 2004         Expires December, 2004



   but none of the data, define the TCP and UDP checksums as INFERRED,
   and carry ONLY the HDRCKSUM in the compressed packet. Since ESP
   packets, when used with authentication, already verify that the data
   hasn't been tampered with, we can re-calculate the TCP and UDP
   checksums during decompression, as long as we have a way to verify
   that the decompressed headers are exactly the same as they were prior
   to compression. The HDRCKSUM gives us this assurance, and thus the
   mechanism is secure.


   The cost is extra processing at the decompressor (who needs to
   calculate TCP or UDP checksums, which include the data of the
   packet).


4.  IANA Considerations


   There are no IANA Considerations.


5.  Acknowledgments


   This document is derived in part from discussions with Cheryl Madson,
   David McGrew, Mark Gillott, Patrick Ruddy, and Dan Wing.


6.  References


   [IPHC]   Degermark, M., Nordgren, B. and S. Pink, "Header
            Compression for IP", 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, Casner, Geevarghese, Thompson, Ruddy, "Compressing
            IP/UDP/RTP headers on links with high delay, packet loss
            and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in
            progress, February 2002


   [ESP]    Kent, S., Atkinson, R., "IP Encapsulating Security
            Payload", RFC 2406, November 1998


   [SECARCH] Kent, S., Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC 2401, November 1998


   [HCOIP]  Vilhuber, "IP header compression in IP tunneling protocols",
            draft-vilhuber-hcoip-00.txt, work in progress, July, 2004


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


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








Vilhuber                                                        [Page 7]


INTERNET DRAFT               July, 2004         Expires December, 2004



7.  Editor's Address


        Jan Vilhuber
        <vilhuber@cisco.com>
        Cisco Systems, Inc.





















































Vilhuber                                                        [Page 8]


Network Working Group                                       J. Vilhuber
INTERNET DRAFT                                        Cisco Systems Inc.
Expire in December, 2004                                      July, 2004



            IP header compression in IP tunneling protocols
                     <draft-vilhuber-hcoip-01.txt>





Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.


   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/1id-abstracts.html


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


   Distribution of this memo is unlimited.


Abstract


   Bandwidth consumption of RTP flows can be reduced by tunneling and
   compressing headers.  This draft defines an IP protocol number and a
   header which can be used to transport IP Header Compressed [IPHC],
   Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets
   over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce
   bandwidth consumption for RTP flows.
















Vilhuber                                                        [Page 1]


INTERNET DRAFT                July, 2004           Expires December, 2004



1.  Introduction


   IP header compression [IPHC] and RTP compression [CRTP] can be used
   to reduce bandwidth consumption, but are only defined for single hops
   over connections with little to no loss and no packet reordering.


   [ECRTP] extends the definition of IP header compression to be used
   over lossy links with the possibility of packet reordering. I.e.
   ECRTP can be used in protocols that run over the Internet at large.


   In general, it turns out to be useful to carry IP Header Compressed
   packets over an IP tunnel (IP-in-IP or IPSec tunnel mode, for
   example), either because the combination (tunnel+HC) is smaller than
   the original packet, or because the traffic is already flowing over
   an existing tunnel, which we could take advantage of.


   This draft recommends that ECRTP is used in the majority of these
   cases, as it is expected that the underlying network does not meet
   the criteria for reliable use of IPHC or CRTP. However, this draft
   does not exclude IPHC and CRTP, as there may be situations where the
   underlying network is well-known to be robust against loss and
   reordering.


   In this document, the key words "MAY", "MUST", "optional",
   "recommended", "required", "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [RFC2119].


2. IP header compression packet format


   [IPHC], [CRTP], and [ECRTP] only define the compression mechanisms
   and compressed packet formats, but leave defining the transport of
   this compressed packet to the underlying transport mechanism.


   In this vein, [PPPHC] extends the PPP Data Link Layer Protocol Field
   values to include the needed Compression Payload Types. For exactly
   the same reason, we need to define the Compression Payload Types used
   when carrying a header-compressed packet over an IP tunnel in this
   draft.


   The types of Compression Payloads are scattered over [IPHC], [CRTP],
   and [ECRTP]. The following table names the Compression Payload Type,
   gives each a number, and specifies which document to look at for the
   exact definition of the Compression Type.


      Header Compression Payload Type       Value             Defined in
      ------------------------------------------------------------------
      IPHC_FULL_HEADER                        0               IPHC/CRTP
      IPHC_COMPRESSED_NON_TCP                 1               IPHC/CRTP
      IPHC_COMPRESSED_TCP                     2               IPHC
      IPHC_COMPRESSED_TCP_NODELTA             3               IPHC
      IPHC_CONTEXT_STATE                      4               IPHC/ECRTP
      IPHC_COMPRESSED_UDP_8                   5               CRTP/ECRTP
      IPHC_COMPRESSED_UDP_16                  6               CRTP/ECRTP
      IPHC_COMPRESSED_RTP_8                   7               CRTP/ECRTP




Vilhuber                                                        [Page 2]


INTERNET DRAFT                July, 2004           Expires December, 2004



      IPHC_COMPRESSED_RTP_16                  8               CRTP/ECRTP
      Reserved by IANA                      9-255


      Table 1: Header Compression Payload Types



2.1. IP header compression packet format in IPv4


   When carried over IPv4, IP header compressed packets will have the
   following header prepended:


       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      !   Comp Type   !
      +-+-+-+-+-+-+-+-+


      Figure 1: IPv4 IP Header Compression Header



   "Comp Type" is a 1 byte field that carries the "Header Compression
   Payload Type" value (as defined in Table 1), that indicates the type
   of compressed payload that follows the header.


   Anything following the 1 byte Comp Payload type field is Compression
   context and data, in accordance with the respective type, as defined
   in the respective documents (see Table 1).


   The IPv4 Protocol Number for IP Header compressed packets as defined
   in this draft shall be XXX [TBD IANA].


2.2. IP header compression packet format in IPv6


   When carried inside IPv6, an IP header compressed packet will be have
   the IP Header Compression Header prepended.


       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Header   |   Comp Type   !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Figure 2: IPv6 IP Header Compression Header



   The Next Header field is a regular IPv6 Next Header field.


   "Comp Type" is a 1 byte field that carries the "Header Compression
   Payload Type" value (as defined in Table 1), that indicates the type
   of compressed payload that follows the header.


   Anything following the 1 byte Comp Payload type field is Compression
   context and data, in accordance with the respective type, as defined
   in the respective documents (see Table 1).


   The IPv6 Next Header value for IP header compressed packets as




Vilhuber                                                        [Page 3]


INTERNET DRAFT                July, 2004           Expires December, 2004



   defined in this draft shall be XXX [TBD IANA]


3.  Security Considerations


   This draft does not change the security of any protocol, as it merely
   provides a mechanism to carry header-compressed packets within
   another IP protocol.


   That being said, this draft allows us to carry IP header compressed
   packets inside IPsec ESP, which provides a way to carry header-
   compressed packets over the Internet in a secure way.


   When encryption is used, as in IPsec ESP tunnels, omitting the IP (as
   well as TCP or UDP/RTP) header removes a large amount of known (or
   guessable) plaintext from the to-be-encrypted payload. While this can
   benefit security it still should not be relied upon as a replacement
   for a strong cryptographic mechanism.


4.  IANA Considerations


   IANA is requested to create a new assignment registry for "Header
   Compression Payload Type Values", initially allowing values in the
   range 0 to 255 decimal.


   Assignment of values in this field require:
         -  the identity of the assignee
         -  a brief description of the new Header Compression Payload type
         -  a reference to a stable document describing the Header
            Compression Payload in detail.


   During the first year of existence of this registry, IANA is
   requested to refer all requests to the IETF <TBD> WG for review.
   Subsequently, requests should be reviewed by the IETF <TBD> Area
   Directors or by an expert that they designate.


   If the number of assignments begins to approach 255, the <TBD> Area
   Directors should be alerted.


5.  Acknowledgments


   This document is derived in part from discussions with Cheryl Madson,
   Mark Gillott, Patrick Ruddy, and Dan Wing.


6.  References


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


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


   [PPPHC]  Engan, Casner, Bormann, "IP Header Compression over PPP",
            RFC 2509, February 1999




Vilhuber                                                        [Page 4]


INTERNET DRAFT                July, 2004           Expires December, 2004



   [ECRTP]  Koren, Casner, Geevarghese, Thompson, Ruddy, "Compressing
            IP/UDP/RTP headers on links with high delay, packet loss
            and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in
            progress, February 2002


   [ESP]    Kent, S., Atkinson, R., "IP Encapsulating Security
            Payload", RFC 2406, November 1998


   [IPIP]   Perkins, "IP Encapsulation within IP", RFC 2003, October 1996


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



7.  Editor's Address


        Jan Vilhuber
        <vilhuber@cisco.com>
        Cisco Systems, Inc.






































Vilhuber                                                        [Page 5]