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

[Gorry Fairhurst <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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.
>
>         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.
>