Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

[Kyle Rose <[e-mail]>]

On Fri, Sep 3, 2021 at 3:54 PM Wesley Eddy <[e-mail]> wrote:

> > > The one item I see missing from this section is a mention of lessons
> > learned
> > > and subsequently applied to the design of QUIC. I think it is worth
> > mentioning,
> > > for instance, that TCP's large surface area of cleartext metadata
> > exposes more
> > > information to the path than required to successfully route packets
> > to their
> > > destination, including to on-path adversaries that may be able to
> > use this
> > > metadata to bolster targeted or pervasive surveillance.
>
> It looks like this is covered pretty well in RFC 8546, which you mention
> below, so I think it might suffice for 793bis to just add a sentence
> noting pretty much exactly what you said above and referring interested
> readers to RFC 8546.
>

Agreed, this sounds good.

> > There is one more omission, adjacent to (but not explicitly about)
> > security,
> > > that I think warrants some text in this document: that is around
> > ossification. ....
>
> I don't really want to add a whole section for this, since we aren't
> going to actually change anything, however, I think it makes sense to
> add the above-mentioned reference to 8546, plus a little bit more
> expansion that references RFC 8558 as having additional recommendations
> that could be applied with regard to future TCP extensions.
>

The IAB's use-it-or-lose-it draft (
https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it) might be
the best reference for this particular problem. This is what 8546 refers to
when discussing this problem. But some brief text describing how the
problem applies to TCP extensibility might be worthwhile, though I'm not
sure where to put it into this document. Something like:

  q[ While TCP was designed from the start with extensibility in mind,
practically speaking standards-compliant extensions have faced numerous
obstacles to deployment as a result of constraints imposed by on-path
elements with assumptions about valid TCP traffic that they then impose on
flows. With respect to the option mechanism, for instance, on-path elements
collectively dubbed "middleboxes" [RFC 3234] often filter or otherwise
modify TCP packets to strip unknown options or otherwise render them
unusable; similarly, middleboxes often re-segment TCP traffic, precluding
the introduction of extensions that presume end-to-end preservation of
stream segmentation, such as in early revisions of tcpcrypt [RFC 8548].
Such protocol ossification beyond the constraints implied by the standard
described herein effectively limits TCP extensibility for use cases
requiring transit over the public Internet. (This effect has subsequently
motivated protocol design patterns that hide data from path elements (for
example, by encrypting as much header information as possible) and that
exercise cleartext or otherwise predictable elements of the wire image
([USE-IT]) to preserve the intended degree of future extensibility.) ]
Kyle