tcpm J. Leslie Internet-Draft JLC.net Intended status: Standards Track October 23, 2014 Expires: April 26, 2015 Checksum Option for TCP draft-leslie-tcpm-checksum-option-00 Abstract There are a number of situations in TCP where middleboxes are known to change TCP-layer data; and it would be helpful for endpoints to detect such changes. TCP-Checksum is a TCP option to pass checksums over particular fields from sender to receiver, which can detect such changes by legacy middleboxes. This document also sets a rule for future middleboxes which insist upon modifying these checksums. Requirements Language 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 [RFC2119]; but only when used in UPPERCASE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Internet-Draft will expire on April 26, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Leslie Expires April 26, 2015 [Page 1] Internet-Draft TCP-Checksum October 2014 Provisions Relating to IETF Documents (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms used in this Document . . . . . . . . . . . . . . . . . 3 3. The TCP-Checksums Option . . . . . . . . . . . . . . . . . . 3 4. Rule for future Middleboxes . . . . . . . . . . . . . . . . . 5 5. Ones-Complement Checksums . . . . . . . . . . . . . . . . . . 5 6. An Initial Use Case . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Middlebox-traversal is a long-standing problem when using TCP as a transport. This document describes TCP-Checksums, an option to checksum particular fields of TCP packets to detect middlebox changes. It does not attempt to give advice on what to do when changes are observed. It does set rules for future middleboxes to prohibit some possible practices when such middleboxes modify the checksums in this option. In particular, middleboxes cannot recognize TCP options which are only defined after the middlebox software is written; and there has been no standard of what to do with such options. Some middleboxes ignore them; some middleboxes drop packets with unknown options; and some have been observed to quietly delete unknown options while leaving others intact. This last practice, deleting individual options, has caused many problem in trying to deploy new TCP options. Thus, this document establishes a rule that unknown options MUST NOT be deleted if a TCP-Checksums option is present. Leslie Expires April 26, 2015 [Page 2] Internet-Draft TCP-Checksum October 2014 2. Terms used in this Document The term "middlebox" as used in this document means any device, or program within another device, along the path from sender to receiver which performs inspection of TCP-layer information with the intent to modify TCP-layer information or enforce rules to drop certain TCP/IP packets. 3. The TCP-Checksums Option The TCP-Checksums Options uses the "type-length-value" format overall. The "value" part may contain requests and/or calculated checksums. The "value" portion may contain requests and/or checksums. The simplest case is two octets, announcing support for the option but no actual checksums or requests. If the length exceeds two octets, the remainder is requests and/or checksums, distinguished by the octet next in sequence. All requests have the high-order bit zero; all checksums have the high-order bit one. The "request" case is, for each request, a single octet stating what portion of the packet the checksum should cover, and what format is requested. The "request" may request a single returned checksum, a continuous stream of returned checksums, or stopping that continuous stream. It is important to note that requests are not "reliably delivered" -- any request may be dropped if the packet it is in is dropped, or even might be deleted by a middlebox. Neither is there any protocol requirement that returned checksums must correlate with the requests, even if they are received. In fact, it is expected that it will be common to send a checksum without it having been requested. The single octet for each request has four fields: the high-order bit set to zero to indicate a request; three bits for field covered; two bits for checksum-type; two bits for checksum-length. The field-covered values defined are 0x0: the base TCP header (not including any options); 0x1: the TCP options (whatever the sender considers to be options); 0x2: the TCP payload intended to go to the application; 0x3-7: for future use. The checksum-types defined are Leslie Expires April 26, 2015 [Page 3] Internet-Draft TCP-Checksum October 2014 0x0: none (please stop sending this); 0x1: ones-complement checksum, send once; 0x2: ones-complement checksum, every packet; 0x3: for future use. The checksum-lengths defined are 0x1: one-octet; 0x2: two-octets; 0x3: three-octets; 0x0: four-octets. Note that all "requests" are one octet in length. The "checksum" case is similar, but always more than one octet in length: for each checksum, a single octet stating what portion of the packet is checksummed and what format, followed, by the (known) number of octets for that checksum. The single octet introducing each request has four fields: the high-order bit set to one to indicate a checksum; three bits for field covered; two bits for checksum-type; two bits for checksum-length. The field-covered values defined are 0x0: the base TCP header (not including any options); 0x1: the TCP options (what the sender considers to be options); 0x2: the TCP payload intended to go to the application; 0x3-7: for future use. The checksum-types defined are 0x0: (not used); 0x1: ones-complement checksum; 0x2-3: for future use. The checksum-lengths defined are 0x1: one-octet (one octet follows); 0x2: two-octets (two octets follow, high-order octet first); 0x3: three-octets (three octets follow, high-order octet first); 0x0: four-octets (four octets follow, high-order octet first). The overall length (second octet of the option) is the total length in octets, including all requests and checksums; and thus can range Leslie Expires April 26, 2015 [Page 4] Internet-Draft TCP-Checksum October 2014 from 2 to 20 or more. Note that no interaction between requests and checksum(s) returned is defined in this protocol: for one example, it is perfectly OK to return a shorter checksum than requested. Since there is no interaction defined to be required, this protocol does not, of itself, need this option to first occur on a SYN packet (though that practice is expected to continue). 4. Rule for future Middleboxes Legacy middleboxes will not be aware of this option, and MAY ignore it or drop packets containing it. The TCPM working-group does not consider it legitimate to delete just this option, but is not hoping to enforce any rule against it. Middleboxes that are aware of it MAY use it to verify their understanding of what is going on; but SHOULD NOT change any checksum values. Middleboxes that do change any checksum values MUST accept full responsibility to comply with any options contained in the packet, including ones defined after the middlebox is programmed. In particular, Middleboxes which understand this option MUST NOT change the checksum values contained in it if the packet, as received, also contains any option they do not understand. (Note that, if for some reason a future middlebox originates a TCP-Checksums option, the question of "changing" checksum values does not arise; but a middlebox SHOULD NOT originate this option if the packet arrived with any option(s) it does not understand.) The TCPM working group does not agree it would ever be appropriate for middleboxes to change the TCP-Checksums checksum values, but this rule should be sufficient to keep the TCP-Checksum option useful in the future. 5. Ones-Complement Checksums Ones-Complement checksums are, simply, all the individual octets added together in one's complement arithmetic. One's complement arithmetic, for eight-bit registers, can have the values -127 through +127, with two combinations representing zero: all-bits-zero, and all-bits-one. Nowadays, it is usually implemented with twos- complement hardware by summing into a larger register; then shifting the high-order bits right the size of the field, and (twos- complement) adding that to the masked field-length bits, repeatedly until there are no bits in the result exceeding the field length. Note that deriving an 8-bit ones-complement checksum from a multi- octet ones-complement checksum is simple, and there is no penalty Leslie Expires April 26, 2015 [Page 5] Internet-Draft TCP-Checksum October 2014 beyond the extra length to receive a longer checksum than requested. Receivers must be able to deal with this (but they must also be able to deal with non-requested checksums, so that shouldn't be an issue The value all-bits-zero is generally not found in the result unless the field being checksummed contains no non-zero octets. We could define that the sender ensure that the zero value be only represented as all-ones, reserving the all-zeros value to flag something else. At the time of this writing, no use for such a flag comes to mind; and the effort is the same whether done by sender or receiver; so for the present, the receiver is expected to check for all-zeros and treat it as all-ones when comparing the checksum received to the checksum computed. 6. An Initial Use Case This work has been inspired by the TCPM working-group attempts at expanding the TCP option space. Middlebox-traversal of expanded option space has proven quite challenging, due to the different things middleboxes have been observed to do and the possibility that different middleboxes, or even the same middlebox with a software upate, might do during the course of a TCP connection. Thus, discussion included the possibility of checksumming the expanded option space whenever an expanded-option-space TCP option is used. From there, it became obvious that checksumming could be a useful tool for other problems. The TCPM working-group has not attempted to reach consensus on exactly when a checksumming option might be used in such cases, preferring to leave that to implementors. The following use-case is just one possibility. Every time an expanded-option-space TCP option is used to signal more than 40 octets of options, it is an unsolved problem what middleboxes might interpret this to mean. The TCP-Checksums option could be used to check for middlebox changes to the field(s) containing the TCP options and extended options. If that checksum fails, the receiving endpoint knows there's middlebox damage, and can route around it. (Details are not appropriate in this document.) Note that both endpoints will have agreed to the interpretation of an expanded-option-space TCP option; and it doesn't matter to them whether a middlebox understands it -- only that a middlebox may have somehow changed the packet. Two obvious examples might be that middleboxes have been observed to delete unknown options without dropping the packet, and middleboxes are known to "coalesce" payload octets from different packets into a single packet or split a packet Leslie Expires April 26, 2015 [Page 6] Internet-Draft TCP-Checksum October 2014 into multiple packets. It is those cases which must be detected. 7. IANA Considerations IANA shall allocate one value in the TCP Option Kind Numbers registry for the TCP-Checksums option. 8. Security Considerations The TCP-Checksums Option introduces no additional Security concerns; but one must be careful not to read into it features it doesn't claim. It is not intended to detect all possible middlebox damage; nor does it intend to suggest any particular remediation of problems it helps detect. 9. Acknowledgements Joe Touch suggested writing this up as a separate RFC. 10. References 10.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Author's Address John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 USA Phone: +1.603.673-6132 Email: john@jlc.net Leslie Expires April 26, 2015 [Page 7]