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

[Matthew Luckie <[e-mail]>]

> >>>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 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.
> 
> 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.