Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

[Victor Kuarsingh <[e-mail]>]

On Wed, Mar 17, 2021 at 3:22 AM Paul Vixie <[e-mail]> wrote:

> On Wed, Mar 17, 2021 at 03:27:29AM +0000, Stephen Farrell wrote:
>



> it sometimes is, but sometimes is not. consider for example a firewall, by
> which a network administrator might qualify as an on-path interferer. that
> certainly breaks some stuff, but it's not a form of non-interoperability --
> it's a form of policy. and if the firewall operator has obligations to the
> server operators or to the end users which obligations do require that
> policy, then i think their policies should not be trivially dismissed.
>

This is an important point that I think may be lost in some conversations.
Many of the
obligations are based on a number of potential factors including corporate
policy, regulatory,
service provider contractual / service terms and end user (e.g. parents)
needs.

In each of those cases, the point of policy control is with party that has
the obligation or whom they
have directly delegated the responsibility.   Also, often times these
obligations are based on where
you are physically (which building/location,country, etc) and not based on
what service you are trying
to reach or use.

Examples of obligations: (1) obligations on protecting privacy data under
GDPR, (2) corporate policy limiting
what a user can reach/do based on employment terms and conditions.


>
> DoH as an example deliberately and intentionally prohibits firewalls from
> restricting or obstructing off-network RDNS. it says so on page 1 of the
> RFC -- they don't try to hide it. those of us figuring out how to cope
> with a world where firewalls are deliberately and intentionally prohibited
> by IETF protocol standards action may ask for some new signaling to support
> our (continuing) obligations.
>
> > (At the same time, I do not claim all interference by on-path actors
> > is "bad" - there are some benefits to firewalls, even if those also
> > often become brittle, e.g. due to out-dated configs.)
>
> thanks for this. to me the foundational principle is that networks have
> "policy autonomy" and if operators screw things up, they have themselves
> to blame and their employees, customers, or families can blame them also.
> to be clear, this means there is no "but", no exception whereby well
> meaning software suppliers or internet protocol designers can say "yes,
> it's your network, but we can't allow you to set policy for it."
>

In line with this and my response higher up in the chain, enforcement of
policy is important.
The other point in her is the route to escalation and resolution.

No matter what is built and/or created, there is a non-trivial amount of
support required
to resolve issues inherent in technology and deployments.  Operators,
enterprises are filled
with support teams who respond to customer/user issues and are held
accountable to resolve
problems.   Having needed tooling and a working support stratum is
essential to delivering service to users.


> however, i lost that argument, so now i'm just trying to limit the damage,
> which is why i'm asking for a policy signal path whereby any device which
> does not obey the local network's policy can be presumed hostile to that
> policy -- ignorance won't be an excuse. i've already removed all mozilla
> corporation software from my networks on the basis of their DoH theatrics,
> but there will be others who don't believe that on my network, my rules
> actually matter.
>

Seems reasonable in that is attempts to remove breakage while addressing
the requirement stated (network/administrator policy).


>
>
>
> --
> Paul Vixie
>

regards,

Victor K



>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>