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

[Wesley Eddy <[e-mail]>]

Hello, we had corresponded about your DISCUSS points a bit earlier, but 
now I've also had the time to go through your other COMMENTs:


On 9/22/2021 4:46 PM, Zaheduzzaman Sarker via Datatracker wrote:
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: Discuss
> ...
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks a lot to the author and the TCPM working group to produce this document.
> It has been long since I read the whole TCP specification, I refreshed myself a
> lot when reviewing this. Thanks for that experience.

Thank you!


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


>
> * Passive open and active open should be defined/described. Even if these are
> well known terms in the community, a verbose description of passive/active open
> will be much appreciated in this document context. if they are defined
> somewhere else then I have missed that, in that case a reference would be more
> appropriate.

This is a good point, and was clear in the original 793, so maybe we can 
just include the relevant text from there (pasted below). I'll try to 
find the best place to fit a slightly edited version of this in for -26, 
if you agree:

   The OPEN call also specifies
   whether the connection establishment is to be actively pursued, or to
   be passively waited for.

   A passive OPEN request means that the process wants to accept incoming
   connection requests rather than attempting to initiate a connection.
   Often the process requesting a passive OPEN will accept a connection
   request from any caller.  In this case a foreign socket of all zeros
   is used to denote an unspecified socket.  Unspecified foreign sockets
   are allowed only on passive OPENs.

   A service process that wished to provide services for unknown other
   processes would issue a passive OPEN request with an unspecified
   foreign socket.  Then a connection could be made with any process that
   requested a connection to this local socket.



> * Section 3.4 : says --
>      There are security issues that result if an off-path attacker is able to
>      predict or guess ISN values.
>
>     A reference to this claim would be highly appreciated. May be we can reuse
>     some ref from 41? I also think "Initial Sequence Number Selection", "Knowing
>     When to Keep Quiet" and "The TCP Quiet Time Concept" should be numbered
>     subtitles.

ACK, I'll add a reference here, and these sections are now numbered in 
my working copy.


>
> * Section 3.5 : can we put some reference for "security level or compartment"?
> A pointer to the appendix A.1 should be enough here.

ACK, this is now in my working copy.


>
> * Section 3.8.1 : says --
>
>     RFC 793 contains an early example procedure for computing the RTO. This was
>     then replaced by the algorithm described in RFC 1122, and subsequently
>     updated in RFC 2988, and then again in RFC 6298.
>
>    I am not sure what am I supposed to do with this information. Suggest to
>    remove this paragraph.

The intention was to make sure that it's clear 6298 is the place to 
look, and that the other descriptions have been replaced by it.  Maybe 
we used too many words for this small of a point though, and could say 
it more succinctly.


> * Section 3.8.5 : describes --
>
>      A TCP implementation MUST support a sequence of urgent data of any length
>      (MUST-31). [18]
>
>    I am not sure what is the reference for? if this is to say this MUST is taken
>    from [18] as described there then to me this reference also should be
>    normative.
>
It's only a reference to where that requirement originally appeared, and 
nothing further from [18] (RFC 1122) is needed to implement this properly.