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

[Martin Duke <[e-mail]>]

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.

On Wed, Sep 8, 2021 at 9:23 AM Kyle Rose <[e-mail]> wrote:

> 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.
>>>
>>
>> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>