From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8462.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc8462.txt (limited to 'doc/rfc/rfc8462.txt') diff --git a/doc/rfc/rfc8462.txt b/doc/rfc/rfc8462.txt new file mode 100644 index 0000000..7fb76db --- /dev/null +++ b/doc/rfc/rfc8462.txt @@ -0,0 +1,1571 @@ + + + + + + +Internet Architecture Board (IAB) N. Rooney +Request for Comments: 8462 S. Dawkins, Ed. +Category: Informational October 2018 +ISSN: 2070-1721 + + + Report from the IAB Workshop on + Managing Radio Networks in an Encrypted World (MaRNEW) + +Abstract + + The Internet Architecture Board (IAB) and GSM Association (GSMA) held + a joint workshop on Managing Radio Networks in an Encrypted World + (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss + solutions for bandwidth optimization on mobile networks for encrypted + content, as current solutions rely on unencrypted content, which is + not indicative of the security needs of today's Internet users. The + workshop gathered IETF attendees, IAB members, and participants from + various organizations involved in the telecommunications industry + including original equipment manufacturers, content providers, and + mobile network operators. + + The group discussed Internet encryption trends and deployment issues + identified within the IETF and the privacy needs of users that should + be adhered to. Solutions designed around sharing data from the + network to the endpoints and vice versa were then discussed; in + addition, issues experienced when using current transport-layer + protocols were also discussed. Content providers and Content + Delivery Networks (CDNs) gave their own views of their experiences + delivering their content with mobile network operators. Finally, + technical responses to regulation were discussed to help the + regulated industries relay the issues of impossible-to-implement or + bad-for-privacy technologies back to regulators. + + A group of suggested solutions were devised, which will be discussed + in various IETF groups moving forward. + + + + + + + + + + + + + + + +Rooney & Dawkins Informational [Page 1] + +RFC 8462 MaRNEW October 2018 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8462. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + +Rooney & Dawkins Informational [Page 2] + +RFC 8462 MaRNEW October 2018 + + +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 + + + + + + + + + + + + + + + + + + +Rooney & Dawkins Informational [Page 3] + +RFC 8462 MaRNEW October 2018 + + +1. Introduction + + The Internet Architecture Board (IAB) and GSM Association (GSMA) held + a joint workshop on Managing Radio Networks in an Encrypted World + (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss + solutions for bandwidth optimization on mobile networks for encrypted + content, as current solutions rely on unencrypted content, which is + not indicative of the security needs of today's Internet users. + + Mobile networks have a set of properties that place a large emphasis + on sophisticated bandwidth optimization. The use of encryption is + increasing on the Internet, which is positive for consumer and + business privacy and security. Many existing solutions for mobile + bandwidth optimization primarily operate on non-encrypted + communications; this can lead to performance issues being amplified + on mobile networks. The use of encryption on networks will continue + to increase; with this understanding, the workshop aimed to + understand how we can solve the issues of bandwidth optimization and + performance on radio networks in this encrypted world. + +1.1. Understanding "Bandwidth Optimization" + + For the purposes of this workshop, bandwidth optimization encompasses + a variety of technical topics related to traffic engineering, + prioritization, optimization, and efficiency enhancements. It also + encompasses user-related topics such as specific subscription or + billing models, and it may touch upon regulatory aspects or other + issues relating to government-initiated regulatory concerns. + + The first category of bandwidth optimization includes the following: + + o Caching + + o Prioritization of interactive traffic over background traffic + + o Per-user bandwidth limits + + The second category of bandwidth optimization may depend on one or + more of the first category optimization strategies, but may, in + particular, also encompass business-related topics such as content + delivery arrangements with content providers. + + Finally, while not strictly speaking of traffic management, some + networks employ policy-based filtering (e.g., requested parental + controls), and many networks support some form of legal interception + functionality per applicable laws. + + + + + +Rooney & Dawkins Informational [Page 4] + +RFC 8462 MaRNEW October 2018 + + + Many of these functions can continue as they are performed today, + even with increased use of encryption. Others are using methods that + inspect parts of the communication that are not encrypted today, but + will be encrypted, and these functions will have to be done + differently in an increasingly encrypted Internet. + +1.2. Topics + + The workshop aimed to answer questions that focused on: + + o understanding the bandwidth optimization use cases particular to + radio networks; + + o understanding existing approaches and how these do not work with + encrypted traffic; + + o understanding reasons why the Internet has not standardized + support for lawful intercept and why mobile networks have; + + o determining how to match traffic types with bandwidth optimization + methods + + o discussing minimal information to be shared to manage networks but + ensure user security and privacy; + + o developing new bandwidth optimization techniques and protocols + within these new constraints; + + o discussing the appropriate network layer(s) for each management + function; and + + o cooperative methods of bandwidth optimization and issues + associated with these. + + The further aim was to gather architectural and engineering guidance + on future work in the bandwidth optimization area based on the + discussions around the proposed approaches. The workshop also + explored possible areas for standardization, e.g., new protocols that + can aid bandwidth optimization whilst ensuring that user security is + in line with new work in transport-layer protocols. + +1.3. Organization of This Report + + This workshop report summarizes the contributions to and discussions + at the workshop, organized by topic. The workshop began with scene- + setting topics that covered the issues around deploying encryption, + the increased need for privacy on the Internet, and setting a clear + understanding that ciphertext should remain unbroken. Later sessions + + + +Rooney & Dawkins Informational [Page 5] + +RFC 8462 MaRNEW October 2018 + + + focused on key solution areas; these included evolution on the + transport layer and sending data up or down the path. A session on + application layers and CDNs aimed to highlight both issues and + solutions experienced on the application layer. The workshop ended + with a session dedicated to discussing a technical response to + regulation with regards to encryption. The contributing documents + identified the issues experienced with encryption on radio networks + and suggested solutions. Of the solutions suggested, some 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 transcripts of + discussion are available at [MARNEW]. + + The outcomes of the workshop are discussed in Sections 7 and 8; they + discuss the progress made since the workshop toward each of the + identified work items through the time this document was approved for + publication. + + Report readers should be reminded that this workshop did not aim to + discuss regulation or legislation, although policy topics were + mentioned 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 the + exception of the "Technical Analysis and Response to Potential + Regulatory Reaction" session, which was conducted under the + [CHATHAM_HOUSE_RULE]. + +1.5. IETF and GSMA + + The IETF and GSMA [GSMA] have different working practices, standards, + and processes. IETF is an open organization with community-driven + standards, with the key aim of functionality and security for the + Internet's users, while the GSMA is membership based and serves the + needs of its membership base, most of whom are mobile network + operators. + + Unlike IETF, GSMA makes few standards. Within the telecommunications + industry, standards are set in various divergent groups depending on + their purpose. Perhaps of most relevance to the bandwidth + optimization topic here is the work of 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. + + + + + + +Rooney & Dawkins Informational [Page 6] + +RFC 8462 MaRNEW October 2018 + + + One of the 3GPP standards relevant to this workshop is Policy and + Charging Control QoS [PCC-QOS]. Traditionally, mobile networks have + managed different applications and services based on the resources + available and priorities given; for instance, emergency services have + a top priority, data has a lower priority, and voice services are + somewhere in-between. 3GPP defined the PCC-QoS mechanism to support + this functionality, and this depends on unencrypted communications + [EffectEncrypt]. + +2. Scene-Setting Sessions + + Scene-setting sessions aimed to bring all attendees up to a basic + understanding of the problem and the scope of the workshop. + + There were three scene-setting sessions: + + o Section 2.1: Scene Setting + + o Section 2.2: Encryption Deployment Considerations + + o Section 2.3: Awareness of User Choice (Privacy) + +2.1. Scene Setting + + The telecommunications industry and Internet standards community are + extremely different in terms of 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 technical implementations are different, and the + motivators between the two industries are also diverse. + + To ensure all attendees were aligned with contributing to discussions + 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 + given below. + + + + + + + + + +Rooney & Dawkins Informational [Page 7] + +RFC 8462 MaRNEW October 2018 + + +2.1.1. Scope + + The attendees identified and agreed to the scope described here. + + We should do the following: + + o in discussion, assume that there is no broken crypto; ciphertext + is increasingly common; congestion does need to be controlled (as + do other transport issues); and network management, including + efficient use of resources in RAN and elsewhere, has to work; + + o identify how/why RAN is different for transport, and attempt to + understand the complexities of RAN (i.e., how hard it is to + manage) and why those complexities matter; + + o identify the precise problems caused by increased use of + encryption; + + o identify players (in addition to end users), the resulting + tensions, and how ciphertext changes those tensions; + + o discuss how some solutions will be radically changed by ciphertext + (it's ok to talk about that) + + o assume that the best possible quality of experience for the end + user is a goal; and lastly, + + o for the next two days, aim to 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: + + o ways of doing interception, legal or not, for the reasons + described in [RFC2804]; and, + + o 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 + encryption being "on by default" will have on new protocol work. The + IETF is also working on encryption at lower layers. One recent + + + + + +Rooney & Dawkins Informational [Page 8] + +RFC 8462 MaRNEW October 2018 + + + example of this work 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. + + Telecommunications networks often contain middleboxes that operators + have previously considered to be trusted, but qualifying trust is + difficult and should not be assumed. Some interesting use cases + exist with these middleboxes, such as anti-spam and malware + detection, but these need to be balanced 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 the 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 that are 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 gain an understanding of + 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 + that affect radio networks, the deployment issues that are solvable + and require no further action, and those issues that have not yet + been solved but should be addressed within the workshop. + + + + + +Rooney & Dawkins Informational [Page 9] + +RFC 8462 MaRNEW October 2018 + + +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 that 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. This has + caused some developers to encrypt content to circumvent these + technologies that are 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 these + services. 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. + + + + + + +Rooney & Dawkins Informational [Page 10] + +RFC 8462 MaRNEW October 2018 + + +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 + + Collaboration between network elements and endpoints could bring + about better content distribution. A number of suggestions were + given; these included the following: + + o Mobile Throughput Guidance [MTG]: exchanges metadata between + network elements and endpoints via TCP options. It also allows + for better understanding of how the transport protocol behaves and + further improves the user experience, although additional work on + MTG is still required. + + o Session Protocol for User Datagrams [SPUD]: a UDP-based + encapsulation protocol to allow explicit cooperation with + middleboxes while using, new encrypted transport protocols. + + o Network Status API: an API for operators to share congestion + status or the state of a cell before an application starts sending + data that could allow applications to change their behavior. + + o Traffic Classification: classifying traffic and adding these + classifications as metadata for analysis throughout the network. + This idea has trust and privacy implications. + + o Congestion Exposure [CONEX]: a mechanism where senders inform the + network about the congestion encountered by previous packets on + the same flow, in-band at the IP layer. + + o Latency versus Bandwidth: a bit that allows the content provider + to indicate whether higher bandwidth or lower latency is of + greater priority and allows the network to react based on that + indication. Where this bit resides in the protocol stack and how + it is authenticated would need to be decided. + + + + + + +Rooney & Dawkins Informational [Page 11] + +RFC 8462 MaRNEW October 2018 + + + o No Network Management Tools: disabling all network management + tools from the network and relying only on end-to-end protocols to + manage congestion. + + o Flow Queue Controlled Delay (FQ-CoDel) [FLOWQUEUE]: a hybrid + packet scheduler / Active Queue Management (AQM) [RFC7567] + algorithm aiming to reduce bufferbloat and latency. FQ-CoDel + manages packets from multiple flows and reduces the impact of + head-of-line blocking from bursty traffic. + + Some of these suggestions rely on signaling from network elements to + endpoints. Others aim to create "hop-by-hop" solutions, which could + be more aligned with how congestion is managed today but with greater + privacy implications. + + Still others rely on signaling from endpoints to network elements. + Some of these rely on implicit signaling and others on explicit + signaling. Some workshop attendees agreed that relying on + applications to explicitly declare the quality of service they + require was not a good path forward given the lack of success with + this model in the past. + +3.1.1. Competition, Cooperation, and Mobile Network Complexities + + One of the larger issues in sharing data about the problems + encountered with encrypted traffic in wireless networks is the matter + of competition; network operators are reluctant to relinquish data + about their own networks because it contains information that is + valuable to competitors, and application providers wish to protect + their users and reveal as little information as possible to the + network. Some people think that if middleboxes were authenticated + and invoked explicitly, this would be an improvement over current + transparent middleboxes that intercept traffic without endpoint + consent. Some workshop attendees suggested any exchange of + information should be bidirectional in an effort to improve + cooperation between the elements. A robust incentive framework could + provide a solution to these issues or at least help mitigate them. + + The radio access network is complex because it must deal with a + number of conflicting demands. Base stations reflect this + environment, and information within these base stations can be of + value 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 instance, understanding + how the radio resource controller and AQM [RFC7567] interact (or + don't interact) could provide valuable information for solving + + + + + +Rooney & Dawkins Informational [Page 12] + +RFC 8462 MaRNEW October 2018 + + + issues. Although many workshop attendees agreed that even though + there is a need to understand the base station, not all agreed that + the base station should be part of a future solution. + + Some suggested solutions were based on network categorization and on + providing this information to the protocols or endpoints. Completely + categorizing radio networks could be impossible due to their + complexity, but categorizing essential network properties could be + possible and valuable. + +4. Transport Layer: Issues, Optimization, and Solutions + + 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 devised to work on a specific network model that did + not anticipate the high error rates and highly variable available + bandwidth scenarios experienced on modern radio access networks. + + Furthermore, new network elements have been introduced (NATs and + network devices with large buffers creating bufferbloat), and + considerable peer-to-peer traffic is competing with traditional + client-server traffic. Consequently, the transport layer today has + requirements beyond what TCP was designed to meet. TCP has other + issues as well; too many services rely on TCP and only TCP, blocking + deployment of new transport protocols like the Stream Control + Transmission Protocol (SCTP) and Datagram Congestion Control Protocol + (DCCP). This means that true innovation on the transport layer + becomes difficult because deployment issues are more complicated than + just building a new protocol. + + The IETF is trying to solve these issues through the IAB's IP Stack + Evolution program, and the first step in this program is to collect + data. Network and content providers can provide 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. For mostly competitive reasons, network + operators do not tend to reveal network information and so are + unlikely to donate this information freely to the IETF. The GSMA is + in a position to try to collect this data and anonymize it before + bringing it to IETF, which should alleviate the network operator + worries but still provide IETF with some usable data. + + Although congestion is only detected when packet loss is encountered + and better methods based on detecting congestion would be beneficial, + a considerable amount of work has already been done on TCP, + especially innovation in bandwidth management and congestion control. + + + + + +Rooney & Dawkins Informational [Page 13] + +RFC 8462 MaRNEW October 2018 + + + Furthermore, although the deficiencies of TCP are often considered + key issues in the evolution of the Internet protocol stack, the main + route to resolve these issues may not be a new TCP, but an evolved + stack. Some workshop participants suggested that SPUD [SPUD] and + Information-Centric Networking (ICN) [RFC7476] may help here. Quick + UDP Internet Connection [QUIC] engineers stated that the problems + solved by QUIC are general problems, rather than TCP issues. This + view was not shared by all attendees of the workshop. Moreover, TCP + has had some improvements in the last few years, which may mean some + of the network lower layers should be investigated to see whether + improvements can be made. + +5. Application-Layer Optimization, Caching, and CDNs + + Many discussions on the effects of encrypted traffic on radio access + networks happen between implementers and the network operators. This + session aimed to gather the opinions of the content and caching + providers regarding their experiences running over mobile networks, + the quality of experience their users expect, and the content and + caching that providers would like to achieve by working with or using + the mobile network. + + Content providers explained how even though this workshop cited + encrypted data over radio access networks as the main issue, the real + issue is network management generally, and all actors (applications + providers, networks, and devices) need to work together to overcome + these general network management issues. Content providers explained + how they assume the mobile networks are standards compliant. When + the network is not standards compliant (e.g., using non-standards- + compliant intermediaries), content providers can experience real + costs as users contact their support centers to report issues that + are difficult to test for and resolve. + + Content providers cited other common issues concerning data traffic + over mobile networks. Data subscription limits (known as "caps") + cause issues for users; users are confused about how data caps work + or are unsure how expensive media is and how much data it consumes. + Developers build products on networks not indicative of the networks + their customers are using, and not every organization has the + finances to build a caching infrastructure. + + Strongly related to content providers, content owners consider CDNs + to be trusted deliverers of content, and CDNs have shown great + success in fixed networks. Now that more traffic is moving to mobile + networks, there is a need to place caches near the user at the edge + of the mobile network. Placing caches at the edge of the mobile + network is a solution, but it requires standards developed by content + providers and mobile network operators. The IETF's CDN + + + +Rooney & Dawkins Informational [Page 14] + +RFC 8462 MaRNEW October 2018 + + + Interconnection [CDNI] Working Group aims to allow global CDNs to + interoperate with mobile CDNs, but this causes huge issues for the + caching of encrypted data between these 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 and managing the + authentication at the original content provider servers. + + At the end of the session, each panelist was asked to identify one + key collaborative work item. Work 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. + +6. Technical Analysis and Response to Potential Regulatory Reaction + + This session was conducted under the Chatham House Rule. The session + aimed to discuss regulatory and political issues, but not their worth + or need, and to understand the laws that exist and how technologists + can properly respond to them. + + Mobile networks are regulated; compliance is mandatory and can incur + costs on the mobile network operator, while non-compliance can result + in service license revocation in some nations. Regulation does vary + geographically. Some regulations are court orders and others are + self-imposed regulations, for example, "block lists" of websites such + as the Internet Watch Foundation [IWF] list. Operators are not + expected to decrypt sites, so those encrypted sites will not be + blocked because of content. + + Parental-control-type filters also exist on the network and are + easily bypassed today, vastly limiting their effectiveness. Better + solutions would allow for users to easily set these restrictions + themselves. Other regulations are also hard to meet, such as user + data patterns, or will become harder to collect, such as Internet of + Things (IoT) cases. Most attendees agreed that if a government + cannot get information it needs (and is legally entitled to have) + from network operators, they will approach content providers. Some + governments are aware of the impact of encryption and are working + with, or trying to work with, content providers. The IAB has + concluded that blocking and filtering can be done at the endpoints of + the communication. + + + + + + + +Rooney & Dawkins Informational [Page 15] + +RFC 8462 MaRNEW October 2018 + + + Not all of these regulations apply to the Internet, and the Internet + community is not always aware of their existence. Collectively, the + Internet community can work with GSMA and 3GPP and act together to + alleviate the risk imposed by encrypted traffic. Some participants + expressed concern that governments might require operators to provide + information that they no longer have the ability to provide because + previously unencrypted traffic is now being encrypted, and this might + expose operators to new liability, but no specific examples were + given during the workshop. A 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 has been collected. This is not + an exhaustive list, and no attempt was made to come to consensus + during the workshop, so there are likely at least some participants + who would not agree with any particular principle listed below. The + list is a union of participant thinking, not an intersection. + + o Encrypted Traffic: Any solution should encourage and support + encrypted traffic. + + o 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. + + o Privacy: New solutions should not introduce new ways for + information to be discovered and attributed to individual users. + + o 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 does not imply + that other workshop participants agreed. Again, the list is a union + of proposed solutions, not an intersection. + + o 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. + + + +Rooney & Dawkins Informational [Page 16] + +RFC 8462 MaRNEW October 2018 + + + o Congestion Control: Many attendees cited congestion control as a + key issue. Further analysis, investigation, and work could be + done in this space. + + o Sprout [SPROUT]: Researched at MIT, Sprout is a transport protocol + for applications that desire high throughput and low delay. + + o 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. + + o 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. + + o Blind Caching [BLIND_CACHING]: This is a proposal for caching of + encrypted content. + + o CDN Improvements: This includes Keyless SSL and better CDN + placement. + + o 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. + + o 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. + + o 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. + + o 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. + + + + + + +Rooney & Dawkins Informational [Page 17] + +RFC 8462 MaRNEW October 2018 + + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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] + + o Meaningful capacity sharing: This includes the ConEx [CONEX] work, + which exposes information about congestion to the network nodes. + + o 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. + + o 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. + + o 5G: Mobile operator standards bodies are in the process of setting + the requirements for 5G. Requirements for network management + could be added. + + + + +Rooney & Dawkins Informational [Page 18] + +RFC 8462 MaRNEW October 2018 + + + In the workshop, attendees identified other areas where greater + understanding could help the standards process. These were + identified as: + + o greater understanding of the RAN within the IETF; + + o reviews and comments on 3GPP perspective; and, + + o how to do congestion control in the RAN. + +7.1. Better Collaboration + + Throughout the workshop, attendees placed 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 + + Since MaRNEW, a number of activities have taken place in various IETF + working groups and in groups external to IETF. The Alternatives to + Content Classification for Operator Resource Deployment (ACCORD) BoF + was held at IETF 95 in November 2015, which brought the workshop + discussion to the wider IETF audiences by providing an account of the + discussions that had taken place within the workshop and highlighting + key areas to progress on. Key areas to progress on and an update on + their current status are as follows: + + o The collection of usable metrics and data were requested by a + number of MaRNEW attendees, especially for use within the IRTF + Measurement and Analysis for Protocols (MAP) Research Group; this + data has been difficult to collect due to the closed nature of + mobile network operators. + + o Understanding impediments to protocol stack evolution has + continued within the IAB's IP Stack Evolution program and + throughout transport-related IETF working groups such as the + Transport Area Working Group (TSVWG). + + o The Mobile Throughput Guidance document [MTG] has entered into a + testing and data collection phase, although further advancements + in transport technologies (QUIC, among others) may have stalled + efforts in TCP-related proposals. + + + + + + +Rooney & Dawkins Informational [Page 19] + +RFC 8462 MaRNEW October 2018 + + + o Work on proposals for caching encrypted content continue, albeit + with some security flaws that proponents are working on further + proposals to fix. Most often, these are discussed within the IETF + HTTPbis Working Group. + + o The Path Layer UDP Substrate (PLUS) BOF at IETF 96 in July 2016 + did not result in the formation of a working group, as attendees + expressed concern on the privacy issues associated with the + proposed data-sharing possibilities of the shim layer. + + o The Limited Use of Remote Keys (LURK) BOF at IETF 96 in July 2016 + did not result in the formation of a working group because the BOF + identified more problems with the presumed approach than + anticipated. + + The most rewarding output of MaRNEW is perhaps the most intangible. + MaRNEW gave two rather divergent industry groups the opportunity to + connect and discuss common technologies and issues affecting users + and operations. Mobile network providers and key Internet engineers + and experts have developed a greater collaborative relationship to + aid development of further standards that work across networks in a + secure manner. + +9. Security Considerations + + This document is an IAB report from a workshop on 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 + + [BLIND_CACHING] + Thomson, M., Eriksson, G., and C. Holmberg, "Caching + Secure HTTP Content using Blind Caches", Work in + Progress, draft-thomson-http-bc-01, October 2016. + + [CDNI] IETF, "Content Delivery Networks Interconnection (cdni)", + . + + [CHATHAM_HOUSE_RULE] + Chatham House, "Chatham House Rule | Chatham House", + . + + + +Rooney & Dawkins Informational [Page 20] + +RFC 8462 MaRNEW October 2018 + + + [CONEX] IETF, "Congestion Exposure (conex) - Documents", + . + + [EffectEncrypt] + Xiong, C. and M. Patel, "The effect of encrypted traffic + on the QoS mechanisms in cellular networks", August 2015, + . + + [FLOWQUEUE] + Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, + J., and E. Dumazet, "FlowQueue-Codel", Work in Progress, + draft-hoeiland-joergensen-aqm-fq-codel-01, November 2014. + + [GSMA] GSMA, "GSMA Homepage", . + + [IWF] IWF, "Internet Watch Foundation Homepage", + . + + [KeylessSSL] + Sullivan, N., "Keyless SSL: The Nitty Gritty Technical + Details", September 2014, . + + [LURK] Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, + "LURK TLS/DTLS Use Cases", Work in Progress, + draft-mglt-lurk-tls-use-cases-02, June 2016. + + [MARNEW] IAB, "Managing Radio Networks in an Encrypted World + (MaRNEW) Workshop 2015", + . + + [MTG] Jain, A., Terzis, A., Flinck, H., Sprecher, N., + Arunachalam, S., Smith, K., Devarapalli, V., and R. Yanai, + "Mobile Throughput Guidance Inband Signaling Protocol", + Work in Progress, draft-flinck-mobile-throughput-guidance- + 04, March 2017. + + [NETWORK_MANAGEMENT] + Smith, K., "Network management of encrypted traffic", Work + in Progress, draft-smith-encrypted-traffic-management-05, + May 2016. + + [NOTE_WELL] + IETF, "IETF Note Well", + . + + + + + +Rooney & Dawkins Informational [Page 21] + +RFC 8462 MaRNEW October 2018 + + + [PCC] Dong, M., Li, Q., Zarchy, D., Brighten Godfrey, P., and M. + Schapira, "PCC: Re-architecting Congestion Control for + Consistent High Performance", Proceedings of the 12th + USENIX Symposium on Networked Systems Design and + Implementation (NSDI '15), USENIX Association, May 2015, + . + + [PCC-QOS] 3GPP, "Policy and charging control signalling flows and + Quality of Service (QoS) parameter mapping", 3GPP TS + 29.213, version 15.3.0, Release 15, June 2018, + . + + [Pew2014] Madden, M., "Public Perceptions of Privacy and Security in + the Post-Snowden Era", November 2014, + . + + [QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: + A UDP-Based Secure and Reliable Transport for HTTP/2", + Work in Progress, draft-tsvwg-quic-protocol-02, January + 2016. + + [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, + DOI 10.17487/RFC2804, May 2000, + . + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + . + + [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., + Tyson, G., Davies, E., Molinaro, A., and S. Eum, + "Information-Centric Networking: Baseline Scenarios", + RFC 7476, DOI 10.17487/RFC7476, March 2015, + . + + [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF + Recommendations Regarding Active Queue Management", + BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, + . + + [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of + Pervasive Encryption on Operators", RFC 8404, + DOI 10.17487/RFC8404, July 2018, + . + + + + +Rooney & Dawkins Informational [Page 22] + +RFC 8462 MaRNEW October 2018 + + + [SDO_3GPP] 3GPP, "3GPP Homepage", . + + [SPROUT] Winstein, K., Sivaraman, A., and H. Balakrishnan, + "Stochastic Forecasts Achieve High Throughput and Low + Delay over Cellular Networks", 10th USENIX Symposium on + Networked Systems Design and Implementation (NSDI + '13), USENIX Association, April 2013, + . + + [SPUD] IETF, "Session Protocol for User Datagrams (spud)", + . + + [STATE_BROWSER] + Barnes, R., "Some observations of TLS in the web", July + 2015, . + + [STATE_SERVER] + Salz, R., "Some observations of TLS in the web", July + 2015, . + + [TCPINC] "TCP Increased Security (tcpinc)", + . + + + + + + + + + + + + + + + + + + + + + + + + + + +Rooney & Dawkins Informational [Page 23] + +RFC 8462 MaRNEW October 2018 + + +Appendix A. Workshop Attendees + + o Rich Salz, Akamai + + o Aaron Falk, Akamai + + o Vinay Kanitkar, Akamai + + o Julien Maisonneuve, Alcatel Lucent + + o Dan Druta, AT&T + + o Humberto La Roche, Cisco + + o Thomas Anderson, Cisco + + o Paul Polakos, Cisco + + o Marcus Ihlar, Ericsson + + o Szilveszter Nadas, Ericsson + + o John Mattsson, Ericsson + + o Salvatore Loreto, Ericsson + + o Blake Matheny, Facebook + + o Andreas Terzis, Google + + o Jana Iyengar, Google + + o Natasha Rooney, GSMA + + o Istvan Lajtos, GSMA + + o Emma Wood, GSMA + + o Jianjie You, Huawei + + o Chunshan Xiong, Huawei + + o Russ Housley, IAB + + o Mary Barnes, IAB + + o Joe Hildebrand, IAB / Cisco + + + + +Rooney & Dawkins Informational [Page 24] + +RFC 8462 MaRNEW October 2018 + + + o Ted Hardie, IAB / Google + + o Robert Sparks, IAB / Oracle + + o Spencer Dawkins, IETF AD + + o Benoit Claise, IETF AD / Cisco + + o Kathleen Moriarty, IETF AD / EMC + + o Barry Leiba, IETF AD / Huawei + + o Ben Campbell, IETF AD / Oracle + + o Stephen Farrell, IETF AD / Trinity College Dublin + + o Jari Arkko, IETF Chair / Ericsson + + o Karen O'Donoghue, ISOC + + o Phil Roberts, ISOC + + o Olaf Kolkman, ISOC + + o Christian Huitema, Microsoft + + o Patrick McManus, Mozilla + + o Dirk Kutscher, NEC Europe Network Laboratories + + o Mark Watson, Netflix + + o Martin Peylo, Nokia + + o Mohammed Dadas, Orange + + o Diego Lopez, Telefonica + + o Matteo Varvello, Telefonica + + o Zubair Shafiq, The University of Iowa + + o Vijay Devarapalli, Vasona Networks + + o Sanjay Mishra, Verizon + + o Gianpaolo Scassellati, Vimplecom + + + + +Rooney & Dawkins Informational [Page 25] + +RFC 8462 MaRNEW October 2018 + + + o Kevin Smith, Vodafone + + o Wendy Seltzer, W3C + +Appendix B. Workshop Position Papers + + o Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu, + "Cooperation Framework between Application layer and Lower Layers" + at + + o Julien Maisonneuve, Vijay Gurbani, and Thomas Fossati, "The + security pendulum" at + + o Martin Peylo, "Enabling Secure QoE Measures for Internet + Applications over Radio Networks is a MUST" at + + + o Vijay Devarapalli, "The Bandwidth Balancing Act: Managing QoE as + encrypted services change the traffic optimization game" at + + + o Humberto J. La Roche, "Use Cases for Communicating End-Points in + Mobile Network Middleboxes" at + + o Patrick McManus and Richard Barnes, "User Consent and Security as + a Public Good" at + + o Iuniana Oprescu, Jon Peterson, and Natasha Rooney, "A Framework + for Consent and Permissions in Mediating TLS" at + + + o Jari Arkko and Goran Eriksson, "Characteristics of Traffic Type + Changes and Their Architectural Implications" at + + + o Szilveszter Nadas and Attila Mihaly, "Concept for Cooperative + Traffic Management" at + + + + + +Rooney & Dawkins Informational [Page 26] + +RFC 8462 MaRNEW October 2018 + + + o Gianpaolo Scassellati, "Vimpelcom Position paper for MaRNEW + Workshop" at + + o Mirja Kuhlewind, Dirk Kutscher, and Brian Trammell, "Enabling + Traffic Management without DPI" at + + o Andreas Terzis and Chris Bentzel, "Sharing network state with + application endpoints" at + + o Marcus Ihlar, Salvatore Loreto, and Robert Skog, "The needed + existence of PEP in an encrypted world" at + + o John Mattsson, "Network Operation in an All-Encrypted World" at + + + o Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello, and Paul + Polakos, "Maintaining Efficiency and Privacy in Mobile Networks + through Information-Centric Networking" at + + o Chunshan Xiong and Milan Patel, "The effect of encrypted traffic + on the QoS mechanisms in cellular networks" at + + + o Thomas Anderson, Peter Bosch, and Alessandro Duminuco, "Bandwidth + Control and Regulation in Mobile Networks via SDN/NFV-Based + Platforms" at + + o Karen O'Donoghue and Phil Roberts, "Barriers to Deployment: + Probing the Potential Differences in Developed and Developing + Infrastructure" at + + o Wendy Seltzer, "Security, Privacy, and Performance Considerations + for the Mobile Web" at + + o Jianjie You, Hanyu Wei, and Huaru Yang, "Use Case Analysis and + Potential Bandwidth Optimization Methods for Encrypted Traffic" at + + + + +Rooney & Dawkins Informational [Page 27] + +RFC 8462 MaRNEW October 2018 + + + o Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and + Encrypted Traffic" at + + o Yves Hupe, Claude Rocray, and Mark Santelli, "Providing + Optimization of Encrypted HTTP Traffic" at + + o M. Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted + Internet" at + + o Kevin Smith, "Encryption and government regulation: what happens + now?" at + +Acknowledgements + + Stephen Farrell reviewed this report in draft form and provided + copious comments and suggestions. + + 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 + + + + + + + + +Rooney & Dawkins Informational [Page 28] + -- cgit v1.2.3