Re: [tsvwg] transport-encrypt-14 review, pt 1

Gorry Fairhurst <> Fri, 10 April 2020 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37CB43A1901; Fri, 10 Apr 2020 00:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YSRfrNgJRw2Q; Fri, 10 Apr 2020 00:35:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B00B33A18FD; Fri, 10 Apr 2020 00:35:18 -0700 (PDT)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 6FC4E1B001C0; Fri, 10 Apr 2020 08:35:13 +0100 (BST)
To: Martin Duke <>,, tsvwg <>
References: <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Fri, 10 Apr 2020 08:35:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] transport-encrypt-14 review, pt 1
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: Fri, 10 Apr 2020 07:35:25 -0000

On 09/04/2020 20:44, Martin Duke wrote:
> - Sec 2.3 explains that transport information is useful in detecting 
> various network pathologies. While true, the range of possible 
> pathologies is only as large as the control surface the transport 
> protocol offers.
> For example, in TCP networks can affect (and measure) packet loss and 
> latency. They also can also modify packets or drop them based on 
> transport layer information, meaning there are more failure modes to 
> detect.
I'm OK going into pathologies of "modifying" packets - but would really 
urge we do that in a separate document. There are *MANY* methods, many 
incentives, and many failure modes - and there is much that is not 

In contrast, the devices and procedures that observe (possibly 
authenticated) headers.

> In QUIC, the latter is almost impossible.
> Aside from Initial Packets, the only possible actions are (1) drop the 
> packet, (2) accelerate or decelerate the packet, (3) change bits that 
> will cause authentication failure at the receiver, or (4) modify the 
> packet at UDP or below.

That seems rather a simple view! Traffic conditioning and monitoring is 
still something that can operate at the flow level and by address, even 
on IPsec flows for instance - just with less accuracy, and likely 
requiring more heuristics and with more and different "failure" modes 
e.g. that impact sequences of packets rather than deterministically drop 
packets with specific headers. The Internet been doing flow detection 
and characterisation for Firewalls, Traffic Classification, DOS 
detection, etc. Even devices that currently perform (mostly benign) ACK 
Filtering of TCP traffic can resort to Size-based queuing/filtering 
(also out there)... that would be less benign (more variable treatment), 
but is widely supported.

I'm unsure that's a helpful place to dig further into though.

> All of these are still measurable over a network segment, though with 
> different techniques from today. Most trivially but perhaps 
> impractically, a complete inventory of bits at the network ingress and 
> egress point will reveal all of this information.
> Put more simply, everything that QUIC conceals from the network can be 
> ruled out as a cause of the network’s treatment of a packet.
That sounds rather niave to say in a RFC though, because the simple view 
doesn't reflect the ways in which per-flow measures are performed. These 
will differ depending on what sort of network segment you consider.