Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

> On 8 Jan 2022, at 18:46, [e-mail] wrote:
> 
> 
>> On Jan 7, 2022, at 11:04 AM, Wesley Eddy <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> I have some comments/questions below. By addressing those, I hope will improve
>>> the document even better:
>>> 
>>> * Section 3.1 : says --
>>>      Note that the list of options may be shorter than the data offset field
>>>      might imply. The content of the header beyond the End-of-Option option
>>>      must be header padding (i.e., zero).
>>> 
>>>    Should this be a normative MUST?
>> Great question ... The EOL option is a zero byte, and the first such option should signal that the option list is over.  So the receiver shouldn't need to process or check any further bytes of options to see if they're also properly zero'ed padding.
>> 
>> So, I wouldn't think this needs to be normative, since if it's not followed, no harm should result.  However, that leads to the question of why it says they must be set to zero then.  Maybe someone else from TCPM has a better answer than "that's just what it's always said" ... To me, it seems like it's a good thing to do, but maybe not really required.
>> 
> I don’t know the original reason, but there are at least three candidates:
> 
> A) because zeroes make it easy to check because they won’t affect the TCP checksum further
> B) to avoid permitting a covert channel
> C) to avoid needing to add and check for NOPs - which are not zeroes, thus need to be checked because they would affect the TCP checksum
> 
> So yes, I think for at least these reasons it should be a MUST. Another way to state this is that an EOL MAY be followed by one or more EOLs to enable alignment of the payload, but MUST NOT be followed by any other option.

With this input I am a bit convinced that we need to be more verbose about the reasons and consider if we should introduce the MUST NOT not part. I would expect  rfc793-bis to be more clearly stating the do’s and don's to the protocol implementers.

//Zahed