Network Working Group R. Thayer
Sable Technology
Internet Draft July 1996
Compression Payload for Use with IP Security
<draft-thayer-seccomp-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
TABLE OF CONTENTS
STATUS OF THIS MEMO.............................................1
ABSTRACT........................................................1
1. INTRODUCTION.................................................2
2. USE OF COMPRESSION FOR IP PACKETS............................2
2.1 INTERACTION WITH AH/ESP.....................................2
3. COMPRESSION PAYLOAD MESSAGE FORMAT...........................2
3.1 NEXT PAYLOAD................................................3
3.2 TYPE........................................................3
3.3 OPTIONS.....................................................3
3.4 IDENT.......................................................3
3.5 LENGTH......................................................3
4. SECURITY CONSIDERATIONS......................................3
5. REFERENCES...................................................4
6. AUTHOR'S ADDRESS.............................................4
Abstract
This document describes a payload format to be used to store
compressed protocol messages within an IP packet which is using
security features as defined in [RFC-1825].
Thayer [Page 1]
Internet Draft IP Compression with IPSEC Page 2
1. Introduction
The introduction of security into packets transmitted using
Internet IP (Version 4) [RFC-791] causes a change in the
applicability of compression technology to data communications.
Specifically, when a packet is encrypted, it becomes essentially
random data, and therefore is highly incompressible. This makes
it difficult to use conventional techniques to compress IP
datagrams, such as PPP compression. To solve this problem it
becomes desirable to compress the data before it is encapsulated
with security features.
2. Use of Compression for IP packets
The process of using data compression techniques for IP packets
is a matter of processing the data in the following order, if IP
Security is present:
a. Source node generates packet
b. IP packet is compressed
c. (optional) ESP transform is applied to IP packet
d. AH transform is applied to IP packet
e. IP packet is transmitted
Note that compression occurs BEFORE encryption.
2.1 Interaction with AH/ESP
Since the 'payload' as seen by ESP (or AH) is no longer IPv4 or
IPv6, the payload type field used with ESP, e.g. [Hughes] or AH
[Atkinson] must specify a value indicating this is compressed.
For purposes of this discussion draft, the value 99 should be
used. This is defined in [RFC-1700] as "any private encryption
scheme" and has been used by implementors in the past for
compression [Thayer]. It is assumed that some more proper value
from IANA will be eventually chosen.
3. Compression Payload Message Format
3322 2222 2222 1111 1111 1100 0000 0000
1098 7654 3210 9876 5432 1098 7654 3210
+------------+-----------+-------------+-----------+
|Next Payload| Type | Options |
+------------+-----------+-------------+-----------+
| Ident | Length |
+------------+-----------+-------------+-----------+
| ... compressed data ... +
Thayer [Page 2]
Internet Draft IP Compression with IPSEC Page 3
3.1 Next Payload
is the type field of the next level of data, from [RFC-1700].
Note this is typically IPv4 or IPv6.
3.2 Type
is the dialect of compression to use. The following values are
predefined, others are t.b.d.
0 = no compression, pass-through
1 = ZLIB compression [ZLIB]
2 = private scheme
3..255 - undefined
3.3 Options
This is a 16-bit field containing options for compression. The
only bit defined at this time is:
0x0001 = flush history after this packet.
Use of this field is specific to the compression dialect. The
value defined here is specifically for use with ZLIB.
3.4 Ident
This is an identifier for this packet. It may be used to
determine if packets have been dropped or for other purposes.
The field is 16 bits wide. The range of the identifier is
dialect-specific. For dialect 0 (pass-through) it must be
0..65535. For dialect 1 (ZLIB) it must be in the range 0..255.
3.5 Length
This is the length of the actual compressed data, in bytes. It
is not necessary for the compressed data to be a multiple of 4
bytes. This counder covers the data only, not the header fields.
4. Security Considerations
This protocol is specifically for use in an IP Security Context.
It therefore is explicitly NOT intended to handle encryption
(since ESP is doing that) or authentication (since AH is doing
that).
Thayer [Page 3]
Internet Draft IP Compression with IPSEC Page 4
5. References
[Atkinson] R. Atkinson, `IP Authentication Header'', draft-ietf-
ipsec-auth-header-00.txt
[Hughes] J. Hughes, `Combined DES-CBC, HMAC and Replay
Prevention Security'' June 1996, Internet Draft draft-ietf-
ipsec-esp-des-md5-02.txt
[RFC-1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS",
10/20/1994. (Pages=230) (Format=.txt) (Obsoletes RFC1340) (STD 2)
[RFC-1825] R. Atkinson, "Security Architecture for the Internet
Protocol", 08/09/1995. (Pages=22) (Format=.txt)
[RFC-791] J. Postel, "Internet Protocol", 09/01/1981. (Pages=45)
(Format=.txt)
[Thayer] R. Thayer, `WHR Accelerator Compression Encapsulation
Protocol', March 1994, presented at Compression BOF at Seattle
IETF.
[ZLIB] L. P. Deutsch, J. Gailly, `ZLIB Compressed Data Format
Specification version 3.3'' draft-deutsch-zlib-spec-01.txt
6. Author's Address
Rodney Thayer
Sable Technology Corporation
246 Walnut Street
Newton Massachusetts 02160
rodney@sabletech.com
+1 617 332 7292
Thayer [Page 4]