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

Tom Herbert <> Fri, 10 April 2020 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55BE13A0BFF for <>; Fri, 10 Apr 2020 07:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZxBxOl8VLzbh for <>; Fri, 10 Apr 2020 07:51:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D5473A0BDB for <>; Fri, 10 Apr 2020 07:51:48 -0700 (PDT)
Received: by with SMTP id cw6so2682339edb.9 for <>; Fri, 10 Apr 2020 07:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5vH8e0tsEAbREdr6J0xEoNBQnnCkbHNTRleCcptn5nU=; b=NQKB3qiQUfhpNB1ZMzk8ghm4VKNk6myp+yqlKYJykVPwYAg4YVR4RVxzjmMrWyN99q 2HZpVYzMrbsjCJsPA7fd/bbbApDKjt/9MHxHt0afCKVkHEAmooo8HJxtOsBzL3K8uVvh MIxLWvnbAAEQcxJQf21q/l4rvU/9sEg/rQGE9W2rbFXlunhymeo37Xmk7VjWiY71Oalv TxDDhwvEywxnOskmlZU0AsBSWxqBpybHT+hUf+8v8S1i0om+ihfHmH6feI/foOn2gZqR Hw3EDc8m0kOfPgjhN+SIQkL2XTA4akoy/TYr6SCvwYUS7nMf0EUUn6f///JJq0Kjf2Ho LUtA==
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:content-transfer-encoding; bh=5vH8e0tsEAbREdr6J0xEoNBQnnCkbHNTRleCcptn5nU=; b=IofaNmq1EO7/xyTlMkgPx+t9dPMKxLXZKILZV1+JtUa4biRtMZXdT0NSJWKvea8sPy XK2goxlObZ6ByfM5hUMRLbalBIvkqY0VeVZpeIW2VCZOrfFEaHafQccWGinA1Kv4sLZn M2gDze4HlI+pUGGgBOzb9VjhptiRTSqDPS+t9JfS2tXw/4uPUUhOsp6mzdyRdo/MehdE 04C8CpPdzGuFz5JuHK5wGH+P/xFg2zgduyfcGVXufej4qWvxHKe+/NKCun4na/CO0IXw Hfphj2fAeDPApav/SX9gLmPYXd0Hud2BA6bRhatV3znHYAFPRnY0VKoFClrQamKFKTOg Ef+A==
X-Gm-Message-State: AGi0PuawW6ApBrJGacRB/IFjGL4Kmdn7xg7frOoH2zvKbEdi339h6rTA +q6+CwDuglhkcotIq0vQYCXQAqcGpywQtMUcBPCVBCiA
X-Google-Smtp-Source: APiQypKtS3RwCjZn2GLwg+ZU8AzyyLtOAhnPcJjiDBiuaJOU2FOqnRQlLp1J17VuoVP64dUJn9ZwgrbVcI+TI3cJ1Mk=
X-Received: by 2002:a17:906:82c6:: with SMTP id a6mr4246430ejy.245.1586530306641; Fri, 10 Apr 2020 07:51:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Fri, 10 Apr 2020 07:51:35 -0700
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Joseph Touch <>, Martin Duke <>, tsvwg <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:51:55 -0000

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.


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


> Gorry