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

[Kyle Rose <[e-mail]>]

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

On Wed, Sep 8, 2021 at 11:56 AM Gorry Fairhurst <[e-mail]>
wrote:

> 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]> 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.
>>
>
>