Re: [Add] ADD State of Things Observations
"Chris Box (BT)" <chris.box.ietf@gmail.com> Thu, 15 October 2020 09:12 UTC
Return-Path: <chris.box.ietf@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316253A138A for <add@ietfa.amsl.com>; Thu, 15 Oct 2020 02:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 YHJ3ee4_QZgJ for <add@ietfa.amsl.com>; Thu, 15 Oct 2020 02:11:58 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 4B1DA3A1389 for <add@ietf.org>; Thu, 15 Oct 2020 02:11:58 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id 188so1751438qkk.12 for <add@ietf.org>; Thu, 15 Oct 2020 02:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EfGNFOqEYc0xDoNkSg9ksdmWCwBcFKGFgsO44+otoJk=; b=uUK8Lx/NK2VvPFmv+g/WUM+KWKzjBfn2Lx4kpfIxaOm6D1vpXkr8as5QAxWZ0aKK7H iCdrbpHN6BPO45y6sK69moCvNEX0/paeR1+M4YAY5rSwa/QMVqmGenJdWQDROJmkybvm 34RKWoi3RR5AMtcBhw1vnM/8UMJNkaB8goZlvTUETFGxOTWwDiknkCLYomlk/jxRH0n3 kKuSQ2AFDY2O6OL0LxeDUVQn1fMGDRUU72Kua9KLmfBMHI4RUlzT9u5zgH752iq8kvSt 92JHgKkn4yuTK79vMF934I8xAbPlR20sW0qWkROIoOauC0GV5C+cT20l+NKSHrQsLEAz pAZA==
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; bh=EfGNFOqEYc0xDoNkSg9ksdmWCwBcFKGFgsO44+otoJk=; b=ail50nm2OmEo4rYUgdLb/iXcyVMWlenvtOPBR+C2wFyz6hqDJ/HUzlSA3IxNBkZ/U7 ahqQ3XiAmGIRjrVljmwnOn2PXYOTSyQekaiddfxS81QJwHMPIMeESd1Dc10SJgmI9wRq n9bYM/V1uiFDEAcd8mOajY166lIoD2iDcI2JOU+XuTr+6Z4ZumpiejIsNNlLt5sTz4Au cGkX1OHJ0er3U9TKgbnFtUquXEh3CWmOZymtJHTfnNayBiXS3bJD44sWAz0B721EHTBX it0MTBdQvuXztipX8XBGy9tRCuTKQV8R5qVOwDqy0rbfqATrD3LLPVkK84rO0Vd7AjRx ZYqQ==
X-Gm-Message-State: AOAM531nXsME3B6OEG0Jxdr7E60N9WG2rC+7RqISAF6MBtP8ZBVnQJv7 SdcJ41XZnfTBzwYhM5BddGxLqZYBJ2FJhXJ6VXo9Dlwuqv4=
X-Google-Smtp-Source: ABdhPJwsDsuWfAUFAzJDKFCB+IVc4vt5T+ljQmTOQuiI3bVru1guNrKhAQ+Z/gnNMjr4vCwYAfl1QZDiTM9CiXCFzJc=
X-Received: by 2002:a05:620a:224:: with SMTP id u4mr2844561qkm.431.1602753117125; Thu, 15 Oct 2020 02:11:57 -0700 (PDT)
MIME-Version: 1.0
References: <22A74993-38FD-4A59-BFAF-4917ABEFC2CB@comcast.com>
In-Reply-To: <22A74993-38FD-4A59-BFAF-4917ABEFC2CB@comcast.com>
From: "Chris Box (BT)" <chris.box.ietf@gmail.com>
Date: Thu, 15 Oct 2020 10:11:46 +0100
Message-ID: <CACJ6M14+t3b_sWWC9+SxvdCADBtdbNVAxZ4TgpWMj7cpHJP32g@mail.gmail.com>
To: "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035a24105b1b20a84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/vws97IHMycCmx5JVbdDBotDuuP8>
Subject: Re: [Add] ADD State of Things Observations
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 09:12:01 -0000
Glenn, I'm happy with the general principle of splitting into 2 or 3 areas and working on those in parallel. But I'm not entirely sure I agree with where you've drawn the distinction. (1) Low-complexity environments. – this would include the case that > started the “My single use case” thread > > > > (2) High-complexity environments – this would include the RFC1918 > situations, networks with more advanced technical controls, > networks/devices with applied policy controls. > I would see RFC1918-addressed forwarders as very much in the scope of "My single use case". In fact as Martin said: > This might need the full matrix of DoT/DoH, v4/v6, with/without a > forwarder, but this is fundamentally just a single use case. > As others have said, such non-upgradeable forwarders are so common that any "tell me how to contact your encrypted version" protocol will need to deal with them. Likewise, a consequence of selecting the network's recommended encrypted resolver is that network-applied policy controls may be in scope. So they are not solely found in "high-complexity environments". But I do agree that it is useful to separate out such more complex items as Enterprise, and the provision of useful information about each possible resolver, such that the client can make a more informed decision if it wishes to. Chris On Wed, 14 Oct 2020 at 20:57, Deen, Glenn <Glenn_Deen= 40comcast.com@dmarc.ietf.org> wrote: > Disclaimer: I’ve discussed the following with my co-chair and our AD for > a sanity check, but if in the end if you don’t like it please send the hate > mail to me as David and Barry are both innocent. > > > > --- > > > > ADD State of Things Observations > > > > Wearing my ADD co-chair hat, I’ve been thinking about the discussion had > during the Sept 10th [1] and Sept 15 [2] Interims, and the subsequent list > thread “My single use case” [3] and the current draft-box-add-requirements > [4] and it seems that there may be emerging two classes of Discovery > situations that the group is discussing that are based on the complexity of > the environment that the client is in. > > > > I’ll expand on what I mean by complexity father down in this note, but > for now the two classes are: > > > > (1) Low-complexity environments. – this would include the case that > started the “My single use case” thread > > > > (2) High-complexity environments – this would include the RFC1918 > situations, networks with more advanced technical controls, > networks/devices with applied policy controls. > > > > > > Complexity > > -------------- > > > > I call this differentiation Complexity because at the heart of the > discussions it seems that it is the number different factors which need to > be satisfied that emerges in the discussions and that these factors aren't > simply classified in to distinct buckets that can be individually satisfied > without consideration of other factors in other buckets. > > > > Throughout various drafts, threads, and discussions the group has had a > variety of operational and technical factors raised from a variety of > situations. > > > > Some factors have been operating in RFC1918 networks with CPE devices that > use stub-resolvers; Other factors have been concerns about network or > device configuration requirements set by secured networks or devices; While > other factors have considered the desire to be able to group associated > resolvers together either by being operated by the same org, or by having > the same policy set, or by same behavior set; Others have been how to > operate in captive portal environments; .... and the list goes on. > > > > This list can of course can contain complexities from the threat level of > the environment or the device itself that could be considered. > > > > The presence of such a wide variety of factors increases the complexity > that a discovery mechanism needs to operating in, and in turn the > complexity of the discovery mechanism itself. > > > > Complexity is not a fixed thing - it is a spectrum of levels from very > simple environments, to more complex environments such as the RFC1918/CPE > situation, through to tightly managed situations, and even to very secured > networks/devices. > > > > > > Where we seem to be at > > --------------------------------- > > > > That has led to a bifurcation that is well captured when you take into > account the discussing in the "My single use case" thread, and the > different breakdown of situations listed in draft-box-add-requirements. > The group has members with interest in working of discovery in difference > levels of complexity. > > > > We also have a couple of deployed, but not necessarily > scalable, approaches being used today by Firefox, Chrome, Microsoft, and > Apple that currently are could be classified as simplistic versions of how > you approach the discovery problem in the least-possible complex > environments. A good example of this is documented in > draft-rescorla-doh-cdisco [5]. > > > > Recognizing that the complexity is a spectrum ranging from low-complexity, > to mid-tired, to high-complexity it occurs to me that a path ahead maybe to > recognize this aspect and instead of fighting it - incorporate it into the > WG group's approach, and not to try to have one answer that works > everywhere. > > > > To that end I'd like to propose the following: > > > > (1) To the authors of Draft-box-add-requirements: > > > > Draft-box-add-requirements details different environments, but it does so > from a perspective of listing each environment and the requirement that is > then needed. Based on comments at the Sept 10th Interim, some > participants took it to a an attempt to create an aggregated list of > requirements that any ADD Discovery solution would need to satisfy, with of > course the entirely reasonable reaction from many that such a list of MUST > requirements would be boiling the ocean and would potentially ignore that > the lower handing fruit of the very low complexity environments. I don' > think that it was the intent of the draft authors to create an > all-encompassing list of MUST requirements. > > > > To that end, I would like to suggest to the draft-add-box-requirements > authors (and anyone who'd like to help them) to update the draft with the > technical feedback they received from the Sept 10 Interim, and to attempt > to restructure the document and its requirements around the ideas of > complexity of the discovery environment, and the second idea that while the > document captures requirements that exist in a variety of increasingly > complex environments. These higher complex requirements don't all need to > be addressed in the output of ADD for ADD meet the needs of the > environments with the highest demand. > > > > The resulting new document would start with looking at low complexity > environments and work up to higher complexity environments, with the > requirements not being a set list of must-meet requirements, but instead a > capturing for reference the spectrum of discovery situations that exist in > the deployment land scape, with a recognition that there may be discovery > methods which only work in the lower complexity ranges. It would also > attempt to document the environmental complexities as it identifies > requirements. > > > > (2) To the working group/other document authors > > > > If we view the landscape of discovery mechanisms as working within > particular ranges of complexity, can we begin to recognize that aspect in > the various draft approaches that have been put forward ? > > > > This would in practical terms end up with proposals that are specifically > targeted at different levels of complexity. A discovery mechanism proposal > would identify and declare the level of complexity and any specific > environmental complexities that it is intended to operate in as part of the > draft. > > > > I'm not suggesting that the ADD group try to produce distinct and unique > discovery approaches for every possible environment. Practically speaking > there seems to be a few - perhaps as little as 2 or 3 - specific levels of > complexity that group participants have brought up repeatedly over > time. If we accept that a single solution may not fit all situations, > then the group can perhaps organically focus its work around the simple > low-complexity case, and around 1 or 2 other specific complexities. > After all the output of ADD is entirely dependent on the group's > participants coming together to work on the aspects that they rate as > important to put their effort into. > > > > Of course it would be nice if there was some commonality in how things > work, and hopefully that is something that can come about by having the > work commonly done in the same group, but it seems that recognizing that > there are different levels of complexity that need solutions can be an > important step. > > > > (3) Form tiger/design teams to work on this > > > > There’s already a number of good proposals that cover discovery from a > couple of different approaches, and we’ve heard from many of them in WG > sessions. With those ideas as seeds, and with the discussions the group > has had now would be a good point to create design teams to work together > and come back with proposals for the different complexity situations. > For a start I would propose a group that will focus on the low-complexity > environment and second group that would focus on the RFC1918/CPE Stub > resolver environment. If there is a third one it likely would be > set-policy/enterprise discovery, which could over a broad variety of > environments beyond enterprise. > > > > > > It's up to the ADD group members > > -------------------------------------------- > > > > In the end the ADD group will go in the direction the group participants > want it to go in. So please share your thoughts on the above approaches > to the ADD mailing list. Is this a workable approach? > > > > > > Regards > > Glenn Deen, ADD co-chair > > > > > > > > ---- > > References: > > > > [1] > https://datatracker.ietf.org/doc/minutes-interim-2020-add-01-202009101300/ > > [2] > https://datatracker.ietf.org/doc/minutes-interim-2020-add-02-202009151300/ > > [3] https://mailarchive.ietf.org/arch/msg/add/IiYpAQ0ujdp0mlUzi1YB2cYYMT8/ > > [4] https://datatracker.ietf.org/doc/draft-box-add-requirements/ > > [5] https://datatracker.ietf.org/doc/draft-rescorla-doh-cdisco/ > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add >
- [Add] ADD State of Things Observations Deen, Glenn
- Re: [Add] ADD State of Things Observations Chris Box (BT)
- Re: [Add] ADD State of Things Observations Deen, Glenn
- Re: [Add] ADD State of Things Observations Andrew Campling
- Re: [Add] ADD State of Things Observations Joey S