Re: [tcpm] A few comments on 793bis

[Wesley Eddy <[e-mail]>]

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:
> 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 
>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] 
>> <mailto:[e-mail]>> kirjoitti:
>>
>>     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.
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     tcpm mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm