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

[Spencer Dawkins at IETF <[e-mail]>]

(Please tell me when I become a pain)

On Fri, Apr 10, 2020 at 2:35 AM Gorry Fairhurst <[e-mail]>
wrote:

>
> 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.
>

I had mentioned this - not so completely - in a couple of posts during
WGLC, but the reasons I'd encourage not expanding the scope of this
document (now) are

   - There are many methods of dorking with transport headers,
   - Many of those methods aren't documented now,
   - Many of those methods are proprietary "secret sauce" of vendors making
   boxes that dork with transport packet headers, and they have no reason to
   help us describe them,
   - Our experience with the MARNEW IAB workshop (
   https://tools.ietf.org/html/rfc8462) was that we could't even get traces
   from 3GPP/GSMA wireless carriers to use as a baseline for the effect of
   middleboxes dorking with packets, not even anonymized traces, and
   - Our experience when we tried to document what session border
   controllers were doing to SIP calls was that what SBCs did was a moving
   target ("can we tell you about our LATEST product features?").

It's worth doing, if it can be done, but is it worth holding this document
up to significantly expand the scope and delay it while we find out?

Thinking about this now, I also wonder whether the audience for this
document is the same as the audience for an analysis of ways that
middleboxes dork with transport headers, but that's a minor question.

Do The Right Thing, of course.

Best,

Spencer


> 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
>
>
>