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
>