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

From: Wesley Eddy <[email-masked]>
Date: Fri, 3 Sep 2021 15:54:30 -0400

Some proposals on how to address the SECDIR last call comments:

On 7/30/2021 5:30 PM, Kyle Rose 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.

> > 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.
> > Given the lengthy back-and-forth I witnessed as chair of the TCPINC WG
> > regarding the (in)feasibility of protecting segmentation and header 
> values on
> > the public internet, it is probably worth adding to a 793bis 
> document a section
> > that briefly outlines the ossification impact of voluminous 
> cleartext and
> > unprotected/un-GREASEd metadata, maybe with a reference to the wire 
> image as
> > defined by RFC 8546. The reason I think this is worthwhile is that 
> it would be
> > good to have the practical limits of TCP extensibility (i.e., in a 
> world with
> > middleboxes and other deeply TCP-aware network elements) documented 
> where folks
> > might look for it when thinking about new options or other new 
> functionality. I
> > would be happy to help flesh out some text here.

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.

If this sounds okay, I can add a couple of sentences to the draft.

---

From: Kyle Rose <[email-masked]>
Date: Sun, 5 Sep 2021 12:13:02 -0400

> noting pretty much exactly what you said above and referring interested

Agreed, this sounds good.

> > ossification. ....

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 5 Sep 2021 17:51:07 +0100

On 05/09/2021 17:13, Kyle Rose wrote:
> On Fri, Sep 3, 2021 at 3:54 PM Wesley Eddy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > ossification.....
> 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:
>
> 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 
> 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
> [email-masked]
> 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

---

From: Kyle Rose <[email-masked]>
Date: Sun, 5 Sep 2021 13:32:58 -0400

On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <[email-masked]>
wrote:

> 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'm not in favor of making a value judgment or discussing the wisdom of
approaches to addressing ossification in this document, but I do think,
given the rare opportunity of publishing a 793bis, that it's worth putting
the implications of TCP ossification in writing so we don't have to
relitigate these issues or explain in detail why such-and-such won't work
whenever they come up in future attempts to extend TCP. I guess I'm arguing
that we shouldn't need Joe Touch to explain multiple times to multiple
groups why a given proposal won't work when we can explain it once and
mic-drop a one-line reference to that.

> https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it, in

This is why I put it in a parenthetical. It's not directly relevant to TCP,
but it does indicate to the interested reader an approach that newer
protocol designs have taken to avoid one of the causes of ossification. I
agree it's not essential.

Kyle

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 6 Sep 2021 08:12:29 +0100

> On 5 Sep 2021, at 18:34, Kyle Rose <[email-masked]> wrote:
> 
> 
>> On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <[email-masked]> wrote:
>> 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'm not in favor of making a value judgment or discussing the wisdom of approaches to addressing ossification in this document, but I do think, given the rare opportunity of publishing a 793bis, that it's worth putting the implications of TCP ossification in writing so we don't have to relitigate these issues or explain in detail why such-and-such won't work whenever they come up in future attempts to extend TCP. I guess I'm arguing that we shouldn't need Joe Touch to explain multiple times to multiple groups why a given proposal won't work when we can explain it once and mic-drop a one-line reference to that.
> 
>> I'd also question the importance of 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.
>  
> This is why I put it in a parenthetical. It's not directly relevant to TCP, but it does indicate to the interested reader an approach that newer protocol designs have taken to avoid one of the causes of ossification. I agree it's not essential.
> 
> Kyle
> 
Thanks for the reply. Seems like you and Wes converged on something slimmer. You could cite RFC 9065, if you wanted another ref. 

Best wishes,
Gorry

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 7 Sep 2021 23:36:55 -0400

Hopefully wrapping this thread up ... I've just posted a -25 revision 
that contains a new paragraph which I think now has references to all of 
the mentioned documents.

    The concept of a protocol's "wire image" is described in RFC 8546
    [54], which describes how TCP's cleartext headers expose more
    metadata to nodes on the path than is strictly required to route the
    packets to their destination.  On-path adversaries may be able to
    leverage this metadata.  Lessons learned in this respect from TCP
    have been applied in the design of newer transports like QUIC [58].
    Additionally, based partly on experiences with TCP and its
    extensions, there are considerations that might be applicable for
    future TCP extensions and other transports that the IETF has
    documented in RFC 9065 [59], along with IAB recommendations in RFC
    8558 [56] and [66].

(where [66] is the IAB use-it-or-lose-it I-D)

I think this should be good for Martin to move ahead with it if captures 
the right sense of what everyone has been suggesting to add.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 8 Sep 2021 10:52:05 -0400

The concern here is broader than security/privacy considerations: while
exposing data unnecessarily to the network does create such concerns, your
proposed text doesn't touch on the problem of protocol ossification, which
is orthogonal to privacy even if it can be mitigated by many of the same
mechanisms.

Kyle

On Tue, Sep 7, 2021 at 11:37 PM Wesley Eddy <[email-masked]> wrote:

> Hopefully wrapping this thread up ... I've just posted a -25 revision that
> contains a new paragraph which I think now has references to all of the
> mentioned documents.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 8 Sep 2021 16:55:44 +0100

On 08/09/2021 15:52, Kyle Rose wrote:
> The concern here is broader than security/privacy considerations: 
> while exposing data unnecessarily to the network does create such 
> concerns, your proposed text doesn't touch on the problem of protocol 
> ossification, which is orthogonal to privacy even if it can be 
> mitigated by many of the same mechanisms.
>
> Kyle
>
Kyle,

RFC9065 might bring some context, when it concluded:

      "Unencrypted transport header fields are likely to ossify rapidly,
       as network devices come to rely on their presence, making it
       difficult to change the transport in future.  This argues that the
       choice to expose information to the network is made deliberately
       and with care, since it is essentially defining a stable interface
       between the transport and the network. Some protocols will want
       to make that interface as limited as possible; other protocols
       might find value in exposing certain information to signal to the
       network or in allowing the network to change certain header fields
       as signals to the transport.  The visible wire image of a protocol
       should be explicitly designed."

My point was that to some extent, ossification - in as much as the wire
image is visible and usable by middleboxes, was a design decision made
when TCP was defined. Many of the methods defined in the PILC WG for
various types of subnetworks also utilised these features.
Connection-tracking firewalls have been around for decades, and rely on
this, etc. This isn't/wasn't a bug, although not making it clear what
middleboxes should do might have been an oversight.
Different design decisions were made for RTP/UDP and QUIC and others,
with different implications.

Gorry

> On Tue, Sep 7, 2021 at 11:37 PM Wesley Eddy <[email-masked] 
>     Hopefully wrapping this thread up ... I've just posted a -25
>     revision that contains a new paragraph which I think now has
>     references to all of the mentioned documents.
>
>     I think this should be good for Martin to move ahead with it if
>     captures the right sense of what everyone has been suggesting to add.
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 8 Sep 2021 12:22:54 -0400

Right, I agree the right sentiment is expressed there: my issue is mainly
with the reference to it in the text Wes proposed being in the
security/privacy considerations section, and with no express reference to
ossification, which is an important part of the issue (as noted in 9065).
It's placement and context that I think needs augmenting. No word beginning
with "ossif" appears anywhere in draft -25. It's possible there's an
appropriate place earlier in the doc, or maybe there should be a short
"extensibility considerations" section. Or maybe I'm simply in the rough on
this, and there's no need to link this document to the wire image
ossification issue.

Kyle

---

From: Martin Duke <[email-masked]>
Date: Wed, 8 Sep 2021 11:44:40 -0700

I'm going to move forward with taking this to the ballot, though if there's
a convenient way to address this I invite Wes to do so.

I don't think we want to go down the road of requiring an "ossification
considerations" section at this point.