Subject: [Add] ADD State of Things Observations

From: "Deen, Glenn" <[email-masked]>
Date: Wed, 14 Oct 2020 19:56:35 +0000

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/

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 15 Oct 2020 10:11:46 +0100

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=
[email-masked]> 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.
>
>
>
> ---
>
>
>
> 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.
>
>
>
> (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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> 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/
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 15 Oct 2020 15:16:22 +0000

Chris,

Thanks for the comment.

I meant the proposed complexity grouping as starting points, but if it’s possible to merge RFC1918/CPE with a less complex case that’s very nice.  There do remain other complex environments that won’t be as easy.   Ultimately such lines are drawn are drawn by  authors and the WG group so we choose to draw as appropriate.

Regardless of where the lines are drawn, for now do people feel the general observations around complexity and path proposed to be reasonable?

Glenn

________________________________
From: Chris Box (BT) <[email-masked]>
Sent: Thursday, October 15, 2020 2:12 AM
To: Deen, Glenn
Cc: ADD Mailing list
Subject: Re: [Add] ADD State of Things Observations

Glenn,

I'm happy with the general principle of splitting into 2 or 3 areas and working on those in parallel.

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

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Oct 2020 20:06:18 +0000

Glenn
The approach you’ve suggested seems like a reasonable way forward, especially if the split is along the lines suggested by Chris.  Ideally we’d first flesh out the user requirements a little more and then have the WG adopt the document so that there is an agreed record of the use cases and associated requirements that we’re aiming to solve.

Andrew

From: Deen, Glenn <[email-masked]>
Sent: 15 October 2020 16:16
To: ADD Mailing list <[email-masked]>
Subject: Re: [Add] ADD State of Things Observations

Chris,

Thanks for the comment.

Glenn

________________________________
From: Chris Box (BT) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 15, 2020 2:12 AM
To: Deen, Glenn
Cc: ADD Mailing list
Subject: Re: [Add] ADD State of Things Observations

Glenn,

In fact as Martin said:

Chris

---

From: Joey S <[email-masked]>
Date: Wed, 21 Oct 2020 18:14:28 -0600

do people feel the
general observations around complexity and path proposed to be
reasonable?

Yes. Adding to what Andrew said, defining pending input in the
narrative and requirements sections of the draft will be helpful in
further clearing the division line in complexity first and later
correlating that to the deployment scale of specific scenarios
if/when needed.

This could also help in avoiding fragmenting the scope of the 2-3
groups too much so we don't go back to a need for consolidation like
we had during the previous IETF meeting.

--
Joey

On 10/15/2020 2:06 PM, Andrew Campling
wrote:

Glenn

The
approach you’ve suggested seems like a reasonable way
forward, especially if the split is along the lines
suggested by Chris.  Ideally we’d first flesh out the user
requirements a little more and then have the WG adopt the
document so that there is an agreed record of the use cases
and associated requirements that we’re aiming to solve.

Andrew

Subject: Re: [Add] ADD State of Things
Observations

Chris,

Thanks for the
comment.

I meant the
proposed complexity grouping as starting points, but
if it’s possible to merge RFC1918/CPE with a less
complex case that’s very nice.  There do remain other
complex environments that won’t be as easy.
Ultimately such lines are drawn are drawn by  authors
and the WG group so we choose to draw as appropriate.

Regardless of
where the lines are drawn, for now do people feel the
general observations around complexity and path
proposed to be reasonable?

Glenn

To: Deen, Glenn

Cc: ADD Mailing list

Subject: Re: [Add] ADD State of Things
Observations

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