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

Tom Herbert <tom@herbertland.com> Fri, 28 February 2020 20:30 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 640193A1D7B for <tsvwg@ietfa.amsl.com>; Fri, 28 Feb 2020 12:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wRYz8h4icaVp for <tsvwg@ietfa.amsl.com>; Fri, 28 Feb 2020 12:30:36 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18213A1DA1 for <tsvwg@ietf.org>; Fri, 28 Feb 2020 12:30:35 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id c7so4879664edu.2 for <tsvwg@ietf.org>; Fri, 28 Feb 2020 12:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=4DHJ58bhRxTnszpD9FVSClN90+E7hYE7M0BRKaBEzZw=; b=FYdnsiXR3/PtI5L6GxcgvsB9rmyzGpy7nQyUOJCMPmBxL2IrM0QA37UFcsKaGU0Qnk bMIlYGWMcyoyv+rI4qcN1RXY9pwLpSkUW0GAnOziC+/G9wS/FWqdEib9SKBLmbu3CZmQ uxUmvPZWlmXZz1gpHGRfUemh9C3xKIlgDxYvAgaTAUKkUYsV2YFJXMxRxVN7qkMXUYRj sHXUuUQzPknvRvI4bbOQyHE/AOG2Qa0beJURnfQ7Qz/WWbqYFgXtMKVU/7a/gjIO3JT/ MtBsRTQdmgbp2WRQQvGnaofm1V1wKAy5ScdUuE3zcgU1RRAVaEnV75YAmJraEZfa7B3E AuQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4DHJ58bhRxTnszpD9FVSClN90+E7hYE7M0BRKaBEzZw=; b=Nzknju/Qa4JXY1UK5IfmwpvOIEhdYHX0FyGzlpLbagaMljmQ0wEQh7fgsphxk6AEhc sQdditpg7j4wvTk+ZDGphxKkJgUxVoXTDISB5LX2mMrTLgGvRJ61UQhCuvPjx7DKmBWz MTtxqFCfT/P58iZDePAKgCUHwYulRS/6rASkwKh/6TsBBNeM1zae2oFHNCXTIdBVeYg5 bw+T+qimwCzv6vLMbM7KbVf2ZerRF5ThlkyHc0AjxECQAJ01dwFEL3P8XNL+DLTx2hYv d3vQXxj5Ji3evrgtqQImEdTPi/pdXBap1k9GkfnsH2ap6/EzyxpYlJphExo51MmrAFs5 A65Q==
X-Gm-Message-State: APjAAAVxVVhhChMTTrTzplC/aMqrnJp2SIiHF4SF/ScQkgrvQ+EIAIRM bParaWqWWKL9ZIbiE3YnLyy2jk8bH3GFNU1JP9AYvfrf+Jc=
X-Google-Smtp-Source: APXvYqylvEFxzscFqDOp+XZcst/0XWMyQrTGi/Xj9U+tQTZKPvmfKaKiFz1Z++T4/mKqwbXBR1IWC1PYukGTzXGL+Uc=
X-Received: by 2002:aa7:d1d8:: with SMTP id g24mr6023340edp.39.1582921833761; Fri, 28 Feb 2020 12:30:33 -0800 (PST)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 28 Feb 2020 12:30:22 -0800
Message-ID: <CALx6S37iBDc7KxOL60=HC_QkWH06-5MU2rqrK=w+mqiKkSdc0w@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IUzHtXNH_Y0GkPeheU8Ru9ZuENU>
Subject: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 20:30:44 -0000

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