Subject: [tcpm] [Technical Errata Reported] RFC7413 (4239)

From: RFC Errata System <[email-masked]>
Date: Thu, 22 Jan 2015 15:24:20 -0800 (PST)

The following errata report has been submitted for RFC7413,
"TCP Fast Open".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7413&eid=4239

--------------------------------------
Type: Technical
Reported by: Matthew Luckie <[email-masked]>

Section: 4.2.1

Original Text
-------------
   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 0 (empty cookie field).

Corrected Text
--------------
   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 2 (empty cookie field).

Notes
-----
A Nil fast-open option has an option length of 2.  A length field of zero would mean an invalid TCP option.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7413 (draft-ietf-tcpm-fastopen-10)
--------------------------------------
Title               : TCP Fast Open
Publication Date    : December 2014
Author(s)           : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain
Category            : EXPERIMENTAL
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2015 15:51:10 -0800

Hi, all,

On 1/22/2015 3:24 PM, RFC Errata System wrote:
> A Nil fast-open option has an option length of 2. 

Agreed.

> A length field of zero would mean an invalid TCP option.

Disagree. The correct reason is, IMO:

	The Nil option has no bytes beyond the Kind and Length
	fields required in all TCP options, and the Length field
	includes the space used for Kind and Length.

The interpretation of an option with a 0 length should not be discussed
in the errata or future updates to this doc; it is out of scope.

(AFAICT, if it were observed, the entire segment would have to be deemed
invalid, not just that individual option. But that's not germane to this
errata).

I suggest the errata be updated accordingly.

Joe

---

From: Matthew Luckie <[email-masked]>
Date: Fri, 23 Jan 2015 19:57:51 -0800

> invalid, not just that individual option. But that's not germane to this

I do not think that the reasoning behind this errata needs to be
discussed in future updates to the RFC (I put my reasoning in the
Notes field of the errata form) but I absolutely believe that a TCP
option defined after RFC793 with a length of zero is an invalid option
that will cause a TCP receiver to stop processing the options.

https://tools.ietf.org/html/rfc793 <-- page 17

Options:  variable

    Options may occupy space at the end of the TCP header and are a
    multiple of 8 bits in length.  All options are included in the
    checksum.  An option may begin on any octet boundary.  There are two
    cases for the format of an option:

      Case 1:  A single octet of option-kind.

      Case 2:  An octet of option-kind, an octet of option-length, and
                     the actual option-data octets.

    The option-length counts the two octets of option-kind and
        option-length as well as the option-data octets.

https://tools.ietf.org/html/rfc5925  <-- page 8

 (discussing a different option type, but all options post 793 are TLVs,
  and this RFC specifically says that the segment should be discarded.
  granted that it is a different TCP option)

   o  Length: An unsigned 1-byte field indicating the length of the
         option in bytes, including the Kind, Length, KeyID, RNextKeyID,
	       and MAC fields.

      >> The Length value MUST be greater than or equal to 4.  When the
            Length value is less than 4, TCP MUST discard the segment.

===

Matthew

---

From: Matthew Luckie <[email-masked]>
Date: Sat, 24 Jan 2015 10:42:41 -0800

> It should be interpreted as a malformed segment, not simply stop the
> processing of the options.

OK.  I took a more careful read of your responses and I think we are
somewhat in agreement, about L<2 being malformed.  But, the source of
two TCP stacks (Linux tcp_parse_options() and FreeBSD tcp_doptions())
show that they just stop processing the options when they get a TLV
option with a L < 2, rather than discard the segment.

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Jan 2015 09:03:31 -0800

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Jan 2015 12:38:24 -0800

> option with a L < 2, rather than discard the segment.

I think that is a mistake in both implementations. Once something 
nonsensical occurs in a TCP header, the segment should be discarded. 
Logging it (with rate limiting) would be nice too. But the rest of the 
message clearly should not be acted upon.

Joe