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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 13:46:02 -0700

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* I found at least one reference that should be normative reference but they
are not. Section 3.8.5 : describes --

    TCP implementations MUST still include support for the urgent mechanism
    (MUST-30). Details can be found in RFC 6093 [38]

  This to ne makes RFC6093 a must to read and understand to deploy this
  specification. Hence it should in the normative references.

* (This perhaps more process thing than technical), me and Benjamin Kaduk
discussed another issue regarding urgent pointer. This specification specifies -

       Pointer indicates first non-urgent octet       | MUST-62|

  RFC1011 rectifies RFC973 to -

      The urgent pointer points to the
         last octet of urgent data (not to the first octet of non-urgent
         data).

  So what does happen to RFC1011 rectification then when 793bis is not bis
  anymore? Is this a known fact and there is conscious decision not to do
  anything about it? or was this a unknown fact and that part of RFC1011 need
  to be obsoleted (how?)?

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

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?

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

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

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

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

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

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 22 Sep 2021 18:27:49 -0400

Hi Zahed, I'll get to your (and the rest of the IESG's) other comments 
later, but wanted to answer to your DISCUSS points more immediately.  
See below.

>    specification. Hence it should in the normative references.

I propose to change this to say "Details on how some TCP implementations 
interpret the urgent pointer can be found in RFC 6093 [38]."  I think 
that would be more of what we want to convey, since it has been done 
differently (and incompatibly), thus why we say that applications 
shouldn't rely on it!  I think this is the right thing to do rather than 
a normative reference, because our goal was to incorporate the normative 
parts of 6093 into this 793bis.

Does this sound okay to you?

>    anything about it? or was this a unknown fact and that part of RFC1011 need

RFC 6093 was written to solve all of this confusion :).  There is really 
nice explanation in 6093 that when implementations were surveyed, most 
were not following 1011 (and 1122's incorporation of that bit from 
1011).  The logic and situation is explained more in 6093, but the most 
relevant short passage I can quote that is clear on the current 
situation is:

    we hereby
    updateRFC 793  <https://datatracker.ietf.org/doc/html/rfc793>  [RFC0793  <https://datatracker.ietf.org/doc/html/rfc0793>],RFC 1011  <https://datatracker.ietf.org/doc/html/rfc1011>  [RFC1011  <https://datatracker.ietf.org/doc/html/rfc1011>], andRFC 1122  <https://datatracker.ietf.org/doc/html/rfc1122>  [RFC1122  <https://datatracker.ietf.org/doc/html/rfc1122>]
    such that "the urgent pointer points to the sequence number of the
    octet following the urgent data" (in segments with the URG control
    bit set), thus accommodating virtually all existing TCP
    implementations.

Hopefully that helps!

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 24 Sep 2021 10:01:37 +0000

Hi Wes,

Thanks for the prompt response. We discussed the points in yesterday’s telechat. See my response reflecting the discussion below --

On 2021-09-23, 00:28, "Wesley Eddy" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Zahed, I'll get to your (and the rest of the IESG's) other comments later,

NO problem at all.

but wanted to answer to your DISCUSS points more immediately.  See below.
On 9/22/2021 4:46 PM, Zaheduzzaman Sarker via Datatracker wrote:

I propose to change this to say "Details on how some TCP implementations interpret the urgent pointer can be found in RFC 6093 [38]."  I think that would be more of what we want to convey, since it has been done differently (and incompatibly), thus why we say that applications shouldn't rely on it!  I think this is the right thing to do rather than a normative reference, because our goal was to incorporate the normative parts of 6093 into this 793bis.

With your modified test, this still sounds normative. 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.

         data).

  to be obsoleted (how?)?

RFC 6093 was written to solve all of this confusion :).  There is really nice explanation in 6093 that when implementations were surveyed, most were not following 1011 (and 1122's incorporation of that bit from 1011).  The logic and situation is explained more in 6093, but the most relevant short passage I can quote that is clear on the current situation is:

   we hereby

   update RFC 793<https://datatracker.ietf.org/doc/html/rfc793> [RFC0793<https://datatracker.ietf.org/doc/html/rfc0793>], RFC 1011<https://datatracker.ietf.org/doc/html/rfc1011> [RFC1011<https://datatracker.ietf.org/doc/html/rfc1011>], and RFC 1122<https://datatracker.ietf.org/doc/html/rfc1122> [RFC1122<https://datatracker.ietf.org/doc/html/rfc1122>]

   implementations.

Hopefully that helps!

Feels like 793bis then should update 1011 as well, as it does to 1122.

BR

Zahed