BoR PC10 (19) 50

Comments on BEREC’s update on Open Internet Guidelines Yiannis Yiakoumis, Nick McKeown (Selfie Networks and ) [email protected] / [email protected]

Dear BEREC officials,

Re: Net neutrality guidelines

We are Internet researchers and practitioners, having built multiple successful companies in the networking industry, and done research at the Computer Science and Electrical Engineering departments at Stanford University, California, USA. Our research work is well-known for its positive impact on the way wired and wireless networks are built.* We have been working on net neutrality (and the implications on network infrastructure) over the last 6 years, both as researchers at Stanford as well as co-founders at Selfie Networks, a technology company working with CAPs and ISPs to enable traffic differentiation in the presence of net neutrality. As part of our company we have been involved with tens of zero-rating programs worldwide, both from the perspective of CAPs and mobile operators.

We are writing to share some of our findings with you, in the hope that our ideas will be useful in your deliberations. In case it is relevant, two of us are EU citizens.

1. Overview of our submission

In its consultation document, BEREC seeks feedback on sections 69 and 70, and in particular whether transport layer payload (and in particular domain) inspection should be acceptable as a means to enable traffic differentiation for billing and more generally traffic differentiation purposes.

First off, we are glad to see that BEREC considers the implications of the mechanisms used for traffic differentiation and seeks stakeholder feedback. The questions in the consultation document highlight real challenges and limitations of operating traffic differentiation in an open way that respects user privacy. In our experience, the existing means for traffic differentiation (inspection of IP addresses and domain names to identify a specific service) is problematic, and the root cause behind several limitations of existing and future traffic differentiation services (both with regards to violation of user privacy and the openness of relevant programs).

At the same time, a demarcation of what operators can (or cannot) do based on network layers is not the right solution, as it makes it much harder for end users (CAPs and/or individuals) to leverage the capabilities of traffic differentiation services, hinders upcoming alternatives to DPI, and doesn’t address the real issues.

We feel that the current debate and wording tries to strike a balance between openness and privacy concerns, using technical mechanisms (IP and domain-based traffic detection) that are fundamentally insufficient to do either of them. Instead, we think that the guidelines should be more forward-looking, define ​ high-level principles and requirements commonly used for privacy-specific matters (like user consent, revocability, and control over what information is shared), and encourage the industry to adopt and develop alternatives to meet these requirements.

We believe timing is good to push for new and better DPI alternatives, and BEREC can be instrumental to support such a change. The existing DPI-based approach for traffic differentiation has certain limitations, and most stakeholders ( operators and CAPs ) realize the shortcomings and challenges associated with it. New

standards that encrypt both DNS and SNI information gain industry traction and will turn existing traffic detection methods obsolete.

Along these lines, we offer one alternative mechanism called "Network Cookies" - an open, secure and generic way that differentiates traffic while respecting user privacy. We believe there are many similar ways to accomplish these goals, and we propose Network Cookies as an indication that this is technically feasible, and economically practical. We make Network Cookies openly available and free, and are in the process to standardize it.

In the following sections we share our thoughts, drawing from multiple years of research work on this topic as well as practical experience driving tens of zero-rating integrations between CAPs and mobile operators in Europe and worldwide.

2. What is the problem with (Deep) Packet Inspection

(Deep) Packet Inspection is the de-facto approach used today for zero-rating. In this approach the network inspects ​ ​ all traffic and compares it with predefined application-specific signatures. The results of traffic inspection are used for different purposes (overall usage analytics, identify new applications that are popular with users, build rich user profiles to improve marketing and targeting, differentiate traffic for zero-rating or QoS).

While most DPI appliances come with a pre-installed set of application signatures (that involve the use of IP addresses, domain names, SSL certificates, traffic patterns, etc), these are not trusted for zero-rating purposes, as they are often inaccurate and slow to adopt changes, which lead to disruptions and erroneous user charges. All mobile operators we are aware of (contractually) require CAPs to provide them with an up-to-date list of domain names and/or IP addresses to configure their network, and give them advance notice when these domains/IP addresses change.

When it comes to usage of domain names vs IP addresses, most CAPs prefer to use domain names. We’ve been involved in cases where mobile operators required use of IP addresses to perform zero-rating, and CAPs were not able to conform to this requirement. There are multiple reasons for that:

● For a given CAP, domain names are way less than IP addresses used, and change less frequently, which makes it simpler to keep up-to-date and in-sync with mobile operators partners ● A big part of the content is hosted in CDNs and cloud-based services, where the same servers are used by multiple CAPs to host their content. Depending on the hosting platform, use of dedicated IP addresses might not be supported at all (e.g., Akamai CDN), or it is available at a significant extra cost (AWS CloudFront).

Despite being the de-facto solution, DPI has some serious limitations both with respect to end-user privacy as well as pricing transparency and openness of existing programs.

Domain names are not generic content: The list of domain names visited by an individual user contain sensitive ​ personal information that can be used to create rich profiles of user preferences. Even when traffic is encrypted through SSL/TLS, the list of recent domains a user visited, one can infer things like her political orientation, sexual preferences, medical conditions, entertainment habits, etc. As such, we believe that casting domain names as generic content that can be monitored freely is not aligned with efforts to preserve user privacy.

No User Consent : Network operators inspect all traffic that comes throughout the network, without users ever giving ​ consent, or being able to revoke such consent.

All or Nothing : for DPI to work, network operators need to monitor all traffic (and all domains) a user is using. If a ​ user signs-up for a music zero-rating program, the network operators will still have to monitor all news, video, games, and any other site this user visits. Even if an operator agrees to monitor traffic only for users that sign-up for zero-rating programs, these users have no control over what information they share: they have to share all their internet activity.

Inaccurate and operationally inefficient: DPI is fundamentally inaccurate when zero-rating today’s applications and ​ this undermines openness and transparency of traffic differentiation programs. Most applications use third-party services (and therefore generate third-party traffic), while changes to IP addresses and domains are frequent and not well communicated between app providers and mobile operators. Because DPI cannot map all traffic to the application under consideration, it cannot zero-rate it. These inaccuracies often lead to unintended charges for users (a common scenario that causes user complaints), or introduces barriers for CAPs to participate in such programs (when they cannot meet a certain accuracy threshold). Overall, such inaccuracies add overhead to mobile operators when dealing with app providers, which eventually limit the openness of such programs.

3. Transport Layer Payload is not “specific content”

The existing guidelines attempt to use network layers to separate what is specific content and what not. We believe this is problematic and insufficient for two reasons:

● Limiting traffic differentiation in the IP protocol will dramatically affect the openness of such programs and increase barriers to entry. As we already explained earlier most CAPs use public cloud infrastructure, do not have dedicated IP addresses and therefore won’t be able to comfort to this. This will limit CAPs that can leverage such programs to a handful of companies that have their own infrastructure (Google, Netflix, Facebook), or are willing to have tight and heavyweight integration with mobile operators and their infrastructure. In a discussion with stakeholders, the use of DiffServ bits in the IP header was brought up as a way to circumvent this problem. Unfortunately, DiffServ bits are not used in practice for security reasons, as they can easily be spoofed and abused. Its use is limited to enterprise settings where one entity has full control of all endpoints and the network. ● Preventing use of transport layer payload for traffic differentiation hinders new technologies that can better serve traffic differentiation while respecting user privacy. One of the most common places to introduce new network functionality are TLS extensions, an extendable header field in the TLS protocol that has been used ​ ​ to introduce several new methods on how to protect and communicate user context from/to third-parties. Our Network Cookies protocol uses TLS extensions to enable CAPs and individual end users explicitly share context with a mobile operator in a trusted and secure way. Encrypted SNI (ESNI) uses TLS extensions to encrypt SNI and domain names all together from the network. Preventing use of transport layer payload for traffic differentiation will block existing and future ideas that can dramatically improve the status quo.

4. How to ensure that user privacy is protected on traffic differentiation services?

We believe that user privacy is not protected by banning any scenario where network operators get access to a user’s specific content, but instead, by giving users control on what information to share and when. Standard rules used in similar services are explicit user consent, revocability, and limiting the information to the bare minimum required to offer a service, To make our point clear, we provide below a rewrite of sections 69 and 70 with relevant language.

69. In assessing traffic management measures, NRAs should ensure that such measures do not monitor the specific content (e.g. domains visited by a user).

70. If access to specific content is necessary in order to provide a service (e.g., to access a zero-rating program), users should be informed about the information monitored by the operator, explicitly give their consent, and be able to revoke it. Access to specific content should be limited only to the necessary information, and not cover all the traffic of an individual user.

By focusing on privacy principles, NRAs can use the experience learned from GDPR and relevant best practices around privacy. They can also embrace technical developments outside BEREC’s Open Internet Guidelines that prevent unintentional leakage and monitoring of domain names. Two such protocols that gain wide industry traction are DNS over HTTPS (DoH) that encrypts DNS requests, and Encrypted SNI which encrypts the SNI field that is used in most zero-rating programs today. Both of these protocols are backed by companies like Google, Apple, Cloudflare, Akamai, Firefox, Comcast, and several others, are already available to end users, and can potentially prevent monitoring of specific user content unless there is explicit user consent.

5. Are there technical simple and economically viable ways to differentiate traffic while preserving user privacy and openness of such programs?

We developed a simple, universal solution to allow end-users (iindividual and/or CAPs) and ISPs to reliably identify services and the network treatment (in terms of pricing and/or QoS) they should receive. We call it Network Cookies.

A network cookie is like a postage stamp: The end-user is given cookies that they can attach to their traffic. A cookie indicates to the network how the traffic is to be treated (e.g., "low jitter" or much more complex policies like "this is zero-rated"). End users obtain cookies in advance from their ISP. They are secure (they can't be used by anyone else), simple (they can easily be processed by gateways in the network and mapped to existing QoS and billing mechanisms in the network), they are revocable (if a user misuses cookies or if they expire, they can be revoked), and they respect user privacy (users don’t have to tell their ISP which traffic they want to prioritize or zero-rate).

Cookies remove technical barriers and make the process of adding content to commercial programs straightforward—all an ISP has to do is give a content provider a cookie. To build a category-based service, ISPs will just have to give corresponding cookies to any eligible CAP. Since this is simple and straight-forward, BEREC and NRAs can easily audit services under question just by monitoring who gets cookies and how, and also require that each eligible request gets fulfilled within a predefined time period. We have implemented network cookies in multiple networking platforms and currently are in the process to standardize them.

To be clear, we do not suggest that BEREC adopts the use of Network Cookies. We just provide evidence that our proposed policies are technically and economically viable, and propose one way for this to happen. To encourage and help others, we make the technical details for network cookies publicly available and open-sourced [1]. We are confident that there are different means to combine traffic differentiation with user privacy. Protocols like DoH and ESNI that make all traffic opaque, can be modified to give users the option to share content on-demand with operators only when needed.

Sincerely, Yiannis Yiakoumis Nick McKeown

[1] Yiannis Yiakoumis, Sachin Katti, Nick McKeown, Neutral Net Neutrality, ACM Sigcomm 2016, Florianopolis, ​ ​ ​ Brazil. Available at http://yuba.stanford.edu/~yiannis/neutral-net-neutrality.pdf [2] Yiannis Yiakoumis, What is wrong with zero-rating and how to fix it. Available at ​ ​ ​ http://yuba.stanford.edu/~yiannis/zero-rating-medium.html

(*) Biographies:

Dr Yiannis Yiakoumis is a co-founder and CEO at Selfie Networks. He received his PhD in EE from Stanford University in 2016, where he worked with Nick McKeown and Sachin Katti. His dissertation research focused on how to enable users to express their preferences to the network and customize it for their own needs. His research interests include software defined networks (SDN), wireless and home networks, and the interactions between networks, users, and network policy regulation. He has worked for Philips Research, Juniper Networks and Google, and his work has been incorporated in Juniper's SDN products and Google's OnHub home router. He holds a Diploma in Electrical Engineering from University of Patras, Greece.

Professor Nick McKeown (PhD/MS UC Berkeley ’95/’92; B.E Univ. of Leeds, ’86) is the Kleiner Perkins, Mayfield and Sequoia Professor of Electrical Engineering and Computer Science at Stanford University, and Faculty Director of the Open Networking Research Center. From 1986-1989 he worked for Hewlett-Packard Labs in Bristol, England. In 1995, he helped architect Cisco's GSR 12000 router. Nick was co-founder and CTO at Abrizio (acquired by PMC-Sierra, 1998), co-founder and CEO of Nemo (“Network Memory”),acquired by Cisco, 2005. In 2007 he co-founded Nicira (acquired by VMware) with and . Nick is chairman of Barefoot Networks which he co-founded with Pat Bosshart and Martin Izzard in 2013. In 2011, he co-founded the Open Networking Foundation (ONF) with Scott Shenker; and the Open Networking Lab (ON.Lab) with Guru Parulkar and Scott Shenker. He is a co-founder and Board Member at Selfie Networks.

Nick is a member of the US National Academy of Engineering (NAE), the American Academy of Arts and Sciences, a Fellow of the Royal Academy of Engineering (UK), the IEEE and the ACM. He received the British Computer Society Lovelace Medal (2005), the IEEE Kobayashi Computer and Communications Award (2009), the ACM Sigcomm Lifetime Achievement Award (2012), the IEEE Rice communications theory award (1999). Nick has an Honorary Doctorate from ETH (Zurich, 2014). Nick's current research interests include software defined networks (SDN), network verification, video streaming, how to enable more rapid improvements to the Internet infrastructure, and tools and platforms for networking research and teaching.