IETF Logo Mail Archive

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

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 15 October 2019 21:32 UTC

Return-Path: <ilubashe@akamai.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 578D1120086 for <tsvwg@ietfa.amsl.com>; Tue, 15 Oct 2019 14:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 lXJx3syC0k74 for <tsvwg@ietfa.amsl.com>; Tue, 15 Oct 2019 14:32:35 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A0712004A for <tsvwg@ietf.org>; Tue, 15 Oct 2019 14:32:35 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9FLQtMK031245; Tue, 15 Oct 2019 22:32:31 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dkfIa1clrzCPLGWsggxaunGfMknr4pktrSznWcsZ+fE=; b=LMLxkSPBfpIZj55SughYtADx07vSO7spqmvuiAIftZ4l0zTIXDmpydWu+TeVsBKK8WGs DXIIscp6ulpIxZZPphrmbSvqdkfJrcfqhGXmPvI2+FXlF+yse954x35xcspnlv1y2NjI +ZhtFLOjmXXYTUbwtSMyeUd4HY/wb5oON4uOKMjY4VS29qskOATVKPJkVC7FfPWv6wnO 7fLMp59LMR8VxTjNr9/YoP2i4m3+Ndf+GagkwsikE0x1nOwLnFW23kiLazsT/R4VaduZ 7+GqShET+B7JYnQ39LEeBLknE1SXIv4g+/W+6FxdVliLxc4jQ5OEryhgIEPpxC7Qxj+o 3g==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vk7898fqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Oct 2019 22:32:31 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9FLWFnE009851; Tue, 15 Oct 2019 17:32:30 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint7.akamai.com with ESMTP id 2vka616dpr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Oct 2019 17:32:29 -0400
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 15 Oct 2019 16:32:22 -0500
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) with mapi id 15.00.1473.005; Tue, 15 Oct 2019 14:32:22 -0700
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Tom Herbert <tom@herbertland.com>, Joe Touch <touch@strayalpha.com>
CC: Christian Huitema <huitema@huitema.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AQHVfq5skMMsqltcGkSZvOGieG/ROadStP4AgATOJgCABLtaMA==
Date: Tue, 15 Oct 2019 21:32:22 +0000
Message-ID: <9c7df6fe717c43739454a91f8080cffa@ustx2ex-dag1mb6.msg.corp.akamai.com>
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>
In-Reply-To: <CALx6S36VYt+LVxWM_ZRos7VK6GArNbenpFD3yaPdqedvkoHpoQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.114.182]
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-15_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=938 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910150184
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-15_08:2019-10-15,2019-10-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=917 phishscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910150183
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cp_kSEmIiHi1nRvhi8EUt8ltUng>
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 21:32:38 -0000

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

> Tom

- Igor

v2.23.0 | Report a Bug | By Email