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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

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.