Internet Draft March 1997 (Expires September 1997)
R. Monsour, Hi/fn Inc.
M. Sabin, Consultant
A. Shacham, Cisco Systems
S. Anand, Microsoft Corporation
R. Thayer, Sable Technology
Compression in IP Security
<draft-monsour-compr-ipsec-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).
This draft is intended provide input to the IP Security working
group as it sorts through the debate regarding the incorporation of
lossless data compression into the IP Security architecture.
Comments about this draft should be submitted to the authors or to
the IPSEC mailing list (ipsec@tis.com).
Abstract
This memo discusses the application of lossless compression
technology to the IP Security Architecture [IPSecArch].
Over the last few several months, a number of lively debates
on this topic have been held on IPSec mailing list. This memo
discusses the issues raised, the alternatives available to
resolve them and provides a set of recommendations to bring
resolution to the issue.
The goals of the draft are to: (1) define the problem solved by the
use of compression in the context of IPSec, (2) review the use of
compression and security technologies as they have been applied
in other layers of the protocol stack, (3) outline a set of
Monsour, et al [Page 1]
INTERNET DRAFT Compression in IP Security March 1996
requirements for applying compression to IPSec, (4) discuss
alternative methods which can be implemented to meet the
requirements, and (4) propose a set of recommendations for
consideration by the working group.
Acknowledgments
The authors wish to acknowledge the many contributors to the
compression debate on the IPSec mailing list. In addition, the
concept of compressing prior to encrypting data is drawn from
several prior sources, including Rodney Thayer's draft
[Thayer], the ECP/CCP protocols under PPP and the TLS protocol
(better known as SSL).
Table of Contents
1. Introduction
2. Compression in IPSec - Problem Definition
3. Review of Other Protocols Using Compression and/or Security
3.1 Overview
3.2 The Encryption Control Protocol (ECP)
3.3 Transport Layer Security (TLS)
3.4 Application Layer Security
4. Does Compression Fall Within the Scope of the Working Group?
5. Requirements for Applying Compression to IPSec
5.1 Negotiated Algorithm
5.2 Stateless AND Stateful Compression
5.3 Compressed Packet Indicator
5.4 Compatibility with Existing and Emerging Implementations
5.5 Optional Use of Compression
5.6 Ability to Optimize Compression Across Protocol Layers
5.7 Anti-Expansion of Payload Data
6. Alternative Approaches to the Use of Compression in IPSec
6.1 Layered Architecture Using a Separate Compression Header
6.2 Optional Feature of ESP
6.3 Comparison of the Two Approaches
7. Which Approach Meets the Proposed Requirements?
7.1 Negotiated Algorithm
7.2 Stateless AND Stateful Compression
7.3 Compressed Packet Indicator
7.4 Compatibility with Existing and Emerging Implementations
7.5 Optional Use of Compression
7.6 Ability to Optimize Compression Across Protocol Layers
7.7 Anti-Expansion of Payload Data
8. Conclusions
9. Recommendations
10. Security Considerations
11. References
12. Authors' Addresses
Monsour, et al [Page 2]
INTERNET DRAFT Compression in IP Security March 1996
1. Introduction
Encrypted data is random in nature and not compressible. When an IP
datagram is encrypted, compression methods used at lower protocol
layers -- e.g., the PPP Compression Control Protocol [RFC1962] --
no longer work. If both compression and encryption are desired,
compression must be performed first.
The IPSec working group of the IETF has been debating the topic
of incorporating lossless data compression into the IPSec
architecture for the past several months. In fact, the initial
introduction of the topic goes as far back as 1994, when Jim
Hughes of Network Systems presented the idea at the San Jose
meeting of the IPSec working group [Dec96WG].
Following that initial presentation, Network Systems, as well
as a handful of other companies have implemented proprietary
methods for compressing IP datagrams prior to encrypting them.
This memo takes that work, and analyzes similar work done in other
security protocols, and proposes a negotiable, interoperable
method for applying lossless data compression to the IPSec
protocol.
The first compression-related drafts were developed in 1996 and
three of those drafts were discussed at the December 1996 IPSec
working group meeting in San Jose [Thayer][Sabin1][Sabin2].
2. Compression in IPSec - Problem Definition
The widespread use of the internet has resulted in equally
widespread use of point-to-point (PPP) connections between hosts as
well as between routers. Lossless compression technology has
been deployed in the PPP environment in the form of a sub-protocol
known as the Compression Control Protocol (CCP). PPP is a
connection-oriented protocol. Many lossless compression technologies
have the capability to retain state across each "packet" of data
that is compressed. Hence, in a connection-oriented protocol such as
PPP, compression can be applied to the continuing stream of
"packets". The principal advantage to such a stateful mechanism is
a higher compression ratio.
Another important aspect of the CCP is the negotiability of the
compression algorithm for each PPP connection.
Today, PPP is the predominant method for end-user hosts to connect
to the internet. Compression in CCP provides end users with
significant improvements in bandwidth utilization.
In a different environment, today's routers that support connections
in the T1 range AND use lossless compression technology, provide
great economic value to their users. For example, a corporate user
Monsour, et al [Page 3]
INTERNET DRAFT Compression in IP Security March 1996
employing a leased T1 line can save thousands of dollars per
month in line charges through the use of compression technology.
The use of encryption technologies at protocol layers higher than
the data-link/PPP layer, renders PPP compression ineffective. With
the strong demand for secure communications, encryption is
actively being deployed at various layers in the protocol stack to
meet the security requirements of various environments. The is the
core problem which has driven the compression debate in the IPSec
working group.
3. Review of Other Protocols Using Compression and/or Security
This section provides an overview of several examples of other
protocols and applications involving the use of lossless compression
technology. Some of the protocols described use compression in
conjunction with encryption.
3.1 Overview
The diagram below depicts the OSI reference model for data
communications protocol layers along with various internet
protocols and/or products which incorporate the use of
compression and/or security capabilities.
These are just a few examples of the technologies being
deployed to meet the security and bandwidth requirements of
various classes of users and systems.
Protocols
and/or
Protocol Layers Products Compression Security
------------------ ----------- ------------- ------------
+----------------+
| Application | PGPmail yes yes
|----------------|
| Presentation | HTTPv1.1* yes no
|----------------|
| Session | TLS/SSL yes yes
|----------------|
| Transport | TCP** no no
|----------------|
| Network | IPSec no yes
|----------------|
| Data Link | PPP/CCP/ECP yes yes
|----------------|
| Physical | link encryptors no yes
+----------------+ link compressors yes no
*[RFC2068]
Monsour, et al [Page 4]
INTERNET DRAFT Compression in IP Security March 1996
**Note: There is discussion within the IETF of taking up work
in this area.
3.2 The Encryption Control Protocol (ECP)
At the same time that the Compression Control Protocol was defined, a
sister protocol, the Encryption Control Protocol (ECP) [RFC1968], was
defined. In the ECP protocol, it is clearly noted that if
compression has been negotiated for a connection, compression must be
performed prior to encryption. As far as the authors can tell at
this time, the ECP has not been widely deployed. However, it should
also be noted that the PPP Extensions working group [PPPEXT] is
currently working on additional security protocols in the areas of
authentication and public key technologies.
3.3 Transport Layer Security (TLS)
TLS [TLS] (formerly/better known as SSL, the Secure Socket Layer)
is a security protocol originally defined and implemented by
Netscape Communications Corporation. In the initial draft of
TLS 1.0, the use of compression is defined as an optional data
transformation which can be used prior to encryption for each
packet.
In TLS, the selection of compression algorithm is a negotiated
property of the session. Since TLS is a connection-oriented
protocol, compression state can be maintained from one packet
to the next, thereby improving compression ratio.
3.4 Application Layer Security
There are several examples of application layer security. Clearly,
any application which has requirements for confidentiality in its
data flow can implement encryption technology to meet such a
security requirement. One example of this is an email application.
A secure email client is capable of encrypting messages sent from
one host to another. PGPmail [PGPMan], a security add-on to many
popular email client products, is one such example. PGPmail
provides the capability to compress mail prior to encrypting it.
No doubt, this is due to the realization of its developers that
subsequent attempts to compress the data at lower layers in the
protocol stack will be rendered ineffective.
4. Does Compression Fall Within the Scope of the Working Group?
There are several issues which surround the question of whether
the IPSec working group should directly consider the issue of
applying compression to the IPSec protocols.
The IPSec working group charter specifically states:
Monsour, et al [Page 5]
INTERNET DRAFT Compression in IP Security March 1996
A security protocol in the network layer will be developed to
provide cryptographic security services that will flexibly
support combinations of authentication, integrity, access
control, and confidentiality.
The protocol formats for the IP Authentication Header (AH)
and IP Encapsulating Security Payload (ESP) will be independent
of the cryptographic algorithm. The preliminary goals will
specifically pursue host-to-host security followed by subnet-to-
subnet and host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed
to support the key management requirements of the network
layer security. The Internet Key Management Protocol (IKMP)
will be specified as an application layer protocol that is
independent of the lower layer security protocol.
The problem definition in section 2 describes the "problem"
in terms of the affect of IPSec on a lower-layer protocol. While
this is indeed true, it is unclear whether the obligation to
provide the detailed protocol "fix" to correct the problem lies
within the scope of the IPSec working group.
While progress is being made, it is also true that the IPSec
specifications have been not been stable and available in a
manner to support widespread interoperable implementations
(as has been noted by various members of the working group).
The user community has indicated their requirement that
compression capabilities be "supported" by IPSec implementations.
The specific methods used to provide such support are clearly
in the scope of the working group to decide.
There is currently discussion underway (within the IETF) to
explore the application of compression in TCP. This raises a
question regarding the potential to provide a consistent
mechanism for supporting compression across these two closely-
related protocols (TCP & IP).
5. Requirements for Applying Compression to IPSec
As noted earlier, the use of encryption at any protocol layer above
the data link layer renders PPP compression ineffective. This leads
to the need to support the use of compression in the context of
IPSec. The question then becomes one of how to provide this
support.
An understanding of the problem, the approaches taken in other
protocol environments, the emerging discussion of compression
support in TCP, and the discussions on the mailing list lead to
the definition of the following requirements for the technical
Monsour, et al [Page 6]
INTERNET DRAFT Compression in IP Security March 1996
approaches to support compression in IPSec.
5.1 Negotiated Algorithm
Regardless of the protocol for which compression support is
provided, a method is required for the two communicating
parties to negotiate both the use and the type of compression
to be applied to the packets.
5.2 Stateless AND Stateful Compression
Since IP is a connectionless/stateless protocol, it is important
that each compressed packet be capable of being decompressed
independently of any other packet; i.e., the successful
decompression of a packet must not depend on the contents of any
other packet(s), nor should it depend on order of receipt of any
other packet(s).
The development of a consistent approach to providing compression
capabilities to both IPSec and TCP should support the use
of stateful compression in the TCP context. TCP's connection
orientation can guarantee packet ordering and thus achieve
higher compression ratios.
5.3 Compressed Packet Indicator
Once the use of compression is negotiated between two
communicating parties, the sender must have the flexibility
to determine whether or not to compress each packet. Such
flexibility requires a per-packet indication of whether or
not the packet is compressed.
5.4 Compatibility with Existing and Emerging Implementations
Changes to the IPSec protocol definitions to support compression
must not not break any existing implementation. This means
that for an implementation to be compression-capable, it will
have to be modified, but it will remain compliant with the IPSec
protocols without the addition of compression support. This
requirement becomes more desirable with the passage of time, as
more and more implementations are developed and deployed.
5.5 Optional Use of Compression
This requirement derives from the previous requirement. If
an existing implementation is to be considered compliant
with the IPSec protocol, then it MUST NOT be required to
provide support for compression.
Monsour, et al [Page 7]
INTERNET DRAFT Compression in IP Security March 1996
5.6 Ability to Optimize Compression Across Protocol Layers
The use of compression at several layers in the protocol stack
can cause inefficiencies in the processing by sending systems.
For example, in an environment where application layer
compression is in use, it is desirable to communicate to the
lower layer protocols that the data is already compressed and
that the lower layers need not attempt to compress (read as
"waste cycles"). Thus, support for compression in IPSec shall
be provide the capability for "turning compression on or off"
through some mechanism of inter-layer communication.
5.7 Anti-Expansion of Payload Data
It is not possible in all instances to pre-determine if a payload
has already been compressed at a higher layer. Future protocol
changes could support such a pre-determination. Until then,
a mechanism for detecting the expansion of data and optionally
sending the original uncompressed payload is required.
6. Alternative Approaches to the Use of Compression in IPSec
Two general technical approaches to meet the requirements
outlined in previous section have been presented to the working
group and subsequently debated on the mailing list. These two
approaches are described below along with their relative
advantages and disadvantages.
6.1 Layered Architecture Using a Separate Compression Header
This approach involves the use of a separate compression header
which would follow the IP header and precede the AH and/or ESP
header(s). The header would provide all the fields necessary
to support compression of either AH and/or ESP payloads as
well as support for compression in TCP.
6.2 Optional Feature of ESP
This approach is based on the fact that it is the encryption
of ESP payloads which renders downstream compression techniques
ineffective. This approach is limited to only compressing
ESP payloads and does not extend naturally to any upper layer
protocols.
6.3 Comparison of the Two Approaches
Below is a comparison of the advantages and disadvantages of the
two approaches.
Monsour, et al [Page 8]
INTERNET DRAFT Compression in IP Security March 1996
Advantages Disadvantages
-----------------------------------------------------------------
Layered not tied to use some delay in getting
Architecture of encryption; i.e., to a standard
works with AH payloads
as well
can be applied to
upper layer protocols
such as TCP in addition
to IPSec
routers can more easily
determine if a packet
is compressed without
knowledge of IPSec
protocol details
Optional Easily defined due to doesn't map well for
Feature its limited scope use in upper layer protocols
of ESP
tied to use of security
protocols
requires routers to know
IPSec to avoid compression
processing overhead
7. Which Approach Meets the Proposed Requirements?
This section describes how the two approaches described in
the previous section meet each of the requirements defined
in section 5.
7.1 Negotiated Algorithm
Both approaches meet this requirement. ISAKMP provides a
method for algorithm negotiation which can easily be extended
to support the negotiation of the use and type of compression.
In the TCP context, TCP negotiation would be extended to
negotiate the use and type of compression.
7.2 Stateless AND Stateful Compression
IPSec compression MUST be stateless. Both approaches support
this concept.
TCP, as a connection-oriented protocol, can support stateful
compression and achieve higher compression ratios as a result.
The use of the layered architecture approach makes stateful
TCP compression possible.
Monsour, et al [Page 9]
INTERNET DRAFT Compression in IP Security March 1996
7.3 Compressed Packet Indicator
In the layered architecture approach, the compression header
would contain a field to indicate whether or not the packet
is compressed.
In the ESP option approach, the most-significant bit of the
pad length field has been proposed to serve this function.
7.4 Compatibility with Existing and Emerging Implementations
Since compression is a negotiated option in both approaches,
they both meet this requirement. Existing implementations
will not negotiate to use compression and will continue to
interoperate with new and existing IPSec compliant implementations.
7.6 Ability to Optimize Compression Across Protocol Layers
The layered architecture approach meets this requirement.
The ESP option approach sacrifices the opportunity to develop
a single method for compressing across IP and TCP layer protocol.
7.7 Anti-Expansion of Payload Data
Both approaches can meet this requirement.
8. Conclusions
The authors have drawn the following conclusions based on
discussions with user community members, analysis of the
proposed technical approaches, and the emerging need to
broaden the use of compression beyond the IPSec context.
- The need for compression in the IPSec context exists.
The effect of IPSec encryption on downstream compression
and the demands by members of the user community demonstrate
a clear need for supporting compression in an IPSec context.
- The compression topic does not distinctly fall in the
charter of the IPSec working group.
- A layered architecture approach is a superior approach when
compared to the ESP option approach to problem of providing
compression capabilities in the IPSec context.
9. Recommendations
The authors recommend the following course of action.
Monsour, et al [Page 10]
INTERNET DRAFT Compression in IP Security March 1996
- Document the IPSec Architecture to Support Optional Compression
It is important that the IPSec architecture specification
include the notion that payload data of IPSec payloads may
optionally be compressed. The draft should note that the
specification for providing such compression capabilities
will be developed outside of the IPSec working group.
- Develop a Layered Architecture Approach to Compression
A layered architecture approach, when considered against
the ESP option approach has significant advantages which
outweigh any potential delays in specification development
and subsequent deployment.
- Establish a compression working group
This group would take on the responsibility for defining
a the layered architecture and the separate compression
header for use in IPSec as well as other candidate upper
layer protocols.
The rationale for this recommendation is based on several
factors, including (1) the user community as well as the
vendor community are under pressure to finalize the IPSec
specifications, complete development and begin deployment
of IPSec-compliant products. As Hugo put in a recent post
to the list, "...further delay of ipsec deployment (which
is also a form of denial-of-service attack :)", (2) the
desire to support compression in a context broader than
IPSec alone (i.e., TCP or other candidate protocols), and
10. Security Considerations
This memo discusses the use of lossless compression technology
in a security protocol, specifically IPSec. The proposed use
of compression within this protocol is not believed to have an
effect on the underlying security functionality provide by the
protocol; i.e., the use of compression is not known to degrade
or alter the nature of the underlying security architecture or
the encryption technologies used to implement it.
The use of compression does change the length of ESP payloads, in a
manner that depends on the data prior to encryption. Thus, the use
of compression may have an effect on the ability of an eavesdropper
to glean information by analyzing the length of transmitted packets.
11. References
[IPSecArch] Atkinson, R., "Security Architecture for the Internet
Protocol," November 1996.
Monsour, et al [Page 11]
INTERNET DRAFT Compression in IP Security March 1996
[Dec96WG] Lambert, P., Minutes of the IPSec Working Group, San Jose
December 1994.
[Thayer] Thayer, R., "Compression Header for IPSec",
draft-thayer-seccomp-00.txt, May, 1996.
[Sabin1] Sabin, M., Monsour R., "
[Sabin2] Sabin, M., Monsour R., "
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP),"
RFC-1962, June 1996.
[RFC2068] ????, "Hypertext Transport Protocol version 1.1",
January, 1997.
[RFC1968] ????, "The PPP Encryption Control Protocol (ECP)",
June 1996.
[PPPEXT] Point-to-Point Protocol Extensions Working Group Charter.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
draft-ietf-tls-protocol-01.txt, March 1997.
[PGPMan] ????, "PGPmail Reference Manual"
[AH] Atkinson, R., "IP Authentication Header"
[ESP] Atkinson, R., "IP Encapsulating Security Payload,"
June 1996.
[DOI] Piper, D., "IPSec Domain of Interpretation", March 1997.
[Calgary] Text Compression Corpus, University of Calgary, available
at
ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus.
8. Authors' Addresses
Robert Monsour
Hi/fn Inc.
12636 High Bluff Drive
San Diego, CA 92130
Email: rmonsour@hifn.com
Michael Sabin
883 Mango Avenue
Sunnyvale, CA 94087
Email: mike.sabin@worldnet.att.net
Monsour, et al [Page 12]
INTERNET DRAFT Compression in IP Security March 1996
Abraham Shacham
Cisco Systems
101 Cooper Street
Santa Cruz, CA 95060
Email: shacham@cisco.com
Sanjay Anand
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: sanjayan@microsoft.com
Rodney Thayer
Sable Technology
246 Walnut Street
Newton, MA 02160
Email: rodney@sabletech.com
Monsour, et al [Page 13]