Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

Tom Herbert <> Tue, 07 April 2020 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAE973A0862 for <>; Tue, 7 Apr 2020 16:30:02 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j7kWRi_Y62-f for <>; Tue, 7 Apr 2020 16:30:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86BE73A086D for <>; Tue, 7 Apr 2020 16:29:45 -0700 (PDT)
Received: by with SMTP id cf14so6170662edb.13 for <>; Tue, 07 Apr 2020 16:29:45 -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=NWMVZwO6oyBnREz2uXQ7BpRcE5Y8ZZweCx6M+0p1/gg=; b=L3apKGrxOfzyVx1hNLIrefhyd59/C3kZ0HxB9Q7El33+LIu/PinvvXo9iYwYtCftwh 4Vz4uRrXG35QJ7pQ+AciSyJzJQvU7v0RfNeKpb4WpFgez/N59ugxp1iH8MJQK2sMTIQT iImMQRsMDXL/faQrZ1hHWKZ+5ETd7AUM6UGZ4O9EkYnstQmssPlHbSa24+OVCWNi6cRp WeWxrRx/BXeqVR1RnLoa0w67r97uVvUJYHlk14iEwAm6KnOTlHvdlMiz8Ug6IP9mR6TG 2t0gRnDdfe7OijD0fdYYTeBdlU4lOldnpjck0Jq9NIX2MHxM8yB3wG9kZ/b/1ten2Fhf 8sSQ==
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=NWMVZwO6oyBnREz2uXQ7BpRcE5Y8ZZweCx6M+0p1/gg=; b=COF7OvqTSE8tI2VfkBDqcK/WBaIR5tR/V4xNozAzbgGGbAmhNl/9ZhtvnPDW/S/kmG VIL080NiucSupL9bkpTA/9YkH8f4Tcgetac/eGJT91M9U9LGs6MY888//IDSToHPy/Lf JhPdO+XOqflPg87tuujRPR6+N6ntocySwqnLoFz0CSsgQ7W3MxxWP3am2PUwZMeNIEb+ k7GmYefl/UXKBD6EgwFtFQrDJVxdG+PvlMd1E702wUujebmF8mOSuZaVdImhrCsiFBfJ w+INnPN7yyJuiUP55NBQWwZqpckMdQDnRK3FTh6GL7acV0WHFBx1tKEIxthPavCVXjXB PMvw==
X-Gm-Message-State: AGi0PubXOPbaLNXpFK/9r+CCVgHM+TjcJPL2IQrkMF1XnrLxHDlhNsdl i2OjXwruiSmO78yAqQrW3Kn9RwWp+h9BVlMX/NzIxw==
X-Google-Smtp-Source: APiQypLsQx2ZeX1WjrsS4jMwXNPmhpjJkkqIUTB47IiLvjYjMxxGbHRWwB57nQesEUusRBcnuSVOIJ0hlYJD+ms5CUc=
X-Received: by 2002:a17:906:8243:: with SMTP id f3mr4158114ejx.166.1586302183757; Tue, 07 Apr 2020 16:29:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 07 Apr 2020 16:29:32 -0700
Message-ID: <>
To: Spencer Dawkins at IETF <>
Cc: Gorry Fairhurst <>, "Black, David" <>, Joseph Touch <>, tsvwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
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: Tue, 07 Apr 2020 23:30:03 -0000

On Tue, Apr 7, 2020 at 3:54 PM Spencer Dawkins at IETF
<> wrote:
> I'm happy to defer to Magnus on this, but ...
> On Tue, Apr 7, 2020 at 2:10 PM Gorry Fairhurst <> wrote:
>> On 07/04/2020 19:11, Tom Herbert wrote:
>> > On Tue, Apr 7, 2020 at 9:20 AM Black, David <> wrote:
>> >>>> Also, a corollary should be the hard requirement:
>> >>>> "Intermediate nodes MUST NOT ever modify transport payload”.
>> >>
>> >>
>> >>> As a general principle, yes - agreed. There’s always the caveat that it’s always OK
>> >>> *with the consent of the endpoints*, e.g., if an enterprise wants to set up the
>> >>> network that way for their users. But in the arbitrary “middle” of the network, it
>> >>> *should* IMO always be MUST NOT.
>> >>
>> >>
>> >> As a general requirement, that’s fine, but it should be stated somewhere other than in this draft, e.g., as this draft is intended to become an Informational RFC.
>> >>
>> > David,
>> >
>> > Changing transport layer header, e.g. for traffic flow optimization
>> > such as those devices doing receive window modulation, might also be
>> > another use of transport header information that could be included in
>> > section 2.1. Currently, the draft only seems to consider uses based on
>> > passive observation of transport headers.
>> Yes, that was the intention to talk about using the information, not
>> changing the header.  WE don't discuss methods that modify the transport
>> header, some ACK-modification methods, Window Modulation,
>> proxy-intercept, PEPs, etc, which can't work if you authenticate the
>> headers.
> That was my understanding when I was encouraging Gorry on this draft.
> In addition to the likelihood that the description of passive observers would be considerably delayed by inclusion of description of active middleboxen dorking with transport headers (we did not lack for controversy on passive observers, in 2017), I wasn't confident that we could come up with a taxonomy of what dorkers were doing, and why they were doing it.
> That's probably the result of me spending time in the SIP community, when we tried to describe what Session Border Controllers were doing in, while SBC vendors were adding features as quickly as their engineers could type. You won't be shocked to discover that vendors considered their dorking to be "secret sauce", that differentiated their products from their competitors, and were not lining up to tell us what they were doing.


That reminds me of the olden days when some dorker providers were
parsing HTTP and replacing ads with their own :-)

> So, unless someone can convince the working group that documenting the dorkers can be completed in finite time and space, I'd discourage expanding the scope of this draft, at this time.

it might be good to clarify the draft that only uses cases of
transport information being observed are in scope.

As I said, the potential tussle happens if the transport protocol
designer decides to make some transport header information visible and
doesn't consider that the network may then modify the information-- I
believe this is prevented in QUIC since the plaintext parts of the
QUIC header are authenticated, but that might not be the case for
other transport protocols.


> And that's not in any way intended to say that documenting the dorkers would be a bad thing, if the working group thought it was possible.
> Best,
> Spencer
>> We therefore were didn't see the need to call-out methods that
>> require changes to the transport header. There are other docs that take
>> a  look at a much broader swathe of mechanisms. If you want to read more
>> about those, see RFC 8404.