RFC 8462

Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)

📅 published October 2018, from ietf

Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) 🎀✨

Okay bestie, this one is an RFC (RFC 8462, if you're keeping track 💅) from the IAB, the Internet Architecture Board. Its authors are N. Rooney and S. Dawkins, who is the editor (Ed.) 🫶. It's dated October 2018, and the category is Informational, so it's not a standard, just a permanent record of a workshop 📚. The ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's a totally standalone moment 🦋.

Abstract

okay so the IAB and the GSM Association (GSMA) ran a joint workshop called Managing Radio Networks in an Encrypted World (MaRNEW) on September 24-25, 2015 📱🔐. The whole point was figuring out how to optimize bandwidth on mobile networks when the content is encrypted 😭. The thing is, the current solutions depend on being able to read unencrypted content, and that's just not what today's users need from their security 💀.

The workshop brought together IETF folks, IAB members, and people from all over the telecom world, like equipment manufacturers, content providers, and mobile network operators 🌸. The group talked about encryption trends on the Internet, the deployment issues the IETF has spotted, and the privacy needs users should be able to count on 🙈. They looked at ideas for sharing data between the network and the endpoints in both directions, plus problems with the transport-layer protocols people use right now 🔥. Content providers and Content Delivery Networks (CDNs) shared what it's actually like delivering their content through mobile network operators 🧚. And finally, they talked about technical responses to regulation, specifically how regulated industries can tell regulators about technologies that are impossible to implement or bad for privacy 💜.

A set of suggested solutions came out of all of this, and those will be discussed in various IETF groups going forward 🦋✨.

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes only 📖.

It's a product of the Internet Architecture Board (IAB) and represents information the IAB decided was valuable enough to keep as a permanent record 🎀. It reflects the consensus of the IAB. Documents the IAB approves for publication aren't candidates for any level of Internet Standard, so see Section 2 of RFC 7841 if you want the details 💅.

For the current status of this document, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8462 🌈.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please actually read those, bestie, because they spell out your rights and restrictions for this document 🙈📜.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Understanding "Bandwidth Optimization"  . . . . . . . . .   4
  1.2.  Topics  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  1.3.  Organization of This Report . . . . . . . . . . . . . . .   5
  1.4.  Use of Note Well and the Chatham House Rule . . . . . . .   6
  1.5.  IETF and GSMA . . . . . . . . . . . . . . . . . . . . . .   6
2.  Scene-Setting Sessions  . . . . . . . . . . . . . . . . . . .   7
  2.1.  Scene Setting . . . . . . . . . . . . . . . . . . . . . .   7
    2.1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .   8
    2.1.2.  Encryption Statistics and Radio Access Network
            Differences . . . . . . . . . . . . . . . . . . . . .   8
  2.2.  Encryption Deployment Considerations  . . . . . . . . . .   9
  2.3.  Awareness of User Choice (Privacy)  . . . . . . . . . . .  10
3.  Network or Transport Solution Sessions  . . . . . . . . . . .  11
  3.1.  Sending Data Up/Down for Network Management Benefits  . .  11
    3.1.1.  Competition, Cooperation, and Mobile Network
            Complexities  . . . . . . . . . . . . . . . . . . . .  12
4.  Transport Layer: Issues, Optimization, and Solutions  . . . .  13
5.  Application-Layer Optimization, Caching, and CDNs . . . . . .  14
6.  Technical Analysis and Response to Potential Regulatory
    Reaction  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
7.  Suggested Principles and Solutions  . . . . . . . . . . . . .  16
  7.1.  Better Collaboration  . . . . . . . . . . . . . . . . . .  19
8.  Since MaRNEW  . . . . . . . . . . . . . . . . . . . . . . . .  19
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
11. Informative References  . . . . . . . . . . . . . . . . . . .  20
Appendix A.  Workshop Attendees . . . . . . . . . . . . . . . . .  24
Appendix B.  Workshop Position Papers . . . . . . . . . . . . . .  26
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1. Introduction 🎀

Okay, so this is the same abstract story again: the IAB and GSMA held their joint MaRNEW workshop on September 24-25, 2015 💖. They wanted to find solutions for mobile bandwidth optimization when the content is encrypted, because the current solutions rely on unencrypted content, and that doesn't match what today's Internet users actually need for security 🔐✨.

Mobile networks have a lot of properties that make sophisticated bandwidth optimization really important 📶. More encryption on the Internet is a good thing for consumer and business privacy and security, honestly iconic 👑. A lot of existing mobile optimization tools work on non-encrypted traffic, and that can make performance problems worse on mobile networks 😭. Encryption on networks is only going to keep growing, so the workshop wanted to figure out how to handle bandwidth optimization and performance on radio networks in this encrypted world 🌈🫶.

1.1. Understanding "Bandwidth Optimization" 🧠

For this workshop, bandwidth optimization covers a bunch of technical topics, like traffic engineering, prioritization, optimization, and efficiency improvements 💅. It also covers user-related stuff, like specific subscription or billing models, and it may touch on regulatory aspects or other issues tied to government-initiated regulatory concerns 📜.

The first category of bandwidth optimization includes:

  • Caching 🗄️
  • Prioritization of interactive traffic over background traffic ⚡
  • Per-user bandwidth limits 🚦

The second category may depend on one or more of the first category's strategies, but it can also cover business-related topics, like content delivery arrangements with content providers 🤝.

Then there's stuff that isn't strictly traffic management. Some networks use policy-based filtering (like requested parental controls) 👀, and many networks support some form of legal interception per applicable laws 🕵️.

A lot of these functions can keep working the way they do today even with more encryption 🙌. Others inspect parts of the communication that aren't encrypted today but will be, so those functions will have to be done differently on an increasingly encrypted Internet 😤.

1.2. Topics 💭

The workshop was trying to answer questions like these 📝:

  • understanding the bandwidth optimization use cases particular to radio networks;
  • understanding existing approaches and how these don't work with encrypted traffic;
  • understanding reasons why the Internet has not standardized support for lawful intercept and why mobile networks have;
  • determining how to match traffic types with bandwidth optimization methods;
  • discussing minimal information to be shared to manage networks but ensure user security and privacy;
  • developing new bandwidth optimization techniques and protocols within these new constraints;
  • discussing the appropriate network layer(s) for each management function; and
  • cooperative methods of bandwidth optimization and issues associated with these.

The bigger goal was to collect architectural and engineering guidance for future bandwidth optimization work, based on the discussions about the proposed approaches 🏗️✨. The workshop also looked at possible areas for standardization, for example new protocols that can help bandwidth optimization while keeping user security in line with new work on transport-layer protocols 🦋.

1.3. Organization of This Report 🗂️

This report summarizes what was contributed and discussed at the workshop, organized by topic 💕. It started with scene-setting topics: the issues around deploying encryption, the growing need for privacy on the Internet, and a clear understanding that ciphertext should remain unbroken 🔒. Later sessions focused on the key solution areas, which were evolution on the transport layer and sending data up or down the path 🚀. A session on application layers and CDNs looked at issues and solutions on the application layer 🍓. The workshop ended with a session on a technical response to regulation about encryption 🧚.

The contributing documents identified the issues encryption causes on radio networks and suggested solutions 💜. Some of those solutions focused on transport evolution, some on trusted middleboxes, and others on collaborative data exchange 🫶. Solutions were discussed within the sessions. All accepted position papers and detailed discussion transcripts are available at [MARNEW] 📚.

The outcomes of the workshop are discussed in Sections 7 and 8, which cover the progress made toward each identified work item through the time this document was approved for publication 🌸.

Readers should keep in mind that this workshop did not aim to discuss regulation or legislation, although policy topics came up in discussions from time to time 🙈.

1.4. Use of Note Well and the Chatham House Rule 🤫

The workshop was conducted under the IETF [NOTE_WELL], with one exception: the "Technical Analysis and Response to Potential Regulatory Reaction" session was conducted under the [CHATHAM_HOUSE_RULE] 🔐💅.

That's part 1 of 6 done, bestie 🎀💖 more parts are coming, so stay tuned 🧚✨

1.5. IETF and GSMA 🌸

Okay so the IETF and the GSMA [GSMA] have totally different working practices, standards, and processes, bestie 🫶 The IETF is an open org with community-driven standards, and its whole vibe is functionality and security for the Internet's users 💖. The GSMA is membership based and serves what its members need, and most of those members are mobile network operators 📱.

Unlike the IETF, GSMA makes few standards 🤷‍♀️. Within telecoms, standards get set in a bunch of different groups depending on what they're for, which is lowkey chaotic. The one most relevant to the bandwidth optimization topic here is the 3rd Generation Partnership Project (3GPP) [SDO_3GPP], which works on radio network and core network standards 📡. 3GPP members include mobile operators and original equipment manufacturers 🏭.

One 3GPP standard relevant to this workshop is Policy and Charging Control QoS [PCC-QOS] 💅. Traditionally, mobile networks have managed different apps and services based on the resources available and the priorities given. For instance, emergency services get top priority, data gets a lower priority, and voice services sit somewhere in-between 🚨. 3GPP defined the PCC-QoS mechanism to support this, and it depends on unencrypted communications [EffectEncrypt] 🔓 (that's the tea 🍵).

2. Scene-Setting Sessions ✨

Scene-setting sessions aimed to get all attendees up to a basic understanding of the problem and the scope of the workshop 🎀.

There were three scene-setting sessions:

  • Section 2.1: Scene Setting
  • Section 2.2: Encryption Deployment Considerations
  • Section 2.3: Awareness of User Choice (Privacy)

2.1. Scene Setting 🧚

The telecom industry and the Internet standards community are extremely different in ethos and practices 💜. Both groups drive technical standards in their domain and build technical solutions, with some policy-driven use cases. These technologies, use cases, and implementations are different, and the motivators between the two industries are also diverse 🌈.

To make sure everyone was aligned on contributing and driving solutions, this "Scene Setting" session worked on generating a clear scope with all attendees involved. In short, it was agreed that 1) ciphertext encrypted by one party and intended to be decrypted by a second party should not be decrypted by a third party in any solution, 2) the Radio Access Network (RAN) does experience issues with increased encrypted traffic, 3) the RAN issues need to be understood precisely, and 4) the goal is to improve user experience on the Internet 🙌. Proposing new technical solutions based on presumed future regulation was not in scope. The full scope is below 👇.

2.1.1. Scope

The attendees identified and agreed to the scope described here 📝.

We should do the following:

  • okay so, assume there's no broken crypto 🔐; ciphertext is getting more and more common; congestion still needs controlling (same with other transport issues); and network management, including using RAN and other resources efficiently, has to keep working 💪;
  • identify how and why RAN is different for transport, and try to understand the complexities of RAN (i.e., how hard it is to manage) and why those complexities matter 🧩;
  • identify the precise problems caused by increased use of encryption 🔍;
  • identify players (in addition to end users), the resulting tensions, and how ciphertext changes those tensions 🎭;
  • discuss how some solutions will be radically changed by ciphertext (it's ok to talk about that) 😭;
  • assume that the best possible quality of experience for the end user is a goal; and lastly, 👑
  • for the next two days, analyze the situation and identify specific achievable tasks that could be tackled in the IETF or GSMA (or elsewhere) and that improve the Internet given the assumptions above 🚀.

We should not delve into the following:

  • ways of doing interception, legal or not, for the reasons described in [RFC2804]; and, 🙅‍♀️
  • unpredictable political actions. 💀

2.1.2. Encryption Statistics and Radio Access Network Differences 📊

According to then-current statistics, attendees were shown that encrypted content reaches around 50% [STATE_BROWSER] [STATE_SERVER]. The IAB is encouraging all IETF working groups to consider the effect of encryption being "on by default" will have on new protocol work. The IETF is also working on encryption at lower layers. One recent example is opportunistic TCP encryption within the TCP Increased Security [TCPINC] Working Group. The aims of these work items are greater security and privacy for end users and their data 🔒.

Telecom networks often contain middleboxes that operators have previously considered trusted, but qualifying trust is difficult and should not be assumed 🙅. Some interesting use cases exist with these middleboxes, like anti-spam and malware detection, but these need balancing against their ability to open up cracks in the network for attacks such as pervasive monitoring 🕳️.

When operators increase the number of radio access network cells (base stations), this can improve radio access network quality of service; however, it also adds to radio pollution 📶. This is one example of the balancing act required when devising radio access network architecture ⚖️.

2.2. Encryption Deployment Considerations 🔐

Encryption across the Internet is on the rise 📈. However, some organizations and individuals mainly driven by commercial perspectives come across a common set of operational issues when deploying encryption. [RFC8404] explains these network management function impacts, detailing areas around incident monitoring, access control management, and regulation on mobile networks. The data was collected from various Internet players, including system and network administrators across enterprise, governmental organizations, and personal use. The aim of the document is to understand what is needed for technical solutions to these issues while maintaining security and privacy for users. Attendees commented that worthwhile additions would be different business environments (e.g., cloud environments) and service chaining. Incident monitoring in particular was noted as a difficult issue to solve, given the use of URLs in today's incident monitoring middleware 🧐.

Some of these impacts to mobile networks can be resolved using different methods, and the [NETWORK_MANAGEMENT] document details these methods. The document focuses heavily on methods to manage network traffic without breaching user privacy and security 🛡️.

By reviewing encryption deployment issues and the alternative methods of network management, MaRNEW attendees were made aware of the issues affecting radio networks, the deployment issues that are solvable and require no further action, and the issues that have not yet been solved but should be addressed within the workshop 🎉.

2.3. Awareness of User Choice (Privacy) 🙈

Some solutions intended to improve delivery of encrypted content could affect some or all of the privacy benefits encryption provides. Understanding user needs and desires for privacy is therefore important when designing these solutions 💭.

From a then-current study [Pew2014], 64% of users said concerns over privacy have increased, and 67% of mobile Internet users would like to do more to protect their privacy 😤. The World Wide Web Consortium (W3C) and IETF have both responded to user desires for better privacy by recommending encryption for new protocols and web technologies. Within the W3C, new security standards are emerging, and the design principles for HTML maintain that users are the stakeholders with the highest priority, followed by implementors and other stakeholders, which further enforces the "user first" principle 👑. Users also have certain security expectations from particular contexts and sometimes use new technologies to further protect their privacy, even if those technologies weren't initially developed for that purpose.

Operators may deploy technologies that can either impact user privacy without being aware of those privacy implications, or incorrectly assume that the benefits users gain from the new technology outweigh the loss of privacy. If these technologies are necessary, they should be opt in ✋.

Internet stakeholders should understand the priority of other stakeholders. Users should be considered the first priority. Other stakeholders include implementors, developers, advertisers, operators, and other ISPs. Some technologies, such as cookie use and JavaScript injection, have been abused by these parties, and this has caused some developers to encrypt content to get around technologies seen as intrusive or bad for user privacy 🍪.

If users and content providers are to opt in to network management services with negative privacy impacts, they should see clear value from using these services and understand the impacts of using them. Users should also have easy abilities to opt out. Some users will always automatically click through consent requests, so any model relying on explicit consent is flawed for these users. Understanding the extent of "auto click-through" may improve decisions about the use of consent requests in the future 🤔. One model (Cooperative Traffic Management) works as an agent of the user; by opting in, metadata can be shared. Issues with this involve trust only being applied at endpoints 🚧.

3. Network or Transport Solution Sessions 🦋

Network or Transport Solution Sessions discussed proposed solutions for managing encrypted traffic on radio access networks. Most solutions focus on metadata sharing, whether this sharing takes place from the endpoint to the network, from the network to the endpoint, or cooperatively in both directions. Transport-layer protocol evolution could be another approach to solve some of the issues radio access networks experience, which cause them to rely on network management middleboxes. By removing problems at the transport layer, reliance on expensive and complex middleboxes could decrease 💜.

3.1. Sending Data Up/Down for Network Management Benefits 📡

okay so bestie, collaboration between network elements and endpoints could totally bring about better content distribution 💖 and people came up with a bunch of ideas for it ✨ highlights:

  • Mobile Throughput Guidance [MTG]: network elements and endpoints swap metadata through TCP options 🎀 it also helps everyone understand how the transport protocol behaves and makes the user experience better too, although more work on MTG is still needed 🔧
  • Session Protocol for User Datagrams [SPUD]: a UDP-based encapsulation protocol that allows explicit cooperation with middleboxes while using, new encrypted transport protocols 🦋
  • Network Status API: an API where operators can share congestion status or the state of a cell before an application starts sending data, which could let apps change how they behave 📶
  • Traffic Classification: classifying traffic and adding those classifications as metadata for analysis across the whole network 🏷️ this one is giving trust and privacy implications, so be careful 🙈
  • Congestion Exposure [CONEX]: a mechanism where senders tell the network about the congestion that earlier packets on the same flow ran into, in-band at the IP layer 🌊
  • Latency versus Bandwidth: a bit that lets the content provider say whether higher bandwidth or lower latency is the bigger priority, so the network can react to that signal 💅 where this bit lives in the protocol stack and how it gets authenticated still need to be figured out 🧩
  • No Network Management Tools: turning off all network management tools and relying only on end-to-end protocols to manage congestion 🌸
  • Flow Queue Controlled Delay (FQ-CoDel) [FLOWQUEUE]: a hybrid packet scheduler / Active Queue Management (AQM) [RFC7567] algorithm that aims to reduce bufferbloat and latency ⚡ it manages packets from multiple flows and cuts down the impact of head-of-line blocking from bursty traffic 🫶

Some of these ideas depend on network elements signaling to endpoints ✨ others try to make "hop-by-hop" solutions, which might line up better with how congestion gets managed today, but with bigger privacy implications 👀

Then there are ideas that rely on endpoints signaling to network elements 📣 some use implicit signaling and some use explicit signaling. A bunch of workshop attendees agreed that asking apps to explicitly declare the quality of service they need was not the way forward, since that model hasn't really worked out in the past 💀

3.1.1. Competition, Cooperation, and Mobile Network Complexities 🥊

okay so one of the bigger problems with sharing data about trouble with encrypted traffic on wireless networks is competition 😤 network operators are super reluctant to give up data about their own networks, because it's valuable info for competitors, and application providers want to protect their users and reveal as little as possible to the network. some people think that if middleboxes were authenticated and invoked explicitly, that would be an upgrade on today's transparent middleboxes that intercept traffic without endpoint consent 🙅‍♀️ some workshop attendees also suggested that any exchange of information should be bidirectional, so the elements can actually cooperate 🤝 a robust incentive framework could solve these issues, or at least help soften them 💜

the radio access network is complex because it has to juggle a bunch of conflicting demands 🌀 base stations reflect that environment, and the info inside them can be valuable to other entities on the path 📦 some workshop participants thought solutions for managing congestion on radio networks should involve the base station if possible 🗼 for example, understanding how the radio resource controller and AQM [RFC7567] interact (or don't interact) could give valuable insight for solving issues 🔍 even though many attendees agreed there's a need to understand the base station, not everyone agreed it should be part of a future solution 🤷‍♀️

some suggested solutions were based on network categorization and on providing that info to the protocols or endpoints 🗂️ completely categorizing radio networks could be impossible because they're so complex, but categorizing essential network properties could be possible and valuable 🍓

4. Transport Layer: Issues, Optimization, and Solutions ✨

okay this is a whole history lesson bestie 📜 TCP has been the dominant transport protocol since TCP/IP replaced the Network Control Protocol (NCP) on the ARPANET in March 1983 🕰️ TCP was originally designed for a specific network model that didn't anticipate the high error rates and highly variable available bandwidth we get on modern radio access networks 📱

and it's only gotten messier 😭 new network elements have shown up (NATs, and network devices with large buffers that create bufferbloat), and a ton of peer-to-peer traffic is competing with traditional client-server traffic 🫠 so the transport layer today has requirements that go beyond what TCP was designed to meet 💅 TCP has other issues too: too many services rely on TCP and only TCP, which blocks deployment of new transport protocols like the Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP) 🚧 that means real innovation on the transport layer gets hard, because deployment issues are way more complicated than just building a new protocol 🥲

the IETF is trying to fix this through the IAB's IP Stack Evolution program 🛠️ and the very first step of that program is to collect data 📊 network and content providers can share data including: the cost of encryption, the advantages of network management tools, the deployment of protocols, and the effects when network management tools are disabled 🔐 but network operators mostly keep network info close to the chest for competitive reasons, so they're unlikely to just donate it to the IETF 🙃 the GSMA is in a good position to collect this data and anonymize it before bringing it to the IETF, which should ease the network operators' worries and still give the IETF some usable data 🧁

congestion is only detected once packet loss shows up, and better methods based on detecting congestion would be a big win 📉 but a lot of work has already been done on TCP, especially innovation in bandwidth management and congestion control 💪

also, the deficiencies of TCP get treated as key issues in the evolution of the Internet protocol stack, but the main route to fixing them might not be a new TCP at all, maybe an evolved stack instead 🧬 some workshop participants suggested that SPUD [SPUD] and Information-Centric Networking (ICN) [RFC7476] could help here 🌐 QUIC engineers (Quick UDP Internet Connection [QUIC]) said the problems QUIC solves are general problems, not TCP issues 🏃‍♀️ not every attendee agreed with that vibe though 🙈 and TCP has improved a lot in the last few years, which might mean some of the network lower layers should be investigated to see whether improvements can be made there too 🔎

5. Application-Layer Optimization, Caching, and CDNs 🍿

okay so a lot of the talks about how encrypted traffic affects radio access networks happen between implementers and network operators 🗣️ this session wanted to hear from the content and caching providers instead 🎬 specifically: their experiences running over mobile networks, the quality of experience their users expect, and the content and caching they'd like to achieve by working with or using the mobile network 📲

content providers explained something really important 💡 even though this workshop named encrypted data over radio access networks as the main issue, the real issue is network management in general, and all the actors (application providers, networks, and devices) need to work together to overcome those general network management issues 🤝 they also said they assume mobile networks are standards compliant 📋 when the network is not standards compliant (for example, using non-standards-compliant intermediaries), content providers can rack up real costs, because users contact their support centers to report issues that are super hard to test for and resolve 📞😩

content providers also cited other common problems with data traffic over mobile networks 🧾 data subscription limits (known as "caps") cause issues for users, who are confused about how data caps work or unsure how expensive media is and how much data it eats up 🍔 developers build products on networks that don't reflect what their customers are actually using, and not every organization has the finances to build a caching infrastructure 🏗️

content providers are strongly connected to CDNs too 🌍 content owners see CDNs as trusted deliverers of content, and CDNs have had great success in fixed networks 🏆 now that more traffic is moving to mobile networks, there's a need to place caches near the user at the edge of the mobile network 📍 putting caches at the edge of the mobile network is a solution, but it requires standards developed by content providers and mobile network operators together 🧩 the IETF's CDN Interconnection [CDNI] Working Group aims to let global CDNs interoperate with mobile CDNs, but this causes huge issues for caching encrypted data between those CDNs 😵 some CDNs are experimenting with approaches like "Keyless SSL" [KeylessSSL] to enable safer storage of content without passing private keys to the CDN 🔑 Blind Caching [BLIND_CACHING] is another proposal, aimed at caching encrypted content closer to the user while managing authentication at the original content provider servers 🫧

at the end of the session, each panelist got asked to name one key collaborative work item 🎤 the items named were: evolving to cache encrypted content, using one bit for latency / bandwidth trade-off (explained below), better collaboration between the network and application, better metrics to aid troubleshooting and innovation, and indications from the network to allow the application to adapt 👑 the vibes are immaculate 🌈

6. Technical Analysis and Response to Potential Regulatory Reaction ✨

okay so this session ran under the Chatham House Rule 🎀, which means we talk about the ideas but don't pin them on specific people. the goal was to chat about regulatory and political issues without getting into whether those rules are worth it or needed (not our call, lol) 🙈. the real aim was to understand the laws that exist and how technologists can properly respond to them 💅

mobile networks are regulated, and compliance is mandatory 😭. it can cost the mobile network operator money, and in some nations, non-compliance can get your service license revoked 💀. the rules vary by location 🌍. some are court orders, and others are self-imposed, like "block lists" of websites such as the Internet Watch Foundation [IWF] list 📋. operators aren't expected to decrypt sites, so encrypted sites won't get blocked because of their content 🔐

parental-control-type filters also exist on the network, but they're super easy to bypass today, so they barely work 🫠. better solutions would let users easily set these restrictions themselves 🫶. other regulations are also hard to meet, like ones about user data patterns, or they're getting harder to collect data for, like Internet of Things (IoT) cases 🧸. most attendees agreed that if a government can't get the information it needs (and is legally entitled to have) from network operators, it'll approach content providers 👀. some governments are aware of the impact of encryption and are working with content providers, or trying to 🤝. and the IAB has concluded that blocking and filtering can be done at the endpoints of the communication 💜

not all of these regulations apply to the Internet, and the Internet community isn't always aware they exist 🧚. collectively, the community can work with GSMA and 3GPP and act together to ease the risk imposed by encrypted traffic 🌈. some participants were worried that governments might require operators to provide information they no longer have the ability to provide, because previously unencrypted traffic is now encrypted. that could expose operators to new liability, but no specific examples were given during the workshop 🤷. one suggestion from some attendees was that if any new technical solutions are necessary, they should easily be "switched off" 🔌

some mobile network operators are producing transparency reports covering regulations, including lawful intercept 📊. operators who have done this already are encouraging others to do the same 🍓

7. Suggested Principles and Solutions 🌸

based on the talks and discussions throughout the workshop, a set of suggested principles and solutions was collected 📝. this isn't an exhaustive list, and no attempt was made to reach consensus during the workshop, so there are likely at least some participants who wouldn't agree with any particular principle below. the list is a union of participant thinking, not an intersection 💖

  • Encrypted Traffic: Any solution should encourage and support encrypted traffic. 🔐
  • Flexibility: Radio access network qualities vary vastly, and the network needs of content can differ significantly, so any new solution should be flexible across either the network type, content type, or both. 🦋
  • Privacy: New solutions should not introduce new ways for information to be discovered and attributed to individual users. 🙈
  • Minimum data only for collaborative work: User data, application data, and network data all need protection, so new solutions should use minimal information to make a working solution. 🛡️

a collection of solutions suggested by various participants during the workshop is given below ✨. inclusion in this list doesn't imply that other workshop participants agreed. again, the list is a union of proposed solutions, not an intersection 🌈

  • Evolving TCP or evolution on the transport layer: This could take a number of forms, and some of this work is already underway within the IETF. 🧩
  • Congestion Control: Many attendees cited congestion control as a key issue. Further analysis, investigation, and work could be done in this space. 🚦
  • Sprout [SPROUT]: Researched at MIT, Sprout is a transport protocol for applications that desire high throughput and low delay. ⚡
  • PCC [PCC]: Performance-oriented Congestion Control is a new architecture that aims for consistent high performance, even in challenging scenarios. PCC endpoints observe the connection between their actions and their known performance, which allows them to adapt their actions. 🧠
  • CDNs and Caches: This suggests that placing caches closer to the edge of the radio network, as close as possible to the mobile user, or making more intelligent CDNs, would result in faster content delivery and less strain on the network. 🚀
  • Blind Caching [BLIND_CACHING]: This is a proposal for caching of encrypted content. 🫣
  • CDN Improvements: This includes Keyless SSL and better CDN placement. 🏠
  • Mobile Throughput Guidance [MTG]: This is a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. 📶
  • One Bit for Latency / Bandwidth Trade-Off: This suggests determining whether using a single bit in an unencrypted transport header to distinguish between traffic that the sender prefers to be queued and traffic that the sender would prefer to drop rather than delay provides additional benefits beyond what can be achieved without this signaling. 🎚️
  • Base Station: Some suggestions involved using the base station, but this was not defined in detail. The base station holds the radio resource controller and scheduler, which could provide a place to host solutions, or data from the base station could help in devising new solutions. 🗼
  • Identify Traffic Types via 5-Tuple: Information from the 5-tuple could provide understanding of the traffic type, and network management appropriate for that traffic type could then be applied. 🔍
  • Heuristics: Networks can sometimes identify traffic types by observing characteristics, such as data flow rate, and then apply network management to these identified flows. This is not recommended, as categorizations can be incorrect. 🙅‍♀️
  • APIs: An API for operators to share congestion status or the state of a cell before an application starts sending data could allow applications to change their behavior. Alternatively, an API could provide the network with information on the data type, allowing appropriate network management for that data type; however, this method exposes privacy issues. 🔌
  • Standard approach for the operator to offer services to Content Providers: Mobile network operators could provide caching services or other services for content providers to use for faster and smoother content delivery. 🤝
  • AQM [RFC7567] and ECN [RFC3168] deployments: Queuing and congestion management methods have existed for some time in the form of AQM, ECN, and others, which can help the transport and Internet protocol layers adapt to congestion faster. 🏃‍♀️
  • Trust Model or Trust Framework: Some solutions in this area (e.g., SPUD) have a reliance on trust when content providers or the network are being asked to add classifiers to their traffic. 🫱
  • Keyless SSL [KeylessSSL]: This allows content providers to maintain their private keys on a key server and host the content elsewhere (e.g., on a CDN). This could become standardized in the IETF. [LURK] 🔑
  • Meaningful capacity sharing: This includes the ConEx [CONEX] work, which exposes information about congestion to the network nodes. 📡
  • Hop-by-hop: Some suggestions offer hop-by-hop methods that allow nodes to adapt flow given the qualities of the networks around them and the congestion they are experiencing. 🐇
  • Metrics and metric standards: In order to evolve current protocols to be best suited to today's networks, data is needed about current network conditions, protocol deployments, packet traces, and middlebox behavior. Beyond this, proper testing and debugging on networks could provide great insight for stack evolution. 📊
  • 5G: Mobile operator standards bodies are in the process of setting the requirements for 5G. Requirements for network management could be added. 📱

in the workshop, attendees identified other areas where greater understanding could help the standards process 🧐. these were identified as:

  • greater understanding of the RAN within the IETF;
  • reviews and comments on 3GPP perspective; and,
  • how to do congestion control in the RAN.

7.1. Better Collaboration 🫶

throughout the workshop, attendees put a lot of emphasis on the need for better collaboration between the IETF and telecommunications bodies and organizations 💜. the workshop was one such way to achieve this, but the good work and relationships built in the workshop should continue, so the two groups can work on solutions that are better for both technologies and users 🦋

8. Since MaRNEW ✨

Okay so, since MaRNEW, a bunch of stuff has been happening in different IETF working groups and in groups outside the IETF 🫶. The Alternatives to Content Classification for Operator Resource Deployment (ACCORD) BoF happened at IETF 95 in November 2015. It brought the workshop talk to the wider IETF crowd by sharing what went down at the workshop and flagging the key areas to keep pushing on. Here's where those areas are at:

  • A bunch of MaRNEW attendees asked for usable metrics and data, especially for the IRTF Measurement and Analysis for Protocols (MAP) Research Group. This has been really hard to collect because mobile network operators are super closed off 😭
  • Understanding what's blocking protocol stack evolution has kept going in the IAB's IP Stack Evolution program and across transport-related IETF working groups like the Transport Area Working Group (TSVWG) 🦋
  • The Mobile Throughput Guidance document [MTG] has entered its testing and data collection phase. Still, new transport tech like QUIC, among others, may have stalled the efforts on TCP-related proposals 🌸
  • Work on proposals for caching encrypted content is still going, but there are some security flaws, and the proponents are working on more proposals to fix them. Most of this gets discussed in the IETF HTTPbis Working Group 🔥
  • The Path Layer UDP Substrate (PLUS) BOF at IETF 96 in July 2016 did not lead to a working group. Attendees were worried about the privacy issues tied to the proposed data-sharing stuff in the shim layer 🙈
  • The Limited Use of Remote Keys (LURK) BOF at IETF 96 in July 2016 did not lead to a working group either, because the BOF found more problems with the presumed approach than anyone expected 💀

The most rewarding output of MaRNEW is honestly the most intangible one ✨. It gave two pretty different industry groups a chance to connect and talk about shared tech and issues that affect users and operations. Mobile network providers and key Internet engineers and experts have built a much stronger collaborative relationship, which helps develop more standards that work across networks in a secure way 💜.

9. Security Considerations 🔒

This document is an IAB report from a workshop on the interactions between network security, especially privacy, and network performance.

It does not affect the security of the Internet, taken on its own.

10. IANA Considerations 🧚

This document has no IANA actions.

11. Informative References 📚

Appendix A. Workshop Attendees 🎀

  • Rich Salz, Akamai
  • Aaron Falk, Akamai
  • Vinay Kanitkar, Akamai
  • Julien Maisonneuve, Alcatel Lucent
  • Dan Druta, AT&T
  • Humberto La Roche, Cisco
  • Thomas Anderson, Cisco
  • Paul Polakos, Cisco
  • Marcus Ihlar, Ericsson
  • Szilveszter Nadas, Ericsson
  • John Mattsson, Ericsson
  • Salvatore Loreto, Ericsson
  • Blake Matheny, Facebook
  • Andreas Terzis, Google
  • Jana Iyengar, Google
  • Natasha Rooney, GSMA
  • Istvan Lajtos, GSMA
  • Emma Wood, GSMA
  • Jianjie You, Huawei
  • Chunshan Xiong, Huawei
  • Russ Housley, IAB
  • Mary Barnes, IAB
  • Joe Hildebrand, IAB / Cisco
  • Ted Hardie, IAB / Google
  • Robert Sparks, IAB / Oracle
  • Spencer Dawkins, IETF AD
  • Benoit Claise, IETF AD / Cisco
  • Kathleen Moriarty, IETF AD / EMC
  • Barry Leiba, IETF AD / Huawei
  • Ben Campbell, IETF AD / Oracle
  • Stephen Farrell, IETF AD / Trinity College Dublin
  • Jari Arkko, IETF Chair / Ericsson
  • Karen O'Donoghue, ISOC
  • Phil Roberts, ISOC
  • Olaf Kolkman, ISOC
  • Christian Huitema, Microsoft
  • Patrick McManus, Mozilla
  • Dirk Kutscher, NEC Europe Network Laboratories
  • Mark Watson, Netflix
  • Martin Peylo, Nokia
  • Mohammed Dadas, Orange
  • Diego Lopez, Telefonica
  • Matteo Varvello, Telefonica
  • Zubair Shafiq, The University of Iowa
  • Vijay Devarapalli, Vasona Networks
  • Sanjay Mishra, Verizon
  • Gianpaolo Scassellati, Vimplecom
  • Kevin Smith, Vodafone
  • Wendy Seltzer, W3C

Appendix B. Workshop Position Papers 🦋

okay bestie, here are every single position paper from the workshop, so you can see who showed up and what they brought 📚✨

Acknowledgements 🫶

Stephen Farrell reviewed this report in draft form and provided copious comments and suggestions. Iconic energy, honestly 👑

Barry Leiba provided some clarifications on specific discussions about Lawful Intercept that took place during the workshop 🎀

Bob Hinden and Warren Kumari provided comments and suggestions during the IAB Call for Comments 💖

Amelia Andersdotter and Shivan Kaul Sahib provided comments from the Human Rights Review Team during the IAB Call for Comments 🌈

Authors' Addresses 💌

Natasha Rooney GSMA

Email: nrooney@gsma.com URI: https://gsma.com

Spencer Dawkins (editor) Wonder Hamster

Email: spencerdawkins.ietf@gmail.com

📦 where this page comes from