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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 20:34:00 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

Many thanks for taking on the task of producing a roll-up update for the
core TCP specification!  I am sure it was a lot of work, but I am happy
to see it done.

That said, I do have a few points that I would like to have a bit more
discussion on before the document is published; I'm happy to see that
Warren already linked to
https://www.ietf.org/blog/handling-iesg-ballot-positions/ on the topic
of what a DISCUSS position can (and cannot) mean.

(1) We incorporate some long-standing enhancements that improve the
security and robustness of TCP (in particular, random ISN and protection
against off-path in-window attacks come to mind), but only at SHOULD or
MAY requirements level.

For example, we currently say:

   A TCP implementation MUST use the above type of "clock" for clock-
   driven selection of initial sequence numbers (MUST-8), and SHOULD
   generate its Initial Sequence Numbers with the expression:

   ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

and:

         +  RFC 5961 [37] section 5 describes a potential blind data
            injection attack, and mitigation that implementations MAY
            choose to include (MAY-12).  TCP stacks that implement
            RFC 5961 MUST add an input check that the ACK value is
            [...]

What prevents us from making a MUST-level requirement for randomized
ISNs?  Is it just the fact that it was only a SHOULD in RFC 6528 and a
perception that promoting to a MUST would be incompatible with retaining
Internet Standard status?

Likewise, what prevents using stronger normative language (e.g., MUST)
for the RFC 5961 protections?

It seems to me that these mechanisms are of general applicability and
provide significant value for use of TCP on the internet, even though
they are not fully robust and do not use cryptographic mechanisms.  If
there are scenarios where their use is harmful or even just not
applicable, that seems like an exceptional case that should get
documented so as to strengthen the general recommendation for the
non-exception cases.

(2) I think this is just a process question to ensure that the IESG
knows what we are approving at Internet Standard maturity, though it
is certainly possible that I misunderstand the situation.

In Section 3.7.3 we see the normative statement (SHLD-6) that "when the
when the effective MTU of an interface varies packet-to- packet, TCP
implementations SHOULD use the smallest effective MTU of the interface
to calculate the value to advertise in the MSS option".  This seems to
originate in RFC 6691 (being obsoleted by this document), but RFC 6691
is only an Informational document and has not had an opportunity to
"accumulate experience at Proposed Standard before progressing", to
paraphrase RFC 6410.

Similarly, Section 3.9.2 has (SHLD-23) "Generally, an application SHOULD
NOT change the DiffServ field value during the course of a connection
(SHLD-23)."  This is a bit harder to track down, as the DiffServ field
was not always known by that name.  I actually failed to find a directly
analogous previous statement of this guidance (presumably my error), and
thus don't know if it had any experience at the PS level or not.

RFC 6410 seems pretty clear that some revisions are okay in Internet
Standards without such "bake time" at PS, but it does seem like
something that should be done consciously rather than by accident.

(3) This is also a process point for explicit consideration by the IESG.

Appendix A.2 appears to discuss a few (rare) scenarios in which the
technical mechanisms of this document fail catastrophically (e.g.,
getting stuck in a SYN|ACK loop and failing to complete the handshake).
Does this meet the "resolved known design choices" and "no known
technical omission" bar required by RFC 2026 even for *proposed*
standard?

(Note that RFC 2026 explicitly says that the IESG may waive this
requirement, at least for PS.)

(AFAICT one such scenario is reported at
https://www.rfc-editor.org/errata_search.php?eid=3305 , which the change
log for this document calls out as "not applicable due to other
changes"; I am not sure which "other changes" are intended, for this
case.)

(4) Another point mostly just to get explicit IESG acknowledgment
(elevating one of Lars' comments to DISCUSS level, essentially).

As the changelog (and gen-art reviewer!) notes:

   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.

I don't see any evidence to suggest that such a review actually
occurred.  Do we want to seek out such a targeted review before
progressing?

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

Thank you for the editorial changes so that we now talk about "a TCP
implementation" or a "remote TCP peer" rather than just "a TCP" or
"a remote TCP"!

Abstract

                                                 It also updates RFC
   5961 by adding a small clarification in reset handling while in the
   SYN-RECEIVED state.  [...]

I'm not sure I found what this clarification was; is SYN-RECEIVED the
correct state?  The ad-hoc diff I constructed between RFC 793 and this
document shows identical text for the "If the RST bit is set" case when
currently in SYN-RECEIVED STATE.

Section 3.1

   Options: [TCP Option]; Options#Size == (DOffset-5)*32; present
   only when DOffset > 5.

My (later) nit-level notation comment aside, the given expression does
not seem to convey the size occupied by the options, but rather the
combined size of the options and the padding.

Section 3.2

   A TCP Option is one of: an End of Option List Option, a No-Operation
   Option, or a Maximum Segment Size Option.

The IANA registry lists some thirty-odd option kinds, so this sentence
just seems false without some additional qualifier ("defined by this
specification", etc.)

Section 3.4

   In response to sending data the TCP endpoint will receive
   acknowledgments.  The following comparisons are needed to process the
   acknowledgments.
      [...]
      SEG.SEQ = first sequence number of a segment

      SEG.LEN = the number of octets occupied by the data in the segment
      (counting SYN and FIN)

      SEG.SEQ+SEG.LEN-1 = last sequence number of a segment

It seems to me that this information from the incoming segment is not
part of processing the *acknowledgment*, but rather part of processing
the data received in that segment (a procedure discussed a few
paragraphs later).

             This clock is a 32-bit counter that typically increments at
   least once every roughly 4 microseconds, [...]
   Maximum Segment Lifetime (MSL), generated ISNs will be unique, since
   it cycles approximately every 4.55 hours, which is much longer than
   the MSL.

Once we put in the "at least" we allow arbitrarily faster clock updates,
and that puts the "approximately every 4.55 hours" estimate in question.
Very fast clock updates would cycle correspondingly faster.  Do we need
to place a lower limit on the clock update interval?  (On first look, it
seems like we might not, since the keyed PRF F() is providing most of
the protection from off-path guessing, and an attacker can always use
direct connections to estimate the clock cycle interval.  OTOH, if it
cycles so fast that it repeats within O(MSL), that might be problematic.)

   parameters and some secret data.  For discussion of the selection of
   a specific hash algorithm and management of the secret key data,
   please see Section 3 of [41].

The guidance in the referenced document seems a bit dated (it indicates
that MD5 is probably still okay for this purpose).  While the known
attacks on MD5 do not directly translate into an attack on ISN
generation, collisions can be found on as little as 64 bytes of input,
and all of the straightforward ways to use pure MD5 as a keyed hash for
this purpose have some undesirable properties.  I'm happy to note that
FreeBSD is using siphash for this purpose, which should be more than
adequate.  I expect that Linux and other major TCP stacks are already
doing something similar, so the guidance to use MD5 may be dated in
practice as well as in utility.

I don't have a great proposal for where to put some updated guidance
(unless there's already some work underway in tcpm?); it is probably not
appropriate to put it inline here, so either an appendix or a separate
document seem plausible.

Section 3.7.1

   The MSS value to be sent in an MSS option should be equal to the
   effective MTU minus the fixed IP and TCP headers.  By ignoring both
   IP and TCP options when calculating the value for the MSS option, if
   there are any IP or TCP options to be sent in a packet, then the
   sender must decrease the size of the TCP data accordingly.  RFC 6691
   [42] discusses this in greater detail.

I note that RFC 6691 is obsoleted by this document; it seems to me that
if we think there is useful content still in that document, we should
include such content in this document instead of referring to a document
we are calling obsolete.  (This is not the only place we do so, to be
clear, but I will try to mention it just once.  I do see the note that
we only claim to incorporate the normative portions of most of the
obsoleted specs, leaving the informational content alone.)

Section 3.8.4

   An implementation SHOULD send a keep-alive segment with no data
   (SHLD-12); however, it MAY be configurable to send a keep-alive
   segment containing one garbage octet (MAY-6), for compatibility with
   erroneous TCP implementations.

Such misbehaved TCP impelementations were misbehaved even in 1989 when
RFC 1122 was published -- do we have a sense for whether they are still
around to any significant degree?

Section 3.8.5

   As a result of implementation differences and middlebox interactions,
   new applications SHOULD NOT employ the TCP urgent mechanism (SHLD-
   13).  However, TCP implementations MUST still include support for the
   urgent mechanism (MUST-30).  Details can be found in RFC 6093 [38].

This "SHOULD NOT employ" has been in force for over a decade (RFC 6093
is dated January 2011).  How long do we have to wait until there are
sufficiently few implementations employing the urgent mechanism that it
no longer needs to be implemented?

Section 3.9.2.3

      An incoming SYN with an invalid source address MUST be ignored
      either by TCP or by the IP layer (MUST-63) (Section 3.2.1.3 of
      [18]).

Requirements of the form "A or B must do X" that are ambiguous about
whether A or B takes the action leave the risk that both will expect the
other party to take the action, and the action will fail to occur.  If
we're in a position to specifically require one (or both!) to check,
that leads to a more robust and verifiable system.  (I assume we're not
in such a position, but it can't hurt to check.)

Section 4

   Destination Address
           The network layer address of the remote endpoint.
   [...]
   Source Address
           The network layer address of the sending endpoint.

These definitions don't seem to work in the context of a receiver
validating the TCP checksum, where the destination address is the local
endpoint's address and the source address is the remote endpoint's
address.  (I note that these definitions are different from what RFC 793
itself used.)

   receive window
           This represents the sequence numbers the local (receiving)
           TCP endpoint is willing to receive.  Thus, the local TCP
           endpoint considers that segments overlapping the range
           RCV.NXT to RCV.NXT + RCV.WND - 1 carry acceptable data or
           control.  Segments containing sequence numbers entirely
           outside of this range are considered duplicates and
           discarded.

Duplicates or injection attacks (when the sequence numbers in the
segment are too large).

Section 5

   The collection of applicable RFC Errata that have been reported and
   either accepted or held for an update to RFC 793 were incorporated
   (Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571,
   1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301, 6222).
   Some errata were not applicable due to other changes (Errata IDs:
   572, 575, 1569, 3305, 3602).

I think that EID 1565 belongs in the "not applicable due to other
changes" list, since the text it attempts to modify involves the
now-removed discussion of the IP "precedence" field.

Similarly, EID 2296 also affected text about precedence and security
that is no longer present in a recognizable form.

   The more secure Initial Sequence Number generation algorithm from RFC
   6528 was incorporated.  See RFC 6528 for discussion of the attacks
   that this mitigates, as well as advice on selecting PRF algorithms
   and managing secret key data.

(As I mentioned up in §3.4, that guidance is no longer current.)

Section 9.1

It's not clear to me that RFC 2675 ([5]) needs to be classified as
normative.

The guidance at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
would suggest that RFC 5961 ([37]) should be classified as normative,
since we replicate its MUST-level requirements with the condition that
"TCP stacks that implement RFC 5961 MUST [...]", which would appear to
make that behavior an "optional feature".

Appendix A.1.2

   The IP security option (IPSO) and compartment defined in [1] was
   refined in RFC 1038 that was later obsoleted by RFC 1108.  The
   Commercial IP Security Option (CIPSO) is defined in FIPS-188, and is
   supported by some vendors and operating systems.  RFC 1108 is now

Should we mention that FIPS-188 is archived and withdrawn by NIST?
(I also didn't find much to define the actual IP option in the PDF I
found,
https://csrc.nist.gov/csrc/media/publications/fips/188/archive/1994-09-06/documents/fips188.pdf,
but I didn't look very hard.)

Appendix A.3

It's fascinating to me that the preferred reference for this modified
Nagle algorithm is an Internet-Draft from 1999, vs something more
recent.

Appendix B

     Every 2nd full-sized segment or 2*RMSS ACK'd | SHLD-19|x| | | | |

This 'x' seems to be in the "MUST" column, not the "SHOULD" column.

   Time Stamp support                             | MAY-10 | | |x| | |

How do we square timestamp support being a "MAY" with SHLD-4,
SHOULD-level guidance to use timestamps to reduce TIME-WAIT?

   Time Exceeded => tell ALP, don't abort         | MUST-56| | | | |x|
   Param Problem => tell ALP, don't abort         | MUST-56| | | | |x|

Is there a double negative between "don't abort" and the 'x' being in
the "MUST NOT" column?

NITS

I made essentially no attempt to de-duplicate the nit-level remarks
against the ballot positions from other ADs (in contrast to the other
comments, where I made some modest effort to de-duplicate).  My
apologies for the extra work to ignore the already-fixed items.

Section 1

   For several decades, RFC 793 plus a number of other documents have
   combined to serve as the core specification for TCP [48].  Over time,
   a number of errata have been filed against RFC 793, as well as
   deficiencies in security, performance, and many other aspects.  The

A naive parse would say that this means a number of errata have been
filed against deficiencies.  I suspect the transition between errata and
deficiencies should refer to deficiencies having been "discovered" or
similar.

   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's a little surprising to see this described as an "update of RFC 793"
(vs. a "replacement of" or "updated version of") since the relationship
is Obsoletes, not Updates.  I might even consider "into a single
consolidated specification".

Section 3.1

   Options: [TCP Option]; Options#Size == (DOffset-5)*32; present
   only when DOffset > 5.

The "Options#Size" notation seems confusing and is not using any
convention I'm aware of.  It does not appear in RFC 793 or any other RFC
that I can find, either.

Section 3.3.1

   maintenance of a TCP connection requires the remembering of several
   variables.  We conceive of these variables being stored in a

"the remembering of" is a fairly awkward phrase, where something like
just "remembering" or "maintaining state for" would flow more naturally.

Section 3.4

   It is essential to remember that the actual sequence number space is
   finite, though very large.  This space ranges from 0 to 2**32 - 1.

The sense of scale in the broader ecosystem may have evolved out from
under us; QUIC's 62-bit sequence space might be more along the lines of
"very large" these days, with a 32-bit space being merely "large".

   A connection is defined by a pair of sockets.  Connections can be

This is the first instance of the word "socket" in this document.
RFC 793 used the term much more prevalently, but this update has
(beneficially, IMO) moved away from that approach in favor of discussing
IP addresses and port numbers.  Might such a change be appropriate here
as well?  Regardless, we should probably have some introduction to what
we mean by "socket" if we are to retain any uses of the term, IMO, more
than just the glossary entry.

   verify this SYN.  The three way handshake and the advantages of a
   clock-driven scheme are discussed in [68].

I don't have access to the reference, but it's not clear from just it's
abstract whether "advantages of" or "advantages over" a clock-driven
scheme is the intended meaning.

   explanation for this specification is given.  TCP implementors may
   violate the "quiet time" restriction, but only at the risk of causing
   some old data to be accepted as new or new data rejected as old
   duplicated by some receivers in the internet system.

Maybe "old duplicated data"?  The current phrasing feels like it's
missing a word.

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

I think this needs an "and", for "prefer to avoid waiting and are
willing to risk".

   To summarize: every segment emitted occupies one or more sequence
   numbers in the sequence space, the numbers occupied by a segment are
   "busy" or "in use" until MSL seconds have passed, upon rebooting a
   block of space-time is occupied by the octets and SYN or FIN flags of
   the last emitted segment, if a new connection is started too soon and
   uses any of the sequence numbers in the space-time footprint of the
   last segment of the previous connection incarnation, there is a
   potential sequence number overlap area that could cause confusion at
   the receiver.

This list seems to be missing an "and".
(Also, is it really only the last emitted segment that could cause
problems?)

Section 3.5

                                                             It is the
   implementation of a trade-off between memory and messages to provide
   information for this checking.

I'm not sure this reads well; is "the implementation of" needed?

      If an incoming segment has a security level, or compartment that
      does not exactly match the level and compartment requested for the
      connection, a reset is sent and the connection goes to the CLOSED
      state.  The reset takes its sequence number from the ACK field of

The comma in the first line is no longer needed (it was part of the list
when precedence was still part of the list).

Section 3.6

      In this case, a FIN segment can be constructed and placed on the
      outgoing segment queue.  No further SENDs from the user will be
      accepted by the TCP implementation, and it enters the FIN-WAIT-1
      state.  RECEIVEs are allowed in this state.  All segments
      preceding and including FIN will be retransmitted until
      acknowledged.  When the other TCP peer has both acknowledged the
      FIN and sent a FIN of its own, the first TCP peer can ACK this
      FIN.  Note that a TCP endpoint receiving a FIN will ACK but not
      send its own FIN until its user has CLOSED the connection also.

Naming the two peers (e.g., A and B) can help avoid awkward grammatical
constructions like "can ACK this FIN" and improve clarity.

Section 3.8

   segments may arrive due to network or TCP retransmission.  As
   discussed in the section on sequence numbers the TCP implementation
   performs certain tests on the sequence and acknowledgment numbers in
   the segments to verify their acceptability.

comma after "sequence number".

Section 3.8.6.2.2

   Note that the general effect of this algorithm is to advance RCV.WND
   in increments of Eff.snd.MSS (for realistic receive buffers:
   Eff.snd.MSS < RCV.BUFF/2).  Note also that the receiver must use its
   own Eff.snd.MSS, assuming it is the same as the sender's.

I think the last sentence would be more clear if it was something like
"making the assumption that is the same" or "on the assumption that it
is the same".

Section 3.8.6.3

   Note that there are several current practices that further lead to a
   reduced number of ACKs, including generic receive offload (GRO), ACK
   compression, and ACK decimation [26].

Reference [26] seems reasonable for ACK decimation and ACK compression,
but doesn't seem to cover GRO at all.

Section 3.9.1

         If the PUSH flag is set, the application intends the data to be
         transmitted promptly to the receiver, and the PUSH bit will be
         set in the last TCP segment created from the buffer.  When an
         application issues a series of SEND calls without setting the
         PUSH flag, the TCP implementation MAY aggregate the data
         internally without sending it (MAY-16).

There's a dedicated paragraph a few paragraphs later for when the PUSH
flag is not set; the last sentence might flow better there.

         Some TCP implementations have included a FLUSH call, which will
         empty the TCP send queue of any data that the user has issued
         SEND calls but is still to the right of the current send
         window.  That is, it flushes as much queued send data as

I think "has issued SEND calls for" (add "for").

Section 3.9.2

   When received options are passed up to TCP from the IP layer, TCP
   implementations MUST ignore options that it does not understand
   (MUST-50).

singular/plural mismatch (it/implementations)

Section 3.9.2.2

   Soft Errors
     For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
     Time Exceeded -- codes 0, 1, and Parameter Problem.

     For ICMPv6 these include: Destination Unreachable -- codes 0 and 3,
     Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1,
     2.

     Since these Unreachable messages indicate soft error conditions,

I'm not entirely sure that I'd classify "parameter problem" as an
"unreachable" message per se.

Section 3.10

   Please note in the following that all arithmetic on sequence numbers,
   acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
   of the sequence number space.  Also note that "=<" means less than or

Some punctuation around "the size of the sequence number space" seems in
order.

   equal to (modulo 2**32).

[In formal mathematics this "less than or equal to, modulo N" operator
is not defined.  But it's probably okay in this context.]

Section 3.10.1

         the parameters of the incoming SYN segment.  Verify the
         security and DiffServ value requested are allowed for this
         user, if not return "error: precedence not allowed" or "error:
         security/compartment not allowed."  If passive enter the LISTEN

It's surprising for the error string to mention "precedence" when the
predicate is DiffServ value.

         with "error: insufficient resources".  If Foreign socket was
         not specified, then return "error: remote socket unspecified".

I suspect s/Foreign/remote/ was intended.  (Also occurs later, but I
will just note it once here.)

Section 3.10.3

      -  Since the remote side has already sent FIN, RECEIVEs must be
         satisfied by data already on hand, but not yet delivered to the
         user.  If no text is awaiting delivery, the RECEIVE will get a
         "error: connection closing" response.  Otherwise, any remaining
         text can be used to satisfy the RECEIVE.

I think s/text/data/ should be applied on the last line (since it was
already applied on the second line).

Section 3.10.7.4

   o  Segments are processed in sequence.  Initial tests on
      arrival are used to discard old duplicates, but further
      processing is done in SEG.SEQ order.  If a segment's
      contents straddle the boundary between old and new, only the
      new parts should be processed.

Maybe s/should be/are/?  There's not really optionality about it...

            *  If this connection was initiated with a passive OPEN
               (i.e., came from the LISTEN state), then return this
               connection to LISTEN state and return.  The user need
               not be informed.  If this connection was initiated
               with an active OPEN (i.e., came from SYN-SENT state)
               then the connection was refused, signal the user
               "connection refused".  In either case, all segments on
               the retransmission queue should be removed.  And in

IIUC, what's described here as "removed" is described elsewhere as
"flushed"; it would be good to use consistent terminology when possible.

         +  Once in the ESTABLISHED state, it is possible to deliver
            segment text to user RECEIVE buffers.  Text from segments
            can be moved into buffers until either the buffer is full
            or the segment is empty.  If the segment empties and
            [...]

As above, it seems like (case-insensitive) s/test/data/ would improve
consistency.

Section 4

   internet datagram
           The unit of data exchanged between an internet module and the
           higher level protocol together with the internet header.

"exchanged between an internet module and the higher level protocol"
sounds like a local operation; I would have expected the definition of
an *internet* datagram to involve transfer over the (inter)network.

   segment length
           The amount of sequence number space occupied by a segment,
           including any controls that occupy sequence space.

Should we say that this is a field in the segment header?

   URG
           A control bit (urgent), occupying no sequence space, used to
           indicate that the receiving user should be notified to do
           urgent processing as long as there is data to be consumed
           with sequence numbers less than the value indicated in the
           urgent pointer.

To me, "value indicated in" is synonymous with "value contained in",
which is problematic here since the urgent field is only 16 bits and
sequence numbers 32 bits.  "indicated by" would be an improvement,
though of course if we're willing to spend more words we can increase
clarity further.

Appendix A.1

   RFC 793 requires checking the IP security compartment and precedence
   on incoming TCP segments for consistency within a connection, and

I think the past tense "required" would be more appropriate upon
publication of this document as an RFC obsoleting RFC 793.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 22 Sep 2021 20:51:15 -0700

Some comments below...
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 22, 2021, at 8:34 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

I’ll take a stab at this issue...

This update does not attempt to change existing IETF consensus. 

In this particular case, AFAIR it allows implementations to not need random number generators, notably for IoT support and legacy hardware. However, in every case, there are long threads in the archives for the RFCs that were ‘rolled in’ here that explain the reason why those recommendations became consensus. That consensus was not re-adjucated during this process.

> for the RFC 5961 protections?

Because those are not always relevant to all implementations either; this is already noted in that RFC as well.

Again, same overall reason - this RFC does not attempt to re-adjudicate existing IETF consensus.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 23 Sep 2021 11:16:20 -0400

> Internet Standard status?

I don't think a MUST for the specific expression used to generate a 
random ISN is necessary since there could be other expressions that 
suffice, and there is no interoperability concern as this is totally 
local to the host.

> for the RFC 5961 protections?

At the time 5961 was published there were both concerns with the IPR as 
well as alternative approaches to achieving the needed robustness, and 
the working group explicitly decided on the requirements language after 
a lot of discussion.

> "accumulate experience at Proposed Standard before progressing", to

In this case, I believe what 6691 says is in accordance with what widely 
deployed code has done for a long time.

I would not make too much of the fact that it's Informational, as it 
wasn't changing the protocol at all, simply providing clarifications and 
correction to mis-statements in older RFCs.

> thus don't know if it had any experience at the PS level or not.

Actually this is prior advice that was widely discussed in the IETF and 
went into RFC 7657 (and the sections referenced in the clip below 
explain why in greater detail):

    o  Should use a single DSCP for all packets within a reliable
       transport protocol session (e.g., TCP connection, SCTP
       association) or DCCP connection (see Sections5.1  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.1>  and5.3  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.3>).

> technical omission" bar required by RFC 2026 even for *proposed*

The TCPM WG has discussed these issues in the past, the referenced I-D 
explains the effect in the real-world and how it's been mitigated in 
different OSes.  There hasn't been consensus that anything needed to be 
done.

> occurred.  Do we want to seek out such a targeted review before

I don't think it occurred.  It was a suggestion at the time when it 
seemed like the IETF wanted to do this for all or most documents, but it 
doesn't seem like that has continued, and in this case, I'm not 
personally clear that there is a lot of value, since this is not a new 
protocol and we haven't added any new mechanisms, options, etc. in this 
particular document that would really motivate specific review.

---

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

Hi Wes, Joe,

Sorry for the slow reply -- I've been a bit fogheaded this week and wanted
to be sure that I was clearheaded when writing on this topic, as it seems
particularly important to be communicating clearly.

On Thu, Sep 23, 2021 at 11:16:20AM -0400, Wesley Eddy wrote:
> suffice, [...]

To be clear, my primary question here is "are randomized ISNs MUST-level
required?".  That can be separated from "is the specific quoted expression
the MUST-level way to do it?" (though I see a number of factors that
suggest that the quoted expression is in fact the correct expression, which
we can discuss later if needed).  In particular, randomized ISNs serve to
provide protection from off-path attacks, which is basically a baseline
requirement for new IETF work, these days.

I see Joe's message saying that "[t]his update does not attempt to change
existing IETF consensus", but that also merits a bit of unpacking.  The
previous standards-track documents that have content rolled into this
document had consensus when published, of course, and in the absence of
other data points we must assume that such consensus continues to hold.
However, I see several other data points that have appeared since the
publication of the documents in question, and as I consider all those data
points I see a very real possibility (note: not certainty) that the current
text of this document does not actually reflect current IETF consensus.  If
we consider, for example, QUIC, a protocol in some ways highly analogous to
TCP, the design considerations for QUIC could be said to include "encrypt
everything you can, and randomize the things you can't encrypt".  Even the
inclusion of a single unencrypted ("spin") bit in QUIC was done only after
extensive and controversial discussion, as an optional feature that is
forbidden from being always on, to allow for a reasonable anonymity set
that obscures which endpoints have specifically disabled it.

In light of the historical context and deployed reality, "encrypt
everything you can" for TCP means "encrypt nothing" (at least as part of
the core protocol spec), but that does not prevent us from acting on
"randomize everything else".  So, while I see Joe's note about not
attempting to re-adjudicate consensus on these points while producing this
document, I'm not sure that we can avoid some level of re-adjudication.
Even producing clear guidance on when it is safe/appropriate to ignore the
recommendation (e.g., use predictable ISNs) might suffice to reconcile the
apparent conflict, in the form of more specific guidance that overrules the
otherwise-conflicting general advice.  I might be able to help suggest some
text of this nature if appropriate, but will need a bit more of guidance
for search queries to find the relevant content in the archives than "long
threads in the archives for the RFCs that were 'rolled in'".  (IETF LC?
WGLC?  Earlier?)

I note additionally (responding to Joe's remark about needing RNGs on all
TCP endpoints, including IoT and legacy devices), that randomizing the ISN
does not require an ongoing source of new random numbers.  On the contrary,
in order to provide the required clock-derived behavior, we specifically
need to *not* get fresh randomness for each TCP connection.  We only need
one secret key that serves to decorrelate the phase of that clock for each
potential connection (4-tuple) and render the phase unpredictable to off-path
observers.  The necessary properties seem to be present even if this secret
key is set once at device provisioning time and never changed subsequently
(though of course best practices would include the ability to change it
later).

I would very much like to hear your thoughts on whether randomized ISNs as
a concept are MUST-level required, and (if not) in what circumstances
non-randomized ISNs are appropriate.

> suffice, and there is no interoperability concern as this is totally 

When you say "no interoperability concern" that seems to be arguing that
because there is no required behavior for interoperability, then we cannot
put a MUST-level requirement; i.e., that we only use MUST-level
requirements when required for interoperability.  I reject that argument;
we make MUST-level requirements "all the time" when required for, e.g.,
security, even if correct behavior cannot be validated by the peer and is
thus not a strict requirement for interoperability.

> the working group explicitly decided on the requirements language after 

The IPR claim appears to be https://datatracker.ietf.org/ipr/421/ which was
made in 2004, some 18 years ago.  It doesn't list an application or patent
number so as to definitively conclude that the IPR has expired, but given
the typical US patent lifetime of 20 years from filing date, it may not
even still be in force by the time this document is published as an RFC.

If there are potential alternate approaches, then it seems we should
consider having the primary normative guidance relate to functionality,
with a specific mechanism given as a known way to satisfy that guidance.
(This is analogous to the proposed "MUST randomize ISNs" above vs "MUST use
this specific formula".)

But neither of those seem conclusive on the question of "stronger normative
language than MAY" for protection against blind in-window attacks, since
the "SHOULD" level is between "MAY" and "MUST", if "MUST" is for some
reason inappropriate.  In particular, it seems that the IETF consensus has
evolved since the publication of RFC 5961, and so I feel a need to attempt
to resolve the apparent disparity between what was in 5961 (and thus is
currently in this draft) and the subsequent evolution of what the IETF
seeks to provide in our protocols.

Joe points out that this behavior is not always relevant for all
implementations, which would support "not MUST" but still seems consistent
with "SHOULD".  Additionally, my sense is that it can be very valuable to
enumerate cases where these mechanisms are known to not be relevant, to aid
implementors in deciding whether or not to implement this functionality.

> correction to mis-statements in older RFCs.

To be clear: I agree with you!
I just wanted to confirm that the IESG as a whole does, too, and per our
discussion last week, that seems to be the case.

>        association) or DCCP connection (see Sections5.1  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.1>  and5.3  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.3>).

Thanks for the specific pointer.  This particular text does look familiar
to me, so maybe I did find it, and just wasn't sure if the transformation
to "SHOULD NOT change" was mechanical.

Regardless, my stance here is the same as for the previous point, and this
should be considered resolved.

> different OSes.  There hasn't been consensus that anything needed to be 

[The IESG seemed okay with proceeding with the current state of things]

> particular document that would really motivate specific review.

Thanks for conveying your recollection of (non-)history.

We discussed this in the IESG meeting, and also didn't see much value in
trying to get a formal review here.  For one, there isn't a formal review
venue that's chartered for that type of review, and it also seems that the
privacy issues with TCP are quite well-known, and the penultimate paragraph
of the security and privacy considerations section already acknowledges
that.

So in short, this point can also be considered resolved.

Thanks again for all the replies so far; I'm also curious if you plan to
reply to the COMMENT section as well.

-Ben

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Sep 2021 15:12:33 -0700

Hi, Ben,

Notes interspersed below.

Joe
—

> On Sep 30, 2021, at 2:36 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Wes, Joe,
> 

Yes, but TCP is decidedly old work. We are always ultra-careful to move its goalposts slowly...

> everything you can, and randomize the things you can't encrypt”.

Consensus on QUIC != consensus on TCP, for the reason stated above.

Remember that one axiom of TCP is “think twice before changing TCP, then don’t”, as a rule (I noted this as far back as IETF 60 in 2004 on this very issue). There are exceptions, of course, but they’re typically a lot more contentious and conservatively considered than for new protocols.

> Even the
> "randomize everything else".  

It doesn’t prevent us from acting, but AFAICT *we have not yet acted*. Although we encourage randomization, it is never a substitute for true security and should not be done at the expense of interoperability - which is especially important for TCP.

> So, while I see Joe's note about not

Agreed, but we have not - at least on this point. If we do, we really need to send this back to the WG for that - and if we allow readjudication of this point, what else?

> threads in the archives for the RFCs that were 'rolled in'".  (IETF LC?

Part of what needs to be considered is what you’re asking from legacy endpoints and why. Again, TCP is not QUIC.

> need to *not* get fresh randomness for each TCP connection.

I don’t know why you have this position; if the ISN of new connections can be predicted based on old ones, then all new connections after the first one after reboot can be attacked.

>  ...We only need
> one secret key that serves to decorrelate the phase of that clock

Clock? Again, you must be thinking of some other system. TCP does not start with a strict requirement of a clock. It requires only timers.

> for each

Randomized ISNs are useful only when I know enough about a connection to attack BUT I can’t see any traffic from that connection - and I want to perform such an attack. These attacks are typically relevant for high-value connections, e.g., BGP, where taking down a connection has consequences. We haven’t seen evidence of people attacking end system connections this way; the only benefit is to crash the connection, which can be retried. 

> thus not a strict requirement for interoperability.

MUSTs that are local to endpoints IMO belong in BCPs, not protocol standards. They don’t define anything that prevents other systems from working.

> even still be in force by the time this document is published as an RFC.

That may be true, but would need to be confirmed, not just inferred.

> (This is analogous to the proposed "MUST randomize ISNs" above vs "MUST use

There are many others, e.g., IPsec, TCP-AO, as well as simply fixing the application to not be so disrupted by an interrupted connection. For BGP, that means not dropping routes simply because the TCP connection fails (which, IMO, was never a good assumption - TCP connectivity should never have been used to infer IP reachability).

> reason inappropriate.  

SHOULD is still stronger than MAY. Right now, it’s probably SHOULD where interrupting connections matters and “don’t waste your time” most everywhere else.

> In particular, it seems that the IETF consensus has
> evolved since the publication of RFC 5961,

Call me when that RFC is updated with stronger language. That didn’t happen yet, so you have (IMO) no basis for this claim.

> and so I feel a need to attempt
> with "SHOULD".  

It would need to be a very carefully crafted SHOULD, e.g., SHOULD for BGP, except where BGP has been fixed to not be susceptible to this issue, which should have already happened, so maybe not so much SHOULD as COULD….

(i.e., it’s not like BGP stood still either).

> Additionally, my sense is that it can be very valuable to

We did this already in rfc4953, in Sec 3.

I think that’s the end of my comments, or at least were you continued discussion on them.

---