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

["[e-mail]" <[e-mail]>]

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

> On Sep 22, 2021, at 8:34 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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?

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.


> Likewise, what prevents using stronger normative language (e.g., MUST)
> 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