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

From: Wesley Eddy <[email-masked]>
Date: Thu, 6 Jan 2022 14:54:07 -0500

This has been on the back burner for a while, but looping back to it now 
... here are some changes I've got ready for submission in a -26 
revision, to see if they sound good to you.

On 9/24/2021 6:01 AM, Zaheduzzaman Sarker wrote:
>
> As we are not deprecating the use of urgent mechanism and it is MUST 
> to support any details to support that is still normative. One 
> alternative would be to bring the related parts of 6093 to the 793bis 
> and be explicit about the warning ( different and incompatible), this 
> fits to intention you describes also perhaps fits better to the fact 
> that 793bis is obsoleting 6093.
>
In 793bis, the change in the definition of the urgent pointer from 6093 
has been fully incorporated.  The only value to referencing 6093 is to 
point to historic and contextual information to explain the odd 
situation.  In the working copy, I've changed the sentence referencing 
to it from:

    Details can be found in RFC 6093.

to:

    Information on how some TCP implementations interpret the urgent
    pointer can be found in RFC 6093.

To be clear, there are no details required for a correct implementation 
in 6093 that aren't in 793bis; 6093 just provided a lot of explanation 
about the situation of the urgent pointer, implementation status, usage 
by applications, and then made the SHLD-13 and MUST-30 statements (that 
are in 793bis) as a result.

> Feels like 793bis then should update 1011 as well, as it does to 1122.
>
You're right, since this is the new TCP specification, it should update 
1011 to say that the things noted there have been included.  I've added 
that in the working copy, and some text explaining it as:

    RFC 1011 contains a number of comments about RFC 793, including some
    needed changes to the TCP specification.  [...]  The present
    document updates RFC 1011, since the comments noted in 1011 have
    been incorporated.:w

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 7 Jan 2022 14:04:23 -0500

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.

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 8 Jan 2022 09:46:50 -0800

> On Jan 7, 2022, at 11:04 AM, Wesley Eddy <[email-masked]> wrote:
> 
> 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.

Joe

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 17 Jan 2022 10:49:25 +0000

> On 8 Jan 2022, at 18:46, [email-masked] wrote:
> 
> 
>> On Jan 7, 2022, at 11:04 AM, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
>> 

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