idnits 2.17.1 draft-iab-marnew-report-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2018) is 2160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board N. Rooney 3 Internet-Draft GSMA 4 Intended status: Informational S. Dawkins, Ed. 5 Expires: November 26, 2018 Wonder Hamster 6 May 25, 2018 8 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) 9 Report 10 draft-iab-marnew-report-02 12 Abstract 14 The Internet Architecture Board (IAB) and GSM Association (GSMA) held 15 a joint workshop on "Managing Radio Networks in an Encrypted World" 16 (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss 17 solutions for bandwidth optimisation on mobile networks for encrypted 18 content, as current solutions rely on unencrypted content which is 19 not indicative of the security needs of today's Internet users. The 20 workshop gathered IETF attendees, IAB members and participants from 21 various organisations involved in the telecommunications industry 22 including original equipment manufacturers, content providers, and 23 mobile network operators. 25 The group discussed the current Internet encryption trends and 26 deployment issues identified within the IETF, and the privacy needs 27 of users which should be adhered. Solutions designed around sharing 28 data from the network to the endpoints and vice versa were then 29 discussed as well as analysing whether issues experienced when using 30 current transport layer protocols are also playing a role here. 31 Content providers and CDNs gave their own views of their experiences 32 delivering their content with mobile network operators. Finally, 33 technical responses to regulation was discussed to help the regulated 34 industries relay the issues of impossible-to-implement or bad-for- 35 privacy technologies back to regulators. 37 A group of suggested solutions were devised which will be discussed 38 in various IETF groups moving forward. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on November 26, 2018. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Understanding "Bandwidth Optimization" . . . . . . . . . 3 73 1.2. Topics . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.3. Organization of this report . . . . . . . . . . . . . . . 5 75 1.4. Use of Note Well and Chatham House Rule . . . . . . . . . 5 76 1.5. IETF and GSMA . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Scene Setting Sessions . . . . . . . . . . . . . . . . . . . 6 78 2.1. Scene Setting . . . . . . . . . . . . . . . . . . . . . . 6 79 2.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.1.2. Encryption Statistics and Radio Access Network 81 Differences . . . . . . . . . . . . . . . . . . . . . 7 82 2.2. Encryption Deployment Considerations . . . . . . . . . . 8 83 2.3. Awareness of User Choice (Privacy) . . . . . . . . . . . 8 84 3. Network or Transport Solution Sessions . . . . . . . . . . . 9 85 3.1. Sending Data Up / Down for Network Management Benefits . 10 86 3.1.1. Competition, Cooperation, and Mobile Network 87 Complexities . . . . . . . . . . . . . . . . . . . . 11 88 4. Transport Layer: Issues, Optimisation and Solutions . . . . . 11 89 5. Application Layer Optimisation, Caching and CDNs . . . . . . 12 90 6. Technical Analysis and Response to Potential Regulatory 91 Reaction . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 7. Suggested Principles and Solutions . . . . . . . . . . . . . 14 93 7.1. Better Collaboration . . . . . . . . . . . . . . . . . . 17 94 8. Since MaRNEW . . . . . . . . . . . . . . . . . . . . . . . . 17 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 98 12. Informative References . . . . . . . . . . . . . . . . . . . 19 99 Appendix A. Workshop Attendees . . . . . . . . . . . . . . . . . 22 100 Appendix B. Workshop Position Papers . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 The Internet Architecture Board (IAB) and GSM Association (GSMA) held 106 a joint workshop on "Managing Radio Networks in an Encrypted World" 107 (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss 108 solutions for bandwidth optimisation on mobile networks for encrypted 109 content, as current solutions rely on unencrypted content which is 110 not indicative of the security needs of today's Internet users. 112 Mobile networks have a set of properties which places a large 113 emphasis on sophisticated bandwidth optimization. Encryption is 114 increasing on the Internet which is positive for consumer and 115 business privacy and security. Many existing mobile bandwidth 116 optimization solutions primarily operate on non-encrypted 117 communications; this can lead to performance issues being amplified 118 on mobile networks. The use of encryption on networks will continue 119 to increase, and with this understanding the workshop aimed to 120 understand how we can solve the issues of bandwidth optimization and 121 performance on radio networks in this encrypted world. 123 1.1. Understanding "Bandwidth Optimization" 125 For the purposes of this workshop, bandwidth optimization encompasses 126 a variety of technical topics related to traffic engineering, 127 prioritisation, optimisation and efficiency enhancements. It also 128 encompasses user-related topics such as specific subscription or 129 billing models, and may touch upon regulatory aspects or other issues 130 relating to government-initiated regulatory concerns. 132 The first category of bandwidth optimization includes: 134 o Caching 136 o Prioritisation of interactive traffic over background traffic 138 o Per-user bandwidth limit 140 The second category of bandwidth optimization may depend on one or 141 more of the first category optimization strategies, but may, in 142 particular, also encompass business-related topics such as content 143 delivery arrangements with content providers. 145 Finally, while not strictly speaking traffic management, some 146 networks employ policy-based filtering (e.g., requested parental 147 controls) and many networks support some form of legal interception 148 functionality per applicable laws. 150 Many of these functions can continue as they are performed today, 151 even with encreased use of encryption. Others are using methods 152 which inspect parts of the communication that will be encrypted, and 153 these functions will have to be done differently in an increasingly 154 encrypted Internet. 156 1.2. Topics 158 The workshop aimed to answer questions including: 160 o Understanding the bandwidth optimization use cases particular to 161 radio networks 163 o Understanding existing approaches and how these do not work with 164 encrypted traffic 166 o Understanding reasons why the Internet has not standardised 167 support for lawful intercept and why mobile networks have 169 o Determining how to match traffic types with bandwidth optimization 170 methods 172 o Discussing minimal information to be shared to manage networks but 173 ensure user security and privacy 175 o Developing new bandwidth optimization techniques and protocols 176 within these new constraints 178 o Discussing the appropriate network layer(s) for each management 179 function 181 o Cooperative methods of bandwidth optimization and issues 182 associated with these 184 The further aim was to gather architectural and engineering guidance 185 on future work in the bandwidth optimisation area based on the 186 discussions around the proposed approaches. The workshop also 187 explored possible areas for standardization, e.g. new protocols that 188 can aid bandwidth optimization whilst ensuring user security inline 189 with new work in transport layer protocols. 191 1.3. Organization of this report 193 This workshop report summarizes the contributions to and discussions 194 at the workshop, organized by topic. The workshop began with scene 195 setting topics which covered the issues around deploying encryption, 196 the increased need for privacy on the Internet and setting a clear 197 understanding that ciphertext should remain unbroken. Later sessions 198 focused on key solution areas; these included evolution on the 199 transport layer and sending data up or down the path. A session on 200 application layers and CDNs aimed to highlight both issues and 201 solutions experienced on the application layer. The workshop ended 202 with a session dedicated to technical response to regulation with 203 regards to encryption. The contributing documents were split between 204 identifying the issues experienced with encryption on radio networks 205 and suggested solutions. Of the solutions suggested some focused on 206 transport evolution, some on trusted middleboxes and others on 207 collaborative data exchange. Solutions were discussed within the 208 sessions. All accepted position papers and detailed transcripts of 209 discussion are available at [MARNEW]. 211 The outcomes of the workshop are discussed in Section 7 and 8, and 212 discuss progress after the workshop toward each of the identified 213 work items as of the time of publication of this report. 215 Report readers should be reminded that this workshop did not aim to 216 discuss regulation or legislation, although policy topics were 217 mentioned in discussions from time to time. 219 1.4. Use of Note Well and Chatham House Rule 221 The workshop was conducted under the IETF [NOTE_WELL] with the 222 exception of the "Technical Analysis and Response to Potential 223 Regulatory Reaction" session which was conducted under 224 [CHATHAM_HOUSE_RULE]. 226 1.5. IETF and GSMA 228 The IETF and GSMA [GSMA] have different working practices, standards 229 and processes. IETF is an open organisation with community driven 230 standards, with the key aim of functionality and security for the 231 Internet's users, while the GSMA is membership based and serves the 232 needs of its membership base, most of whom are mobile network 233 operators. 235 Unlike IETF, GSMA makes few standards. Within the telecommunications 236 industry standards are set in various divergent groups depending on 237 their purpose. Perhaps of most relevance to the bandwidth 238 optimisation topic here is the work of the 3rd Generation Partnership 239 Project (3GPP) [SDO_3GPP] which works on radio network and core 240 network standards. 3GPP members include mobile operators and original 241 equipment manufacturers. 243 One of the 3GPP standards relevant to this workshop is PCC-QoS 244 [PCC-QOS]. Traditionally mobile networks have managed different 245 applications and services based on the resources available and 246 priorities given; for instance, emergency services have a top 247 priority, data has a lower priority and voice services are somewhere 248 in-between. 3GPP defined the PCC-QoS mechanism to support this 249 functionality, and this depends on unencrypted communications 250 [EffectEncrypt]. 252 2. Scene Setting Sessions 254 Scene setting sessions aimed to bring all attendees up to a basic 255 understanding of the problem and the scope of the workshop. There 256 were three scene setting sessions: Scene Setting (defining scope), 257 Encryption Deployment Considerations and Trust Models and User Choice 258 (Privacy). 260 2.1. Scene Setting 262 The telecommunications industry and Internet standards community are 263 extremely different in terms of ethos and practices. Both groups 264 drive technical standards in their domain and build technical 265 solutions with some policy-driven use cases. These technologies, use 266 cases and technical implementations are different, and the motivators 267 between the two industries are also diverse. 269 To ensure all attendees were aligned with contributing to discussions 270 and driving solutions this "Scene Setting" session worked on 271 generating a clear scope with all attendees involved. In short: it 272 was agreed that ciphertext encrypted by one party and intended to be 273 decrypted by a second party should not be decrypted by a third party 274 in any solution, that the radio access network (RAN) does experience 275 issues with increased encrypted traffic, that we need to understand 276 what those problems are precisely and that our goal is to improve 277 user experience on the Internet. Proposing new technical solutions 278 based on presumed future regulation was not in scope. The full scope 279 is given below. 281 2.1.1. Scope 283 The attendees identified and agreed the following scope: 285 o In discussion we should assume: No broken crypto, Ciphertext 286 increasingly common, congestion does need to be controlled as do 287 other transport issues and Network management including efficient 288 use of resources, in RAN and elsewhere, has to work 290 o How/why is RAN different for transport; help us understand the 291 complexities of the RAN and how hard it is to manage and why those 292 matter 294 o What are the precise problems caused by more ciphertext 296 o Identify players, in addition to end users, the resulting tensions 297 and how ciphertext changes those 299 o Some solutions will be radically changed by ciphertext, it's ok to 300 talk about that 302 o The best possible quality of experience for the end user is a goal 304 o Our aim for the next two days is to analyse the situation and 305 identify specific achievable tasks that could be tackled in the 306 IETF or GSMA (or elsewhere?) and that improve the Internet given 307 the assumptions above 309 o We should not delve into: 311 * Ways of doing interception (legal or not), for the reasons 312 described in [RFC2804] 314 * Unpredictable political actions. 316 2.1.2. Encryption Statistics and Radio Access Network Differences 318 Attendees were shown that encrypted content is reaching around 50% 319 according to then-current statistics [STATE_BROWSER] and 320 [STATE_SERVER]. The IAB is encouraging all IETF working groups to 321 consider the effect encryption being "on by default" will have on new 322 protocol work, and the IETF is also working on encryption at lower 323 layers. One recent example of this work is opportunistic TCP 324 encryption within the [TCPINC] Working Group. The aims of these work 325 items are greater security and privacy for end users and their data. 327 Telecommunications networks often contain middleboxes that operators 328 have previously considered to be trusted, but qualifying trust is 329 difficult and should not be assumed. Some interesting use cases 330 exist with these middleboxes, such as anti-spam and malware 331 detection, but these need to be balanced against their ability to 332 open up cracks in the network for attacks such as pervasive 333 monitoring. 335 When operators increase the number of radio access network cells 336 ("Base Stations"), this can improve the radio access network quality 337 of service , but also adds to radio pollution. This is one example 338 of the balancing act required when devising radio access network 339 architecture. 341 2.2. Encryption Deployment Considerations 343 Encryption across the Internet is on the rise. However, some 344 organisations and individuals come across a common set of operational 345 issues when deploying encryption, mainly driven by commercial 346 perspectives. The [UBIQUITOUS] draft explains these network 347 management function impacts, detailing areas around incident 348 monitoring, access control management, and regulation on mobile 349 networks. The data was collected from various Internet players, 350 including system and network administrators across enterprise, 351 governmental organisations and personal use. The aim of the document 352 is to gain an understanding of what is needed for technical solutions 353 to these issues, maintaining security and privacy for users. 354 Attendees commented that worthwhile additions would be: different 355 business environments (e.g. cloud environments) and service chaining. 356 Incident monitoring in particular was noted as a difficult issue to 357 solve given the use of URL in today's incident monitoring middleware. 359 Some of these impacts to mobile networks can be resolved using 360 difference methods and the [NETWORK_MANAGEMENT] draft details these 361 methods. The draft focuses heavily on methods to manage network 362 traffic without breaching user privacy and security. 364 By reviewing encryption depoyment issues and the alternative methods 365 of network management MaRNEW attendees were made aware of the issues 366 which affect radio networks, the deployment issues which are solvable 367 and require no further action, and those which aren't currently 368 solveable and which should be addressed within the workshop. 370 2.3. Awareness of User Choice (Privacy) 372 Some solutions intended to improve delivery of encrypted content 373 could affect some or all of the privacy benefits that encryption 374 provides. Understanding user needs and desires for privacy is 375 therefore important when designing these solutions. 377 From a then-current study [Pew2014] 64% of users said concerns over 378 privacy have increased, 67% of mobile Internet users would like to do 379 more to protect their privacy. The World Wide Web Consortium (W3C) 380 and IETF have both responded to user desires for better privacy by 381 recommending encryption for new protocols and web technologies. 382 Within the W3C new security standards are emerging and the design 383 principles for HTML hold that users are the stakeholders with most 384 priority, followed by implementors and other stakeholders, further 385 enforcing the "user first" principle. Users also have certain 386 security expectations from particular contexts, and sometimes use new 387 technologies to further protect their privacy even if those 388 technologies weren't initially developed for that purpose. 390 Operators may deploy technologies which can impact user privacy 391 without being aware of those privacy implications or incorrectly 392 assume that the benefits users gain from the new technology outweigh 393 the loss of privacy. If these technologies are necessary they should 394 be opt-in. 396 Internet stakeholders should understand the priority of other 397 stakeholders. Users should be considered the first priority. Other 398 stakeholders include implementors, developers, advertisers, operators 399 and other ISPs. Some technologies such as cookie use and JavaScript 400 injection have been abused by these parties. This has caused some 401 developers to encrypt content to circumvent these technologies which 402 are seen as intrusive or bad for user privacy. 404 If users and content providers are to opt-in to network management 405 services with negative privacy impacts, they should see clear value 406 from using these services, and understand the impacts of using these 407 services. Users should also have easy abilities to opt-out. Some 408 users will always automatically click through consent requests, so 409 any model relying on explicit consent is flawed for these users. 410 Understanding the extent of "auto click through" may improve 411 decisions about the use of consent requests in the future. One model 412 (Cooperative Traffic Management) works as an agent of the user; by 413 opting-in metadata can be shared. Issues with this involve trust 414 only being applied at endpoints. 416 3. Network or Transport Solution Sessions 418 Network or Transport Solution Sessions aimed to discuss proposed 419 solutions for managing encrypted traffic on radio access networks. 420 Most solutions focus on metadata sharing, whether this sharing takes 421 place from the endpoint to the network, from the network to the 422 endpoint, or cooperatively in both directions. Transport layer 423 protocol evolution could be another approach to solve some of the 424 issues radio access networks erience which cause them to rely on 425 network management middleboxes. By removing problems at the 426 transport layer, reliance on expensive and complex middleboxes could 427 decrease. 429 3.1. Sending Data Up / Down for Network Management Benefits 431 Collaboration between network elements and endpoints could bring 432 about better content distribution. A number of suggestions were 433 given; these included: 435 o Mobile Throughput Guidance [MTG]: exchanges metadata between 436 network elements and endpoints via TCP Options. It also allows 437 for better understanding of how the transport protocol behaves and 438 improving user experience further, although additional work on MTG 439 is still required. 441 o SPUD [SPUD]: a UDP-based encapsulation protocol to allow explicit 442 cooperation with middleboxes while using new, encrypted transport 443 protocols. 445 o Network Status API: An API for operators to share congestion 446 status or the state of a cell before an application starts sending 447 data could allow applications to change their behaviour. 449 o Traffic classification: classifying traffic and adding these 450 classifications as metadata for analysis throughout the network. 451 This idea has trust and privacy implications. 453 o ConEx [CONEX]: a mechanism where senders inform the network about 454 the congestion encountered by previous packets on the same flow, 455 in-band at the IP layer. 457 o Latency versus Bandwidth: allowing the content provider to 458 indicate whether higher bandwidth or lower latency is of greater 459 priority and allowing the network to react based on that 460 indication. Where this bit resides in the protocol stack and how 461 it is authenticated would need to be decided. 463 o No network management tools: disabling all network management 464 tools from the network and rely only on end-to-end protocols to 465 manage congestion. 467 o Fairness-aware Delay-controlled Controlled Delay (FD-CoDel) 468 [FLOWQUEUE]: a hybrid packet scheduler/Active Queue Management 469 (AQM, [RFC7567]) algorithm, aiming to reduce bufferbloat and 470 latency. FQ-CoDel manages packets from multiple flows and reduces 471 the impact of head-of-line blocking from bursty traffic. 473 Some of these suggestions rely on signaling from network elements to 474 endpoint. Others aim to create "hop-to-hop" solutions, which could 475 be more aligned with how congestion is managed today, but with 476 greater privacy implications. 478 Still others rely on signaling from endpoints to network elements. 479 Some of these rely on implicit signaling, and others on explicit 480 signaling. Some workshop attendees agreed that relying on 481 applications to explicitly declare the quality of service they 482 require was not a good path forward, given the lack of success with 483 this model in the past. 485 3.1.1. Competition, Cooperation, and Mobile Network Complexities 487 One of the larger issues in the sharing of data about the problems 488 encountered with encrypted traffic in wireless networks is the matter 489 of competition; network operators are reluctant to relinquish data 490 about their own networks because it contains information that is 491 valuable to competitors, and application providers wish to protect 492 their users and reveal as little information as possible to the 493 network. Some people think that if middleboxes were authenticated 494 and invoked explicitly, this would be an improvement over current 495 transparent middleboxes that intercept traffic without endpoint 496 consent. Some workshop attendees suggested any exchange of 497 information should be bidirectional, in an effort to improve 498 cooperation between the elements. A robust incentive framework could 499 provide a solution to these issues, or at least help mitigate them. 501 The radio access network is complex because it must deal with a 502 number of conflicting demands. Base stations reflect this 503 environment, and information within these base stations can be of 504 value to other entities on the path. Some workshop participants 505 thought solutions for managing congestion on radio networks should 506 involve the base station if possible. For instance, understanding 507 how the Radio Resource Controller and AQM [RFC7567] interact (or 508 don't interact) could provide valuable information for solving 509 issues. Although many workshop attendees agreed that even though 510 there is a need to understand the base station, not all agreed that 511 the base station should be part of a future solution. 513 Some suggested solutions were based on network categorisation and on 514 providing this information to the protocols or endpoints. Completely 515 categorising radio networks could be impossible due to their 516 complexity, but categorising essential network properties could be 517 possible and valuable. 519 4. Transport Layer: Issues, Optimisation and Solutions 521 TCP has been the dominant transport protocol since TCP/IP replaced 522 the NCP Network Control Protocol on the Arpanet in March 1983. TCP 523 was originally devised to work on a specific network model that did 524 not anticipate the high error rates and highly variable available 525 bandwidth scenarios experienced on modern radio access networks. 527 Furthermore new network elements have been introduced (NATs and 528 network devices with large buffers creating bufferbloat), and 529 considerable peer-to-peer traffic is competing with traditional 530 client-server traffic. Consequently the transport layer today has 531 requirements beyond what TCP was designed to meet. TCP has other 532 issues as well; too many services rely on TCP and only TCP, blocking 533 deployment of new transport protocols like SCTP and DCCP. This means 534 that true innovation on the transport layer becomes difficult because 535 deployment issues are more complicated than just building a new 536 protocol. 538 The IETF is trying to solve these issues through the IAB's "Stack 539 Evolution" programme, and the first step in this programme is to 540 collect data. Network and content providers can provide data 541 including: the cost of encryption, the advantages of network 542 management tools, the deployment of protocols, and the effects when 543 network management tools are disabled. Network operators do not tend 544 to reveal network information mostly for competitive reasons and so 545 are unlikely to donate this information freely to IETF. The GSMA is 546 in a position to try to collect this data and anonymise it before 547 bringing it to IETF which should alleviate the network operator 548 worries but still provide IETF with some usable data. 550 A considerable amount of work has already been done on TCP, 551 especially innovation in bandwidth management and congestion control; 552 although congestion is only detected when packet loss is encountered, 553 and better methods based on detecting congestion would be beneficial. 555 Furthermore, although the deficiencies of TCP are often considered as 556 key issues in the evolution of the Internet protocol stack, the main 557 route to resolve these issues may not be a new TCP, but an evolved 558 stack. Some workshop participants thought SPUD [SPUD] and ICN 559 [RFC7476] are two suggestions which may help here. QUIC [QUIC] 560 engineers stated that the problems solved by QUIC are general 561 problems, rather than TCP issues. This view was not shared by all 562 attendees of the workshop. Moreover, TCP has had some improvements 563 in the last few years which may mean some of the network lower layers 564 should be investigated to see whether improvements can be made here. 566 5. Application Layer Optimisation, Caching and CDNs 568 Many discussions on the effects of encrypted traffic on radio access 569 networks happen between implementers and the network operators; this 570 session aimed to gather the opinions of the content and caching 571 providers including their experiences running over mobile networks, 572 the quality of experience their users expect, and what content and 573 caching providers would like to achieve by working with or using the 574 mobile network. 576 Content providers explained how even though this workshop cited 577 encrypted data over radio access networks as the main issue, the real 578 issue is network management generally, and all actors (applications 579 providers, networks and devices) need to work together to overcome 580 these general network management issues. Content providers explained 581 how they assume the mobile networks are standard compliant. When the 582 network is not standards compliant (e.g. using non-standards- 583 compliant intermediaries) content providers can experience real costs 584 as users contact their support centres to report issues which are 585 difficult to test for and resolve. 587 Content providers cited other common issues concerning data traffic 588 over mobile networks. Data subscription limits ("caps") cause issues 589 for users; users are confused about how data caps work or are unsure 590 how expensive media is and how much data it consumes. Developers 591 build products on networks not indicative of the networks their 592 customers are using and not every organisation has the finances to 593 build a caching infrastructure. 595 Strongly related to content providers, content owners consider CDNs 596 to be trusted deliverers of content and CDNs have shown great success 597 in fixed networks. Now that more traffic is moving to mobile 598 networks there is a need to place caches at the edge of the mobile 599 network, near the users. Placing caches at the edge of the mobile 600 network is a solution, but requires standards developed by content 601 providers and mobile network operators. The CNDi Working Group 602 [CDNI] at IETF aims to allow global CDNs to interoperate with mobile 603 CDNs; but this causes huge issues for the caching of encrypted data 604 between these CDNs. Some CDNs are experimenting with approaches like 605 "Keyless SSL" [KeylessSSL] to enable safer storage of content without 606 passing private keys to the CDN. Blind Caching [BLIND_CACHING] is 607 another proposal aimed at caching encrypted content closer to the 608 user and managing the authentication at the original content provider 609 servers. 611 At the end of the session each panelist was asked to identify one key 612 collaborative work item. Work items named were: evolving to cache 613 encrypted content, using one-bit for latency / bandwidth trade-off 614 (explained below), better collaboration between the network and 615 application, better metrics to aid troubleshooting and innovation, 616 and indications from the network to allow the application to adapt. 618 6. Technical Analysis and Response to Potential Regulatory Reaction 620 This session was conducted under Chatham House Rule. The session 621 aimed to discuss regulatory and political issues, but not their worth 622 or need; rather to understand the laws that exist and how 623 technologists can properly respond to these. 625 Mobile networks are regulated, compliance is mandatory (and non- 626 compliance can result in service license revocation in some nations) 627 and can incur costs on the mobile network operator. Regulation does 628 vary geographically. Some regulations are court orders, others are 629 self-imposed regulations, for example, "block lists" of websites such 630 as the Internet Watch Foundation list [IWF]. Operators are not 631 expected to decrypt sites, so those encrypted sites will not be 632 blocked because of content. 634 Parental control-type filters also exist on the network and are 635 easily bypassed today, vastly limiting their effectiveness. Better 636 solutions would allow for users to easily set these restrictions 637 themselves. Other regulations are also hard to meet, such as user 638 data patterns, or will become harder to collect - such as "Internet 639 of Things" (IoT) cases. Most attendees agreed that if a government 640 cannot get information it needs and is legally entitled to have from 641 network operators they will approach content providers. Some 642 governments are aware of the impact of encryption and are working 643 with, or trying to work with, content providers. The IAB has 644 concluded blocking and filtering can be done at the endpoints of the 645 communication. 647 Not all of these regulations apply to the Internet, and the Internet 648 community is not always aware of their existence. Collectively the 649 Internet community can work with GSMA and 3GPP and act collectively 650 to alleviate the risk imposed by encrypted traffic. Some 651 participants expressed concern that governments might require 652 operators to provide information that they no longer have the ability 653 to provide, because previously-unencrypted traffic is now being 654 encrypted, and this might expose operators to new liability, but no 655 specific examples were given during the workshop. A suggestion from 656 some attendees was that if any new technical solutions are necessary, 657 they should easily be "switched off". 659 Some mobile network operators are producing transparency reports 660 covering regulations including lawful intercept. Operators who have 661 done this already are encouraging others to do the same. 663 7. Suggested Principles and Solutions 665 Based on the talks and discussions throughout the workshop a set of 666 suggested principles and solutions has been collected. This is not 667 an exhaustive list, and no attempt was made to come to consensus 668 during the workshop, so there are likely at least some participants 669 who would not agree with any particular principle listed below. The 670 list is a union of participant thinking, not an intersection. 672 o Encrypted Traffic: any solution should encourage and support 673 encrypted traffic. 675 o Flexibility: radio access network qualities vary vastly and the 676 network needs of content can differ significantly, so any new 677 solution should be flexible across either the network type, 678 content type, or both. 680 o Privacy: new solutions should not introduce new ways where 681 information can be discovered and attributed to individual users. 683 o Minimum data only for collaborative work: user data, application 684 data, and network data all needs protection, so new solutions 685 should use the minimum information to make a working solution. 687 A collection of solutions suggested by various participants during 688 the workshop is given below. Inclusion in this list does not imply 689 that other workshop participants agreed. Again, the list is a union 690 of proposed solutions, not an intersection. 692 o Evolving TCP or evolution on the transport layer: this could take 693 a number of forms and some of this work is already underway within 694 the IETF. 696 o Congestion Control: many attendees cited congestion control as a 697 key issue. Further analysis, investigation and work could be done 698 in this space. 700 o SPROUT: research at MIT which is a transport protocol for 701 applications that desire high throughput and low delay. [SPROUT] 703 o PCC: Performance-oriented Congestion Control: is a new 704 architecture that aims for consistent high performance even in 705 challenging scenarios. PCC endpoints observe the connection 706 between their actions and their known performance, which allows 707 them to adapt their actions. [PCC] 709 o CDNs and Caches: placing caches closer to the edge of the radio 710 network, as close as possible to the mobile user, or making more 711 intelligent CDNs would result in faster content delivery and less 712 strain on the network. 714 o Blind Caching: a proposal for caching of encrypted content 715 [BLIND_CACHING]. 717 o CDN improvements: including keyless SSL and better CDN placement. 719 o Mobile Throughput Guidance: a mechanism and protocol elements that 720 allow the cellular network to provide near real-time information 721 on capacity available to the TCP server. [MTG] 723 o One bit for latency / bandwidth trade-off: determining whether 724 using a single bit in an unencrypted transport header to 725 distinguish between traffic that the sender prefers to be queued 726 and traffic that the sender would prefer to drop rather than delay 727 provides additional benefits beyond what can be achieved without 728 this signaling. 730 o Base Station: some suggestions involved "using the Base Station", 731 but this was not defined in detail. The Base Station holds the 732 Radio Resource Controller and scheduler which could provide a 733 place to host solutions, or data from the Base Station could help 734 in devising new solutions. 736 o Identify traffic types via 5-tuple: information from the 5-tuple 737 could provide understanding of the traffic type, and network 738 management appropriate for that traffic type could then be 739 applied. 741 o Heuristics: Networks can sometimes identify traffic types by 742 observing characteristics such as data flow rate and then apply 743 network management to these identified flows. This is not 744 recommended as categorisations can be incorrect. 746 o APIs: An API for operators to share congestion status or the state 747 of a cell before an application starts sending data could allow 748 applications to change their behaviour. Alternatively an API 749 could provide the network with information on the data type, 750 allowing appropriate network management for that data type, 751 although this method exposes privacy issues. 753 o Standard approach for operator to offer services to Content 754 Providers: mobile network operators could provide caching services 755 or other services for content providers to use for faster and 756 smoother content delivery. 758 o AQM [RFC7567] and ECN [RFC3168] deployments: queuing and 759 congestion management methods have existed for some time in the 760 form of AQM, ECN and others which can help the transport and 761 Internet protocol layers adapt to congestion faster. 763 o Trust Model or Trust Framework: some solutions in this area (e.g. 764 SPUD) have a reliance on trust when content providers or the 765 network are being asked to add classifiers to their traffic. 767 o Keyless SSL [KeylessSSL]: allows content providers to maintain 768 their private keys on a "key server" and host the content 769 elsewhere (e.g. on a CDN). This could become standardised in 770 IETF. [LURK] 772 o Meaningful capacity sharing: including the ConEx [CONEX] work 773 which exposes information about congestion to the network nodes. 775 o Hop-by-hop: some suggestions offer hop-by-hop methods allowing 776 nodes to adapt flow given the qualities of the networks around 777 them and the congestion they are experiencing. 779 o Metrics and metric standards: in order to evolve current protocols 780 to be best suited to today's networks, data is needed about 781 current network conditions, protocol deployments, packet traces 782 and middlebox behaviour. Beyond this, proper testing and 783 debugging on networks could provide great insight for stack 784 evolution. 786 o 5G: Mobile operator standards bodies are in the process of setting 787 the requirements for 5G. Requirements for network management 788 could be added. 790 In the workshop, attendees identified other areas where greater 791 understanding could help the standards process. These were 792 identified as: 794 o Greater understanding of the RAN at IETF. 796 o Reviews and comments on 3GPP perspective. 798 o How to do congestion control in the RAN. 800 7.1. Better Collaboration 802 Throughout the workshop attendees placed emphasis on the need for 803 better collaboration between the IETF and telecommunications bodies 804 and organisations. The workshop was one such way to achieve this, 805 but the good work and relationships built in the workshop should 806 continue so the two groups can work on solutions which are better for 807 both technologies and users. 809 8. Since MaRNEW 811 Since MaRNEW a number of activities have taken place in various IETF 812 working groups, and in groups external to IETF. The ACCORD BoF was 813 held at IETF 95 in November 2015, which brought the workshop 814 discussion to the wider IETF audiences by providing an account of the 815 discussions that had taken place within the workshop and highlighting 816 key areas to progress on. Key areas to progress and an update on 817 their current status follows: 819 o The collection of useable metrics and data were requested by a 820 number of MaRNEW attendees, especially for use within the IRTF 821 Measurement and Analysis for Protocols (MAP) Research Group; this 822 data has been difficult to collect due to the closed nature of 823 mobile network operators. 825 o Understanding impediments to protocol stack evolution has 826 continued within the IAB's Stack Evolution programme and 827 throughout transport-related IETF working groups such as the 828 Transport Area Working Group (TSVWG). 830 o The Mobile Throughput Guidance draft has entered into a testing 831 and data collection phase; although further advancements in 832 transport technologies (among others, QUIC) may have stalled 833 efforts in TCP-related proposals. 835 o Work on proposals for caching encrypted content continue, albeit 836 with some security flaws which proponents are working on further 837 proposals to fix. Most often these are discussed within the IETF 838 HTTPbis working group. 840 o The PLUS BOF at IETF 96 in July 2016 did not result in the 841 formation of a working group, with attendees expressing concern on 842 the privacy issues associated with the data sharing possibilities 843 of the shim layer proposed. 845 o The LURK BOF at IETF 96 in July 2016 did not result in the 846 formation of a working group, because the BOF identified more 847 problems with the presumed approach than anticipated. 849 The most rewarding output of MaRNEW is perhaps the most intangible. 850 MaRNEW gave two rather divergent industry groups the opportunity to 851 connect and discuss common technologies and issues affecting users 852 and operations. Mobile Network providers and key Internet engineers 853 and experts have developed a greater collaborative relationship to 854 aid development of further standards which work across networks in a 855 secure manner. 857 9. Security Considerations 859 This document is an IAB report from a workshop on interactions 860 between network security, especially privacy, and network 861 performance. 863 It does not affect the security of the Internet, taken on its own. 865 10. IANA Considerations 867 This document makes no requests of IANA. 869 11. Acknowledgements 871 Stephen Farrell reviewed this report in draft form and provided 872 copious comments and suggestions. 874 Barry Leiba provided some clarifications on specific discussions 875 about Lawful Intercept that took place during the workshop. 877 Bob Hinden and Warren Kumari provided comments and suggestions during 878 the IAB Call for Comments. 880 Amelia Andersdotter and Shivan Kaul Sahib provided comments from the 881 Human Rights Review Team during the IAB Call for Comments. 883 12. Informative References 885 [BLIND_CACHING] 886 Holmberg, M., "Caching Secure HTTP Content using Blind 887 Caches", October 2016, . 890 [CDNI] "Content Delivery Networks Interconnection Working Group", 891 n.d., . 893 [CHATHAM_HOUSE_RULE] 894 "Chatham House Rule", n.d., 895 . 897 [CONEX] "Congestion Exposure Working Group", n.d., 898 . 900 [EffectEncrypt] 901 Patel, C., "The effect of encrypted traffic on the QoS 902 mechanisms in cellular networks", August 2015, 903 . 906 [FLOWQUEUE] 907 Dumazet, P., "FlowQueue-Codel", March 2014, 908 . 911 [GSMA] "GSMA Homepage", n.d., . 913 [IWF] "Internet Watch Foundation", n.d., 914 . 916 [KeylessSSL] 917 Sullivan, N., "Keyless SSL: The Nitty Gritty Technical 918 Details", September 2014, . 921 [LURK] Ma, D., "TLS/DTLS Content Provider Edge Server Split Use 922 Case", January 2016, . 925 [MARNEW] "MaRNEW Workshop IAB Homepage", n.d., 926 . 928 [MTG] Smith, A., "Mobile Throughput Guidance Inband Signaling 929 Protocol", September 2015, 930 . 933 [NETWORK_MANAGEMENT] 934 Smith, K., "Network management of encrypted traffic", May 935 2015, . 938 [NOTE_WELL] 939 "IETF Note Well", n.d., . 942 [PCC] Schapira, M., "PCC, Re-architecting Congestion Control for 943 Consistent High Performance", May 2015, 944 . 946 [PCC-QOS] "Policy and charging control signalling flows and Quality 947 of Service (QoS) parameter mapping", March 2016, 948 . 950 [Pew2014] "Public Perceptions of Privacy and Security in the Post- 951 Snowden Era", November 2014, 952 . 955 [QUIC] Swett, J., "QUIC, A UDP-Based Secure and Reliable 956 Transport for HTTP/2", June 2015, 957 . 960 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 961 DOI 10.17487/RFC2804, May 2000, . 964 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 965 of Explicit Congestion Notification (ECN) to IP", 966 RFC 3168, DOI 10.17487/RFC3168, September 2001, 967 . 969 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 970 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 971 "Information-Centric Networking: Baseline Scenarios", 972 RFC 7476, DOI 10.17487/RFC7476, March 2015, 973 . 975 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 976 Recommendations Regarding Active Queue Management", 977 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 978 . 980 [SDO_3GPP] 981 "3GPP Homepage", n.d., . 983 [SPROUT] Balakrishnan, K., "Stochastic Forecasts Achieve High 984 Throughput and Low Delay over Cellular Networks", April 985 2013, 986 . 989 [SPUD] "Session Protocol for User Datagrams", n.d., 990 . 992 [STATE_BROWSER] 993 Barnes, R., "Some observations of TLS in the web", July 994 2015, . 997 [STATE_SERVER] 998 Salz, R., "Some observations of TLS in the web", July 999 2015, . 1002 [TCPINC] "TCP Increased Security Working Group", n.d., 1003 . 1005 [UBIQUITOUS] 1006 Morton, K., "Effect of Ubiquitous Encryption", March 2015, 1007 . 1010 Appendix A. Workshop Attendees 1012 o Rich Salz, Akamai 1014 o Aaron Falk, Akamai 1016 o Vinay Kanitkar, Akamai 1018 o Julien Maisonneuve, Alcatel Lucent 1020 o Dan Druta, AT&T 1022 o Humberto La Roche, Cisco 1024 o Thomas Anderson, Cisco 1026 o Paul Polakos, Cisco 1028 o Marcus Ihlar, Ericsson 1030 o Szilveszter Nadas, Ericsson 1032 o John Mattsson, Ericsson 1034 o Salvatore Loreto, Ericsson 1036 o Blake Matheny, Facebook 1038 o Andreas Terzis, Google 1040 o Jana Iyengar, Google 1042 o Natasha Rooney, GSMA 1044 o Istvan Lajtos, GSMA 1046 o Emma Wood, GSMA 1048 o Jianjie You, Huawei 1050 o Chunshan Xiong, Huawei 1052 o Russ Housley, IAB 1053 o Mary Barnes, IAB 1055 o Joe Hildebrand, IAB / Cisco 1057 o Ted Hardie, IAB / Google 1059 o Robert Sparks, IAB / Oracle 1061 o Spencer Dawkins, IETF AD 1063 o Benoit Claise, IETF AD / Cisco 1065 o Kathleen Moriarty, IETF AD / EMC 1067 o Barry Leiba, IETF AD / Huawei 1069 o Ben Campbell, IETF AD / Oracle 1071 o Stephen Farrell, IETF AD / Trinity College Dublin 1073 o Jari Arkko, IETF Chair / Ericsson 1075 o Karen O'Donoghue, ISOC 1077 o Phil Roberts, ISOC 1079 o Olaf Kolkman, ISOC 1081 o Christian Huitema, Microsoft 1083 o Patrick McManus, Mozilla 1085 o Dirk Kutscher, NEC Europe Network Laboratories 1087 o Mark Watson, Netflix 1089 o Martin Peylo, Nokia 1091 o Mohammed Dadas, Orange 1093 o Diego Lopez, Telefonica 1095 o Matteo Varvello, Telefonica 1097 o Zubair Shafiq, The University of Iowa 1099 o Vijay Devarapalli, Vasona Networks 1100 o Sanjay Mishra, Verizon 1102 o Gianpaolo Scassellati, Vimplecom 1104 o Kevin Smith, Vodafone 1106 o Wendy Seltzer, W3C 1108 Appendix B. Workshop Position Papers 1110 o Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu, 1111 "Cooperation Framework between Application layer and Lower Layers" 1112 at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1113 MaRNEW_1_paper_33.pdf 1115 o Julien Maisonneuve, Thomas Fossati and Vijay Gurbani, "The 1116 security pendulum and the network" at https://www.iab.org/wp- 1117 content/IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf 1119 o Martin Peylo, "Enabling Secure QoE Measures for Internet 1120 Applications over Radio Networks is a MUST" at 1121 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1122 MaRNEW_1_paper_32.pdf 1124 o Vijay Devarapalli, "The bandwidth balancing act: Managing QoE as 1125 encrypted services change the traffic optimization game" at 1126 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1127 MaRNEW_1_paper_10.pdf 1129 o Humberto La Roche, "Use Cases for Communicating End-Points in 1130 Mobile Network Middle-Boxes" at https://www.iab.org/wp-content/ 1131 IAB-uploads/2015/08/MaRNEW_1_paper_12.pdf 1133 o Richard Barnes and Patrick McManus, "User Consent and Security as 1134 a Public Good" at https://www.iab.org/wp-content/IAB- 1135 uploads/2015/08/MaRNEW_1_paper_13.pdf 1137 o Iuniana Oprescu, Jon Peterson and Natasha Rooney, "A Framework for 1138 Consent and Permissions in Mediating TLS" at https://www.iab.org/ 1139 wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_31.pdf 1141 o Jari Arkko and Goeran Eriksson, "Characteristics of Traffic Type 1142 Changes and Their Architectural Implications" at 1143 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1144 MaRNEW_1_paper_15.pdf 1146 o Szilveszter Nadas and Attila Mihaly, "Traffic Management for 1147 Encrypted Traffic focusing on Cellular Networks" at 1148 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1149 MaRNEW_1_paper_16.pdf 1151 o Gianpaolo Scassellati, "Vimpelcom Position Paper for MaRNEW 1152 Meeting" at https://www.iab.org/wp-content/IAB-uploads/2015/09/ 1153 MaRNEW_1_paper_17.pdf 1155 o Mirja Kuehlewind, Dirk Kutscher and Brian Trammell, "Enabling 1156 Traffic Management without DPI" at https://www.iab.org/wp-content/ 1157 IAB-uploads/2015/08/MaRNEW_1_paper_18.pdf 1159 o Andreas Terzis and Chris Bentzel, "Sharing network state with 1160 application endpoints" at https://www.iab.org/wp-content/IAB- 1161 uploads/2015/08/MaRNEW_1_paper_19.pdf 1163 o Marcus Ihlar, Robert Skog and Salvatore Loreto, "The needed 1164 existence of Performance Enhancing Proxies in an Encrypted World" 1165 at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1166 MaRNEW_1_paper_20.pdf 1168 o John Mattsson, "Network Operation in an All-Encrypted World" at 1169 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1170 MaRNEW_1_paper_21.pdf 1172 o Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello and Paul 1173 Polakos, "Maintaining Efficiency and Privacy in Mobile Networks 1174 through Information-Centric Networking" at https://www.iab.org/wp- 1175 content/IAB-uploads/2015/08/MaRNEW_1_paper_23.pdf 1177 o Chunshan Xiong and Milan Patel, "The effect of encrypted traffic 1178 on the QoS mechanisms in cellular networks" at 1179 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1180 MaRNEW_1_paper_25.pdf 1182 o Thomas Anderson, Peter Bosch and Alessandro Duminuco, "Bandwidth 1183 Control and Regulation in Mobile Networks via SDN/NFV-Based 1184 Platforms" at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1185 MaRNEW_1_paper_26.pdf 1187 o Karen O'Donoghue and Phil Roberts, Barriers to Deployment: 1188 "Probing the Potential Differences in Developed and Developing 1189 Infrastructure" at https://www.iab.org/wp-content/IAB- 1190 uploads/2015/08/MaRNEW_1_paper_27.pdf 1192 o Wendy Seltzer, "Performance, Security, and Privacy Considerations 1193 for the Mobile Web" at https://www.iab.org/wp-content/IAB- 1194 uploads/2015/08/MaRNEW_1_paper_28.pdf 1196 o Jianjie You, Hanyu Wei and Huaru Yang, "Use Case Analysis and 1197 Potential Bandwidth Optimization Methods for Encrypted Traffic" at 1198 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1199 MaRNEW_1_paper_29.pdf 1201 o Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and 1202 Encrypted Traffic" at https://www.iab.org/wp-content/IAB- 1203 uploads/2015/08/MaRNEW_1_paper_30.pdf 1205 o Claude Rocray, Mark Santelli and Yves Hupe, "Providing 1206 Optimization of Encrypted HTTP Traffic" at https://www.iab.org/wp- 1207 content/IAB-uploads/2015/08/MaRNEW_1_paper_341.pdf 1209 o Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted 1210 Internet" at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1211 MaRNEW_1_paper_35.pdf 1213 o Kevin Smith, "Encryption and government regulation: what happens 1214 now?" at https://www.iab.org/wp-content/IAB-uploads/2015/09/ 1215 MaRNEW_1_paper_1.pdf 1217 Authors' Addresses 1219 Natasha Rooney 1220 GSMA 1222 Email: nrooney@gsma.com 1223 URI: https://gsma.com 1225 Spencer Dawkins (editor) 1226 Wonder Hamster 1228 Email: spencerdawkins.ietf@gmail.com