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

"Lubashev, Igor" <> Wed, 16 October 2019 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E621208A1 for <>; Wed, 16 Oct 2019 14:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 y4pYivsm47B8 for <>; Wed, 16 Oct 2019 14:49:18 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94145120046 for <>; Wed, 16 Oct 2019 14:49:18 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x9GLlKxR021960; Wed, 16 Oct 2019 22:49:14 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=db8hVp+xesuCuq6pTEifGARZxuJ8sNSj8+CRV2PwUto=; b=ZM+s7FJINzoyVXDtXlJlqLtFoYSYsO5hHIlRKu3VYU1fw5FVlzVf3wj4rxhdlIj6lUel E8DmmMVoZhu6z8k/0F5k+V4CVIs/hjcVIz/LFOBKr4HYRBiVpZWL76ENIDtjyhr7CH7u J4PvxTLt67eCFQSiV3udBzi7Cf/FHMrk/nHzvSQdRQty7vWPbJ4S3EgEPzN23Gc+tfAc Y40r4yVJLPReg3dNngAaHHv4to1bkMLdp/oEv/z4rheXRkPKOn8mzDzhC7VCezxo0bSj PBzKoo6KvCMzr+GxJoL2josGHUxtkF2N1MDXE7XJdtyZaiFUCffkHUQK88Bpg0pHAAPB Fg==
Received: from prod-mail-ppoint8 ( [] (may be forged)) by with ESMTP id 2vnp4pvv3d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 22:49:14 +0100
Received: from pps.filterd ( []) by ( with SMTP id x9GLlCjl018368; Wed, 16 Oct 2019 17:49:14 -0400
Received: from ([]) by with ESMTP id 2vka5x494b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 17:49:13 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 16:49:12 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Wed, 16 Oct 2019 14:49:12 -0700
From: "Lubashev, Igor" <>
To: Tom Herbert <>
CC: Joe Touch <>, Christian Huitema <>, "" <>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AQHVfq5skMMsqltcGkSZvOGieG/ROadStP4AgATOJgCABLtaMIAAmDoAgADUndA=
Date: Wed, 16 Oct 2019 21:49:12 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-16_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910160180
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-16_08:2019-10-16,2019-10-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 mlxscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910160180
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: Wed, 16 Oct 2019 21:49:21 -0000

> On Tue, Oct 15, 2019 at 7:22 PM From: Tom Herbert <> wrote:
> 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.

I am NOT saying "don't define an IPv6 HBH EH that would solve this problem, because it would not work everywhere".  Quite the opposite -- we should do something like IPv6 HBH EH, because all traffic should be IPv6 w/ HBH EH working in the future.

The argument is that we should _also_ do something, possibly temporary, to take care of the very significant portion of the network where IPv6 w/ HBH EH does not work today.  (I know that temporary things have a tendency to last forever, and it stinks, but we are talking about a very large portion of the traffic today.)


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

The "brokenness" this draft points to is the lack of network signals.  IPv6 HBH workaround is good, but it would not help for the majority of connections today.  So the workaround is incomplete.


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

Yes, complete agreement here. A useful signal that cannot be received by a device is a good incentive for the operators to fix the device or to buy a different one. But while filtering IPv6 HBH EH is up to the operators, the use of IPv4 instead of IPv6 on a dual-protocol network is out of operators' control, so operator incentives are not a complete solution, unfortunately.

> Tom

- Igor