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

[Paul Vixie <[e-mail]>]

On Wed, Mar 17, 2021 at 03:27:29AM +0000, Stephen Farrell wrote:
> 
> Hiya,
> 
> A question (*)...
> 
> On 17/03/2021 02:58, Paul Vixie wrote:
> > generally speaking, ...
> 
> Don't you think that ossification due to often not-often
> updated middleboxes has an effect on interoperability? I
> thought that was a more-or-less accepted proposition, but
> perhaps it's not.

it is. but not all continuity is ossification. sometimes things work the
way they should, or at least work the way people who making informed choices
have deliberately chosen. (even if that "way" happens to have continuity.)

> ISTM if one does accept an "aged middlebox breaks things"
> argument, then "interference by on-path actors" is clearly
> one of the barriers to interoperability we face.

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.

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."

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.

> (*) To be honest, mine is maybe as loaded a question as if I'd described
> things as "full-throated" or wondered about flying pigs etc. But FWIW, I
> don't mind a bit of rhetoric at all:-)

thanks for this, too. i don't aim for outlandishness; it simply finds me.

-- 
Paul Vixie