Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Tom Herbert <tom@herbertland.com> Tue, 15 October 2019 23:22 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3912080E for <tsvwg@ietfa.amsl.com>; Tue, 15 Oct 2019 16:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx-Yo0cp7-6x for <tsvwg@ietfa.amsl.com>; Tue, 15 Oct 2019 16:22:23 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D48812003E for <tsvwg@ietf.org>; Tue, 15 Oct 2019 16:22:23 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id y91so19705295ede.9 for <tsvwg@ietf.org>; Tue, 15 Oct 2019 16:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CE03DB3D7B45C245BCA0D2432779493630766752@MX307CL04.corp.emc.com> <e8c30f3f-606f-0c0d-a7dd-b2bb6f31a9fd@huitema.net> <A2F184BB-E352-4AE6-B7A0-FDF6D8851DFB@strayalpha.com> <CALx6S36VYt+LVxWM_ZRos7VK6GArNbenpFD3yaPdqedvkoHpoQ@mail.gmail.com> <9c7df6fe717c43739454a91f8080cffa@ustx2ex-dag1mb6.msg.corp.akamai.com>
In-Reply-To: <9c7df6fe717c43739454a91f8080cffa@ustx2ex-dag1mb6.msg.corp.akamai.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 15 Oct 2019 16:22:10 -0700
Message-ID: <CALx6S361-wmgGWcTQHNsXnJEPkdCbvOhSCGwd5a9R0RQ_E=CCg@mail.gmail.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: Joe Touch <touch@strayalpha.com>, Christian Huitema <huitema@huitema.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bW1uJ2gxSTCjlGFOBHmYhCdLP3k>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 23:22:26 -0000
On Tue, Oct 15, 2019 at 2:32 PM Lubashev, Igor <ilubashe@akamai.com> wrote: > > > On Sat, Oct 12, 2019 at 12:02 PM Tom Herbert <tom@herbertland.com> 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 > > Tom > > - Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Scharf, Michael
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Scharf, Michael
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lars Eggert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Scharf, Michael
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Scharf, Michael
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Roni Even (A)
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Kuhn Nicolas
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… philip.eardley
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transpor… emile.stephan
- Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-t… Lubashev, Igor
- Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transpor… Peter Gutmann
- Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transpor… Eric Rescorla
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Joel M. Halpern
- Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transpor… Peter Gutmann
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Joe Touch
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Joel M. Halpern
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… S Moonesamy
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Colin Perkins
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… S Moonesamy
- Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg… Ian Swett
- Re: [tsvwg] [ippm] [OPSAWG] TSVWG WGLC: draft-iet… MORTON, ALFRED C (AL)