Subject: [tcpm] A few comments on 793bis

From: Joseph Touch <[email-masked]>
Date: Thu, 22 Oct 2020 15:47:56 -0700

Hi, all,

Comments below, if still useful.

Joe

——

Regarding RFC5961, we were very careful in the applicability statement therein to limit the SHOULD recommendations with specific conditions and MAY implement elsewhere. This update to 793 misrepresents those current recommendations as SHOULD for everyone, e.g., here:

               A potential blind reset attack is described in RFC 5961
               [32], with the mitigation that a TCP implementation
               SHOULD first check that the sequence number exactly
               matches RCV.NXT prior to executing the action in the next
               paragraph.

That text should instead say “MAY first check”, adding, if desired, "(SHOULD, under the conditions noted in RFC 5961)”. That corrected text belongs also in section 3.4 where reset processing is discussed.

—

All places that mention issuing a RST (including sec 3.4 and the state machine) should note that the side issuing the RST ought to enter TIME_WAIT - and explain why, as noted in:
	Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999. 

—
 
The following text should include a MUST, as shown below:

    (all TCP options except End of option list and No-Operation
     MUST have length fields)

—

The following text should be preceded by an inline ‘heading’ as shown:

        Experimental TCP options

        Experimental TCP option values are defined in [22], and [39]
        describes the current recommended usage for these experimental
        values.

—

The following text should be moved earlier in the section, because its current location suggests it is related to the experimental options discussion (and it is not):

        Note: There is ongoing work to extend the space available for
        TCP options, such as [53].

It might be appropriate to move this before the discussion of specific options, for example.

—

The definition of TIME-WAIT should describe its purpose as also including avoiding delayed segments from previous connections affecting new connections.

—

I would strongly encourage reformatting to allow the TCP state machine to avoid page break boundaries.

It may also be useful to add a note that RST can be issued from any state with a corresponding (implied) transition to TIME-WAIT; similarly, receipt of RST from any state goes to LISTEN. These transitions are not shown only because they would complicate the diagram.

—

The following statement is false:

  The protocol places no restriction on a particular connection being
   used over and over again.

Avoiding that happening too quickly in succession is one of the purposes of TIME-WAIT. New ISNs are only PART of that protection (which means the rest of this section needs revision to clarify this issue).

—

The security of TCP is discussed incorrectly, IMO. The ISN discussion and RST discussion, in particular, although trying to help protect against off-path attacks, are only very tenuously considered “security”. There should be some other way of discussing this and making sure that if TCP users need secure connections they need to use TCP-AO or IPsec.

—

The ISN clock statement with MUST seems to overreach. The previous text talks about the use of clocks being recommended, but a MUST is much stronger. The assertion needs more wiggle words or a more generous definition of clock to avoid being used out of context to prevent simple implementations on lightweight devices.

—
end.

---

From: Juhamatti Kuusisaari <[email-masked]>
Date: Fri, 23 Oct 2020 08:20:32 +0300

+1

Especially the last ISN clock MUST statement is something that I also
consider quite restrictive for low end devices. If we cannot change it for
bis, some minimum viable solution described in detail/referenced would be
nice.

--
  Juhamatti

pe 23. lokakuuta 2020 klo 1.49 Joseph Touch <[email-masked]>
kirjoitti:

> Regarding RFC5961, we were very careful in the applicability statement
> therein to limit the SHOULD recommendations with specific conditions and
> MAY implement elsewhere. This update to 793 misrepresents those current
> recommendations as SHOULD for everyone, e.g., here:
>
> That text should instead say “MAY first check”, adding, if desired,
> "(SHOULD, under the conditions noted in RFC 5961)”. That corrected text
> belongs also in section 3.4 where reset processing is discussed.
>
> —
>
> All places that mention issuing a RST (including sec 3.4 and the state
> machine) should note that the side issuing the RST ought to enter TIME_WAIT
> - and explain why, as noted in:
>         Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP and Its
> Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE, 1999.
>
> —
>
> The following text should be moved earlier in the section, because its
> current location suggests it is related to the experimental options
> discussion (and it is not):
>
> The definition of TIME-WAIT should describe its purpose as also including
> avoiding delayed segments from previous connections affecting new
> connections.
>
> —
>
> It may also be useful to add a note that RST can be issued from any state
> with a corresponding (implied) transition to TIME-WAIT; similarly, receipt
> of RST from any state goes to LISTEN. These transitions are not shown only
> because they would complicate the diagram.
>
> —
>
> Avoiding that happening too quickly in succession is one of the purposes
> of TIME-WAIT. New ISNs are only PART of that protection (which means the
> rest of this section needs revision to clarify this issue).
>
> —
>
> The security of TCP is discussed incorrectly, IMO. The ISN discussion and
> RST discussion, in particular, although trying to help protect against
> off-path attacks, are only very tenuously considered “security”. There
> should be some other way of discussing this and making sure that if TCP
> users need secure connections they need to use TCP-AO or IPsec.
>
> —
>
> The ISN clock statement with MUST seems to overreach. The previous text
> talks about the use of clocks being recommended, but a MUST is much
> stronger. The assertion needs more wiggle words or a more generous
> definition of clock to avoid being used out of context to prevent simple
> implementations on lightweight devices.
>
> —
> end.
>
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 23 Oct 2020 06:33:17 +0000

All,

> Comments below, if still useful.

Thanks, Joe.

@all: Comments on 793bis are still useful. I have not concluded the WGLC so far, as I hope to get some "late" reviews.

Nonetheless, we already have some excellent reviews for 793bis, i.e., I plan to conclude the WGLC soon-ish.

Thus, if rfc793 is still on your TODO list, please hurry up!

Michael

---

From: Joseph Touch <[email-masked]>
Date: Fri, 23 Oct 2020 08:09:16 -0700

FWIW, I don’t know where the MUST for that came from. It’s never been a MUST.

The sad thing is how much of this doc rolls in the continued (IMO) assault on TCP as needing “security” protections somehow integrated into its basic mechanisms. It continues a trend of mistaking errors for attacks and mistaking unsecured TCP for a secure service.

Joe

> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari <[email-masked]> wrote:
> 
> 
> +1
> 
> Especially the last ISN clock MUST statement is something that I also consider quite restrictive for low end devices. If we cannot change it for bis, some minimum viable solution described in detail/referenced would be nice.
> 
> --
>   Juhamatti
> 
> 
> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch <[email-masked] <mailto:[email-masked]>> kirjoitti:
> Hi, all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 23 Oct 2020 11:23:06 -0400

We are trying not to make up anything new for this document that wasn't 
already from prior RFCs, so if that has been done wrong, then we should 
fix it!

In this case, I think the MUST comes from RFC1122 (4.2.2.9):

             A TCP MUST use the specified clock-driven selection of
             initial sequence numbers.

And the text on this in 793bis is a merger of this and RFC 6528, as it says:

    This recommended algorithm is further described inRFC 6528  <https://datatracker.ietf.org/doc/html/rfc6528>  [36  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18#ref-36>] and
    builds on the basic clock-driven algorithm fromRFC 793  <https://datatracker.ietf.org/doc/html/rfc793>.

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

So, I could use help in understanding what to do here, without going 
against what has already been put down in 1122 and not relaxed since.

On 10/23/2020 11:09 AM, Joseph Touch wrote:
> The sad thing is how much of this doc rolls in the continued (IMO) 
> assault on TCP as needing “security” protections somehow integrated 
> into its basic mechanisms. It continues a trend of mistaking errors 
> for attacks and mistaking unsecured TCP for a secure service.
>
> Joe
>
>> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>> +1
>>
>> consider quite restrictive for low end devices. If we cannot change 
>> it for bis, some minimum viable solution described in 
>> detail/referenced would be nice.
>>
>> --
>>   Juhamatti
>>
>>
>> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch <[email-masked] 
>> <mailto:[email-masked]>> kirjoitti:
>>
>>     Hi, all,
>>
>>     Regarding RFC5961, we were very careful in the applicability
>>     statement therein to limit the SHOULD recommendations with
>>     specific conditions and MAY implement elsewhere. This update to
>>     793 misrepresents those current recommendations as SHOULD for
>>     everyone, e.g., here:
>>
>>     That text should instead say “MAY first check”, adding, if
>>     desired, "(SHOULD, under the conditions noted in RFC 5961)”. That
>>     corrected text belongs also in section 3.4 where reset processing
>>     is discussed.
>>
>>     —
>>
>>     All places that mention issuing a RST (including sec 3.4 and the
>>     state machine) should note that the side issuing the RST ought to
>>     enter TIME_WAIT - and explain why, as noted in:
>>             Faber, T; Touch, J; Yue, W: The TIME-WAIT state in TCP
>>     and Its Effect on Busy Servers. In: Infocom, pp. 1573-1583, IEEE,
>>     1999.
>>
>>     —
>>
>>     The following text should be moved earlier in the section,
>>     because its current location suggests it is related to the
>>     experimental options discussion (and it is not):
>>
>>     The definition of TIME-WAIT should describe its purpose as also
>>     including avoiding delayed segments from previous connections
>>     affecting new connections.
>>
>>     —
>>
>>     It may also be useful to add a note that RST can be issued from
>>     any state with a corresponding (implied) transition to TIME-WAIT;
>>     similarly, receipt of RST from any state goes to LISTEN. These
>>     transitions are not shown only because they would complicate the
>>     diagram.
>>
>>     —
>>
>>     Avoiding that happening too quickly in succession is one of the
>>     purposes of TIME-WAIT. New ISNs are only PART of that protection
>>     (which means the rest of this section needs revision to clarify
>>     this issue).
>>
>>     —
>>
>>     The security of TCP is discussed incorrectly, IMO. The ISN
>>     discussion and RST discussion, in particular, although trying to
>>     help protect against off-path attacks, are only very tenuously
>>     considered “security”. There should be some other way of
>>     discussing this and making sure that if TCP users need secure
>>     connections they need to use TCP-AO or IPsec.
>>
>>     —
>>
>>     The ISN clock statement with MUST seems to overreach. The
>>     previous text talks about the use of clocks being recommended,
>>     but a MUST is much stronger. The assertion needs more wiggle
>>     words or a more generous definition of clock to avoid being used
>>     out of context to prevent simple implementations on lightweight
>>     devices.
>>
>>     —
>>     end.
>>
>>
>>
>>
>>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 23 Oct 2020 14:42:06 -0700

The trouble is that RFC1122 makes this claim while citing RFC793, which, at best, says:

  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds. 

The key here is “possibly fictitious”. Another key is that the clock increments ROUGHLY - not precisely. Finally, nothing addresses whether this clock persists after reboot.

What we want to avoid is text that implies either a realtime clock or even persistent state across connections that might not be available.

“The specified clock-driven” is not the same as “a clock-driven”. RFC793 has too many wiggle words that aren’t included here to have the current text stand alone.

I’d suggest that 793-bis needs something as follows:

   TCP Initial Sequence Numbers are based on a number sequence that monotonically increases until it wraps and wraps infrequently, known loosely as a “clock”. This clock is a 32-bit counter that typically increments at least once every roughly 4ms, although it is neither realtime nor precise, and need not persist across reboots.

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

Joe

> On Oct 23, 2020, at 8:23 AM, Wesley Eddy <[email-masked]> wrote:
> 
> We are trying not to make up anything new for this document that wasn't already from prior RFCs, so if that has been done wrong, then we should fix it!
> 
>    This recommended algorithm is further described in RFC 6528 <https://datatracker.ietf.org/doc/html/rfc6528> [36 <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18#ref-36>] and
>    builds on the basic clock-driven algorithm from RFC 793 <https://datatracker.ietf.org/doc/html/rfc793>.
> 
> So, I could use help in understanding what to do here, without going against what has already been put down in 1122 and not relaxed since.
> 
> 
>>> On Oct 22, 2020, at 10:20 PM, Juhamatti Kuusisaari <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> +1
>>>

---

From: Juhamatti Kuusisaari <[email-masked]>
Date: Sat, 24 Oct 2020 17:50:46 +0300

For the reference I was missing, here is roughly how FreeBSD does it [1]:

"
 * Implementation details:
 *
 * Time is based off the system timer, and is corrected so that it
 * increases by one megabyte per second.  This allows for proper
 * recycling on high speed LANs while still leaving over an hour
 * before rollover.
 *
 * As reading the *exact* system time is too expensive to be done
 * whenever setting up a TCP connection, we increment the time
 * offset in two ways.  First, a small random positive increment
 * is added to isn_offset for each connection that is set up.
 * Second, the function tcp_isn_tick fires once per clock tick
 * and increments isn_offset as necessary so that sequence numbers
 * are incremented at approximately ISN_BYTES_PER_SECOND.  The
 * random positive increments serve only to ensure that the same
 * exact sequence number is never sent out twice (as could otherwise
 * happen when a port is recycled in less than the system tick
 * interval.)
"
where
#define ISN_BYTES_PER_SECOND 1048576

This not quite how it works with the latest version as there
isn_offset is updated on the fly instead of a separate function call
for every tick (i.e. the comment should be updated), which is a better
approach indeed. Based on this, I'd say there are simple references
for clock-driven functionality easily available, maybe we do not need
to add them to the bis.

--
 Juhamatti

[1] https://svnweb.freebsd.org/base/stable/12/sys/netinet/tcp_subr.c?revision=366565&view=co

On Sat, 24 Oct 2020 at 00:45, Joseph Touch <[email-masked]> wrote:
>    This recommended algorithm is further described in RFC 6528 [36] and
>    builds on the basic clock-driven algorithm from RFC 793.
>
> pe 23. lokakuuta 2020 klo 1.49 Joseph Touch <[email-masked]> kirjoitti:
>>
>> Hi, all,
>>

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 26 Oct 2020 13:31:56 -0400

On 10/23/2020 5:42 PM, Joseph Touch wrote:
>    TCP Initial Sequence Numbers are based on a number sequence that 
> monotonically increases until it wraps and wraps infrequently, known 
> loosely as a “clock”. This clock is a 32-bit counter that typically 
> increments at least once every roughly 4ms, although it is neither 
> realtime nor precise, and need not persist across reboots.
>
Just a nit-pick, but it should be "microseconds" rather than "ms"; 
otherwise, I totally agree there are some good clarifications here.

I'd like to hybridize your recommendation with the more specific 
estimate of the wrapping period into:

    TCP Initial Sequence Numbers are generated from a number sequence
    that monotonically increases until it wraps, known loosely as
    a “clock”. This clock is a 32-bit counter that typically increments
    at least once every roughly 4 microseconds, although it is neither
    assumed to be realtime nor precise, and need not persist across
    reboots.  The clock component is intended to insure that with a
    Maximum Segment Lifetime (MSL), generated ISNs will be unique, since
    it cycles approximately every 4.55 hours, which is much longer than
    the MSL.

    A TCP implementation MUST use a clock-driven selection of
    initialsequence numbers (MUST-8) as specified above, and SHOULD
    generate its Initial Sequence Numbers with the expression:  ...

How does this sound to you?

---

From: Joseph Touch <[email-masked]>
Date: Mon, 26 Oct 2020 10:40:44 -0700

Hi, Wes,

> On Oct 26, 2020, at 10:31 AM, Wesley Eddy <[email-masked]> wrote:
> 
> Just a nit-pick, but it should be "microseconds" rather than "ms"; otherwise, I totally agree there are some good clarifications here.
> 
Agreed (it should have been “us” above).
> I'd like to hybridize your recommendation with the more specific estimate of the wrapping period into:
> 
> TCP Initial Sequence Numbers are generated from a number sequence that monotonically increases until it wraps, known loosely as a “clock”. This clock is a 32-bit counter that typically increments at least once every roughly 4 microseconds, although it is neither assumed to be realtime nor precise, and need not persist across reboots.  The clock component is intended to insure that with a Maximum Segment Lifetime (MSL), generated ISNs will be unique, since it cycles approximately every 4.55 hours, which is much longer than the MSL.
> 
> A TCP implementation MUST use a clock-driven selection of initial sequence numbers (MUST-8) as specified above, and SHOULD generate its Initial Sequence Numbers with the expression:  ...
> 
I’d suggest, just to be careful for IoT implementations:

	A TCP implementation MUST use the above type of “clock” for clock-driven selection…

Otherwise, looks good.

Joe