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

Kyle Rose <> Wed, 08 September 2021 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB69A3A2DD9 for <>; Wed, 8 Sep 2021 09:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6NCgl6c8J-Dq for <>; Wed, 8 Sep 2021 09:23:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70B4B3A2DD6 for <>; Wed, 8 Sep 2021 09:23:08 -0700 (PDT)
Received: by with SMTP id u9so4142149wrg.8 for <>; Wed, 08 Sep 2021 09:23:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fN2AM1DKuzl30istmTo/1ipKITP2/59Ko/aXARImcAc=; b=Y0eRvVZiMrOUb5bttYTNbDAjt90hWOdhJ6EZhHNC+8y5ZWU2TDbw5C4Yr2Pwjwsmyq idZPXf73zKYiAvES6JBMOufXZgH2VM4UkeQpUUR5l2/QwtgR10+1k37bJ/K0fZ9pIgui 4b665iuhJ/HTD4I1LqXHc9RsO7YuqcL6OJgaQ=
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=fN2AM1DKuzl30istmTo/1ipKITP2/59Ko/aXARImcAc=; b=HfEmQNEbbfiY33JQ/n/AUzdwjBr0JL/aZUJPhHG6YaYJ+/OLyhzgOCwZ303xT6qSRq ASnsqrX3wHTqv+P0yUANwhKjhzGlfsHRBgjtnV5ga2505d5kX084MrnRuclmB5rZ1hgC 5bU508uhOPsYXWix13/w6iqtqLPug4ruNCuZq8YqUuuX1Ltd4Fr2Cag76HH2M5cgW6pD fRKSXjLdD/Ccwr8pXtFjcA+GYL945tISZzTl2z/HsNKRcvP+l7OLLixK6iP0cjpIaX1C cQLuNFv/B8cPvZx3E46ckIL+2xymKl/mAZqoMu4GBfr0QMYTVJwOjzxq1BQj4BL0TDKb AfNw==
X-Gm-Message-State: AOAM531wneG5gIafhvOEpvaxuyZXM4ExHw9gYfuJFh3kKGV/iVnnSui3 UmvoEjubaONKV5fDkIe9dTy9J+ZSw74aUWYAvcCDzw==
X-Google-Smtp-Source: ABdhPJwzxbLPhzSd/tHIJh3JWJQIQQqED0V6Ku14dz1+bwwbyOeCAuPXNd67vh960ftj1M4+rnmIqtZYnFflwm5DQR4=
X-Received: by 2002:adf:fd51:: with SMTP id h17mr5116779wrs.178.1631118185583; Wed, 08 Sep 2021 09:23:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Wed, 08 Sep 2021 12:22:54 -0400
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Wesley Eddy <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="00000000000009ec5605cb7e4c12"
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 16:23:14 -0000

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.


On Wed, Sep 8, 2021 at 11:56 AM Gorry Fairhurst <>

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