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

Spencer Dawkins at IETF <> Fri, 10 April 2020 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36AA73A0BC6; Fri, 10 Apr 2020 07:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lqCi2GcVvKFq; Fri, 10 Apr 2020 07:44:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EFF23A0BC3; Fri, 10 Apr 2020 07:44:30 -0700 (PDT)
Received: by with SMTP id h25so2148244lja.10; Fri, 10 Apr 2020 07:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hyW3a/V8/WNLC7kBZv42s5STgc2PxKr3BvfNYiGwskw=; b=exH7B+bw1BjTuE4ELM0ONmTCxOW6sLzmXvUmaDqn/R+nM48gWzmPhnQktNCj5wJ+18 UqfbTEQsCxwlTfn0zrnS80hxRyxO61o4uNKu+Ya+bTn+FHvqT0ooJJFhBEii7Qt2heH2 Ql9hoxquVpi4VSSb3uJidvnOGN1WP2AygTaLCPl1+XEtUhekOJpuEgLmWowQjpHSDE8+ a06n8kkhsGQ4jFK8mGcZ7bx2X2ipAVkKOdAP1y1K4vqmX3QS9TuU1HSa3DGC7RAmdRIh EXWZm6EgTMIFq1dPrJpf/fkLEM/sh23mUFDD16XZoH4u+ITuXmw4A9TQGGVDC/F/auP2 1edw==
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; bh=hyW3a/V8/WNLC7kBZv42s5STgc2PxKr3BvfNYiGwskw=; b=hRYT8Mlyl01Fn3ZwGyL88ntcZz1q1+rw8djc7IkANyBjFo0fb1RC4tfI36A3WGj2tZ c4WDZfiQrU8hf7Vt4lC92uF22+Fl8IcwXmIYJBuzDglQ3zPWImAGo6OW15k3h38H7brr Lx03QSkiVoZS7s7B7E8ddLGDZ9HXjTe0cslzecNVr/c5a/sw6+7vvlfd6gY1p3wxCPZh Q12G5PV7I7jBU8eihwRQCMR72r2XCEJ533EcC5UPfOOkpFWdfSNqOFdpGDeLxC4NIRG/ zcnzGqDUuZc/3WDkkgq1DzucZx5/8kjmdXFNjdnhIBgeyaaCAYOG9kE6HtRAUjwXCyC9 AmvA==
X-Gm-Message-State: AGi0PuYmtZ7cvKqEM9ww6/3nKjLtbKvG457RBt0FLD2OXBwBojmr+6NQ rrfm/HQRuibfy1Zi6Ychy+O5yQ+PV5dG7r7xBHQ=
X-Google-Smtp-Source: APiQypL1pF+Oaysjq/dpFZY14B0NlZ7A/zCuAHHHLkdeIbnwEwnbhxSCiNYs3TwhSxcwElzv+cXWHQ1YcSCz270mupM=
X-Received: by 2002:a05:651c:23b:: with SMTP id z27mr3105966ljn.125.1586529868736; Fri, 10 Apr 2020 07:44:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 10 Apr 2020 09:44:02 -0500
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Martin Duke <>,, tsvwg <>
Content-Type: multipart/alternative; boundary="000000000000406b0705a2f0c54d"
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 14:44:36 -0000

(Please tell me when I become a pain)

On Fri, Apr 10, 2020 at 2:35 AM Gorry Fairhurst <>

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



> 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