idnits 2.17.1 draft-sabin-lzs-payload-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Atkins96], [RFC-1974]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '... The sender MUST reset the compressi...' RFC 2119 keyword, line 179: '... The sender MUST flush the compresso...' RFC 2119 keyword, line 210: '...n implementation SHOULD monitor the re...' RFC 2119 keyword, line 212: '...se, the uncompressed payload SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Atkins96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Calgary' -- Possible downref: Non-RFC (?) normative reference: ref. 'Piper' ** Downref: Normative reference to an Informational RFC: RFC 1974 Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft March 1997 (Expires Sept 1997) 4 M. Sabin, Consultant 5 R. Monsour, Hi/fn Inc. 7 LZS Payload Compression Transform for ESP 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 It is intended that a future version of this draft be submitted to 29 the IESG for publication as an Informational RFC. Comments about 30 this draft should be submitted to the authors or to the IPSEC mailing 31 list (ipsec@tis.com). 33 Abstract 35 This memo proposes a "payload compression transform" based on the LZS 36 compression algorithm. The transform can be used to compress the 37 payload field of an IP datagram that uses the Encapsulating Security 38 Payload (ESP) format. The compression transform proposed here is 39 stateless, meaning that a datagram can be decompressed independently 40 of any other datagram. Compression is performed prior to the 41 encryption operation of ESP, which has the side benefit of reducing 42 the amount of data that must be encrypted. 44 This memo anticipates a forthcoming ESP document that will supercede 45 [Atkins96]. The forthcoming document will allow for ESP payloads to 46 be compressed via transforms such as the one described in this memo. 48 Sabin, et al [Page 1] 49 Acknowledgments 51 The LZS details presented here are similar to those in "PPP Stac LZS 52 Compression Protocol," by R. Friend and W. A. Simpson [RFC-1974]. 54 The authors wish to thank the many participants of the IPSEC mailing 55 list whose discussion made possible the architecture for integrating 56 compression with ESP. 58 Table of Contents 60 1. Introduction 61 2. Format of Transformed Payload 62 3. Compression Control Bit 63 4. Compression Procedure 64 5. Decompression Procedure 65 6. Additions to ISAKMP DOI 66 7. Security Considerations 67 8. References 68 9. Author's Addresses 69 10. Appendix: Compression Efficiency versus Datagram Size 71 1. Introduction 73 Encrypted data is random in nature and not compressible. When an IP 74 datagram is encrypted, compression methods used at lower protocol 75 layers -- e.g., PPP compression [RFC-1962] -- no longer work. If 76 both compression and encryption are desired, compression must be 77 performed first. 79 A side benefit of compressing the data first is that the amount of 80 data which must be encrypted is reduced. In some implementations, 81 compression is done in hardware and encryption is done in software, 82 and this can represent a significant reduction in software overhead. 84 The Encapsulating Security Payload (ESP) format is well suited to 85 combining compression with encryption, for a variety of reasons: 87 - ESP is the place were encryption is applied to an IP datagram. 88 It is straightforward to precede the encryption step by an 89 optional compression step. The compression step transforms an 90 uncompressed ESP payload into a compressed ESP payload. This 91 "payload compression transform" can be independently defined and 92 used with any ESP transform. 94 - ESP provides a security parameters index (SPI) that links a 95 datagram to security parameters negotiated elsewhere. A 96 destination uses the SPI to look up the ESP transform needed to 97 decode an incoming datagram. If compression details are included 99 Sabin, et al [Page 2] 100 among the negotiated parameters, a destination can also use the 101 SPI to look up the compression transform needed to decode the ESP 102 payload. 104 This memo proposes a payload compression transform based on the LZS 105 compression algorithm. The transform can be used to compress any ESP 106 payload. The transform is stateless, meaning that the payload of a 107 datagram can be decompressed independently of any other datagram. 108 This is important in IP, where the delivery of individual datagrams 109 is not guaranteed. 111 1.1 Background of LZS Compression 113 The LZS algorithm is a lossless compression method that uses a 114 sliding window of 2,048 bytes. During compression, redundant 115 sequences of data are replaced with tokens that represent those 116 sequences. During decompression, the original sequences are 117 substituted for the tokens, in such a way that the original data 118 is exactly recovered. LZS differs from lossy schemes, such as 119 those often used for video compression, that do not exactly 120 reproduce the original data. 122 Details of LZS formatting can be found in [ANSI94]. 124 The efficiency of the LZS algorithm depends on the degree of 125 redundancy in the original data. A typical compression ratio 126 is 2:1. LZS achieves a compression ratio of 2.34:1 on 127 the University of Calgary Text Compression Corpus [Calgary]. 129 1.2 Licensing 131 Hi/fn, Inc., holds patents on the LZS algorithms. A restricted 132 license reference implementation is available for use in IPSEC 133 applications at no cost. Source and object licenses are available 134 on a non-discriminatory basis. Hardware implementations are also 135 available. For more information, contact Hi/fn at the address 136 listed with the authors' addresses. 138 1.3 Requirements Terminology 140 In this document, the words that are used to define the 141 significance of each particular requirement are usually 142 capitalized. These words are: 144 - MUST: This word, or the adjective "REQUIRED," means that the 145 item is an absolute requirement of the specification. 147 - SHOULD: This word, or the adjective "RECOMMENDED," means 149 Sabin, et al [Page 3] 150 that there might exist valid reasons in particular 151 circumstances to ignore this item, but the full implications 152 should be understood and the case carefully weighed before 153 taking a different course. 155 - MAY: This word, or the adjective "OPTIONAL," means that the 156 item is truly optional. One vendor might choose to include the 157 item because of a particular marketplace requirement or because 158 it enhances the product, while another vendor might omit the 159 item. 161 2. Format of Transformed Payload 163 The input to the payload compression transform is a payload to be 164 encapsulated by ESP. The output of the transform is a new payload. 165 The output payload contains the input payload's data in either 166 compressed or uncompressed format. If the uncompressed format is 167 used, the output payload is identical to the input payload. If the 168 compressed format is used, the output payload consists of the input 169 payload data, compressed and formatted according to [ANSI94]. 171 The input and output payloads are each an integral number of bytes 172 in length. 174 The sender MUST reset the compression history prior to processing 175 each datagram's payload. This ensures that each datagram's payload 176 can be decompressed independently of any other, as is needed when 177 datagrams are received out of order. 179 The sender MUST flush the compressor each time it transmits a 180 compressed datagram. Flushing means that all data going into the 181 compressor is included in the output, i.e., no data is held back in 182 the hope of achieving better compression. Flushing is necessary to 183 prevent a datagram's data from spilling over into a later datagram. 185 3. Compression Control Bit 187 The Compression Control (CC) bit is a single bit that indicates 188 whether or not the payload is compressed. A value of 1 indicates 189 compressed, and a value of 0 indicates uncompressed. 191 The CC bit is not part of the payload transform. We anticipate it 192 being defined in the upcoming ESP document. 194 4. Compression Procedure 196 The compression procedure consists of the following steps: 198 Sabin, et al [Page 4] 199 i) The sender resets the compression history. 201 ii) The sender decides whether or not to compress the payload. 203 - If the sender chooses to compress the payload, the LZS 204 algorithm is applied. The resulting compressed data is 205 formatted according to [ANSI94]. The CC bit is set to 1. 207 - If the sender chooses not to compress the payload, the 208 CC bit is cleared to 0. 210 An implementation SHOULD monitor the results of the payload 211 compression operation and reject the operation if it results in 212 expansion. In such a case, the uncompressed payload SHOULD be 213 transmitted with the CC bit cleared to 0. 215 After the payload has been transformed by these steps, the 216 transformed payload is submitted to the encode procedure of the 217 selected ESP transform. 219 5. Decompression Procedure 221 Prior to applying the decompression procedure, the decode procedure 222 of the selected ESP transform is applied to extract the payload. 224 The decompression procedure consists of the following step: 226 - The receiver checks the CC bit. If CC = 1, the LZS 227 decompression algorithm is applied to the payload data. If CC = 228 0, decompression is not applied. 230 6. Additions to ISAKMP DOI 232 The Internet Security Association and Key Management Protocol 233 (ISAKMP) defines a framework for negotiating security associations. 234 The IPSEC Domain of Interpretation (DOI) for ISAKMP, described in 235 [Piper], defines the attributes of a security association that can be 236 negotiated. 238 In order to accommodate the negotiation of compression, we propose 239 the following additions to section 4.5, "IPSEC Security Association 240 Attributes," in [Piper]: 242 Attribute Classes 244 class value type 245 ------------------------------------------------- 246 > Compression Algorithm 12 B 248 Sabin, et al [Page 5] 249 Class Values 251 > Compression Algorithm 252 > RESERVED 0 253 > LZS 1 254 > 255 > Values 2-61439 are reserved to IANA. Values 61440-65535 are 256 > for private use among mutually consenting parties. 257 > 258 > There is no default value for Compression Algorithm, as it 259 > must be specified to correctly identify the applicable 260 > transform. 262 7. Security Considerations 264 This memo discusses the use of lossless compression in a security 265 protocol, specifically, ESP. The proposed use of compression is 266 believed to have no effect on the security of the encryption and 267 authentication algorithms used in ESP, nor is it believed to have any 268 effect on the underlying security architecure of IPSEC. 270 The use of compression does change the length of ESP payloads, in a 271 manner that depends on the data prior to encryption. Thus, the use 272 of compression may have an effect on the ability of an eavesdropper 273 to glean information by analyzing the length of transmitted packets. 275 8. References 277 [ANSI94] American National Standards Institute, Inc., "Data 278 Compression Method for Information Systems," ANSI X3.241-1994, 279 August 1994. 281 [Atkins96] Atkinson, R., "IP Encapsulating Security Protocol," 282 RFC-xxxx, June 1996. 284 [Calgary] Text Compression Corpus, University of Calgary, available 285 at 286 ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. 288 [Piper] Piper, D., "The Internet IP Security Domain of 289 Interpretation for ISAKMP," work in progress, available at 290 . 292 [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)," 293 RFC-1962, June 1996. 295 [RFC-1974] Friend, R., and Simpson, W.A., "PPP Stac LZS Compression 297 Sabin, et al [Page 6] 298 Protocol," RFC-1974, August 1996. 300 9. Authors' Addresses 302 Michael Sabin 303 883 Mango Avenue 304 Sunnyvale, CA 94087 305 Email: mike.sabin@worldnet.att.net 307 Robert Monsour 308 Hi/fn Inc. 309 12636 High Bluff Drive 310 San Diego, CA 92130 311 Email: rmonsour@earthlink.net 313 10. Appendix: Compression Efficiency versus Datagram Size 315 The following table offers some guidance on the compression 316 efficiency that can be achieved as a function of datagram size. Each 317 entry in the table shows the compression ratio that was achieved when 318 the proposed transform was applied to a test file using datagrams of 319 a specified size. 321 The test file was the University of Calgary Text Compression Corpus 322 [Calgary]. The length of the file prior to compression was 3,278,000 323 bytes. When the entire file was compressed as a single payload, a 324 compression ratio of 2.34 resulted. 326 Datagram size,| 64 128 256 512 1024 2048 4096 8192 16384 327 bytes | 328 --------------|---------------------------------------------------- 329 Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14 330 ratio | 332 Sabin, et al [Page 7]