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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96E9E3A0C13; Fri, 10 Apr 2020 08:03:53 -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 NA_I4pigH-GD; Fri, 10 Apr 2020 08:03:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B5AE3A0C11; Fri, 10 Apr 2020 08:03:51 -0700 (PDT)
Received: by with SMTP id w20so2024805iob.2; Fri, 10 Apr 2020 08:03:51 -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=MJTPzKI4Jn+4RTNh3On3f7H0Fpn5sLqP62eRQXPa5jM=; b=dHbPkrNZFMpH6EsouxUkIyoe0ODGj4L4jLiZhCxPIL0sVutowPZ8VLs1M7YPK+9Rkx /kUVkQDBX3rSglkvNUFDrVHDeJWwzxO3CiF2/5aucUDPRCjc906+ksdx9avvx6o3EUOH 7WOq6sVlDmkF4huszNPifLaCYbFP/ByVA7VVkwe+fhbZeLXL4mO+x2TuymumSfNRfs0z fLPzldY47T5ehZyI0IShsuZD2SC8ydNoLyfPJ2EAE4PkH+pAwoNqpQsCHZBnNsyV4hRJ lKs9kfPO00IWk+g7Xfe2PxLhpbFqh8BNA1u37nJgEzqyyUYRbB5B6QwYVTcbyOMtaBeK H33Q==
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=MJTPzKI4Jn+4RTNh3On3f7H0Fpn5sLqP62eRQXPa5jM=; b=jeKoCuH4A8jxxU/bzbDzkB7gadnaj6rReHacHioLjP2J40BAKw7GP/WlIH5rUDggn4 6nLwx4COhhJH6WEx2BsFQw3jHjuluqE1nh9lCTGobtMzHNAMMGj4fpMZwkgPU0rqVzoz QtZWeaE7VJJaHgi6DEaL6kT4TBmaU15oHUnP1NWwpWvBQ9i0oAlFl+WuHXeByrN8QE7e eOJ/nGJ1kzYq1Fhea7I/TZEzBZp1uHBq2Lc8ew0Mc3gwL+LlhQ1BsWOQ1UpK3ldNaIE3 RtMa3NNBEov/IFfFu7WtI9Jp3E2UQS+5Tk5ghZjVDZXhfqvbPi1JvhoDYJiBtxQs+a9w g29A==
X-Gm-Message-State: AGi0PubM0bMfQZ7RXYHyuouc2Y/ia1xu5fxFvA569IqyM6YbNccIrMBX rcCyTSq1DX9NHWGxGA0m05EyDgV5xyxz7oJDdq4hjUyNMeY=
X-Google-Smtp-Source: APiQypL3CUbJXYlSiDWZMuQG1heDhHrbnmUnQNo3sdy37J7WCEBGmOPwQq+PT1x/yp2hJEWAi1XFrubjfTbIPnCltB8=
X-Received: by 2002:a5d:9e13:: with SMTP id h19mr4748503ioh.152.1586531030581; Fri, 10 Apr 2020 08:03:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 10 Apr 2020 08:03:40 -0700
Message-ID: <>
To: Tom Herbert <>
Cc: Gorry Fairhurst <>, Joseph Touch <>, tsvwg <>,
Content-Type: multipart/alternative; boundary="00000000000080cdc805a2f10a17"
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:03:54 -0000

 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.


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