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

Martin Duke <> Wed, 08 September 2021 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12F093A3254 for <>; Wed, 8 Sep 2021 11:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RX3VTuBLOJOg for <>; Wed, 8 Sep 2021 11:44:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 931BC3A3252 for <>; Wed, 8 Sep 2021 11:44:54 -0700 (PDT)
Received: by with SMTP id q14so259434ils.5 for <>; Wed, 08 Sep 2021 11:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7h3Wpigtl21AEeVt1crG4kxdreUxP79JseycfVLAy/U=; b=LmamMO8mTx7/6OWC7A1+ESvWIY88Xvw9pumFC86hm5UgXrAW8Jw8Ys+SU+fAl0XHo2 drrxaE0hQxS0YxredxxzGHbKcMe2W7h6stclU5I2XVPRnEuKv4vYsaM59/FpfJgKU7sN 4aMxeiKv0GVCijxMm1Kjck1JV7f0jIDfZEjjhx584cwZ+L3odpimEyn5000IxdQ83DPZ ZE7vY8YWFeRP82NYx99G9slE3o6UR6/gEzXbRod18a3HxTcAdIHtdaztWdRQ0A9cguE9 BVo3xkhYo7kugnaQ/zIpCoXJG4RffipFtHndDhPaTcRQS1jfEXi0wE8fm/pWyAITO72H kC3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7h3Wpigtl21AEeVt1crG4kxdreUxP79JseycfVLAy/U=; b=Cvb7QFapCjXMnmJPFuDoYwnSYyYUN4ryAsYfD0rO8SEBSkEVR9d6gq4u8pqFQW5hK2 ZGcFBdtut9XT0W0iUnYR9cyVG16mz/hm6KXG9TmJBsXo2uKjJiqsm8T+tOqXNef1Zb5J esdT0K3no/4AGWoF2PGuWF9/I3AXuKqqRMirGiAQUvDXLt+jzI9VN58rxCG8FGmxtgUE 4AsLvlBpGLLAGLTiJ4yO8O9g9tPVJFpNGvU5Q19momnINc56Efxb4NbFbpQ+rZURSk4j m+mbleyHgXRD3Q4tabkA3qzejaOuHcSFVC7PTTNnIcAG+iTki30f0IojXIjEUWh0OzA1 KdrQ==
X-Gm-Message-State: AOAM533mrN0b0h7rYIr6DUMqPTKzmDchDkkkpSTdnj8+TV2h0BZHalz3 Fm3c50sd0PGPJzrmwa1HJ99JlyR9ckUOlJFKcN2CufSF
X-Google-Smtp-Source: ABdhPJzvftD8oQnb3pN7NswTLL32QaC0z3Xdw93/1OHJueZnQfaT/kFNH67gfVh/APwYVsv2O9Z1/l4ht4RXo2sH0KU=
X-Received: by 2002:a05:6e02:17cf:: with SMTP id z15mr931024ilu.103.1631126692544; Wed, 08 Sep 2021 11:44:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Wed, 08 Sep 2021 11:44:40 -0700
Message-ID: <>
To: Kyle Rose <>
Cc: Gorry Fairhurst <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="00000000000017c76b05cb8047b7"
Archived-At: <>
Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Sep 2021 18:45:00 -0000

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