Network Working Group J. Vilhuber
INTERNET DRAFT Cisco Systems Inc.
Expire in July, 2003 January, 2003
IP header compression in IPsec ESP
<draft-vilhuber-hcoesp-00.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 September, 2002 Expires March, 2003
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 September, 2002 Expires March, 2003
+---------------------------------+
| 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 September, 2002 Expires March, 2003
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 September, 2002 Expires March, 2003
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 September, 2002 Expires March, 2003
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 September, 2002 Expires March, 2003
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, September, 2002
[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 September, 2002 Expires March, 2003
7. Editor's Address
Jan Vilhuber
<vilhuber@cisco.com>
Cisco Systems, Inc.
Vilhuber [Page 8]