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

"Martin Thomson" <> Mon, 04 November 2019 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A23A2120888; Sun, 3 Nov 2019 19:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=JZ/c+PlF; dkim=pass (2048-bit key) header.b=YZFb9gXd
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pXAITiYrTFjj; Sun, 3 Nov 2019 19:17:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30E7E120058; Sun, 3 Nov 2019 19:17:48 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 59DBD21B7C; Sun, 3 Nov 2019 22:17:47 -0500 (EST)
Received: from imap2 ([]) by compute1.internal (MEProxy); Sun, 03 Nov 2019 22:17:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=qXfZNKNjV8al7Q0EhqhEdt8QVs+5kwh m1evR3GmSmG4=; b=JZ/c+PlFzs1RzyfVQwAJ4YQXKXASxEQiFGsofTRf6a0MLXO wEh4h2EO9REaiGn93BAMTjYUi2YYC8zDhRYsnLQeAcMv7ga2VPZj2HuxtPAXtKFj jX9obxkrAkPOhyb6xbDGoqR7JIsDSh4FtQgoUXQXh0r8Cc9YuX53sIf0JwmuAy/k H0hBiGlfbciAPsIDlsNn/ZpezpZEzioGud0Oc8bgnMfCd74Z4nUuhiLflvXKN6Qb R95PYkNNDzlKEZf/5O3ZBaV3dHOJSMbsO/UydTlAg6A3J1u5KDnYrBJgLReVN2xO ccokQEKs2oCHG9MEnBHXfQZX0sZo3jKAD+/dHbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qXfZNK NjV8al7Q0EhqhEdt8QVs+5kwhm1evR3GmSmG4=; b=YZFb9gXdaZ7Bue3VaEE55G ZmgHWL9A/TJCS/995tZ8FHkGXdkF7+XFxxljpAtsLVhRV7+pAkjitAXhPDdNPLRo xWdnpxyEYT+E1luRUHKyV/AYIYe8gcy0RauWVcpZe8TVvIyxyS+JAV+GkRz6MYG9 OV58roiqZqWnCdtAySzvDBZrTHo54knVGT2mRK3bTlAgiEguhgxXxQYx5w9UnWPg Cd4FJXBatkVmOAnee8mZewIgx9rCaSCvs8l/P7HjlmgyK+BxGNbig+4MAuKAhHJX fUn/u7bYrx8vkwSceKR2XEwQ1WSZHmQHoDul08goakghdPGBB07AXS0G6F2KXRWw ==
X-ME-Sender: <xms:W5i_Xcy-ne9Dlwnp6DFvzl4m9ORzimNTxzL_kMss_ssorAHtzvkdMQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd
X-ME-Proxy: <xmx:W5i_XclxUE0aro2scuqyiZ1tAzMTgNDNuyb_r4ZBmZCiNt298D_lqA> <xmx:W5i_XRESxnO3V_b0L4jByK2cj0n8BGLjdyLDxOBtDIPJemWxNNcGSQ> <xmx:W5i_XcWW0H1b384v0GU4ozZ3v2BCqYIZ0rUNQaQHFvxyOPIaI7ODuA> <xmx:W5i_XfmMtp0M183CCpYR1lQiJbm6DocvFCzAtJYUxsiEh8fGb3tWnw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 06002E00A3; Sun, 3 Nov 2019 22:17:46 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 04 Nov 2019 14:17:19 +1100
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tsvwg] =?utf-8?q?=5Bsaag=5D__Comments_on_draft-ietf-tsvwg-trans?= =?utf-8?q?port-encrypt-08=2Etxt?=
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: Mon, 04 Nov 2019 03:17:53 -0000

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.

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.