idnits 2.17.1 draft-bellovin-tcpcomp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages -- Found 5 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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. 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.) -- The document date (October 1999) is 8959 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2393' on line 49 looks like a reference -- Missing reference section? 'FILTDRAFT' on line 127 looks like a reference -- Missing reference section? 'RFC-2119' on line 74 looks like a reference -- Missing reference section? 'RFC1122' on line 82 looks like a reference -- Missing reference section? 'DRAFTREC' on line 124 looks like a reference -- Missing reference section? 'RFC2394' on line 159 looks like a reference -- Missing reference section? 'RFC2395' on line 159 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bellovin, Buchsbaum, Muthukrishnan 2 Internet Draft AT&T Labs--Research 4 Expiration Date: April 2000 October 1999 6 TCP Compression Filter 8 draft-bellovin-tcpcomp-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 This draft document will be submitted to the RFC Editor as an 26 Experimental RFC. Distribution of this document is unlimited. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 We propose a TCP filter option to install compression in a virtual 37 layer between TCP and the application layer. The method is 38 incrementally deployable, as neither party will install the 39 compression layer without the other's consent. 41 3. Introduction 43 The natural place to compress data is at the application level, where 44 application-specific semantics can be used to attain better 45 compression. Unfortunately, this requires changing each and every 46 application, or at least changing user behavior. 48 An alternative is to compress the data at the IP level, as is done in 49 IPCOMP [RFC2393]. While this is application independent, its 50 effectiveness is also limited, since each packet must be compressed 51 individually. 53 We propose compressing immediately above TCP, as negotiated by a TCP 54 option. One side sends an ordered list of which compression 55 algorithms it supports. The other side selects one from the list, 56 which commits both sides to compressing the payloads of all 57 subsequent packets accordingly. 59 An example of where this could help is the transmission of email 60 messages with large attachments, often word processor documents or 61 slide presentations. Files of these types are quite compressible; 62 doing the compression at a higher layer, however, would require 63 either manual user intervention or changes to many different mail 64 sending and receiving packages. 66 This option is an example of a TCP filter option of the class 67 described in [FILTDRAFT]. 69 3.1. Specification of Requirements 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC-2119]. 75 4. Option Format 77 We use one TCP option, of type TCO (to be assigned by IANA), to 78 signal compression. A type field indicates the operation. 80 A compression algorithm announcement MUST NOT appear except as 81 specified by the [FILTDRAFT] protocol. (All TCPs MUST ignore unknown 82 options in SYN packets [RFC1122].) Compressed packets MUST NOT be 83 sent unless both parties have agreed to the appropriate filter via 84 the protocol [FILTDRAFT]. 86 Compression algorithm IDs will be assigned by IANA. 88 +--------+--------+---------+ 89 | TCO | len | alg... | 90 +--------+--------+---------+ 92 The compression filters, including any parameters, are fixed during 93 the three-way handshake by the protocol [FILTDRAFT]. Subsequently, 94 they may only be changed by in-band communication, i.e., by the 95 compression algorithms themselves interpreting the data stream. 97 +--------+--------+---------+---------+ 98 | TCO | len | alg | parm... | 99 +--------+--------+---------+---------+ 101 5. Behavior 103 As per [FILTDRAFT], by "initiator," we indicate the party that first 104 includes compression options in its SYN packet, and by "respondent," 105 we indicate the other party. 107 If the respondent (cf., [FILTDRAFT] protocol) has indicated that it 108 can accept a compression algorithm, a sender MUST use it. As 109 described in Section 2.2 of RFC 2393, the initiator SHOULD verify 110 that compression does not increase the size of the message. If it 111 does, it SHOULD NOT initiate compression. 113 Only the initial compression algorithms and parameters are determined 114 by the compression options in the handshake. Senders MAY apply 115 hysteresis to sending both compressed and uncompressed packets, per 116 RFC 2393, but only by using in-band communication, i.e., messages in 117 the data stream itself. In particular, to permit uncompressed data 118 to be co-mingled with compressed data, we anticipate that particular 119 compression algorithms will include their own header structures in 120 the data stream. Again, note that because of the stream nature of 121 TCP, the uncompressed portion may be sent in the same packet as 122 compressed data. Any necessary framing must be done by particular 123 compression algorithms. They may, however, specify the use of the 124 TCP record mark filter option [DRAFTREC]. 126 Senders MUST honor the compression algorithm specified by the 127 respondent, as per [FILTDRAFT]. Local dictates to the contrary 128 require in-band communication to alter the compression behavior; if 129 the compression algorithm precludes such communication, then the 130 session must be terminated and re-established with different (or 131 absent) compression options. 133 6. Interactions 135 6.1. TCP Urgent Pointer 137 Compression filters must note application requests to send urgent 138 data. The urgent pointer passed down to TCP must point to the 139 appropriate compressed bytes. Upon receipt of an urgent packet (more 140 precisely, a packet where the urgent pointer denotes a byte within 141 it), the uncompression routine must send the appropriate notification 142 to the application, while pointing to the proper uncompressed byte. 144 7. Security Considerations 146 Compressing data above the TCP layer should not have any negative 147 impact on security. In particular, port numbers are not compressed. 148 Some firewalls and intrusion detection systems examine TCP payload 149 data, however, and they may be confused by compression. The former 150 may wish to delete the compression option; if the latter are used, 151 administrators may wish to disable compression. 153 8. Acknowledgements 154 9. References 156 10. Appendix 158 Initial compression algorithms to be supported SHOULD include DEFLATE 159 [RFC2394] (algorithm code 0x00) and LZS [RFC2395] (algorithm code 160 0x01). 162 11. Author Information 164 Steven M. Bellovin 165 smb@research.att.com 166 +1 973-360-8656 168 Adam L. Buchsbaum 169 alb@research.att.com 170 +1 973-360-8674 172 S. Muthukrishnan 173 muthu@research.att.com 174 +1 973-360-7212 176 AT&T Labs--Research 177 Shannon Laboratory 178 180 Park Avenue 179 Florham Park, NJ 07974