Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt

Spencer Dawkins at IETF <> Fri, 28 February 2020 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A08A3A1DD8 for <>; Fri, 28 Feb 2020 13:02:49 -0800 (PST)
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 xbqzQQK0_tEw for <>; Fri, 28 Feb 2020 13:02:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B639C3A1DDE for <>; Fri, 28 Feb 2020 13:02:43 -0800 (PST)
Received: by with SMTP id 83so3089793lfh.9 for <>; Fri, 28 Feb 2020 13:02:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ieZKa6wrbJnRy0CMyHeCO/SNw9uutB0/EF7FC+KPUw=; b=Pyevcf3FuljtsIP1mq3XpsM0CFEYfUN7L9hdk+6W7NJdvtJtf4+GZWheLGKgwUJxms j2XM/KpdVu7/PI/zSNNTxfLnpR/TQGHJUZ4M9lyTTacZIdRJsJ/1d18W2juoVgFnubeB RYt8R2YDm5gBWlKKvtsKQDDf3lZNFyvpMoiGf7XLDnwDpedqUu0N3n8jhmrlxblmxhcX 0zzfZhC2iSxFnrKVKKdQ3ITKQbJHrxQjeUAUe4BFfdRrDn7lLMMuXY4Z/W3tnEJjPZfn gAR3pQY5cKuSx6cCylwo2FMh+dDnzde5B8pvUH4LdCm0OUInA/Xe9cf6bWNxFqm//WxC 1Bzw==
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=1ieZKa6wrbJnRy0CMyHeCO/SNw9uutB0/EF7FC+KPUw=; b=GX3u0rgJ91uhAm0tBgmIDaim3Fwn622ah9m/hN5AMB1CrAWL9pOQa3QZIoq4FAgx+C pZoFynj3Z/QgUJyK/aloRuWVeltfUsjwEPJfj4QjxRjuWLbDHKLjxWgVeS/SSVEPdu8O 3bPsklr/CjoTN42cQDKuK5ZGrhST71oa21n1BDQPL2UznbBC7abAyxJylPX8Jg4VvXJf lsEaRagNY/97QcMp30W93VTn+tpplpWdEgFkMTVgJZ76Vmv9qmg2s/AsbsQSjAiENAyv ryrJgdged3ygNDDhfQK8q8HUnC9xi+2+/HvpdiAV6U/7BRihg0pfrpc80OdE58Jq2v+K hHow==
X-Gm-Message-State: ANhLgQ360fS3u5AjvA1ogrZTz47VoSRDo+QHZRT4NBFn8OAjSQGbhSGI PF66Sml4iH0fDZVZzFVLNoLw0ShOWPqQs/x3KRkKP2AjyCY=
X-Google-Smtp-Source: ADFU+vvItg9T0Fi1vWjNILK/sSGNIfxUj1YRlpavR3pRpQ2HrjsPrSZuV8bP/+2iYWpLc6iOV46PSJUZpJpMASuP0BY=
X-Received: by 2002:ac2:5549:: with SMTP id l9mr3702005lfk.53.1582923761910; Fri, 28 Feb 2020 13:02:41 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 28 Feb 2020 15:02:15 -0600
Message-ID: <>
To: Tom Herbert <>
Cc: tsvwg <>
Content-Type: multipart/alternative; boundary="0000000000008909a6059fa9282d"
Archived-At: <>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Feb 2020 21:02:50 -0000

Hi, Tom,

On Fri, Feb 28, 2020 at 2:31 PM Tom Herbert <> wrote:

> While the draft certainly has improved both in tone and content, I
> still feel like there is one area that is very under-represented.
> Namely the possibility of using extension headers to carry necessary
> transport information that the network needs. I have brought this up
> several times, and don't believe it has been adequately addressed.
> Section 5 discusses extension headers (in a rather offhand manner). It

You're talking about Section 5.2, right?

> is presented in a very negative light focused on the why they won't
> work. The crux of the argument in the draft is that extension headers
> are not deployable, RFC7872 is referenced as the basis for that
> conclusion. But as we pointed out, and even acknowledged in the draft
> text now, that is from 2016, so the data and questionable. But even if
> it were still relevant the conclusion drawn from it that EHs are not
> usable in any form is highly debatable.
> What the draft fails to mention is that Hop-by-Hop extensions headers
> are the ONLY protocol conformant way to signal intermediate nodes with
> data, including transport layer information, other than what is
> contained in the IP header. Intermediate nodes that parse packets
> beyond the network layer are not protocol conformant. This is not just
> an academic purist statement, this is DPI which is what has led to
> protocol ossification and hence is a primary motivation for transport
> headers being encrypted in the first place (see QUIC reasoning on
> this). Extension headers are also being dismissed because of protocol
> non-conformance in intermediate nodes. As often noted, RFC8200 has
> relaxed requirements concerning HBH options so that intermediate nodes
> can ignore. I believe that RFC8200 was published after RFC7828
> potential impact of that change was not measured.
> So then one interpretation of the draft is that it is trying to
> justify one type of protocol non-conformance, on the basis it is
> useful in practice, yet on the other hand rejects the correct solution
> to the problem on the because of another type of protocol
> non-conformance making it not deployable. There seems to be a
> significant irony at work here.

ISTM that the draft (if we're talking about 5.2) is talking about
interdomain use of hop-by-hop extension headers, which might reasonably be
deployed in a domain that you make decisions about (the subject of 5.1),
but are (let's say) more challenging to deploy if you're expecting them to
work between arbitrary endpoints attached to arbitrary domains,
interconnected over arbitrary topologies.

I don't disagree with the points you're making, but ISTM that if the
working group wants to say hop-by-hop extension headers can be a plan, that
should appear in 5.1, unless someone can point to at least one success
story of hop-by-hop extension headers being widely deployed and used across
domain boundaries.



> Tom