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

["Scharf, Michael" <[e-mail]>]

Chiming in as TCPM co-chair and document shepherd...

> > Here, we
> > have the constraint of retaining compatibility with the existing deployment
> > base (which is a very compelling constraint!), so you do not see me
> > advocating for mandatory tcpcrypt (for example).  But I want to see some
> > explanation of what harm or risk there is in saying that the ISN is always
> > produced with the PRF of the 5-tuple (okay, 4-tuple since the protocol is
> > always TCP), to motivate a divergence from the more-secure behavior and
> > thereby justify retaining the behavior currently in the draft.  What
> > constraint are we subject to that prevents doing the right (security-wise)
> > thing?
> 
> We already have RFC6528 that specifies this as a SHOULD.
>
> My question to you is “what has changed since 2012 that makes you think
> this is now appropriate for a MUST”.

It was clear consensus in TCPM *not* to realize SHOULD/MUST modifications of the TCP protocol in 793bis, but instead to limit the document to protocol mechanisms that already have IETF consensus.

It was also TCPM consensus that stacks that correctly implement existing TCP standards prior to 793bis should not become incompatible to the TCP standards once 793bis is published.
 
> AFAICT, that’s where the burden of proof is, not on us to defend keeping a
> SHOULD.

If a SHOULD shall be replaced by a MUST, an alternative approach would be to start a new standards track document in TCPM, get feedback from implementers, ensure that the change indeed has TCPM working group and IETF consensus, and then update the TCP standards accordingly.

In this specific case, that spec would be probably a short document that can be reviewed relatively easily and thus published fast, if the TCPM working group agrees that it is the right-thing-to-do.

Michael