[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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. Tom
- [tsvwg] Comment on draft-ietf-tsvwg-transport-enc… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Spencer Dawkins at IETF
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Erik Kline
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… C. M. Heard
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Erik Kline
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Gorry (erg)