Network Working Group Bellovin, Buchsbaum, Muthukrishnan Internet Draft AT&T Labs--Research Expiration Date: April 2000 October 1999 TCP Filters draft-bellovin-tcpfilt-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." This draft document will be submitted to the RFC Editor as an Experimental RFC. Distribution of this document is unlimited. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract We propose a method to specify general-purpose filters between TCP and the application layer. The method is incrementally deployable, as neither party will use a filter layer without the other's consent. Bellovin FORMFEED[Page 1] Internet Draft draft-bellovin-tcpfilt-00.txt October 1999 3. Introduction TCP [RFC793] provides applications with a simple reliable byte stream. While this is a powerful primitive, some applications require more. For example, many applications require delimited records. Others benefit from compression or encryption. While these services can be implemented by individual applications, it is sometimes desirable to provide a common mechanism. This is especially useful for administratively decreed options that are intended to be used by unchanged applications. For example, an administrator can configure a pair of systems so that all FTP traffic between the two is compressed, without modifying either the clients or the servers. We describe a simple mechanism based on TCP options. During the exchange of SYN packets, one side initiates a filter negotiation by announcing what filters it is prepared to employ. The other responds in the next ACK packet by listing the subset of those filters that it is prepared to accept. Thence, each side applies the agreed upon filters to the payload in each subsequent packet. For the sake of simplicity, there is no negotiation after the initial three-way handshake. Furthermore, both directions use the same set of filters. 3.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. 4. Option Format Each filter uses one TCP option, of type TFI (to be assigned by IANA). SYN packets contain a list of filter options; these represent the types of filter the sender wishes to receive. A filter option has the following format: +--------+--------+--------+ | TFI | len | parm...| +--------+--------+--------+ A filter option announcement can have parameters; parameters are option-dependent and are described in the appropriate documents. Bellovin FORMFEED[Page 2] Internet Draft draft-bellovin-tcpfilt-00.txt October 1999 Each side includes the agreed upon options until it is guaranteed that the other side has received an ACK with those options. (Cf., Protocol.) Thence no filter options are included in subsequent packets. 5. Protocol By "initiator," we indicate the party that first includes filter options in its SYN packet. By "respondent," we indicate the other party. The initiator includes a list of filters it is prepared to employ in its SYN packet. The respondent includes a (possibly empty) subset of those options in its first ACK packet. Both sides are then committed to applying precisely the filters indicated by the respondent to the payload in each subsequent packet. (Cf., Behavior.) In the event of a simultaneous open, both sides will use the filters that form the intersection of the filter requests in the two SYN packets. This is confirmed by the two SYN+ACK packets. Both initiator and respondent MUST NOT include payload data in any SYN packet that includes filter options. Similarly, the contacted party MUST NOT act as an initiator if the initial SYN packet includes payload data. Because TCP options do not consume sequence number space, and hence are not acknowledged, each party MUST include precisely the options indicated by the respondent in all packets until it receives an ACK for a packet that contained at least one data byte, i.e., until it is guaranteed that the other party has acknowledged those options. Thereafter, the party does not include filter options in any subsequent packet. Bellovin FORMFEED[Page 3] Internet Draft draft-bellovin-tcpfilt-00.txt October 1999 6. Behavior If the respondent has indicated that it can accept a filter, a sender MUST use it. If multiple filters apply to a packet (cf., Protocol), it indicates that all of those filters were applied to the packet. Filters are applied by the receiving system in the order in which the options were specified by the respondent (cf., Protocol). Thus, if the options following the base TCP header denote "ENCRYPTION" and "COMPRESSION", the receiving system must first decrypt the packet and then uncompress it. Obviously, the sender must apply the filters in the opposite order, first compressing the packet and then encrypting it. Filters are strictly layered. There should not be interactions between different layers, though it is perfectly proper for one layer to assume the standard behavior provided by another. In particular, while it is perfectly proper for a filter to assume that TCP provides a reliable byte stream, it is not proper for it to assume any particular packet construction. If nothing else -- and there are many other reasons -- TCP's window size management, retransmission, and the coalescence of different segments into one during retransmission would wreak havoc on any filter that did make such assumptions. 6.1. Filter Selection Again, because of the unpredictability of TCP's actual packetization, the filters to be used MUST be constant during a connection. The first packet sent after the initial SYN for each side MUST include the filter options that will be used during all transmissions for that connection. This specifically includes the ACK packet that finishes the three-way handshake. Because filter options appear only so far as to acknowledge respondent's final choices, parameters in a given filter option are fixed by the SYN negotiation for the duration of a connection. They may be changed only by in-band communication, i.e., by the filter itself interpreting the payload data. 6.2. Header Compression Packets with filter options may be subject to header compression [RFC1144]. There is no problem in doing so. Changes to the TCP options field can have a negative effect on header compression; this should not present a serious problem, however, since the options Bellovin FORMFEED[Page 4] Internet Draft draft-bellovin-tcpfilt-00.txt October 1999 occur only in the initial packets of a connection. 6.3. TCP URGENT Markings Since TCP proper is unaware of the behavior (or even the existence) of any filter modules, it will simply note the URGENT pointer as usual. It is the responsibility of filter modules to handle this properly, including notifying the application (or any higher layers) as needed. Filters that change the length of the application- supplied data stream, such as compression modules, MUST make the corresponding adjustments to the effective URGENT pointer that is passed up. 7. Open Issues The exact option syntax proposed here may not be ideal. To conserve option space, it may be useful to make all filters suboptions to a single TCP filter option. It may also be useful to use separate options for request and transmission. That would avoid possible race conditions in the event of complex retransmissions of SYN+ACK packets or simultaneous opens, or to permit different filters to be used in each direction. In the simultaneous open case, separate options would also permit proper acquiescence to a filter request by a host that supports the option but had not requested it. We considered allowing packet-level filter specification, by including appropriate filter options in each data-carrying packet. This would allow out-of-band modulation of the filter behavior during the connection. While such packet-level specification is theoretically possible, we anticipate that making the protocol robust, in particular vis-a-vis packet retransmission and coalescence, will be hard enough to make it impractical. Bellovin FORMFEED[Page 5] Internet Draft draft-bellovin-tcpfilt-00.txt October 1999 8. Security Considerations Filtering data above the TCP layer should not have any negative impact on security. In particular, port numbers are not affected. Some firewalls and intrusion detection systems examine TCP payload data, however, and they may be confused by some filters. The former may wish to delete filter options; if the latter are used, administrators may wish to disable such options. Particular filter options, such as encryption, may have their own security considerations. 9. Acknowledgements 10. References 11. Author Information Steven M. Bellovin smb@research.att.com +1 973-360-8656 Adam L. Buchsbaum alb@research.att.com +1 973-360-8674 S. Muthukrishnan muthu@research.att.com +1 973-360-7212 AT&T Labs--Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07974 Bellovin FORMFEED[Page 6]