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

Versions: 00                                                            
Internet Draft                         December 1996 (Expires June 1997)

                                                    M. Sabin, Consultant
                                                  R. Monsour, Hi/fn Inc.
                                         C. Allen, Consensus Development


               LZS Compression Transform for TLS Protocol
                      <draft-sabin-lzs-tls-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).


Abstract

   This memo proposes a compression method for the TLS protocol based on
   the LZS compression algorithm.  The method can be used to compress
   the contents of a TLS record.  The compression method proposed here
   is stateless, meaning that a record can be decompressed independently
   of any other record.  Compression is performed prior to the
   encryption operation, which has the side benefit of reducing the
   amount of data that must be encrypted.


Acknowledgments

   The LZS details presented here are similar to those in "PPP Stac LZS
   Compression Protocol," by R. Friend and W. A. Simpson [RFC-1974].


Table of Contents

   1.  Introduction
   2.  Format of Compressed Fragment



Sabin, et al                                                   [Page  1]

INTERNET DRAFT          LZS Compression for TLS            December 1996


   3.  Compression Procedure
   4.  Decompression Procedure
   5.  Security Considerations
   6.  References
   7.  Author's Addresses
   8.  Appendix:  Compression Efficiency versus Fragment Size


1.  Introduction

   Encrypted data is random in nature and not compressible.  When the
   TLS protocol [TLS] transmits encrypted records, compression methods
   used at lower protocol layers -- e.g., PPP compression [RFC-1962] --
   no longer work.  If both compression and encryption are desired,
   compression must be performed first.  Accordingly, the TLS protocol
   provides a mechanism for including compression prior to encryption.

   A side benefit of compressing the data first is that the amount of
   data which must be encrypted is reduced.  In some implementations,
   compression is done in hardware and encryption is done in software,
   and this can represent a significant reduction in software overhead.

   This memo proposes a compression method for the TLS protocol based on
   the LZS compression algorithm.  The method is stateless, meaning that
   the contents of a TLS record can be decompressed independently of any
   other record.


   1.1  Background of LZS Compression

      The LZS algorithm is a lossless compression method that uses a
      sliding window of 2,048 bytes.  During compression, redundant
      sequences of data are replaced with tokens that represent those
      sequences.  During decompression, the original sequences are
      substituted for the tokens, in such a way that the original data
      is exactly recovered.  LZS differs from lossy schemes, such as
      those often used for video compression, that do not exactly
      reproduce the original data.

      Details of LZS formatting can be found in [ANSI94].

      The efficiency of the LZS algorithm depends on the degree of
      redundancy in the original data.  A typical compression ratio
      is 2:1.  LZS achieves a compression ratio of 2.34:1 on
      the University of Calgary Text Compression Corpus [Calgary].


   1.2  Licensing

      Hi/fn Inc. holds patents on the LZS algorithm.  Source and object
      code licenses for LZS are available on a non-discriminatory basis.



Sabin, et al                                                   [Page  2]

INTERNET DRAFT          LZS Compression for TLS            December 1996


      Hardware implementations are also available.  For more
      information, contact Hi/fn at the address listed with the authors'
      addresses.


   1.3  Requirements Terminology

      In this document, the words that are used to define the
      significance of each particular requirement are usually
      capitalized.  These words are:

         - MUST:  This word, or the adjective "REQUIRED," means that the
         item is an absolute requirement of the specification.

         - SHOULD:  This word, or the adjective "RECOMMENDED," means
         that there might exist valid reasons in particular
         circumstances to ignore this item, but the full implications
         should be understood and the case carefully weighed before
         taking a different course.

         - MAY:  This word, or the adjective "OPTIONAL," means that the
         item is truly optional.  One vendor might choose to include the
         item because of a particular marketplace requirement or because
         it enhances the product, while another vendor might omit the
         item.


2.  Format of Compressed Fragment

   The input to the compression function is a TLSPlaintext.fragment.
   The output of the function is a TLSCompressed.fragment.  The format
   of the TLSCompressed.fragment is as follows:


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      CC       |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Fragment Data (compressed or uncompressed)          |
   |                                                               |
   |                                               +-+-+-+-+-+-+-+-|
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   2.1  Compression Control

      The Compression Control (CC) field is a single, bit-mapped byte.
      The bits are numbered 7 (most significant) to 0 (least
      significant).  The following bits are defined:




Sabin, et al                                                   [Page  3]

INTERNET DRAFT          LZS Compression for TLS            December 1996



         - COMPRESSED (bit 7)

         This bit is set to 1 to indicate the fragment is compressed.
         It is cleared to 0 to indicate the fragment is not compressed.


         - HIST_RESET (bit 6)

         This bit is set to 1 to indicate that the compression history
         was reset prior to processing this fragment.  It is cleared to
         0 to indicate the compression history was not reset.

         In order to make the compression function stateless between
         records, the sender MUST reset the compression history prior to
         processing each fragment.  Thus, the HIST_RESET bit MUST be set
         to 1 in every fragment.  (The HIST_RESET bit is defined here
         for upwards compatibility with future methods that may allow
         statefulness.)

         The sender MUST flush the compressor at the end of each
         compressed fragment.  Flushing means that all data going into
         the compressor is included in the output, i.e., no data is held
         back in the hope of achieving better compression.  Flushing is
         necessary to prevent a record's data from spilling over into a
         later record.


   2.2  Fragment Data

      The Fragment Data field contains the data of
      TLSPlaintext.fragment, in either compressed or uncompressed form.
      The value of the COMPRESSED bit of the CC field is set
      accordingly.  The Fragment Data field is an integral number of
      bytes in length.


3.  Compression Procedure

   The compression procedure consists of the following steps:

      i)  The sender resets the compression history and sets the
      HIST_RESET bit of the CC field to 1.

      ii)  The sender decides whether or not to compress the fragment.

         - If the sender chooses to compress the fragment, the LZS
         algorithm is applied.  The resulting compressed data is
         formatted according to [ANSI94].  The COMPRESSED bit of the CC
         field is set to 1.




Sabin, et al                                                   [Page  4]

INTERNET DRAFT          LZS Compression for TLS            December 1996


         - If the sender chooses not to compress the fragment, the
         COMPRESSED bit of the CC field is set to 0.

      iii)  The CC field and Fragment Data field are concatenated.

   An implementation SHOULD monitor the results of the fragment
   compression operation and reject the operation if it results in
   expansion.  In such a case, the uncompressed fragment SHOULD be
   transmitted with the COMPRESSED bit set to 1.


4.  Decompression Procedure

   The decompression procedure consists of the following steps:

      i)  The receiver checks the HIST_RESET bit of the CC field.  If
      HIST_RESET = 1, the decompression history is reset.  If HIST_RESET
      = 0, a TLS error alert of type "decompression_failure" is
      declared.

      ii)  The receiver checks the COMPRESSED bit of the CC field.  If
      COMPRESSED = 1, the LZS decompression algorithm is applied to the
      fragment data.  If COMPRESSED = 0, decompression is not applied.

      iii)  The CC field is removed, leaving only the Fragment Data
      field.


5.  Security Considerations

   Security issues are not discussed in this memo.


6.  References

   [ANSI94] American National Standards Institute, Inc., "Data
      Compression Method for Information Systems," ANSI X3.241-1994,
      August 1994.

   [Calgary]  Text Compression Corpus, University of Calgary, available
      at
      ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus.

   [RFC-1962] D. Rand, "The PPP Compression Control Protocol (CCP),"
      RFC-1962, June 1996.

   [RFC-1974] R. Friend and W. A. Simpson, "PPP Stac LZS Compression
      Protocol," RFC-1974, August 1996.

   [TLS] A. Frier, P. Karlton, P. Kocher, and T. Dierks, "The TLS
      Protocol Version 1.0," work in progress, available at



Sabin, et al                                                   [Page  5]

INTERNET DRAFT          LZS Compression for TLS            December 1996


      ftp://ds.internic.net/draft-ietf-tls-protocol.00.txt,
      November 1996.


7.  Authors' Addresses

   Michael Sabin
   883 Mango Avenue
   Sunnyvale, CA  94087
   Email:  mike.sabin@worldnet.att.net

   Robert Monsour
   Hi/fn Inc.
   12636 High Bluff Drive
   San Diego, CA  92130
   Email: rmonsour@earthlink.net

   Christopher Allen
   Consensus Development Corporation
   1563 Solano Avenue #355
   Berkeley, CA  94707-2116
   Email: christophera@consensus.com


8.  Appendix:  Compression Efficiency versus Fragment Size

   The following table offers some guidance on the compression
   efficiency that can be achieved as a function of fragment size.  Each
   entry in the table shows the compression ratio that was achieved when
   the proposed method was applied to a test file using fragments of
   a specified size.

   The test file was the University of Calgary Text Compression Corpus
   [Calgary].  The length of the file prior to compression was 3,278,000
   bytes.  When the entire file was compressed as a single fragment, a
   compression ratio of 2.34 resulted.


    Fragment size,|  64   128   256   512  1024  2048  4096  8192 16384
    bytes         |
    --------------|----------------------------------------------------
    Compression   |1.18  1.28  1.43  1.58  1.74  1.91  2.04  2.11  2.14
    ratio         |











Sabin, et al                                                   [Page  6]