Subject: [tcpm] Erik Kline's Yes on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Sun, 19 Sep 2021 18:08:23 -0700

Erik Kline has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: Yes

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[ general ]

* Thanks for all this.

* I had several questions around "security/compartment" test, but
  Appendix A.1 was very helpful.

* I debated whether or not the source routing stuff (3.9.2.1) should rise
  to the level of a DISCUSS or not.  Please let me know what you think.

[S2, nit]

* "including examples of A, B, C" -> "A, B, and C", perhaps

[S3.1, nit]

* Urgent Pointer, "is only be interpreted"

  -> "is only to be interpreted"
  -> "is only interpreted"

  or something

[S3.3.2, nit]

* "These transitions are not not explicitly shown" -> double (k)not?

[S3.4, nit]

* "on an incoming segments" -> "on an incoming segment", perhaps

[S3.5, question]

* Is there an example of what possible use a RST w/ data could serve?

  I didn't see anything in S3.10.7(.*) that indicated the data in a segment
  with the RST flag set could get processed (I may have missed it).

[S3.7.1, comment]

* In networks where NAT64 is employed, the default MSS assumed by a sender
  will differ from the default assumed by a receiver, since the address
  families sent and received will be different.

  This may bolster the case for MAY-3 being a SHOULD (or even a MUST ;-) but,
  more to the point, may be a caveat to note w.r.t. SHLD-5.

  Alas, I could find no discussion of MSS option handling in RFC 6146,
  so I wonder if that's something that we missed...

[S3.9.1, nit]

* "use the same local address is used that was used" ->
  "use the same local address that was used", perhaps

[S3.9.2.1]

* I feel like there should be some additional caveat about security
  implications of support for source routing.  RFC 6274, for example, says
  packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
  be dropped, citing various security concerns.

  I'm not sure there needs to be a lot of text; perhaps just an observation
  that some end systems may not support the source route semantics described
  here for security (or policy) reasons?

[S3.9.2.2]

* I feel like ICMPv6 DestUnreach 2 and 4 should be treated as hard errors,
  but haven't found any explicit documentation yet.  Was the intention here
  to imply that ICMP DU 2-4 includes both ICMPv4 and v6, or just ICMPv4?
  If the latter, should we make a statement about ICMPv6?

  <aside>
  My expectation doesn't exactly line up with Linux's icmpv6_err_convert()
  behavior, it seems.
  </aside>

  I'm fine with the text as is -- given that the TCP/IPv6 Internet generally
  functions just fine today :-) -- just curious for the sake of clarification.

[S3.10.{1,2}, nit]

* These sections introduce "foreign socket" whereas I believe all other
  mentions are "remote socket" (and, indeed, the error strings also say
  "remote socket").

  Maybe s/foreign/remote/g ?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Sep 2021 12:55:39 -0700

On Sun, Sep 19, 2021 at 06:08:23PM -0700, Erik Kline via Datatracker wrote:
[...]
>   with the RST flag set could get processed (I may have missed it).

Section 4.2.2.12 of RFC 1122 (sorry, the section link doesn't work, though
https://www.rfc-editor.org/rfc/rfc1122.html#page-87 gets most of the way
there) has:

            A TCP SHOULD allow a received RST segment to include data.

            DISCUSSION
                 It has been suggested that a RST segment could contain
                 ASCII text that encoded and explained the cause of the
                 RST.  No standard has yet been established for such
                 data.

-Ben

---

From: Erik Kline <[email-masked]>
Date: Thu, 30 Sep 2021 13:12:50 -0700

>                  RST.  No standard has yet been established for such
Ah, so including such text in 3.10.7.* would have elevated some
discussion to a level not (yet) warranted.  Makes sense, thank you.

I look forward to the forthcoming Proposed Standard for TCP RSTs containing
XML-encoded documents of error explainer text.  :D

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Sep 2021 13:56:27 -0700

PS - should we also note what should happen with that data, i.e., until it is defined in some other way?

I.e., SHOULD allow RST to include data, but this data is NOT part of the TCP byte stream.
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 30, 2021, at 1:12 PM, Erik Kline <[email-masked]> wrote:
> 
> On Thu, Sep 30, 2021 at 12:55 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.rfc-editor.org/rfc/rfc1122.html#page-87 <https://www.rfc-editor.org/rfc/rfc1122.html#page-87> gets most of the way
> there) has:
> 
> Ah, so including such text in 3.10.7.* would have elevated some discussion to a level not (yet) warranted.  Makes sense, thank you.
> 
> I look forward to the forthcoming Proposed Standard for TCP RSTs containing XML-encoded documents of error explainer text.  :D
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Sep 2021 14:38:04 -0700

Probably worth checking, yes.  I thought there was some text that implied
"not part of the byte stream" already, but couldn't point to if offhand.

-Ben