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

Kyle Rose <> Sun, 05 September 2021 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47E7D3A0B91 for <>; Sun, 5 Sep 2021 10:33:18 -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 I_P_85WpV8P7 for <>; Sun, 5 Sep 2021 10:33:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C7503A0B8B for <>; Sun, 5 Sep 2021 10:33:11 -0700 (PDT)
Received: by with SMTP id b6so6217710wrh.10 for <>; Sun, 05 Sep 2021 10:33:11 -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=kdCA4FwEIMj8bc8z1gfs4qCbI/KJmzPmr6fk+i1Q93I=; b=bAzdOuO20cz5CWMpnZMKHAZks2OPV0RmpgIj4Djf22KYOEVPoG5x1Fa7pqSxhLT4j0 P6zDA/Hfydhexb9E4jRsPZXMmH9gzIcYV/h+IeCOG05JqDzWoMnz4d+6JBg6cMaxTXR3 PP63OOWWtgJ+xBpkyqrrQmGRlMToeDdK4BU+8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kdCA4FwEIMj8bc8z1gfs4qCbI/KJmzPmr6fk+i1Q93I=; b=FU/vRaKzLvDJxOgKuRBv4Ju7OcwCvi3orL5Ji8fMVHYTrxY04DcaWLfOx1W66CcROI uTuRPrF9R4DxyX3ei8TbtTT9U/DA7pHC3sLEaZB9AtAgzJEP09iUdaZZuRm64lKl/BZ0 v7I5NgnMAfqCjXcfH9cKQLxoEmF5Yqg57yGuOjiCiBhPhwBl8vNvZtHUB8vEEuHNieB8 8i0WsJIYRA131QSqFYh4hd34JT05rKjKhxJZeEiEQs8tGlwA0nAN2F3kDzt4y7iGCT7f 6WThyQ9hznlnIvOTyeuvoqp2Ct8WvnhDbAIBrgq17SrSllIZn3wpMmPCRCNQJOMYYYoy HNGw==
X-Gm-Message-State: AOAM533Bog1FDN+NwhuSFOlL8XifKNY+sMKKnp8oc1iuqFyEu3j3AOVF gGd46HRx7WufNyAak+YudMxEUcB/itHps/jWeCqoTA==
X-Google-Smtp-Source: ABdhPJy2Jjk5u3PlZS/9mMvZsIlX1jjnoW0QLgoW8AH1qANONXTAcXg4ZP2wtIt4JsmN/MmlqAzmhTAyEV2JUTZ8rYk=
X-Received: by 2002:adf:e4c5:: with SMTP id v5mr9102295wrm.1.1630863189499; Sun, 05 Sep 2021 10:33:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Sun, 05 Sep 2021 13:32:58 -0400
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Wesley Eddy <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="0000000000001677d805cb42ede4"
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: Sun, 05 Sep 2021 17:33:18 -0000

On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <>

> To me, this has a much more complicated history, and I think TCP has been
> extended many times - albeit not sucessfully in the ways mentioned above,
> but in other watys. It seems like a discussion of whether ossification has
> been good or bad. I'd also really quite concerned to see words like "often"
> used without clarifying further -  there are legitimate cases where
> filtering can be useful for managing the security of TCP connections: A
> firewall in one context might do many things, and that might actually be a
> good security model; in another context that might be different.
I'm not in favor of making a value judgment or discussing the wisdom of
approaches to addressing ossification in this document, but I do think,
given the rare opportunity of publishing a 793bis, that it's worth putting
the implications of TCP ossification in writing so we don't have to
relitigate these issues or explain in detail why such-and-such won't work
whenever they come up in future attempts to extend TCP. I guess I'm arguing
that we shouldn't need Joe Touch to explain multiple times to multiple
groups why a given proposal won't work when we can explain it once and
mic-drop a one-line reference to that.

I'd also question the importance of
>, in
> relation to the core TCP spec, even though the message is clear for MPTCP.

This is why I put it in a parenthetical. It's not directly relevant to TCP,
but it does indicate to the interested reader an approach that newer
protocol designs have taken to avoid one of the causes of ossification. I
agree it's not essential.