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

Martin Duke <> Fri, 10 April 2020 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8477C3A07AD; Fri, 10 Apr 2020 08:09:40 -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 cZHHczf2JF1N; Fri, 10 Apr 2020 08:09:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56BC53A07A2; Fri, 10 Apr 2020 08:09:38 -0700 (PDT)
Received: by with SMTP id i75so2040569ild.13; Fri, 10 Apr 2020 08:09:38 -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=RuEVIv9aCKyE64vu5RHgXQoS6FVQnU8Uxft+gBnVeNI=; b=L4FEc6tzx2mYyCCKNDVGYWCLE42QeX4mFXRFEdtfHn3IKBFmCJjbvc9G13NIM4my/p oBQoDTJubhkCyPPXRluq1JkrUih0FPlSwhE8PAaUvXXuu9b+9As2GY99bVrlnALEQJCR WGDfD+CuMlfOIOi0Qxl4mISodFxmflC4LYMPWGkekYRTbgTjVYAR41jfatouKjKgnam8 Fii+5BVM2oTysl8h0HZlopWJWVjkckIi2S6iA0o3VggM8TsTamzmZ+8zCbZx4ojZRvll 4AVsgMm0yFp0ibjnC+eCM8ye5CbWaNy2o9DezJ08096/NrF3F2lWjJAoWfFGcGGHiner dAJQ==
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=RuEVIv9aCKyE64vu5RHgXQoS6FVQnU8Uxft+gBnVeNI=; b=RJp6WH6m8kLxX/RrK33IG/ZpYf5xkHvuh4TJd6y92owgShsDmRv5Am3A1xQ+9LQOa0 +g2DMclJuW5IaN5EMIjsgRbLLHc+fzhafthpyNAMClmll7BXrvZTaS/UlhUu6A/nfxRf 3X2zobGkIuNljOQIIs/fZMBbrpXVNlh3JAsToepxsPwAldDSxFmtpoV5c34HazIVBeMw I6k8wAjD0bi/Ea0t3/mp3VmkPKOqCHgJzst95NWMuFU3CSIj3Mik7MdJTWUbE977Fw33 3Et/S4UNmhB4bBNwhvoTmJxyQa0ohjn43DGszjv9ulzblLl4+rg6qULqRKUwh36U9Ois FFlA==
X-Gm-Message-State: AGi0PuYd9dIKhsZcaI58W6XWv0YzMeyhmMSVXlD+rTfLPedZgxOGMETC f0UJb/GKzBq7qHbEcqz4MPXi6mYLXfSM4u9SdDmOoyqT
X-Google-Smtp-Source: APiQypK9ZBksVwjcs42SvliG+SMz1R9t6qpc03oq838jC7hxJwepWLRjMrHn2aKmiTEsb56esnx/yyoj/oZfZ0NaSjk=
X-Received: by 2002:a92:8402:: with SMTP id l2mr4862557ild.99.1586531377674; Fri, 10 Apr 2020 08:09:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 10 Apr 2020 08:09:27 -0700
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Tom Herbert <>, Joseph Touch <>, tsvwg <>,
Content-Type: multipart/alternative; boundary="0000000000003100ba05a2f11fe8"
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 15:09:41 -0000

Fair enough. I am willing to accept the judgment of the WG on this.

On Fri, Apr 10, 2020 at 8:08 AM Gorry Fairhurst <>

> On 10/04/2020 16:03, Martin Duke wrote:
> Very well everyone,
> I'm conscious of coming in at a very late stage in the consensus -- if
> we've already defined header modification as out of scope, then very well
> (although it would be good to state that the Introduction, assuming I
> didn't miss it there). That certainly negates my comments PEPs and
> injection attacks as subjects, although that seems like an important part
> of this landscape.
> To Gorry:
> > 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.
> By "almost impossible" I was exactly suggesting this kind of approach,
> which I am fairly convinced will lead to tears. But people are going to do
> what they're going to do, I guess.
> Martin
> Yes, and my own judgment (personal of course) is also that going too far
> down this particular direction could well end in tears.
> Gorry
> On Fri, Apr 10, 2020 at 7:51 AM Tom Herbert <> wrote:
>> On Fri, Apr 10, 2020 at 12:45 AM Gorry Fairhurst <>
>> wrote:
>> >
>> >
>> > On 09/04/2020 21:20, Joseph Touch wrote:
>> >
>> >
>> >
>> > On Apr 9, 2020, at 12:44 PM, Martin Duke <>
>> wrote:
>> >
>> > - Conversely, middlebox interference with headers does enable
>> performance enhancing proxies for extraordinary link types like satellite.
>> >
>> >
>> > Those are only “extraordinary” only in the “been around for 50 years in
>> the Arpanet/Internet”. That understanding goes back as far as RFC 346 and
>> IEN 8.
>> >
>> > Additionally, ground nets often experience similar BW delay products,
>> which can be the dominant driver.
>> >
>> > There are known ways to help TCP over such links that don’t involve
>> these sort of steps, documented as far back as RFC 2488, some of which are
>> now being incorporated (faster window growth and recovery, ala Hybla).
>> >
>> > I.e., just because a mechanism CAN rely on these headers doesn’t mean
>> that’s the only - or even safe - way to do so.
>> >
>> > Joe
>> >
>> > I'm with Joe there are MANY ways that devices sitting in the network
>> *do* presently change TCP headers. This is not at all restricted to
>> specific technologies such as Satellite. TCP ACK filtering/decimation/etc
>> is commonly used on a variety of paths to reduce return link traffic in
>> WiFi, Docsis, LTE, etc. PEPs have split TCP in many ways where delay and/or
>> loss is important, devices that track or change rwnd are out there, as are
>> other devices that have modified other things for better or worese. However
>> we already have RFC3135, RFC3449, a variety of header compression specs,
>> and more recently RFC8404. All of which delve into these topics.
>> >
>> > In an earlier thread, I motivated restoring the focus on methods that
>> observe headers and do not "manipulate" these. It's true that when the WG
>> decided to add the "ossification" examples at the start iof the document,
>> that these were nearly all related to changing headers, but still I think
>> the focus of the remainder should be on methods that do not change headers
>> - That also is the set of methods that could be compatible with end-to-end
>> authentication.
>> >
>> Gorry,
>> I think the draft is trying to walk a fine line. The draft provides
>> several examples of presumably benevolent instances of passive
>> observation, however doesn't acknowledge there are deployed use cases
>> of modification. There are people that would probably agree that maybe
>> observation is okay but modification is detrimental. There are also
>> those that might say any use of transport information by intermediate
>> nodes is bad and leads to ossification, so both observation and
>> modification should be prevented. A third camp might say we've been
>> modifying TCP fields and our users are seeing great benefits so it's
>> okay. I don't think there is consensus on which of these viewpoints is
>> correct, however I believe that the goal of the draft is trying to
>> establish a balanced position without judgement, so not mentioning a
>> known use case that would definitely be affected by transport layer
>> encryption seems like an omission.
>> I'd also point out that if a transport protocol developer makes a
>> conscious decision to not encrypt some data in the transport layer for
>> the benefit of observation at intermediate nodes, it's just as easy
>> for them to also purposely not authenticate data so that intermediate
>> nodes could modify it (again this is independent of any judgement as
>> to whether intermediate nodes observing or modifying end-to-end data
>> is a good thing).
>> Tom
>> > Gorry