[tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

Tom Herbert <tom@herbertland.com> Fri, 03 April 2020 16:48 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 6FB023A079E for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 09:48:57 -0700 (PDT)
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 W7WI41jIAGaC for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 09:48:56 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 F03563A079C for <tsvwg@ietf.org>; Fri, 3 Apr 2020 09:48:55 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id a43so10014440edf.6 for <tsvwg@ietf.org>; Fri, 03 Apr 2020 09:48:55 -0700 (PDT)
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=brRQw0Zdu4pvCSbmJinM6hEgMvXSHK+WITOSlYx3p4U=; b=XiQqoRh7jKg2mUxy+5mqIaSvVwFNq9372FUEm6rnn9tJZl990zlsmWfTMgVV41/QcM cVda8e73a/pHti+o5DDqlTt/ZUSeNu7USdXKCgOwEAbBc0MwMnG6v9QnJtAa9FY/xoNu QV5Pbafg8CdKcHpNHm6Q8FctsisbZzd2PrVJfSkrpbNmbO4VuclcxCqDi+UjeNA3+Fw8 HkEkdo4drtjpSSbyQ2bLeHyAa+jExGdNa9RMFHJx3BtasSRzp8Ffxpoe7kPk2sGWrYv6 IFJdclSKltufDisD1QEiv8UnbnnnJBym8a89Vw48YaZs5tUAXoypTc9yQRB7W1x5HvjO /6ag==
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=brRQw0Zdu4pvCSbmJinM6hEgMvXSHK+WITOSlYx3p4U=; b=TMbkH89KdvMqyFMyACv1WYSbGTixmiX6/SZBJVJuG5sFDOd1OtZx59C56XjBz89Kh3 XqKZpWCDctjOAu3cu/ECUTvltJYB9WVjLzSlgWhnby8Nmt4LVh8AFJ6EQiluF3jRDYJ0 4250Rn9x3wHK9FL0sSHhQOxpU6HnDei3qtG+fb4ptyoETgYtLDEsKTlrgjT5EipAmPU3 zl+5IxG8dQ4llu/4tCX3nfLIOz6GNkIe7bsXtchYh/kymnK9/lNup1KaXhogpEWD2vDP 7jbCI/8l3lAMgCr1La3bo5GnWGORPc8J/RYr+qTcufeY8FHSi1dulCI6gkyfnosvtOar DWvA==
X-Gm-Message-State: AGi0Pub869UZQIKgNQeWXxjjOeLnf4EdvJtwxCqVhob/l/NDDw66MMAR hBAsuxR4aFQEgpvKk+S7rvBagEs311BTGMjmQouFokPt13Y=
X-Google-Smtp-Source: APiQypKKcC6QOyBh4KD7wnCSAKz+NGAdLZnRj6B96juw8Ul6NK0IBHtSqNlr1cf9CjuNeXlVJ7DjaYOD5RzhEwaa7B8=
X-Received: by 2002:aa7:d602:: with SMTP id c2mr8874634edr.118.1585932533890; Fri, 03 Apr 2020 09:48:53 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 3 Apr 2020 09:48:42 -0700
Message-ID: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4sOJoYTqEHL-O4yse1eLjuFLKL0>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
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, 03 Apr 2020 16:48:57 -0000

Hi, a few comments.

I don't understand this statement from the draft:

"The value of this information would be enhanced if the exposed
information could be verified to match the internal state of the
transport by observing the transport behaviour."

I assume this means that the network nodes would need to understand
the internal state of transport protocols. How would this work?

If the idea is that the exposed information is somehow verified with
the endpoints that securely provide the information then maybe I
understand that. But, if the idea is that intermediate nodes need to
autonomously deduce the internal state themselves, I think that is
problematic. Aside from all the known problems that stateful network
devices have caused, there seems to be a circular dependency here.
AFAIK the only way to deduce the internal state of a transport
connection in the network would be by inspecting the exposed transport
information, but this statement seems to be saying the exposed
information can't be trusted unless the internal state has been
deduced. Am I missing something?

>From the draft:

"An endpoint/protocol could choose to expose transport header
information to optimise the benefit it gets from the network

There is also the possibility that the endpoints didn't expose
transport layer information, but the network incorrectly thinks it
did. The network may simply misinterpret bits in packets as being
transport layer information when in fact the data can be something
completely different and unrelated. The canonical example of this is
QUIC or any transport encapsulated in UDP payload. Per, RFC7605,
transport port numbers only have meaning at end points. So for example
a network device may think a packet with UDP destination port 80 is
QUIC, when in fact it is something completely different, hence the
network device may misinterpret the payload as being QUIC. I suspect
it's unlikely that this situation will benefit the user, and more
likely the network would not treat such packets well. There's been
some work on this problem, like magic numbers in SPUD or analysis to
mitigate the effects of misinterpretation like done for QUIC spin bit,
but I don't believe anyone has proposed a general solution (other than
moving the necessary information into the network layer and have
intermediate nodes stop doing DPI).  I believe this problem should be
mentioned in the draft with a reference to RFC7605 .