Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Tom Herbert <> Tue, 15 October 2019 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F3912080E for <>; Tue, 15 Oct 2019 16:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 jx-Yo0cp7-6x for <>; Tue, 15 Oct 2019 16:22:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D48812003E for <>; Tue, 15 Oct 2019 16:22:23 -0700 (PDT)
Received: by with SMTP id y91so19705295ede.9 for <>; Tue, 15 Oct 2019 16:22:23 -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=+9TVbP4eQtXryht4yQRibreLUmu9wXHQMH17VQlGbUE=; b=VIkPu9/O+Zj5p+bk5M3dXSpiYKuRoTQgaCWyGCAb7u4/ZL4ELZo4j6tyeb7Tc9Lvlg sgl6wjB6c+yUwZ2kV1lEN21Hi6xkA77moIqRwc8wjZiiAGZB9R/W96z1BIEV/d25fdQA ESHlUjZUCZUYPyr6pb+8SXY/Y5W2Sbjsb+Dbif4HQw3OPMcchxSCu4U6OAJbBNN2dUXh osmxVCvr6Bt3/CtWtUFx1h73rGJhVkZtlSJR2qRlq3VZffPXCmDI1DJDq8sTP0S6Hqyk 5g+fTLyIuCKJj/x6UiC13AvcrZIyiQjiinxwlzbonnFVqIpDHmGpU6Veoonq+GPerNlg xEkA==
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=+9TVbP4eQtXryht4yQRibreLUmu9wXHQMH17VQlGbUE=; b=pzSgQOU8/PC5H2zqAasSsa6qAUvMr/ZLUrAQwHZOTFCUTjNNEq0Fojck2o1pCAulDi P2Xn7lgMUFicQXnL+YM+sx1SNu5pPHE4restMEwaLeeOZhWEjvvuHJkaY0WiXZD5tbhJ oZRkQqnkgMVLY85eoMOn/uYqFv9VlDqzG+kjCCwhkWSSEBOep51hW4ZoBKIKuDp0w+02 h1eTsfcqSkup2SAfN1BfSi+E4U+SzXIBgS/R522chJB5LBimDOrjvH3hlRpX9hp3LAQG Rcl6kJtR1+HuYc1fv9bB+mMlw6UGXIjRHCXTMSZRpl7fAzkvzZM6LfNmM9MRsYHS5M4w UH0Q==
X-Gm-Message-State: APjAAAVdKVboExLpzH2riMk5tPWMq0G61SkDORhvIQGjXQSdPd20s/VJ 8oKlU57RcYjQXh4Kic1DzdLvH9oWhW0h+TclbF1+Rg==
X-Google-Smtp-Source: APXvYqy2ecckPX2Timx66mvakRt9XVb5kcT7mR3SGd/Y9wvu9yjMhRE6be4NVtG6Bxu+hu1sDuXnb3qapAX2+RYeBwU=
X-Received: by 2002:a17:906:d971:: with SMTP id rp17mr37721231ejb.42.1571181741525; Tue, 15 Oct 2019 16:22:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 15 Oct 2019 16:22:10 -0700
Message-ID: <>
To: "Lubashev, Igor" <>
Cc: Joe Touch <>, Christian Huitema <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
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, 15 Oct 2019 23:22:26 -0000

On Tue, Oct 15, 2019 at 2:32 PM Lubashev, Igor <> wrote:
> > On Sat, Oct 12, 2019 at 12:02 PM Tom Herbert <> wrote:
> >
> > I do believe that there will be valid use cases for hosts to signal the network
> > for services. There is a least one robust, explicit, and transport agnostic
> > method to allow hosts to signal the network with transport related
> > information and even application layer information-- that's Hop-by-Hop
> > Options extension header. A critical difference with parsing transport layers,
> > is that the end host is in control of what information is exposed in HBH
> > options. As I've said several times, I believe this draft is missing on the
> > opportunity to propose this as the "solution" to middleboxes losing visibility
> > because of encryption.
> +1
> An explicit signal-to-network, such as IPv6 HBH option, is architecturally far superior to a hotch-podge of protocol-specific signals.  I think it would be great for this draft to encourage design and standardization of such explicit signal.
> We know too well, unfortunately, that such signal, IPv6 HBH option, will not work for most of Internet traffic today (IPv4 traffic and IPv6 traffic flowing over links blocking IPv6 HBH option). The speed with which we can deploy encrypted-header protocols (i.e. QIUC) and a reliable explicit-signal-to-network HBH option differ greatly. What are we to do in the interim?
Hi Igor,

The statement that IPv6 HBH will not work for most of the Internet
traffic today is a rather broad generalization. In a sense, we could
also that IPv6 doesn't work for most of the Internet traffic. I will
accept that there is not ubiquitous support for HBH EH in all
networks, but in the same way that IPv6 can be deployed before there's
100% support we need to be able to deploy things like HBH options.
Similarly, asking what to do in the "interim" seems a bit presumptuous
as that implies there is a defined path to getting to ubiquity.
Analogously, one could say that NAT is an interim solution until IPv6
is fully supported-- but NAT has been going on for more than twenty
years, at what point is that not considered an interim solution? :-)
In other words, we can't wait for everyone to be on the same page to
deploy something.

So to me the fundamental question is more about how do we deploy new
protocols or existing protocols that are hard to deploy because of
ossification. The answer lies in answering these two questions: 1) how
do we work around the existing brokenness 2) how do we motivate fixing
the brokenness.

For the workaround, we can apply the philosophy of IPv6 "happy
eyeballs" which is essentially using probing or external information
to determine if the path to the destination supports a certain
protocol (e.g. IPv6, HBH EH, UDP, etc.). I believe there's a general
solution that might some day involve mapping the Internet to provide
hosts information about what paths are known to support what protocols
based on a priori information from the experiences of other hosts.
This also relates to one of my complaints about RFC7872 being often
quoted as the evidence that EH is not supported in the Internet. It
was a good data point, but it was just one snapshot in time and now
it's over three years old so it's starting to become stale. We really
need up to date, real time measurements of the Internet for such
things to get meaningful guidance for protocol development (I think
there was some discussion in 6man and maprg along those lines). This
also serves as the basis for an argument that not encrypting transport
headers can't be considered an interim solution.

For motivation, this seems to be a matter of demonstrating incentive
for middlebox vendors to fix their solutions. Network signaling should
be a good incentive. If the host is explicitly signaling the network
that means it has reason to do so, meaning there's some value provided
by the network. So if the network wants to provide the value based on
signals, it needs to support the signaling mechanism-- hence this is
the incentive!


> > Tom
> - Igor