Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Tom Herbert <> Tue, 05 November 2019 04:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D09712000F for <>; Mon, 4 Nov 2019 20:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TUy-AWoEDZpb for <>; Mon, 4 Nov 2019 20:36:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B30E212002F for <>; Mon, 4 Nov 2019 20:36:25 -0800 (PST)
Received: by with SMTP id a67so2903060edf.11 for <>; Mon, 04 Nov 2019 20:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yKtl12sE2aQzP7ZrfUsuEs1Dj7jhl+9kOCh0RfL8H1w=; b=thMNi9H51B0XCuqNvUcOGzAZN+OYJgq7VE6VIAEWSunZwh0HwyM6auSc/r9+kNpBjt eJZjuWyl0aTa7syXwBjVjbKrCbDovJW6e9G64O/zyii5g9PAp/ovgMxoQczqj4TbNJp9 JpE0IrvTbk2CE3PLE5jfkaasGHF1L7h8/kXIE/XZNagWv5Ipe8Hx8VsSpkGAXz8sOcKL 4PAa56zDf7HYCV4or3QNXsWw0CXkLEoLHZ6yExe/SsUtzvZ86+oNDDNSyyWIRAG8mia1 NNaMQ9KPMly5DjiFa/5wSSXrm1IJ7YJxQ8FyvNnHwMWmytVRzQMHDndZKDjTq9z5pE5G IkBA==
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:content-transfer-encoding; bh=yKtl12sE2aQzP7ZrfUsuEs1Dj7jhl+9kOCh0RfL8H1w=; b=WLWwg987TihVTmo5WOhyXpUe7civmiqgF/zKgCK4oAc6ibAwYtxslky2mmGR9XYCQG N1WwjJIXA4CZrENHTfBAsftE0hXzhwd12alMiFhluNq6J4eBOEOYDyt/h7DuMEjlb7LE BY6hcBpHaVY0FlxGoxwWkm2IkoKSjd1p+Oxh/ps6cGKhvCN2RULePNzb/UQvXL3R5nYt G8OCr+a1erKeqA42GCIUcvgtvKZRIGWIFgMN2s8XW5/Ox7mHSGlFqbk2JZRtP4mu6IWX t7icnQmJbM/suiNdcB8aAyVlW0sl+7EbYUaTL+lL/ftulaVjztOd1AGSybQIPRTCNDhy 0a8g==
X-Gm-Message-State: APjAAAVzaImF++HkGSzm3G+5rVocEcPW7uY8wwETXIVh7Td20HC3JEwN gIGC6T6AH1Dzh4aB97stMjaLmBcrqq/BjQEuvePzi9/i
X-Google-Smtp-Source: APXvYqxMfIMpufXgVSsxg0qMwqyZ3Ywo9JoQtqF6BkRyRkac0RXWzEXR2BJvLXuopNEsPMRbG2gFuhJea5nE/40xMQM=
X-Received: by 2002:a17:906:c801:: with SMTP id cx1mr28032724ejb.266.1572928583969; Mon, 04 Nov 2019 20:36:23 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Mon, 4 Nov 2019 20:36:12 -0800
Message-ID: <>
To: Martin Thomson <>
Cc:, tsvwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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: Tue, 05 Nov 2019 04:36:28 -0000

On Sun, Nov 3, 2019 at 7:18 PM Martin Thomson <> wrote:
> On Mon, Nov 4, 2019, at 13:15, Tom Herbert wrote:
> > QUIC presents a problem in itself since the QUIC harders are inside
> > the UDP payload so intermediate devices end up needing to parse the
> > UDP transport payload. I believe the only way to identify a QUIC
> > packet is by matching port numbers, but per RFC7605 interpretation of
> > port numbers in the middle of the network is prone to
> > misinterpretation. Eventually, something that looks like a QUIC packet
> > based on port number will be misinterpreted. Looking at
> > draft-ietf-quic-transport-23, I don't see any discussion about this or
> > reference to RFC7605.
> Please refer to draft-ietf-quic-manageability for that discussion.

I looked at that draft. While it does mention RFC7605, the explanation
for how non-QUIC packets that match port 443 aren't misinterpreted
isn't particularly satisfying. Other than assuming port number match
is sufficient, the recommended approach seems to be for middleboxes to
track flows by handshake. But, that then requires state to be
maintained and implies that packets for the flow must be consistently
be routed through the same device (a common problem for any stateful
device in the network). I don't think the QUIC spin bit serves as an
exemplar for reliably exposing transport layer information in a
transport protocol that is otherwise encrypted.


> Note that while there has been extensive discussion on what QUIC should expose in terms of loss and latency, I recall relatively little discussion about distinguishing QUIC from other protocols outside of the narrow context of ensuring that QUIC can be effectively multiplexed with certain other protocols.
> My sense is that some people are assuming that they can use port numbers, which are fraught for the reasons you identify.  Others might choose to infer the use of QUIC using the "QUIC bit": the 0x40 bit in QUIC version 1 is fixed.
> Personally, I think that endpoints are not obligated to signal which protocol they are using to the network.  Maybe the QUIC bit is that signal and I'm just in denial.  I guess we'll see whether I can send packets with a 0 value for that bit...
> > This can be contrasted to putting the information in HBH options which
> > can be correctly and unambiguously identified anywhere in the network.
> I happen to agree, though I don't think that this is as simple as you might be implying. makes a similar assertion, but identifies some of the underlying complexities.