Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Jared Mauch <jared@puck.nether.net> Thu, 06 December 2018 19:24 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD80130E50; Thu, 6 Dec 2018 11:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nOnrI9u91MPR; Thu, 6 Dec 2018 11:24:16 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B30C131143; Thu, 6 Dec 2018 11:24:16 -0800 (PST)
Received: from [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739] (unknown [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 5F9D554053C; Thu, 6 Dec 2018 14:24:14 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAKKJt-eNCeV4hS=v99NGAYFkkmLdSO5Cp9gk2ojdbZ5vrU7img@mail.gmail.com>
Date: Thu, 06 Dec 2018 14:24:13 -0500
Cc: Stewart Bryant <stewart.bryant@gmail.com>, IETF list <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net
Content-Transfer-Encoding: quoted-printable
Message-Id: <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net>
References: <CACL_3VGeJPzDhS0RVAvpQs9W8b4EODft-qJRwBD6Xxm+X6BZ6A@mail.gmail.com> <CAL9jLabK0bZz2nki=oFNHT0OrpVAB8pw7emAj2BtkHRCzkfmqQ@mail.gmail.com> <cf64abbf-e447-71e3-b983-4e525cc139aa@gmail.com> <CAL9jLaYMRDGFa7Qzj4ukRV1FPbJM40qbuZ34SYxoA30Z+h3EWw@mail.gmail.com> <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <d078ea0f-3c2c-f782-4c1a-b54c463b48ce@gmail.com> <CAKKJt-eNCeV4hS=v99NGAYFkkmLdSO5Cp9gk2ojdbZ5vrU7img@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/jFZVD2_IAxnO_x2SzWcQJWBs15Q>
Subject: Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 19:24:30 -0000


> On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Speaking as an individual who ballots on working group charters ... 
> 
> On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> 
> On 06/12/2018 12:57, Gert Doering wrote:
> > Hi,
> >
> > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote:
> >> However, aren't we moving to a world where new protocols get carried
> >> over UDP anyway?
> > Over HTTPS, you intended to say?
> Some and some.  It depends on what aspect of the stack you spend your 
> time thinking about.
> 
> "you're both right" :-) ... 
> 
> As noted earlier in this thread, we punted new transport protocols into UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we can't get DCCP deployed at scale, and we don't see any reason to think that any new transport protocol will be any different" stage, at least a decade ago. So, when I see people talking about SCTP, it's usually in a context like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only defined over UDP. 
> 
> (I suspect the world would have been a slightly better place if we'd done the DCCP encapsulation in UDP from day 1, because DCCP functionality could have been really useful when we started encapsulating every known network protocol in UDP, but that's not relevant to this discussion)
> 
> But since QUIC's initial deliverable includes its HTTP mapping, https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into play. I would oversimplify that draft as saying "we are way more excited about applications using HTTP as a substrate now, than we were in 2002", so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at least to me.
> 
> I don't know that's a perfect plan, but I've been balloting on working group charters for at least 3 years, assuming that it's a plan. 

Yes, we’ve also seen the security/crypto all the things overreach impact the routing area as well.  We’ve not seen a suitable option to replace TCP transport that is viable due to the timescales involved.  I’ve provided feedback at the mic in London in SAAG about the problems of this for people who need very reliable transport, some level of transport security but do not want or require transport privacy. 

- Jared