Transmission Control Protocol (TCP)
draft-ietf-tcpm-rfc793bis-28

Thank you for the work on this document. I only have minor comments, and some questions.

I have divided comments into "minor" (including the questions) and "nits". Neither require replies strictly speaking, please feel free to address as you see fit. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document.

Francesca

## minor

1. -----

Figure 1

FP: The figure's capture is "TCP Header Format", but Options and Data are included as well.

2. -----

Figure 2

FP: For consistency, I would have kept the same style as in Figure 1. Additionally, the IPv4 fields below do not have their size explicitly specified, so using the same type of formatting as in Figure 1 would help, IMO.

3. -----

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |       0       |
      +-+-+-+-+-+-+-+-+

FP: More of a question than a comment: how come this change, compared to RFC 793? Any particular reason, or was it only for readability?

4. -----

FP: This is surely me missing something but, in section 3.5 I see:

   4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED

   5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

which is followed by:

   Note that the sequence number of the segment in line 5 is the same as
   in line 4 because the ACK does not occupy sequence number space (if
   it did, we would wind up ACKing ACKs!).

However, later on, in Figure 13:

   2.  (Close)                                              (Close)
       FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
                   <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
                   ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->

   3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
                   <-- <SEQ=301><ACK=101><CTL=ACK>      <--
                   ... <SEQ=101><ACK=301><CTL=ACK>      -->

I am confused why in this case, in line 3, ACK does in fact occupy sequence number space. What am I missing?

## nit

5. -----

   Initial Sequence Number Selection

FP: I assume this (and following) was not numbered to keep it as close as possible to the original RFC, is that right? For readability, I would suggest numbering these subsections.

Thanks very much for this document and all the work that went into it. Thanks also for the clear and illuminating shepherd write-up.

Below are some comments I hope will be helpful.

1. Regarding in §1,

  The purpose of this document is to bring together all of the IETF
  Standards Track changes that have been made to the base TCP
  functional specification and unify them into an update of [RFC 793].

It also incorporates Informational documents, right? For example, RFC 6691 is Informational, as is 6429. So, these are being elevated, by virtue of their incorporation, to Standards Track. I'm not saying that's a problem, but the quoted text, while technically accurate I suppose (it doesn't say "exclusively Standards Track changes" after all) is misleading.

2. Regarding, in §3.4,

  A new acknowledgment (called an "acceptable ack"), is one for which
  the inequality below holds:

   SND.UNA < SEG.ACK =< SND.NXT

I’m having a hard time seeing why the first part of the inequality is < and not =<. Wouldn’t =< be the case when a single new byte is being acknowledged? (Based on the definition that SND.UNA is the “oldest unacknowledged sequence number” and therefore, presumably needs to be acknowledged.) I do see this text is unchanged from RFC 793 so I am very likely wrong, but I’d appreciate knowing WHY I’m wrong…

3. Regarding, in §3.4,

     even if data rates escalate to 10's of megabits/sec. At 100
     megabits/sec, the cycle time is 5.4 minutes, which may be a little
     short, but still within reason.

I realize this is, again, inherited from RFC 793 but it seems hopelessly quaint in 2021 and not suitable for publication today. I mean, my unexceptional commodity home connection is 1 Gbps and it just goes up from there. At 100 Gbps we’re down to a cycle time of ~300 msec which no longer seems so easy to brush off as "still within reason". I’m not suggesting this document has to fix the problem, and indeed I’m aware there are other documents for this purpose — but does the outdated text have to be retained? 

4. The parenthetical reference to “User Telnet” in §3.8.3 seemed equally anachronistic. Seems like it could just be removed. 

5. It made me sad while reviewing the document, that certain sections were stingy with subsection numbering. In particular §3.4 has the unnumbered subheadings "Initial Sequence Number Selection", "Knowing When to Keep Quiet", and "The TCP Quiet Time Concept", and §3.5 has "Half-Open Connections and Other Anomalies", "Reset Generation", and "Reset Processing". I think it would make the document more usable if these were numbered, as we tend to do in the modern era, and as the rest of the document does do. (I may have missed some, the list above isn't necessarily exhaustive.)

Nits:

6. I found it odd that figure 11 uses Z and X as the sequence numbers, whereas all the previous illustrations used actual numbers. It works of course, but it's inconsistent.

7. In §3.1:

   The control bits are also know as "flags"

   S/know/known/

8. In §3.1, “one’s complement” should be “ones’ complement”. 

9. In §3.3.2:

   transitions are not not explicitly shown

   Presumably the double negation isn’t isn't deliberate. :-)

10. In §3.4:

    next sequence number expected on an incoming segments

    Should be segment, singular. 

11. In §3.4:

    sequence space occupying controls

    I think this needs, or at least would be better with, a hyphen: “sequence space-occupying controls”

12. In several places, "anyways" should probably be "anyway". (At least my dictionary suggests the change.)

13. In §3.4:

  Hosts that prefer to avoid waiting are
  willing to risk possible confusion of old and new packets at a given
  destination may choose not to wait for the "quiet time".

“Are willing” should be “and are willing”

14. In §3.6:

    the user can terminate his side gracefully

Perhaps consider a non-gendered pronoun such as "their"?

15. In §3.8.2:

  [RFC 1122] required implementation of Van Jacobson's congestion control
  algorithms slow start and congestion avoidance together with

Seems as though there’s some punctuation missing. Perhaps “RFC 1122 required implementation of Van Jacobson’s congestion control algorithms, slow start, and congestion avoidance, together with“?

16. “Internet” is inconsistently capitalized throughout, probably corresponding to age of the text. But I suppose the RFCEd will fix this.

I have discussed the open DISCUSS items listed by Ben Kaduk with Wesley Eddy and Martin Duke. Ben's first issue was discussed in the WG and rejected by consensus. The document shepherd also raised that making changes to the protocol that weren't a part of other RFCs or erratas was "out of scope" for this update. Ben's remaining issues were discussed at a previous IESG telechat.

Thank you to Kyle Rose for the SECDIR review.

I support Ben, Lars, Warren and Zahed’s DISCUSS positions.

** Appendix A.1 and the shepherd write-up which explains why the antiquated text around “security compartments” for multi-level systems is still in this draft.  It’s disappointing that there was no prior IETF consensus action to establish the basis of pruning it.  My suggested addition for Appendix A.1 would be to make a much clearer statement than “the state of IP security options that may be used by MLS systems is not as clean”.  It isn’t clear what is meant by “clean” – is it intended to say that it is not in fact used?

** Section 3.1. Per “[TCP Option]; Options#Size == (DOffset-5)*32;”, I found this notation confusing. What does the “#” in “Options#Size” indicate?

** Section 3.4.  Per “There are security issues that result if an off-path attacker is able to predict or guess ISN values”, a reference might be helpful for this statement.  Perhaps [41] or [Morris185] from [41].

** Section 3.9.2 and 3.9.2.1 The text here discusses various IP options like timestamp, record route and source routing.  Either in this section or in the Security Considerations the security implications of these options should be highlights.  Specifically, Section 4.3 – 4.5 of RFC7126 outline these security issues and has normative guidance to treat these packets as default drop. 

** Section 7.  Recommend being more precise on the lack of security services:

OLD
but there are no built-in cryptographic capabilities
   to support any form of privacy, authentication

NEW
but there are no built-in cryptographic capabilities
   to support any form of confidentiality, authentication

** Section 7.
   In order to fully protect TCP connections (including their control
   flags) IPsec or the TCP Authentication Option (TCP-AO) [36] are the
   only current effective methods. Other methods discussed in this
   section may protect the payload 

The text should be more precise on what “protect” means.  IPSec and TCP-AO provide different security services.  IPSec will provide confidentiality and integrity, but TCP-AO only provides the latter.

Likewise, the reference to protect the payload needs to be clarified.  Which exact security service does “protect” align with?

** Section 7.  Further discussion on TCP stack fingerprinting would be helpful.  RFC8546 notes that “In particular, the metadata, such as sequences of interpacket timing and packet sizes, can be used to    infer other parameters of the behavior of the protocols in use or to fingerprint protocols and/or specific implementations of those protocols.”  However, it’s more than that – it’s the specific choices of options, their sequence in the packets, etc.  Pretty much everything a tool like nmap does to profile host OSes.

--- EDIT ---
I originally balloted DISCUSS, ending with "As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise." - I see that there was a discussion on the list. I still think that it would be useful to have some additional text so that users don't cut themselves on sharp edges, but this is just my opinion, and so I'm clearing the DISCUSS.
Thanks all for the DISCUSSion.
----

Thank you very much to the authors and WG for writing this -- it's an important piece of work, and seems like it was probably also a large amount of work. Thanks!

Also, thanks to Sarah Banks for the OpsDir review - it was helpful.
Oh, and thanks to Erik, whose text I stole :-)

Thanks for addressing my Discuss and comments. I am happy with the current version. This is really a good work...

As I am on vacations abroad, I had no time to review this very-much-needed document, hence, I am trusting the Internet directorate review by Bernie Volz:
https://datatracker.ietf.org/doc/review-ietf-tcpm-rfc793bis-25-intdir-telechat-volz-2021-09-22/

Thank you for your time spent on this 'bis' document

-éric

Section 3.1. , paragraph 50, comment:
>      Note: There is ongoing work to extend the space available for TCP
>      options, such as [64].

draft-ietf-tcpm-tcp-edo has been dead for four years, not sure how useful it is
to point to.

Section 3.4. , paragraph 35, comment:
>    Initial Sequence Number Selection

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 46, comment:
>    Knowing When to Keep Quiet

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 47, comment:
>    The TCP Quiet Time Concept

Shouldn't this be a heading starting a new sub-section?

Section 3.4. , paragraph 49, comment:
>    At 2 megabits/sec. it
>    takes 4.5 hours to use up 2**32 octets of sequence space.  Since the
>    maximum segment lifetime in the net is not likely to exceed a few
>    tens of seconds, this is deemed ample protection for foreseeable
>    nets, even if data rates escalate to 10's of megabits/sec.  At 100
>    megabits/sec, the cycle time is 5.4 minutes, which may be a little
>    short, but still within reason.

It would be nice to see an argument if any considerations change for today's
higher-bandwidth Internet paths.

Section 3.5. , paragraph 37, comment:
>    Half-Open Connections and Other Anomalies

Shouldn't this be a heading starting a new sub-section?

Section 3.5. , paragraph 74, comment:
>    Reset Processing

Shouldn't this be a heading starting a new sub-section?

Section 3.9.1. , paragraph 1, comment:
> 3.9.1.  User/TCP Interface

This section would be much more readable if each command was in its own
sub-section. I find deeply indented text that spans multiple pages difficult to
follow.

Section 5. , paragraph 50, comment:
>    Early in the process of updating RFC 793, Scott Brim mentioned that
>    this should include a PERPASS/privacy review.  This may be something
>    for the chairs or AD to request during WGLC or IETF LC.

Has this review has happened?

Document obsoletes RFC793, but does not cite it as a reference.

Document obsoletes RFC879, but does not cite it as a reference.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.3.2. , paragraph 21, nit:
-       Note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT
-               ^^  ^ ^^^^           -------
+       Note 2: The figure omits a transition from FIN-WAIT-1 to TIME-WAIT
+               ^^^ +++ ^^^^^^^ ^^

Section 3.8.6.1. , paragraph 4, nit:
-    paper" situation described in Section 4.2.2.17 of RFC1122.  The
-                                                      ^^^ ^^^
+    paper" situation described in Section 4.2.2.17 of [18].  The
+                                                      ^ ^^

Section 3.8.6.3. , paragraph 3, nit:
-    recomendations to immediately acknowledge out-of-order segments,
+    recommendations to immediately acknowledge out-of-order segments,
+        +

"Table of Contents", paragraph 2, nit:
>  . . . . . . . . . 108 A.4. Low Water Mark Settings . . . . . . . . . . . .
>                                 ^^^^^^^^^^
This is normally spelled as one word.

Section 3.1. , paragraph 8, nit:
> ing host. The control bits are also know as "flags". Assignment is managed b
>                                     ^^^^
Did you mean "known"?

Section 3.2. , paragraph 12, nit:
> ue and to the current segment. In addition several variables relating to the
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 3.3.2. , paragraph 15, nit:
> m SYN-RECEIVED to LISTEN on receiving a RST is conditional on having reached
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.3.2. , paragraph 16, nit:
> rationale). These transitions are not not explicitly shown, otherwise the di
>                                   ^^^^^^^
This phrase contains a double negative, or a comma may be missing.

Section 3.3.2. , paragraph 16, nit:
> icult to read. Similarly, receipt of a RST from any state results in a trans
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.4. , paragraph 25, nit:
> The clock component is intended to insure that with a Maximum Segment Lifetim
>                                    ^^^^^^
Did you mean "ensure" (=make sure)? "Insure" means "pay money to insurance
company".

Section 3.4. , paragraph 37, nit:
> owing whether the segment was an old delayed one or not, unless it remembers
>                                  ^^^^^^^^^^^
Make sure that the adjective "old" is correct. Possibly, it should be an adverb
(typically ~ly) that modifies "delayed". Possibly, it should be the first word
in a compound adjective (hyphenated adjective). Possibly, it is correct.

Section 3.4. , paragraph 37, nit:
> e sender to verify this SYN. The three way handshake and the advantages of a
>                                  ^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.4. , paragraph 47, nit:
> nets, even if data rates escalate to 10's of megabits/sec. At 100 megabits/se
>                                      ^^^^
Apostrophes aren't needed for decades.

Section 3.5. , paragraph 3, nit:
> he ACK field is incorrect and returns a RST (reset) with its SEQ field select
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 25, nit:
> onnection exists, so TCP Peer A sends a RST. The RST is acceptable so TCP Pe
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 29, nit:
> (line 3) and causes TCP A to generate a RST (the ACK in line 3 is not accepta
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.5. , paragraph 80, nit:
> d, its TCP implementation SHOULD send a RST to show that data was lost (SHLD-
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.1. , paragraph 9, nit:
>  not support attachment to links with a MTU greater than 65,575 [5], and the
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7.5. , paragraph 2, nit:
> s of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachab
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.8.2. , paragraph 4, nit:
> tion, or at least to determine whether or not more urgent data remains to be
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.8.3. , paragraph 2, nit:
> hat all have the same sequence number so there will be no way to reorder them
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 3.8.3. , paragraph 6, nit:
> g accepted that much data. This, so called "shrinking the window," is strong
>                                  ^^^^^^^^^
The expression "so-called" is usually spelled with a hyphen.

Section 3.8.6.2.1. , paragraph 17, nit:
> he operating system will verify the users authority to open a connection with
>                                     ^^^^^
An apostrophe may be missing.

Section 3.8.6.2.2. , paragraph 4, nit:
> ction name can then be used as a short hand term for the connection defined
>                                  ^^^^^^^^^^
This word is normally spelled as one.

Section 3.9.1. , paragraph 27, nit:
> he user level protocol is not well thought out) that the closing side is una
>                               ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3.9.2. , paragraph 7, nit:
> aiting delivery, the RECEIVE will get a "error: connection closing" response
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.1. , paragraph 2, nit:
> , this is an error and should receive a "error: connection closing" response
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> arded. An incoming segment containing a RST is discarded. An incoming segment
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.2. , paragraph 11, nit:
> . An incoming segment not containing a RST causes a RST to be sent in respon
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.9.2.3. , paragraph 1, nit:
> g segment not containing a RST causes a RST to be sent in response. The ackn
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.1. , paragraph 3, nit:
> ED state, delete TCB, and return. Otherwise (no ACK) drop the segment and ret
>                                   ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 3.10.1. , paragraph 3, nit:
> o ACK, and the segment did not contain a RST. - If the SYN bit is on and the
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.1. , paragraph 6, nit:
>  generate an acknowledgement in the later processing steps, saving this extra
>                                     ^^^^^
Did you mean "latter" (=the second of two items)?

Section 3.10.7.4. , paragraph 30, nit:
> aining sequence numbers entirely outside of this range are considered duplic
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.10.7.4. , paragraph 32, nit:
> a segment containing RST give rise to a RST in response. SEG.ACK segment ack
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.10.7.4. , paragraph 83, nit:
>  573: Reported by Bob Braden (note: This errata basically is just a reminder
>                                     ^^^^
The demonstrative "This" may not agree with the plural noun "errata". Did you
mean "these"?

Section 3.10.7.4. , paragraph 83, nit:
>  of the "functional specification". Also the 1122 text on the retransmission
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 3.10.7.4. , paragraph 102, nit:
> discussion in 2015 also indicated that that we should not try to add sections
>                                   ^^^^^^^^^
Possible typo: you repeated a word.

Section 5. , paragraph 2, nit:
> firewalls, and other technologies outside of the end-host TCP implementation.
>                                   ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 8. , paragraph 2, nit:
> beneficial to consider. A.4. Low Water Mark Settings Some operating system ke
>                                  ^^^^^^^^^^
This is normally spelled as one word.

Reference [20] to RFC1644, which was obsoleted by RFC6247 (this may be on
purpose).

Reference [17] to RFC896, which was obsoleted by RFC7805 (this may be on
purpose).

Reference [19] to RFC1349, which was obsoleted by RFC2474 (this may be on
purpose).

These URLs in the document did not return content:
 * http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-edo-10.txt
 * http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-04.txt
 * http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seccomp-prec-00.txt

I support Ben's Discuss point 3.

I would like to thank the author and WG of taking on the task of cleaning up and updating the TCP spec, it is hard work, but very important and helpful to the wider Internet community.

However, having read the shepherd's writeup, I do partly question whether publishing this as Internet Standard rather the Proposed Standard is really the right choice.  The Shepherd's writeup seems to suggest that there are various aspects of the protocol where implementations either all deviate from the standard, or mitigate various issues.  Ideally, I would prefer for IETF consensus to be reached on a standard way of how to address those issues, and then collect those into an rfc793bisbis that accurately represents what a current TCP implementation is expected to look like.  However, I can also see that, RFC 793 is an Internet Standard, and publishing a cleanup of that spec, that doesn't change anything, along with the fact that TCP is deployed everywhere, make is hard to not classify RFC793bis as an Internet Standard ...

But, anyway, I really do appreciate the cleanup work that has happened here.

Regards,
Rob