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

[Gorry Fairhurst <[e-mail]>]

On 09/04/2020 20:44, Martin Duke wrote:
>
<snip>
> - 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 
published.

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.

Gorry