Sorry for the late review; on the plus side, I'm coming to it with fresh eyes.
Overall, this document reads as if it was originally written to highlight the
downsides of increased use of encryption, and then rewritten to be more neutral
in tone. Unfortunately, some of the original intent posited there still seeps
through.
In doing so, it often fails to convey that there are any options other than
"this has to be done by the network." I know that this has been cast as a
survey of potential impacts, and therefore doesn't necessary need to enumerate
alternatives, but the way that it's written could easily lead a reader to think
that there aren't alternatives. It also is odd that alternatives are not
enumerated when they're often well-known, and the really interesting issues are
in the tradeoffs between doing something in the network (i.e., as a third
party) vs. by one of the endpoints (a first party to communication) or their
delegates.
For example, Section 2.2 talks about the importance of passive monitoring for
traffic surveys, but fails to discuss alternative means of gathering data
(e.g., anonymised data from content providers; telemetry from client
implementations) that are superior in some ways, limited in others. It would be
a useful contribution to characterise the tradeoffs here, so this is an
opportunity lost.
Section 2.3.2.1 points out that "Web proxies are widely used", but fails to
note that the vast bulk of caching is done by endpoints -- browsers, CDNs and
reverse proxies, thereby sidestepping the issues of encryption (although they
have their own unique challenges). Discussing why this form of caching has
become prevalent might help inform network operators as to why getting the
economics and trust relationships of intermediation right is important.
Section 2.3.2.2 motivates DPI as "Input for Differential Treatment", but fails
to note the developing efforts to coordinate client and server behaviour to
adapt to network conditions, without the need for stripping encryption.
Section 2.4 talks about need for compression proxies, but fails to note the
deployment of them in overlay networks (e.g., by Google Chrome, UCBrowser,
Opera Mini, etc.). There is a minefield of issues surrounding them, of course,
but it's useful context.
Section 2.5.2 does note that endpoint-based alternatives might be possible, but
fizzles out after that. Exploring why they haven't developed would be a
substantial contribution.
A few additional points:
* The Introduction says "it is important to catalog existing standard functions
around network management, security and troubleshooting that have depending
upon the availability of open information to function." Using the word
"standard" here is misleading; some of the described functions are not
envisioned or enshrined by Internet Standards.
* The Introduction says "The IETF reiterates its view that pervasive monitoring
is an attack..." It's odd to have an Informational document "reiterate" a BCP.
* Much of the Introduction motivates this document as being about "network
management, security and troubleshooting." Then, later, it inserts things like
"monitoring services", policy enforcement, and parental controls. These are
qualitatively very different things. Being able to monitor and run the network
to provide a service is not the same as being able to impose your will upon the
users of that service. Elevating the latter to the status of the former is not
something we should even unintentionally imply, even if it is common practice.
* Section 1.1 asserts that "Increased use of encryption (either opportunistic
or authenticated) will impact operations for security and network management,
causing a shift in how these functions are performed." This is an assertion
about the future that's quite strong. I could see it saying that they *have*
impacted, and then giving examples, or that they *might* impact them in the
future, but asserting that it *will* impact them seems like an assertion that
doesn't have IETF consensus.
* Section 2.6.5 talks about injecting HTTP headers into a connection and fails
to note the significant privacy issues brought about by this practice. Using
encryption to defeat this is, to many in the IETF community, a feature, not a
bug.
Hope this helps,
--
Mark Nottingham https://www.mnot.net/