[tcpm] Handling of malformed options (was: Re: poll for adopting draft-gont-tcp-security)

[Fernando Gont <[e-mail]>]

Hello, Joe,

>>>> This suggests that extending SACK while still using the same option type
>>>> is not a good idea, or at least not a backwards-compatible one.
>>> ...
>>>
>>> It may also suggest a bug.
>> Where's the bug? The spec says the length field is e.g. 2. If you
>> implement the standard, and receive an option with a length field that
>> is different than 2, how are you supposed to process the option? If you
>> don't know how to process it, it seems sensible to ignore the option.
> 
> OK, since this is supposed to be a security doc, can you explain why you
> take a segment with a mis-formed option and ignore it, even when the
> length - the field that tells you where the next option starts - is
> nonsensical?
> 
> Why don't you drop the segment or send a RST?

draft-gont-tcp-security recommends to silently drop the segment, *NOT*
to silently ignore the option.

>From Section 4.4.1 (page 43) of draft-gont-tcp-security-00:

"  The SACK-permitted option is composed by an option-kind octet (which
   must be 4), and an option-length octet which must be 2.  Therefore,
   the following check should be performed on the option:

   option-length == 2

   If the option does not pass this check, the TCP segment carrying the
   option should be silently dropped."


This should be a clear example that this document is not simply turning
"current implementations" into "advice". i.e., the advice provided
sometimes differs from what many implementations are doing (as in this
case).

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1