Internet DRAFT - draft-leslie-tcpm-checksum-option
draft-leslie-tcpm-checksum-option
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]
