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

Spencer Dawkins at IETF <> Tue, 07 April 2020 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91D73A052C for <>; Tue, 7 Apr 2020 15:54:19 -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 1lyKV8OkzSR1 for <>; Tue, 7 Apr 2020 15:54:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7C6B3A0529 for <>; Tue, 7 Apr 2020 15:54:17 -0700 (PDT)
Received: by with SMTP id b1so5598936ljp.3 for <>; Tue, 07 Apr 2020 15:54:17 -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=+rHGxbqb1EVMyDsZiJDgdg0MOGI8UDaS5lHobSGQWFc=; b=Jdcm1LrYh1nxdEGpgDcnRYaYqimK+jx9IM7C5pmEMIpbO4e58vdrBZ+YvhtkVddALS 315mhpMqLdUHnAZT2bj8qjmj57f7atSIt0H9OEd0MY+aVx25vCThF+cXIszSc8tc28oT YCEMjyU5u8G69tY2qIDiQrxL58dQiHM5LPyjEYXfhU8yML49cBsx0Pe7sxH6JGXe4sZc c3boeJctM8Fugr1jnuCFeUYYXuNjSzvDxbV9W+Boyr+YSYHrUZiX+3jCGZPvdsOOBZ7d 2OXBu/0SH1JoIDiWVYPSSjjotlQlcuYe89mfo2A3IRgzw9ExPb2j86i8uvQTubmQQUse i3bg==
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=+rHGxbqb1EVMyDsZiJDgdg0MOGI8UDaS5lHobSGQWFc=; b=DoJgmyznfSUbkV/aR+YgNYdHVluNXPMWN/jZ0FIWO/kqu4ADAaKFdocFivCjFj5X0t zQOd5ICn4EY0xRpmox0GeSt7UZErSXVN8YYMWQ2gloDX4ZWq7Ojf8A8dbostzlTBOc5u DhbkCTOnwYWyW+llKOZvE+BhFQLP10yWvk3A8kinodmJfKsawq4V3x4+8MmQHf1hOidG bStMGm0HpL2DvO7Op/KIEOGTKikJfeFIOuG2ZkkaVCgcKSh/IWlJrJ6JNedyYPnX4Bor +Cc7dNecYXbQIwGcQWj2ui4+M2vaUgXuR2qsSIbU4TymRouNKceIPFwnEl7yydAp+FOq voeQ==
X-Gm-Message-State: AGi0Publ0xgKePtA6qeLHzByG4iEcBs5fUt5Sz7ygVQm85s+dJsHJeXO G7Sa+Pt6YjiZzX244rc/gzRtF6Jtpx4nUymM82E=
X-Google-Smtp-Source: APiQypKVL3f+/nwEMkKv+lW4kFmlj7e0+Li4TY5Ny1Y+BUZYBeVPST7GGDqno19H0PG7gOHPFXM7FcuPN4FZxlPtfGo=
X-Received: by 2002:a05:651c:20d:: with SMTP id y13mr3215056ljn.112.1586300055855; Tue, 07 Apr 2020 15:54:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 07 Apr 2020 17:53:49 -0500
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Tom Herbert <>, "Black, David" <>, Joseph Touch <>, tsvwg <>
Content-Type: multipart/alternative; boundary="0000000000005628c905a2bb4331"
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 22:54:20 -0000

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.

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.

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.



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