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

[Joe Touch <[e-mail]>]

On 1/24/2015 10:42 AM, Matthew Luckie wrote:
>>>>> 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.

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