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

[Gorry Fairhurst <[e-mail]>]

On 05/09/2021 17:13, Kyle Rose wrote:
> On Fri, Sep 3, 2021 at 3:54 PM Wesley Eddy <[e-mail] 
> <mailto:[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/z 
> <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
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

To me, this has a much more complicated history, and I think TCP has 
been extended many times - albeit not sucessfully in the ways mentioned 
above, but in other watys. It seems like a discussion of whether 
ossification has been good or bad. I'd also really quite concerned to 
see words like "often" used without clarifying further -  there are 
legitimate cases where filtering can be useful for managing the security 
of TCP connections: A firewall in one context might do many things, and 
that might actually be a good security model; in another context that 
might be different.

I'd also question the importance of 
https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it 
<https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it>, in 
relation to the core TCP spec, even though the message is clear for MPTCP.

Maybe this is something for TCPm to consider in the future, but overall, 
I'm maybe a little unsure why a TCP spec would add this, and how this 
relates to TCP.

Gorry