Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"

[Brian Trammell (IETF) <[e-mail]>]

Hi Mark, all,

Quoting below for emphasis.

> On 14 Nov 2019, at 00:37, Mark Nottingham <[e-mail]> wrote:
> 
> There are user-centred arguments as to why it's necessary to impose that policy at the network level (eg., lack of interfaces to configure IoT devices), but let's not start from the assumption that the best place to interpose those services is by having the network transparently handle them, just because that's how it's been done before.

This, a few hundred times.

We've tried transparent network functions of various forms; for the most part, they either work while irretrievably changing the architecture (e.g. NAT have moved the network/transport layer header boundary to include the transport port numbers), or they tend only to work in a restricted set of environments (which may or may not be the environments the functions are sold to work in, but that's a different rant).

> Let's also not assume that obtaining consent explicitly from the user to interpose those services is easy or without risks of various sorts; we have lots of examples where allowing random devices on networks to ask permission to do things ended up badly.

In a cleaner architectural environment, we could move some of these functions to the endpoints (e.g., replacing in-network TCP enhancement with, well, better TCP stacks, which is largely what has happened in server and end-user platforms space over the past couple of decades), and transmute the rest into network functions deployed transparently, where the function's presence is explicit, and ideally exposed to the endpoint in such a way that the endpoint can negotiate with it.

Of course, as you say, the gap between transparency to the network/transport endpoint and informed user consent is a large one. But it'd be nice if we could work on solving that problem, as opposed to pretending that the accidental situation we find ourselves in with a network cluttered with functions that try and fail to be transparent is somehow essential to the Internet architecture, and argue about how best to maintain that situation.

It's also not lost on me that "user consent" is a slippery beast for functions (lawful intercept) where asking for consent is antithetical to the function at hand. In these situations, consent is given by a third party, generally someone from the judiciary in common law jurisdictions. But control over who gives consent is key to how the function is used and misused even in the most pervasive cases.

What the IAB is trying to do with this statement (IMHO) is to try to separate these threads. The way most of these functions are built tends to break things that are well outside the scope of the desired function, without an analysis of the tradeoffs involved. Without discussion of these tradeoffs, an informed discussion of the pros and cons of any given in-network function is not really possible. Hence "avoiding *unintended* harm".

Cheers,

Brian