Re: [Edm] Please review draft-iab-use-it-or-lose-it-01

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 19 July 2021 01:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3EE3A1B8D for <edm@ietfa.amsl.com>; Sun, 18 Jul 2021 18:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZvrdZNIexrGE for <edm@ietfa.amsl.com>; Sun, 18 Jul 2021 18:54:20 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 9C8D03A1B89 for <edm@iab.org>; Sun, 18 Jul 2021 18:54:20 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id b2so4217034plx.1 for <edm@iab.org>; Sun, 18 Jul 2021 18:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kzlTL91SsyiA1+TjRyHkvXQfZlyGnwNKK76b7mOBpFg=; b=UjKTQVlzxcuqulGJH8uy3jozlao/aJEqJPbzKX7/lZS9Ka3SYO6LqlPA6lErMOiaSZ Imoq3wrSd8gOzKLuuNgBjN6oznAtU/fbx8PC0AcMOsmrD/KVcwi2VPs5TZMI56fbAcHh Qwja3HrYpJN1AiAmgLHZXa1cgJRQu+7unPpbEaKilHX5zptcu4pqpdkRCedJ+gueXBIU C9NHql2WvBBcgGlxRd2AaGh8z4TIwwR9gMkg+mi0mdNBy/+lQYdSfjfIRF4XBxKeJt06 dJvQYL0MmPa3ULOWz9z/XCHx1y3BaDOsO2D1XgItVGWN6eSOVWIaxRZEw2fp0DrB9+Ma lrBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kzlTL91SsyiA1+TjRyHkvXQfZlyGnwNKK76b7mOBpFg=; b=NJYlMfBSUnw44fWbMMtKa/Czo31x9bXtkJ0BmB6qUeMu4Un1SfbVFuE0K+14OsmVW6 NdM7FfDxU2JIeQYB5elHGgko/Gwm7zAfLfJjAEVMD+LTAjt244HVuotbQ8fqF4tem2sc Vi1tvR91D5FRgi4V7tLcNlz535ZLwdDJNWjNNgVauMAeBwGfdbd4xlG65/2gjjGSvhnL QcB+GfWToXma1SY+j5tO9yoghMnGWWIV5mbBkfRzQE1Fy8/Y5nWDq967wYrinhu/kcM7 VCXB6WEXTqEliny5dEL404QxjgLtQaynPmENotYwg8RjEYttmRmlU7BXpza3C26sL2cZ EUlA==
X-Gm-Message-State: AOAM530WzhP6OvZe5/uCi55dTuUJmcrdk3XmwO+iDQz8nAhBSrH87HvE qlbJPCrfOlwP8amLgmXpAm273+BI6VH4jA==
X-Google-Smtp-Source: ABdhPJy6Lnaii/yyDFBS0I62lapi58fAuKhYQ2HnIejqamW+D7F3mW5fTrgaCC3Ia2vwF0zXzU5AbA==
X-Received: by 2002:a17:90a:3e02:: with SMTP id j2mr7076703pjc.81.1626659658094; Sun, 18 Jul 2021 18:54:18 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id r29sm17849157pfq.102.2021.07.18.18.54.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jul 2021 18:54:17 -0700 (PDT)
To: Martin Thomson <mt@lowentropy.net>, Toerless Eckert <tte@cs.fau.de>
Cc: edm@iab.org
References: <162626887655.14379.5438309391409890693@ietfa.amsl.com> <80F3F8A2-2C3C-4DE8-BD1D-07842F5B2F89@apple.com> <20210715154649.GD24216@faui48e.informatik.uni-erlangen.de> <5149e82e-4f98-411b-9e34-27f243352b95@www.fastmail.com> <a2a718ba-7231-449f-8a55-fcc6a7823d59@www.fastmail.com> <20210716231731.GR24216@faui48e.informatik.uni-erlangen.de> <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9a5eec9d-90ae-ffd3-fc83-00e3800d7f9c@gmail.com>
Date: Mon, 19 Jul 2021 13:54:13 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <01832870-dfe9-42c8-b10f-d22169b94096@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/kws4AjMrecDIPljaWQHl_vt7UUM>
Subject: Re: [Edm] Please review draft-iab-use-it-or-lose-it-01
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2021 01:54:26 -0000

Martin,

> The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate.

Not really. That's what Router Alert is all about. I'm saying it is much of a success, but it recognized from the start that not all routers are equal.

The ineffectiveness of both RFC2113 and RFC2711 illustrates that there is fundamentally no difference between IPv4 Options and IPv6 Extension Headers in this respect. The network is equally ossified and opaque to new ones in both cases.

Here is some of the recent debris from this problem:

draft-eastlake-6man-hide-options-00
draft-peng-v6ops-hbh-04
draft-herbert-6man-eh-limits-00
draft-ietf-v6ops-ipv6-ehs-packet-drops-08
draft-ietf-opsec-ipv6-eh-filtering-08
draft-hinden-6man-hbh-processing-01

Regards
   Brian

On 19-Jul-21 12:03, Martin Thomson wrote:
> 
> 
> On Sat, Jul 17, 2021, at 08:37, Toerless Eckert wrote:
>> So put all the text about undesirable middleboxes into a separate section,
>> including the conclusions about encrypted protocols, because i don't
>> think the document has arguments about encryption applicable to b).
> 
> I just reviewed the document and while there is mention of the multi-participant problem in a few places, the only substantive pieces are a dedicated section on the subject (which I think is worthwhile) and a separate section that mentions cryptography as a means of controlling participation.  I think that it is OK as it is.
>  
>> I think you are contradicting yourself.
>>
>> Yes, the IP version field is indeed maybe the most easily reached
>> extension point across the examples given. And IMHO we do not
>> need to invent New IP Versions regularily just to keep the
>> extension point greased (although i think there are other good
>> reasons to do so, but thats a different discussion, happy to
>> point you to a draft of mine for that too if there is interest ;-).
>>
>> The example problem with the IP version extension point was
>> one of c) - unplanned middleboxes. 
> 
> Routers are not unexpected protocol participants in IP.  What was unexpected there was that routers were forwarding v6 packets without understanding any of their contents.
> 
> Maybe this is a problem with approaching it from the perspective of the number of participants.  The key point is that other participants might not allow extension, regardless of how many participants there are.  The corollary is that more participants increases the chances that extension is blocked by a participant.  The supporting observation is that sometimes there are more participants than you might have expected.
> 
> I think that's a clean argument construction.
> 
> The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate.  The >>2 corollary applies in full though.
> 
>> The more fundamental reason for this proposed characterization
>> of some metric for difficulty of extension points (depth inside
>> state machinery) is of course experience from testing suites and code
>> coverage measurements. The deeper the extension point in the state
>> machinery, the more code in the suite you need to get it covered.
> 
> I don't think that necessarily holds.  When we built QUIC, one of the most difficult pieces of code to build is the transport parameters.  It's right at the end of a long sequence of things that you need to get right with a bunch of interactions between encryption levels, transport stuff, TLS internals, and 0-RTT interactions.  It's about as deep in the state machine as I have ever experienced in building protocols.
> 
> QUIC transport parameters are nonetheless pretty completely reliable as a means of extending the protocol.  Maybe it's just because it is early days, but my belief is that it is the fact that we already have lots of uses of extensions that rely on them: https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry#quic-transport-parameters
> 
> On Sat, Jul 17, 2021, at 09:17, Toerless Eckert wrote:
>> On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote:
>>> Just one note.  Throughout you mention authentication where the draft uses the word "cryptography".  My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things.  Are you perhaps reading that word with the narrow meaning of "encryption"?
>>
>> https://en.wikipedia.org/wiki/Cryptography
>>   "More generally, cryptography is about constructing and analyzing protocols
>>    that prevent third parties or the public from reading private messages"
> 
> https://en.wiktionary.org/wiki/cryptography is a better match with my understanding:
> 
>> The discipline concerned with communication security (eg, confidentiality of messages, integrity of messages, sender authentication, non-repudiation of messages, and many other related issues), [...]
>