Subject: [tcpm] RFC 793-bis comments

From: Anthony Sabatini <[email-masked]>
Date: Tue, 14 Oct 2014 23:49:21 -0400

[All - Please forgive my lack of comments, I have had surgery on both eyes over the last six months - Tony]

The purpose of revising a standard is to clarify and update it, but as importantly, to correct flaws which hinder future elaboration and standardization. 

There exists currently in TCP two such areas of concern, the offset field and the use of multiple command bits such as SYN and FIN in the same packet. 

Another area of concern is that the original RFC 793 document does not recognize the existence of devices that will relay messages and the standards for forwarding and discarding of messages in that class of device, as opposed to the behavior required of an end point device. The rules that require the discarding of a message by an end point device are not applicable to a transited device which must propagate all messages which it does not understand. It is crucial that the standard identify what conditions will be discarded by both devices and which shall be discarded by end point devices but forwarded by transited devices.  

One such condition is the setting of SYN and FIN in the same packet on an end point device where this combination is undefined the packet should be discarded, but on a transited device the packet must be forwarded since future standardization may, for example, define this combination as indicating a new TCP service such as a maintenance or traffic control message. 

The single biggest obstacle to improving TCP is the fact that the data offset field is both poorly defined and greatly limited. As currently defined half the possible values are invalid and the options area which it defines is too small to provide the necessary space to allow options to fulfill their full promise. Also being an offset it hard wires the size of a TCP header preventing the addition of header fields in a future standard. 

In the current standard the data offset field should be redefined as the length of the options field and values 0 - 7 should be defined as follows: "in normal use on an end point device a value of 0-7 should be discarded but on a transited device should be forwarded.  Values 0 -7 if present represent a TCP options area length of 32 - 60 bytes (8 - 15  32 bit words). Values 0 - 7 in current use can only be used by negotiation via the options field and thus cannot appear on a packet where a SYN is set" (subject to future standardization current end point devices should discard a packet with SYN and a value of 0 -7 transited devices should forward the packet). 

Anthony Sabatini
200 West 20th Street
Apt. 1216
New York, NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388

---

From: David Borman <[email-masked]>
Date: Wed, 15 Oct 2014 09:09:40 -0500

On Oct 14, 2014, at 10:49 PM, Anthony Sabatini <[email-masked]> wrote:

...

> One such condition is the setting of SYN and FIN in the same packet on an end point device where this combination is undefined the packet should be discarded, but on a transited device the packet m…

If only it were true that "transited device which must propagate all messages which it does not understand”, but that’s not the reality.
Though TCP is an end-to-end protocol, middle boxes delve into the TCP header and make decisions on whether or not a packet is acceptable, breaking the end-to-end nature of TCP.  It is sad that this has become the reality, and every proposed enhancement to TCP now has to consider how it will survive through middle boxes.

> In the current standard the data offset field should be redefined as the length of the options field and values 0 - 7 should be defined as follows: "in normal use on an end point device a value of…

Redefining the meaning of Data Offset values 0-4 (5-7 are valid) is not a new idea, see http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00.  As with any proposal for expanding the TCP option space, the biggest challenge is trying to make use of it in the initial SYN and still maintain backwards compatibility.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Oct 2014 07:50:08 -0700

On 10/14/2014 8:49 PM, Anthony Sabatini wrote:
> The purpose of revising a standard is to clarify and update it, but as
> importantly, to correct flaws which hinder future elaboration and
> standardization.

I disagree. AFAICT, changes to TCP need to be proposed and vetted
separately from the process of integrating those changes into RFC793-bis.

> There exists currently in TCP two such areas of concern, the offset
> field and the use of multiple command bits such as SYN and FIN in the
> same packet.

Behavior in that case is clearly defined in RFC793:

    eighth, check the FIN bit,

      Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
      since the SEG.SEQ cannot be validated; drop the segment and
      return.

> Another area of concern is that the original RFC 793 document does not
> recognize the existence of devices that will relay messages and the
> standards for forwarding and discarding of messages in that class of
> device, as opposed to the behavior required of an end point device. 

That's because TCP is a protocol between endpoints. Any intermediate
device that interprets or modifies TCP is acting (correctly or
incorrectly) on behalf of those endpoints.

We need to make sure that such middleboxes act correctly in that regard.
I disagree that we need to make TCP robust to any intermediate
participation.

A protocol has rules and defined behavior. Take that away and it's no
longer a protocol. Sometimes the answer has to be "NO, that's not
permitted".

> The
> rules that require the discarding of a message by an end point device
> are not applicable to a transited device which must propagate all
> messages which it does not understand. It is crucial that the standard
> identify what conditions will be discarded by both devices and which
> shall be discarded by end point devices but forwarded by transited
> devices. 
> 
> One such condition is the setting of SYN and FIN in the same packet on
> an end point device where this combination is undefined the packet
> should be discarded, but on a transited device the packet must be
> forwarded since future standardization may, for example, define this
> combination as indicating a new TCP service such as a maintenance or
> traffic control message.

That depends on whether the intermediate device is acting as a router
(in which case it shouldn't even be looking at the transport header) or
acting on behalf of an endpoint. Whenever it acts on behalf of an
endpoint, it limits that endpoint as well -- the overall protocol
behavior is the intersection of all devices that participate in the
protocol.

> The single biggest obstacle to improving TCP is the fact that the data
> offset field is both poorly defined and greatly limited.

It is very clearly defined. I agree that it is limited.

> As currently
> defined half the possible values are invalid and the options area which
> it defines is too small to provide the necessary space to allow options
> to fulfill their full promise. Also being an offset it hard wires the
> size of a TCP header preventing the addition of header fields in a
> future standard.
> 
> In the current standard the data offset field should be redefined as the
> length of the options field and values 0 - 7 should be defined as
> follows:

We've discussed this many times before; it is not possible to redefine
that (or most other) TCP fields in ways that don't affect legacy
implementations.

If you have a proposal for doing this, it would be useful to review
those past discussions as well as to explain how you intend to support
legacy endpoints.

That would be a separate document that would need to be accepted as a
standards-track change to TCP before being considered for a revision to
RFC793.

Because the current revision of RFC793 is underway, IMO all such new
proposals are not part of the current revision.

Joe