Re: Comments on draft-mm-wg-effect-encrypt-11

[Eliot Lear <lear@xxxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature