Hi Mark,
On 5/1/17 5:45 AM, Mark Nottingham wrote:
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.
What I'm becoming concerned about is us not talking about what we're
talking about. If encryption presents challenges in some deployments,
certainly one should say so. One should also say what workarounds are
available, and maybe even what challenges or complexities those
workarounds themselves introduce.
And so for instance:
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.
There are two key issues to DPI is intended to tackle:
* The ability to identify a class of traffic at all, perhaps without
so much as the benefit of fixed TCP/UDP port assignments, as is
often the case with media streams; and
* Trust between the end devices and the network administration, where
the administrator wants to know that a traffic class is used solely
for authorized purposes (e.g., nobody's prioritizing Age of Empires
by attempting to mimic an IP-based phone).
When encryption is present, the DPI fails. To remedy this there are
essentially four approaches:
1. Trust one of the endpoints, if possible, to report that the
communication is authentic and authorized;
2. Require that set-up of communications (such as a media streams)
occur through a trusted 3rd party that reports 5-tuple information
(including call completion);
3. Make do with what information can be gleaned outside the payload
(e.g., packet timing, sequencing, etc - so-called meta-information);
4. Give up.
I'm sure smarter people than me have come up with options 5, 6, etc, but
you get the idea.
The trust relationships have to be in place for options 1 or 2 to work,
and for the mobile operator use case that might be quite tricky.
Option 2 presents a state management issue, and may or may not incur a
latency penalty during setup. Both 1 and 2 have attendant complexity of
additional communication paths, but as they say, there ain't no such
thing as a free lunch, and that really is or should be the point of the
draft.
It may not be feasible to go into even this much detail in each case,
and we shouldn't require that, so long as the problem statement is well
supported.
This seems to be what you're looking for in the context of caching:
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.
I like the idea of examining the economic relationships between, say,
the end user's service provider and the end user, versus the end user
service provider and the content provider, etc., and where value might
be had with regard to those who have business relationships and those
who don't. Note the case where the user is an employee is different
than when the user is a service provider customer, the former of which
is discussed in Section 4.
One caution: this document risks turning into a tome if the discussion
goes too long. Better to be succinct and reference where one can.
Eliot
signature.asc
Description: OpenPGP digital signature