[tcpm] A few comments on 793bis

[Joseph Touch <[e-mail]>]

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.