idnits 2.17.1 draft-iab-marnew-report-01.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2018) is 2257 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1145 -- Looks like a reference, but probably isn't: '2' on line 1149 -- Looks like a reference, but probably isn't: '3' on line 1154 -- Looks like a reference, but probably isn't: '4' on line 1159 -- Looks like a reference, but probably isn't: '5' on line 1163 -- Looks like a reference, but probably isn't: '6' on line 1167 -- Looks like a reference, but probably isn't: '7' on line 1171 -- Looks like a reference, but probably isn't: '8' on line 1176 -- Looks like a reference, but probably isn't: '9' on line 1181 -- Looks like a reference, but probably isn't: '10' on line 1185 -- Looks like a reference, but probably isn't: '11' on line 1189 -- Looks like a reference, but probably isn't: '12' on line 1193 -- Looks like a reference, but probably isn't: '13' on line 1198 -- Looks like a reference, but probably isn't: '14' on line 1202 -- Looks like a reference, but probably isn't: '15' on line 1207 -- Looks like a reference, but probably isn't: '16' on line 1212 -- Looks like a reference, but probably isn't: '17' on line 1217 -- Looks like a reference, but probably isn't: '18' on line 1222 -- Looks like a reference, but probably isn't: '19' on line 1226 -- Looks like a reference, but probably isn't: '20' on line 1231 -- Looks like a reference, but probably isn't: '21' on line 1235 -- Looks like a reference, but probably isn't: '22' on line 1239 -- Looks like a reference, but probably isn't: '23' on line 1243 -- Looks like a reference, but probably isn't: '24' on line 1247 == Unused Reference: 'PLUS' is defined on line 908, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-hoeiland-joergensen-aqm-fq-codel-00 == Outdated reference: A later version (-02) exists of draft-mglt-lurk-tls-use-cases-00 == Outdated reference: A later version (-04) exists of draft-flinck-mobile-throughput-guidance-03 == Outdated reference: A later version (-02) exists of draft-tsvwg-quic-protocol-00 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Rooney 3 Internet-Draft GSMA 4 Expires: August 23, 2018 S. Dawkins, Ed. 5 Wonder Hamster 6 February 19, 2018 8 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) 9 Report 10 draft-iab-marnew-report-01 12 Abstract 14 The MarNEW workshop aimed to discuss solutions for bandwidth 15 optimisation on mobile networks for encrypted content, as current 16 solutions rely on unencrypted content which is not indicative of the 17 security needs of today's Internet users. The workshop gathered IETF 18 attendees, IAB members and various organisations involved in the 19 telecommunications industry including original equipment 20 manufacturers and mobile network operators. 22 The group discussed the current Internet encryption trends and 23 deployment issues identified within the IETF, and the privacy needs 24 of users which should be adhered. Solutions designed around sharing 25 data from the network to the endpoints and vice versa were then 26 discussed as well as analysing whether the current issues experienced 27 on the transport layer are also playing a role here. Content 28 providers and CDNs gave an honest view of their experiences delivery 29 content with mobile network operators. Finally, technical responses 30 to regulation was discussed to help the regulated industries relay 31 the issues of impossible to implement or bad-for-privacy technologies 32 back to regulators. 34 A group of suggested solutions were devised which will be discussed 35 in various IETF groups moving forward. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 23, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . 4 75 1.4. Use of Note Well and Charter 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 . . . . . . . . . . 7 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 . 9 86 3.1.1. Competition, Cooperation, and Mobile Network 87 Complexities . . . . . . . . . . . . . . . . . . . . 10 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 96 10. Informative References . . . . . . . . . . . . . . . . . . . 18 97 Appendix A. Workshop Attendees . . . . . . . . . . . . . . . . . 23 98 Appendix B. Workshop Position Papers . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 Mobile networks have a set of requirements and properties which 104 places a large emphasis on sophisticated bandwidth optimization. 105 Encryption is increasing on the Internet which is positive for 106 consumer and business privacy and security. Many existing mobile 107 bandwidth optimization solutions primarily operate on non-encrypted 108 communications; this can lead to performance issues being amplified 109 on mobile networks. Encryption on networks will continue to 110 increase; and with this understanding the workshop aimed to 111 understand how we can solve the issues of bandwidth optimization and 112 performance on radio networks in this encrypted world. 114 1.1. Understanding "Bandwidth Optimization" 116 For the purposes of this workshop, bandwidth optimization encompasses 117 a variety of technical topics related to traffic engineering, 118 prioritisation, optimisation, efficiency enhancements, as well as 119 user-related topics such as specific subscription or billing models. 120 These can include: 122 o Caching 124 o Prioritisation of interactive traffic over background traffic 126 o Per-user bandwidth limit 128 o Business-related topics such as content delivery arrangements with 129 specific content providers. 131 Many of these functions can continue as they're performed today, even 132 with more encryption. Others are using methods which inspect parts 133 of the communication that are encrypted, and these will have to be 134 done differently in an encrypted Internet. 136 Finally, while not strictly speaking traffic management, some 137 networks employ policy-based filtering (e.g., requested parental 138 controls) and many networks support some form of legal interception 139 functionality per applicable laws. 141 1.2. Topics 143 The workshop aimed to answer questions including: 145 o Understanding the bandwidth optimization use cases particular to 146 radio networks 148 o Understanding existing approaches and how these do not work with 149 encrypted traffic 151 o Understanding reasons why the Internet has not standardised 152 support for lawful intercept and why mobile networks have 154 o Determining how to match traffic types with bandwidth optimization 155 methods 157 o Discussing minimal information to be shared to manage networks but 158 ensure user security and privacy 160 o Developing new bandwidth optimization techniques and protocols 161 within these new constraints 163 o Discussing the appropriate network layer(s) for each management 164 function 166 o Cooperative methods of bandwidth optimization and issues 167 associated with these 169 The further aim was to gather architectural and engineering guidance 170 on future work in the bandwidth optimisation area based on the 171 discussions around the proposed approaches. The workshop also 172 explored possible areas for standardization, e.g. new protocols that 173 can aid bandwidth optimization whilst ensuring user security inline 174 with new work in the transport layer. 176 1.3. Organization of this report 178 This workshop report summarizes the contributions to and discussions 179 at the workshop, organized by topic. The workshop began with scene 180 setting topics which covered the issues around deploying encryption, 181 the increased need for privacy on the Internet and setting a clear 182 understanding that ciphertext should remain unbroken. Later sessions 183 focused on key solution areas; these included evolution on the 184 transport layer and sending data up or down the path. A session on 185 application layers and CDNs aimed to highlight both issues and 186 solutions experienced on the application layer. The workshop ended 187 with a session dedicated to technical response to regulation with 188 regards to encryption. The contributing documents were split between 189 identifying the issues experienced with encryption on radio networks 190 and suggested solutions. Of the solutions suggested some focused on 191 transport evolution, some on trusted middleboxes and others on 192 collaborative data exchange. Solutions were discussed within the 193 sessions. All accepted position papers and detailed transcripts of 194 discussion are available at [MARNEW]. 196 The outcomes of the workshop are discussed in Section 7 and 8, and 197 discuss progress after the workshop toward each of the identified 198 work items as of the time of publication of this report. 200 Report readers should be reminded that this workshop did not aim to 201 discuss regulation or legislation, although policy topics were 202 mentioned in discussions from time to time. 204 1.4. Use of Note Well and Charter House Rule 206 The workshop was conducted under the IETF [NOTE_WELL] with the 207 exception of the "Technical Analysis and Response to Potential 208 Regulatory Reaction" session which was conducted under 209 [CHATHAM_HOUSE_RULE]. 211 1.5. IETF and GSMA 213 The IETF and GSMA [GSMA] have divergent working practices, standards 214 and processes. IETF is an open organisation with community driven 215 standards with the key aim of functionality and security for the 216 Internet's users, the GSMA is membership based and serves the needs 217 of its membership base most of whom are mobile network operators. 219 Unlike IETF, GSMA makes few standards. Within the telecommunications 220 industry standards are set in various divergent groups depending on 221 their purpose. Perhaps of most relevance to the bandwidth 222 optimisation topic here is the work of the [SDO_3GPP] which work on 223 radio network and core network standards with their members which 224 include mobile operators and original equipment manufacturers. 226 One of the [SDO_3GPP] standards relevant to this workshop is PCC-QoS 227 [PCC-QOS]. Traditionally mobile networks have managed different 228 applications and services based on the resources available and 229 priorities given; for instance, emergency services have a top 230 priority, data has a lower priority and voice services are somewhere 231 in-between. [SDO_3GPP] defined the PCC-QoS mechanism to support this 232 functionality, and this depends on unencrypted communications 233 [EffectEncrypt]. 235 2. Scene Setting Sessions 237 Scene setting sessions aimed to bring all attendees up to a basic 238 understanding of the problem and the scope of the workshop. There 239 were three scene setting sessions: Scene Setting (defining scope), 240 Encryption Deployment Considerations and Trust Models and User Choice 241 (Privacy). 243 2.1. Scene Setting 245 The telecommunications industry and Internet standards community are 246 extremely different in terms of ethos and practices. Both groups 247 drive technical standards in their domain and build technical 248 solutions with some policy-driven use cases. These technologies, use 249 cases and technical implementations are different; not only this but 250 motivators between the two industries are also diverse. 252 To ensure all attendees were aligned with contributing to discussions 253 and driving solutions this "Scene Setting" session worked on 254 generating a clear scope with all attendees involved. In short: it 255 was agreed that ciphertext encrypted by one party and intended to be 256 decrypted by a second party should not be decrypted by a third party 257 in any solution, that the radio access network (RAN) is different and 258 does experience issues with increased encrypted traffic, that we need 259 to understand what those problems are precisely and that our goal is 260 to improve user experience on the Internet. Proposing new technical 261 solutions based on presumed future regulation was not in scope. The 262 full scope is given below. 264 2.1.1. Scope 266 The attendees identified and agreed the following scope: 268 o In discussion we should assume: No broken crypto, Ciphertext 269 increasingly common, congestion does need to be controlled as do 270 other transport issues and Network management including efficient 271 use of resources, in RAN and elsewhere, has to work 273 o How/why is RAN different for transport; help us understand the 274 complexities of the RAN and how hard it is to manage and why those 275 matter 277 o What are the precise problems caused by more ciphertext 279 o Identify players, incl. Users, and resulting tensions and how 280 ciphertext changes those 282 o Some solutions will be radically changed by ciphertext, it's ok to 283 talk about that 285 o As good as possible Quality of experience for end user is a goal 287 o Our aim for the next two days is to analyse the situation and 288 identify specific achievable tasks that could be tackled in the 289 IETF or GSMA (or elsewhere?) and that improve the Internet given 290 the assumptions above 292 o We should not delve into: 294 * Ways of doing interception (legal or not), see [RFC2804] for 295 why 297 * Unpredictable political actions. 299 2.1.2. Encryption Statistics and Radio Access Network Differences 301 Attendees were shown that encrypted content is reaching around 50% 302 according to recent statistics [STATE_BROWSER] and [STATE_SERVER]. 303 The IAB are encouraging all IETF groups to consider encryption by 304 default on their new protocol work and the IETF are also working on 305 encryption on lower layers, for example TCP encryption within the 306 [TCPINC] Working Group. The aims of these items of work are greater 307 security and privacy for users and their data. 309 Telecommunications networks often contain middleboxes that operators 310 have previously considered to be trusted; but qualifying trust is 311 difficult and should not be assumed. Some interesting use cases 312 exist with these middleboxes; such as anti-spam and malware 313 detection, but these need to be balanced against their ability to 314 open up cracks in the network for attacks such as pervasive 315 monitoring. 317 When operators increase the number of radio access network cells 318 ("Base Stations"), this can improve the radio access network quality 319 of service , but also adds to radio pollution. This is one example 320 of the balancing act required when devising radio access network 321 architecture. 323 2.2. Encryption Deployment Considerations 325 Encryption across the Internet is on the rise. However, some 326 organisations and individuals come across a common set of operational 327 issues when deploying encryption, mainly driven by commercial 328 perspectives. The [UBIQUITOUS] draft explains these network 329 management function impacts, detailing areas around incident 330 monitoring, access control management, and regulation on mobile 331 networks. The data was collected from various Internet players, 332 including system and network administrators across enterprise, 333 governmental organisations and personal use. The aim of the document 334 is to gain an understanding of what is needed for technical solutions 335 to these issues, maintaining security and privacy for users. 336 Attendees commented that worthwhile additions would be: different 337 business environments (e.g. cloud environments) and service chaining. 338 Incident monitoring in particular was noted as a difficult issue to 339 solve given the use of URL in today's incident monitoring middleware. 341 Some of these impacts to mobile networks can be resolved using 342 difference methods and the [NETWORK_MANAGEMENT] draft details these 343 methods. The draft focuses heavily on methods to manage network 344 traffic without breaching user privacy and security. 346 By reviewing encryption depoyment issues and the alternative methods 347 of network management MaRNEW attendees were made aware of the issues 348 which affect radio networks, the deployment issues which are solvable 349 and require no further action, and those which aren't currently 350 solveable and which should be addressed within the workshop. 352 2.3. Awareness of User Choice (Privacy) 354 Some solutions intended to improve delivery of encrypted content 355 could affect some or all of the privacy benefits that encryption 356 provides. Understanding user needs and desires for privacy is 357 therefore important when designing these solutions. 359 From a recent study [Pew2014] 64% of users said concerns over privacy 360 have increased, 67% of mobile Internet users would like to do more to 361 protect their privacy. The W3C and IETF have both responded to user 362 desires for better privacy by recommending encryption for new 363 protocols and web technologies. Within the W3C new security 364 standards are emerging and the design principles for HTML hold that 365 users are the stakeholders with most priority, followed by 366 implementors and other stakeholders, further enforcing the "user 367 first" principle. Users also have certain security expectations from 368 particular contexts, and sometimes use new technologies to further 369 protect their privacy even if those technologies weren't initially 370 developed for that purpose. 372 Operators may deploy technologies which can impact user privacy 373 without being aware of those privacy implications or incorrectly 374 assume that the benefits users gain from the new technology outweigh 375 the loss of privacy. If these technologies are necessary they should 376 be opt-in. 378 Internet stakeholders should understand the priority of other 379 stakeholders. Users should be considered the first priority, other 380 stakeholders include implementors, developers, advertisers, operators 381 and other ISPs. Some technologies have been absued by these parties, 382 such as cookie use or JavaScript injection. This has caused some 383 developers to encrypt content to circumvent these technologies which 384 they find intrusive or bad for their users privacy. 386 If users and content providers are to opt-in to user network 387 management services with negative privacy impacts they should see 388 clear value from using these services, and understand the impacts on 389 clear interfaces. Users should also have easy abilities to opt-out. 390 Some users will always automatically click through consent requests, 391 so any model relying on explicit consent is flawed for these users. 392 Understanding the extent of "auto click through" may help make better 393 decisions for consent requests in the future. One model (Cooperative 394 Traffic Management) works as an agent of the user; by opting-in 395 metadata can be shared. Issues with this involve trust only being 396 applied at endpoints. 398 3. Network or Transport Solution Sessions 400 Network or Transport Solution Sessions aimed to discuss suggested and 401 new solutions for managing encrypted traffic on radio access 402 networks. Most solutions focus on the sharing of metadata; either 403 from the endpoint to the network, from the network to the endpoint, 404 or cooperative sharing between both. Evolutions on the transport 405 layer could be another approach to solve some of the issues radio 406 access networks erience which cause them to require network 407 management middleboxes. By removing problems at the transport layer, 408 reliance on expensive middleboxes could decrease. 410 3.1. Sending Data Up / Down for Network Management Benefits 412 Collaboration between network elements and endpoints could bring 413 about better content distribution. A number of suggestions were 414 given, these included: 416 o Mobile Throughput Guidance [MTG]: exchanges data between the 417 network elements and the endpoints via TCP Options. It also 418 allows for gaining a better idea of how the transport protocol 419 behaves and improving user experience further, although the work 420 still needs to evolve. 422 o SPUD [SPUD]: a UDP-based encapsulation protocol to allow explicit 423 cooperation with middleboxes while using new, encrypted transport 424 protocols. 426 o Network Status API: An API for operators to share congestion 427 status or the state of a cell before an application starts sending 428 data could allow applications to change their behaviour. 430 o Traffic classification: classifying traffic and adding this as 431 metadata for analysis throughout the network. This idea has trust 432 and privacy implications. 434 o ConEx [CONEX]: a mechanism where senders inform the network about 435 the congestion encountered by previous packets on the same flow, 436 in-band at the IP layer. 438 o Latency versus Bandwidth: allowing the content provider to 439 indicate whether a better bandwidth or lower latency is of greater 440 priority and allowing the network to react. Where this bit 441 resides and how to authenticate it would need to be decided. 443 o No network management tools: disabling all network management 444 tools from the network and allow the protocols to manage 445 congestion alone. 447 o FlowQueue Codel [FLOWQUEUE]: a hybrid packet scheduler/AQM 448 algorithm, aiming to reduce bufferbloat and latency. FQ-CoDel 449 mixes packets from multiple flows and reduces the impact of head 450 of line blocking from bursty traffic. 452 Some of these suggestions rely on signaling from network elements to 453 endpoint. 455 Others aim to create "hop-to-hop" solutions, which could be more 456 inline with how congestion is managed today, but with greater privacy 457 implications. 459 Still others rely on signaling from endpoints to network elements. 460 Some of these rely on implicit signaling, and others on explicit 461 signaling. Some workshop attendees agreed that applications 462 explicitly declaring what quality of service they require was not a 463 good route, given the lack of success with this model in the past. 465 3.1.1. Competition, Cooperation, and Mobile Network Complexities 467 One of the larger issues in the sharing of data is the matter of 468 competition; network operators are reluctant to relinquish data about 469 their own networks because it can competitive information, and 470 application providers wish to protect their users and reveal as 471 little information as possible to the network. Some people think 472 that if middleboxes were authenticated and invoked explicitly, this 473 would be an improvement over current transparent middleboxes that 474 intercept traffic without endpoint consent. Some workshop attendees 475 suggested any exchange of information should be bidirectional, in an 476 effort to improve cooperation between the elements. A robust 477 incentive framework could provide a solution to these issues, or at 478 least help mitigate them. 480 The radio access network is complex because it must deal with a 481 number of conflicting demands. Base stations reflect this 482 environment, and information within these base stations can be of 483 value to other entities on the path. Some workshop participants 484 thought solutions for managing congestion on radio networks should 485 involve the base station if possible. For instance, understanding 486 how the Radio Resource Controller and AQM [RFC7567] interact (or 487 don't interact) could provide valuable information for solving 488 issues. Although many workshop attendees agreed that even though 489 there is a need to understand the base station not all agreed that 490 the base station should be part of a future solution. 492 Some suggested solutions were based on network categorisation and 493 providing this information to the protocols or endpoints. 494 Categorising radio networks could be impossible due to their 495 complexity, but categorising essential network properties could be 496 possible and valuable. 498 4. Transport Layer: Issues, Optimisation and Solutions 500 TCP has been the dominant transport protocol since TCP/IP replaced 501 NCP on the Arpanet in March 1983. TCP was originally devised to work 502 on a specific network model that did not anticipate the high error 503 rates and highly variable available bandwidth scenarios experienced 504 on modern radio access networks. Furthermore new network elements 505 have been introduced (NATs and network devices with large buffers 506 creating bufferbloat), and considerable peer-to-peer traffic is 507 competing with traditional client-server traffic. Consequently the 508 transport layer today has requirements beyond what TCP was designed 509 to meet. TCP has other issues as well; too many services rely on TCP 510 and only TCP, blocking deployment of new transport protocols like 511 SCTP and DCCP. This means that true innovation on the transport 512 layer becomes difficult because deployment issues are more 513 complicated than just building a new protocol. 515 The IETF is trying to solve these issues through the "Stack 516 Evolution" programme, and the first step in this programme is to 517 collect data. Network and content providers can provide data 518 including: the cost of encryption, the advantages of network 519 management tools, the deployment of protocols, and the effects when 520 network management tools are disabled. Network operators do not tend 521 to reveal network information mostly for competition reasons and so 522 is unlikely to donate this information freely to IETF. The GSMA is 523 in a position to try to collect this data and anonymise it before 524 bringing it to IETF which should alleviate the network operator 525 worries but still provide IETF with some usable data. 527 A considerable amount of work has already been done on TCP, 528 especially innovation in bandwidth management and congestion control; 529 although congestion is usually detected by detecting loss, and better 530 methods based on detecting congestion would be beneficial. 532 Furthermore, although the deficiencies of TCP are often considered as 533 key issues in the evolution of the stack, the main route to resolve 534 these issues may not be a new TCP, but an evolved stack. Some 535 workshop participants thought SPUD [SPUD] and ICN [RFC7476] are two 536 suggestions which may help here. QUIC [QUIC] engineers stated that 537 the problems solved by QUIC are general problems, rather than TCP 538 issues. This view was not shared by all attendees of the workshop. 539 Moreover, TCP has had some improvements in the last few years which 540 may mean some of the network lower layers should be investigated to 541 see whether improvements can be made here. 543 5. Application Layer Optimisation, Caching and CDNs 545 Many discussions on the effects of encrypted traffic on radio access 546 networks happen between implementers and the network operators; this 547 session aimed to gather the opinions of the content and caching 548 providers including their experiences running over mobile networks, 549 the experience their users expect, and what they would like to 550 achieve by working with or using the mobile network. 552 Content providers explained how even though this workshop cited 553 encrypted data over radio access networks as the main issue the real 554 issue is network management generally, and all actors (applications 555 providers, networks and devices) need to work together to overcome 556 these general network management issues. Content providers explained 557 how they assume the mobile networks are standard compliant. When the 558 network is not standards compliant (e.g. using non-standards- 559 compliant intermediaries) content providers can experience real costs 560 as users contact their support centres to report issues which are 561 difficult to test for and build upon. 563 Content providers cited other common issues concerning data traffic 564 over mobile networks. Data caps cause issues for users; users are 565 confused about how data caps work or are unsure how expensive media 566 is and how much data it consumes. Developers build products on 567 networks not indicative of the networks their customers are using and 568 not every organisation has the finances to build a caching 569 infrastructure. 571 Strongly related to content providers, Content owners consider CDNs 572 to be trusted deliverers of content and CDNs have shown great success 573 in fixed networks. Now traffic is moving more to mobile networks 574 there is a need to place caches at the edge of the mobile network, 575 near the users. Placing caches at the edge of the mobile network is 576 a solution, but requires standards developed by content providers and 577 mobile network operators. The CNDi Working Group [CDNI] at IETF aims 578 to allow global CDNs to interoperate with mobile CDNs; but this 579 causes huge issues for the caching of encrypted data between these 580 CDNs. Some CDNs are experimenting with approaches like "Keyless SSL" 581 [KeylessSSL] to enable safer storage of content without passing 582 private keys to the CDN. Blind Caching [BLIND_CACHING] is another 583 proposal aimed at caching encrypted content closer to the user and 584 managing the authentication at the original content provider servers. 586 At the end of the session the panelists were asked to identify one 587 key collaborative work item, these were: evolving caching to cache 588 encrypted content, using one-bit for latency / bandwidth trade-off 589 (explained below), better collaboration between the network and 590 application, better metrics to aid bug solving and innovation, and 591 indications from the network to allow the application to adapt. 593 6. Technical Analysis and Response to Potential Regulatory Reaction 595 This session was conducted under Chatham House Rule. The session 596 aimed to discuss regulatory and political issues; but not their worth 597 or need, rather to understand the laws that exist and how 598 technologists can properly respond to these. 600 Mobile networks are regulated, compliance is mandatory (and non- 601 compliance can result in service license revocation in some nations 602 round the world) and can incur costs on the mobile network operator. 603 Regulation does vary geographically. Some regulations are court 604 orders, others are self-imposed regulations, for example, "block 605 lists" of websites such as the Internet Watch Foundation list [IWF]. 606 Operators are not expected to decrypt sites, so those identified 607 sites which are encrypted will not be blocked. 609 Parental control-type filters also exist on the network and are 610 easily bypassed today, vastly limiting their effectiveness. Better 611 solutions would allow for users to easily set these restrictions 612 themselves. Other regulations are also hard to meet - such as user 613 data patterns, or will become harder to collect - such as IoT cases. 614 Most attendees agreed that if a government cannot get information it 615 needs and is legally entitled to have from network operators they 616 will approach content providers. Some governments are aware of the 617 impact of encryption and are working with or trying to work with 618 content providers. The IAB have concluded blocking and filtering can 619 be done at the endpoint of the communication. 621 Not all of these regulations apply to the Internet, and the Internet 622 community is not always aware of their existence. Collectively the 623 Internet community can work with GSMA and 3GPP and act collectively 624 to alleviate the risk imposed by encrypted traffic. Some 625 participants expressed the concern that governments might require 626 operators to provide information that they no longer have the ability 627 to provide, because traffic has been encrypted, and this might expose 628 operators to new liability, but no specific examples were given 629 during the workshop. A suggestion from some attendees was that if 630 any new technical solutions are necessary, they should have the 631 ability to be easily switched off. 633 Some mobile network operators are producing transparency reports 634 covering regulations including lawful intercept. Operators who have 635 done this already are encouraging others to do the same. 637 7. Suggested Principles and Solutions 639 Based on the talks and discussions throughout the workshop a set of 640 suggested principles and solutions has been collected. This is not 641 an exhaustive list, and no attempt was made to come to consensus 642 during the workshop, so there are likely participants who would not 643 agree with any particular principle listed below. 645 o Encrypted Traffic: any solution should encourage and support 646 encrypted traffic. 648 o Flexibility: radio access network qualities vary vastly and 649 different network needs in content can be identified, so any new 650 solution should be flexible to either the network type or content 651 type or both. 653 o Privacy: new solutions should not introduce ways where information 654 can be discovered flows and attribute them to users. 656 o Minimum data only for collaborative work: user data, app data and 657 network data all needs protecting, so new solutions should use the 658 minimum information to make a working solution. 660 A collection of solutions suggested by various participants during 661 the workshop is given below. Inclusion in this list does not imply 662 that other workshop participants agreed. 664 o Evolving TCP or evolution on the transport layer: this could take 665 a number of forms and some of this work is already existing within 666 IETF. Other suggestions include: 668 o Congestion Control: many attendees cited congestion control as a 669 key issue, further analysis, investigation and work could be done 670 here. 672 o SPROUT: research at MIT which is a transport protocol for 673 interactive applications that desire high throughput and low 674 delay. [SPROUT] 676 o PCC: Performance-oriented Congestion Control: is a new 677 architecture that aims for consistent high performance even in 678 challenging scenarios. PCC endpoints observe the connection 679 between their actions and their known performance, which allows 680 them to adapt their actions. [PCC] 682 o CDNs and Caches: placing caches closer to the mobile user or 683 making more intelligent CDNs would result in faster content 684 delivery and less train on the network. Related work includes: 686 o Blind Caching: a proposal for caching of encrypted content 687 [BLIND_CACHING]. 689 o CDN improvements: including keyless SSL and better CDN placement. 691 o Mobile Throughput Guidance: a mechanism and protocol elements that 692 allow the cellular network to provide near real-time information 693 on capacity available to the TCP server. [MTG] 695 o One bit for latency / bandwidth trade-off: determining whether 696 using a single bit to distinguish between traffic that the sender 697 prefers to be queued and traffic that the sender would prefer to 698 drop rather than delay provides additional benefits beyond what 699 can be achieved without this signaling. 701 o Base Station: some suggestions involved "using the Base Station", 702 but this was not defined in detail. The Base Station holds the 703 Radio Resource Controller and scheduler which could provide either 704 a place to host solutions or data from the Base Station could help 705 in devising new solutions. 707 o Identify traffic types via 5-tuple: information from the 5-tuple 708 could provide understanding of the traffic type which network 709 management could then be applied. 711 o Heuristics: Networks can sometimes identify traffic types through 712 specifics such as data flow rate and then apply network management 713 to these identified flows. This is not recommended as 714 categorisations can be incorrect. 716 o APIs: An API for operators to share congestion status or the state 717 of a cell before an application starts sending data could allow 718 applications to change their behaviour. Alternatively an API 719 could provide the network with some information on the data type 720 to provide network management to, although this method exposes 721 privacy issues. 723 o Standard approach for operator to offer services to Content 724 Providers: mobile network operators could provide caching services 725 or other services for content providers to use for faster and 726 smoother content delivery. 728 o AQM [RFC7567] and ECN [RFC3168] deployments: queuing and 729 congestion management methods have existed for sometime in the 730 form of AQM, ECN and others which can help the transport and 731 Internet layer adapt to congestion faster. 733 o Trust Model or Trust Framework: some solutions in this area (e.g. 734 SPUD) have a reliance on trust when content providers or the 735 network are being asked to add classifiers to their traffic. 737 o Keyless SSL [KeylessSSL]: allows content providers to maintain 738 their private keys on a "key server" and host the content 739 elsewhere (e.g. on a CDN). This could become standardised in 740 IETF. [LURK] 742 o Meaningful capacity sharing: including the ConEx [CONEX] work 743 which exposes information about congestion to the network nodes. 745 o Hop-by-hop: some suggestions offer hop-by-hop methods allowing 746 nodes to adapt flow given the qualities of the networks around 747 them and the congestion they are experiencing. 749 o Metrics and metric standards: in order to evolve current protocols 750 to be best suited to today's networks, data is needed from the 751 current network conditions, protocol deployments, packet traces 752 and middlebox behaviour. Beyond this, proper testing and 753 debugging on networks could provide great insight for stack 754 evolution. 756 o 5G: Mobile operator standards bodies are in the process of setting 757 the requirements for 5G. Requirements for network management 758 could be added. 760 In the workshop attendees identified other areas where greater 761 understandinf could help the standards process. These were 762 identified as: 764 o Greater understanding of the RAN at IETF 766 o Reviews and comments on 3GPP perspective 768 o How to do congestion controlling in RAN. 770 7.1. Better Collaboration 772 Throughout the workshop attendees placed emphasis on the need for 773 better collaboration between the IETF and telecommunications bodies 774 and organisations. The workshop was one such way to achieve this, 775 but the good work and relationships built in the workshop should 776 continue so the two groups can work on solutions which are better for 777 both technologies and users. 779 8. Since MaRNEW 781 Since MaRNEW a number of activities have taken place in various 782 seperate working groups or groups external to IETF. The ACCORD BoF 783 was held at IETF95 which brough the workshop discussion to the wider 784 IETF audiences by providing an account of the discussions within the 785 workshop and highlighting key areas to progress on. Key areas to 786 progress and an update on their current status follows: 788 o The collection of useable metrics and data were requested by a 789 number of MaRNEW attendees; this has been difficult to collect due 790 to the closed nature of mobile network operations. 792 o The IAB's Stack Evolution programme has continued discussion and 793 development of guidance on the evolvability of protocols. 795 o The Measurement and Analysis of Protocols (MAP) Research Group was 796 chartered before IETF 96, and provides a venue for the discussion 797 of data and research on many of the topics addressed at MaRNEW, 798 including the deployment of encryption and the prevalence of in- 799 network inpairments to protocol evolution. 801 o The Mobile Throughput Guidance draft has entered into a testing 802 and data collection phase; although further advancements in 803 transport technologies (noteably QUIC) may have stalled efforts in 804 TCP-related proposals. 806 o Attempts on proposals for caching of encrypted content continue 807 albeit with some security flaws which proponents are working on 808 further proposals to fix. Most often these are discussed within 809 the HTTP WG. 811 o The PLUS BOF did not result in the formation of a working group, 812 with attendees expressing concern on the privacy issues associated 813 with the data sharing possibilities of the shim layer proposed. 815 o The LURK BOF did not result in the formation of a working group, 816 because the BOF identified more problems than anticipated with 817 this approach. 819 The most rewarding output of MaRNEW is perhaps the most intangible. 820 MaRNEW gave two rather divergent industry groups the opportunity to 821 connect and discuss common technologies and issues affecting users 822 and operations. Mobile Network providers and key Internet engineers 823 and experts have developed a greater collaborative relationship to 824 aid development of further standards which work across networks in a 825 secure manner. 827 9. Acknowledgements 829 Stephen Farrell reviewed this report in draft form and provided 830 copious comments and suggestions. 832 Barry Leiba provided corrections. 834 10. References 836 10.1. Informative References 838 [BLIND_CACHING] 839 Holmberg, M., "Caching Secure HTTP Content using Blind 840 Caches", October 2016, . 843 [CDNI] "Content Delivery Networks Interconnection Working Group", 844 n.d., . 846 [CHATHAM_HOUSE_RULE] 847 "Chatham House Rule", n.d., 848 . 850 [CONEX] "Congestion Exposure Working Group", n.d., 851 . 853 [EffectEncrypt] 854 Patel, C., "The effect of encrypted traffic on the QoS 855 mechanisms in cellular networks", August 2015, 856 . 859 [FLOWQUEUE] 860 Dumazet, P., "FlowQueue-Codel", March 2014, 861 . 864 [GSMA] "GSMA Homepage", n.d., . 866 [IWF] "Internet Watch Foundation", n.d., 867 . 869 [KeylessSSL] 870 Sullivan, N., "Keyless SSL: The Nitty Gritty Technical 871 Details", September 2014, . 874 [LURK] Ma, D., "TLS/DTLS Content Provider Edge Server Split Use 875 Case", January 2016, . 878 [MARNEW] "MaRNEW Workshop IAB Homepage", n.d., 879 . 881 [MTG] Smith, A., "Mobile Throughput Guidance Inband Signaling 882 Protocol", September 2015, 883 . 886 [NETWORK_MANAGEMENT] 887 Smith, K., "Network management of encrypted traffic", May 888 2015, . 891 [NOTE_WELL] 892 "IETF Note Well", n.d., 893 . 895 [PCC] Schapira, M., "PCC, Re-architecting Congestion Control for 896 Consistent High Performance", May 2015, 897 . 899 [PCC-QOS] "Policy and charging control signalling flows and Quality 900 of Service (QoS) parameter mapping", March 2016, 901 . 903 [Pew2014] "Public Perceptions of Privacy and Security in the Post- 904 Snowden Era", November 2014, 905 . 908 [PLUS] "Proceedings of the PLUS BoF at IETF 96, Berlin, July 909 2016", n.d., 910 . 912 [QUIC] Swett, J., "QUIC, A UDP-Based Secure and Reliable 913 Transport for HTTP/2", June 2015, 914 . 917 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 918 DOI 10.17487/RFC2804, May 2000, 919 . 921 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 922 of Explicit Congestion Notification (ECN) to IP", 923 RFC 3168, DOI 10.17487/RFC3168, September 2001, 924 . 926 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 927 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 928 "Information-Centric Networking: Baseline Scenarios", 929 RFC 7476, DOI 10.17487/RFC7476, March 2015, 930 . 932 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 933 Recommendations Regarding Active Queue Management", 934 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 935 . 937 [SDO_3GPP] 938 "3GPP Homepage", n.d., . 940 [SPROUT] Balakrishnan, K., "Stochastic Forecasts Achieve High 941 Throughput and Low Delay over Cellular Networks", April 942 2013, 943 . 946 [SPUD] Kuehlewind, B., "Requirements for the design of a Session 947 Protocol for User Datagrams (SPUD)", n.d., 948 . 950 [STATE_BROWSER] 951 Barnes, R., "Some observations of TLS in the web", July 952 2015, . 955 [STATE_SERVER] 956 Salz, R., "Some observations of TLS in the web", July 957 2015, . 960 [TCPINC] "TCP Increased Security Working Group", n.d., 961 . 963 [UBIQUITOUS] 964 Morton, K., "Effect of Ubiquitous Encryption", March 2015, 965 . 968 10.2. URIs 970 [1] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 971 MaRNEW_1_paper_33.pdf 973 [2] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 974 MaRNEW_1_paper_4.pdf 976 [3] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 977 MaRNEW_1_paper_32.pdf 979 [4] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 980 MaRNEW_1_paper_10.pdf 982 [5] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 983 MaRNEW_1_paper_12.pdf 985 [6] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 986 MaRNEW_1_paper_13.pdf 988 [7] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 989 MaRNEW_1_paper_31.pdf 991 [8] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 992 MaRNEW_1_paper_15.pdf 994 [9] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 995 MaRNEW_1_paper_16.pdf 997 [10] https://www.iab.org/wp-content/IAB-uploads/2015/09/ 998 MaRNEW_1_paper_17.pdf 1000 [11] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1001 MaRNEW_1_paper_18.pdf 1003 [12] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1004 MaRNEW_1_paper_19.pdf 1006 [13] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1007 MaRNEW_1_paper_20.pdf 1009 [14] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1010 MaRNEW_1_paper_21.pdf 1012 [15] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1013 MaRNEW_1_paper_23.pdf 1015 [16] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1016 MaRNEW_1_paper_25.pdf 1018 [17] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1019 MaRNEW_1_paper_26.pdf 1021 [18] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1022 MaRNEW_1_paper_27.pdf 1024 [19] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1025 MaRNEW_1_paper_28.pdf 1027 [20] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1028 MaRNEW_1_paper_29.pdf 1030 [21] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1031 MaRNEW_1_paper_30.pdf 1033 [22] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1034 MaRNEW_1_paper_341.pdf 1036 [23] https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1037 MaRNEW_1_paper_35.pdf 1039 [24] https://www.iab.org/wp-content/IAB-uploads/2015/09/ 1040 MaRNEW_1_paper_1.pdf 1042 Appendix A. Workshop Attendees 1044 o Rich Salz, Akamai 1046 o Aaron Falk, Akamai 1048 o Vinay Kanitkar, Akamai 1050 o Julien Maisonneuve, Alcatel Lucent 1052 o Dan Druta, AT&T 1054 o Humberto La Roche, Cisco 1056 o Thomas Anderson, Cisco 1058 o Paul Polakos, Cisco 1060 o Marcus Ihlar, Ericsson 1062 o Szilveszter Nadas, Ericsson 1064 o John Mattsson, Ericsson 1066 o Salvatore Loreto, Ericsson 1068 o Blake Matheny, Facebook 1070 o Andreas Terzis, Google 1072 o Jana Iyengar, Google 1074 o Natasha Rooney, GSMA 1076 o Istvan Lajtos, GSMA 1078 o Emma Wood, GSMA 1080 o Jianjie You, Huawei 1082 o Chunshan Xiong, Huawei 1084 o Russ Housley, IAB 1086 o Mary Barnes, IAB 1088 o Joe Hildebrand, IAB / Cisco 1089 o Ted Hardie, IAB / Google 1091 o Robert Sparks, IAB / Oracle 1093 o Spencer Dawkins, IETF AD 1095 o Benoit Claise, IETF AD / Cisco 1097 o Kathleen Moriarty, IETF AD / EMC 1099 o Barry Leiba, IETF AD / Huawei 1101 o Ben Campbell, IETF AD / Oracle 1103 o Stephen Farrell, IETF AD / Trinity College Dublin 1105 o Jari Arkko, IETF Chair / Ericsson 1107 o Karen O'Donoghue, ISOC 1109 o Phil Roberts, ISOC 1111 o Olaf Kolkman, ISOC 1113 o Christian Huitema, Microsoft 1115 o Patrick McManus, Mozilla 1117 o Dirk Kutscher, NEC Europe Network Laboratories 1119 o Mark Watson, Netflix 1121 o Martin Peylo, Nokia 1123 o Mohammed Dadas, Orange 1125 o Diego Lopez, Telefonica 1127 o Matteo Varvello, Telefonica 1129 o Zubair Shafiq, The University of Iowa 1131 o Vijay Devarapalli, Vasona Networks 1133 o Sanjay Mishra, Verizon 1135 o Gianpaolo Scassellati, Vimplecom 1136 o Kevin Smith, Vodafone 1138 o Wendy Seltzer, W3C 1140 Appendix B. Workshop Position Papers 1142 o Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu, 1143 "Cooperation Framework between Application layer and Lower Layers" 1144 at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1145 MaRNEW_1_paper_33.pdf [1] 1147 o Julien Maisonneuve, Thomas Fossati and Vijay Gurbani, "The 1148 security pendulum and the network" at https://www.iab.org/wp- 1149 content/IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf [2] 1151 o Martin Peylo, "Enabling Secure QoE Measures for Internet 1152 Applications over Radio Networks is a MUST" at 1153 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1154 MaRNEW_1_paper_32.pdf [3] 1156 o Vijay Devarapalli, "The bandwidth balancing act: Managing QoE as 1157 encrypted services change the traffic optimization game" at 1158 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1159 MaRNEW_1_paper_10.pdf [4] 1161 o Humberto La Roche, "Use Cases for Communicating End-Points in 1162 Mobile Network Middle-Boxes" at https://www.iab.org/wp-content/ 1163 IAB-uploads/2015/08/MaRNEW_1_paper_12.pdf [5] 1165 o Richard Barnes and Patrick McManus, "User Consent and Security as 1166 a Public Good" at https://www.iab.org/wp-content/IAB- 1167 uploads/2015/08/MaRNEW_1_paper_13.pdf [6] 1169 o Iuniana Oprescu, Jon Peterson and Natasha Rooney, "A Framework for 1170 Consent and Permissions in Mediating TLS" at https://www.iab.org/ 1171 wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_31.pdf [7] 1173 o Jari Arkko and Goeran Eriksson, "Characteristics of Traffic Type 1174 Changes and Their Architectural Implications" at 1175 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1176 MaRNEW_1_paper_15.pdf [8] 1178 o Szilveszter Nadas and Attila Mihaly, "Traffic Management for 1179 Encrypted Traffic focusing on Cellular Networks" at 1180 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1181 MaRNEW_1_paper_16.pdf [9] 1183 o Gianpaolo Scassellati, "Vimpelcom Position Paper for MaRNEW 1184 Meeting" at https://www.iab.org/wp-content/IAB-uploads/2015/09/ 1185 MaRNEW_1_paper_17.pdf [10] 1187 o Mirja Kuehlewind, Dirk Kutscher and Brian Trammell, "Enabling 1188 Traffic Management without DPI" at https://www.iab.org/wp-content/ 1189 IAB-uploads/2015/08/MaRNEW_1_paper_18.pdf [11] 1191 o Andreas Terzis and Chris Bentzel, "Sharing network state with 1192 application endpoints" at https://www.iab.org/wp-content/IAB- 1193 uploads/2015/08/MaRNEW_1_paper_19.pdf [12] 1195 o Marcus Ihlar, Robert Skog and Salvatore Loreto, "The needed 1196 existence of Performance Enhancing Proxies in an Encrypted World" 1197 at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1198 MaRNEW_1_paper_20.pdf [13] 1200 o John Mattsson, "Network Operation in an All-Encrypted World" at 1201 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1202 MaRNEW_1_paper_21.pdf [14] 1204 o Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello and Paul 1205 Polakos, "Maintaining Efficiency and Privacy in Mobile Networks 1206 through Information-Centric Networking" at https://www.iab.org/wp- 1207 content/IAB-uploads/2015/08/MaRNEW_1_paper_23.pdf [15] 1209 o Chunshan Xiong and Milan Patel, "The effect of encrypted traffic 1210 on the QoS mechanisms in cellular networks" at 1211 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1212 MaRNEW_1_paper_25.pdf [16] 1214 o Thomas Anderson, Peter Bosch and Alessandro Duminuco, "Bandwidth 1215 Control and Regulation in Mobile Networks via SDN/NFV-Based 1216 Platforms" at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1217 MaRNEW_1_paper_26.pdf [17] 1219 o Karen O'Donoghue and Phil Roberts, Barriers to Deployment: 1220 "Probing the Potential Differences in Developed and Developing 1221 Infrastructure" at https://www.iab.org/wp-content/IAB- 1222 uploads/2015/08/MaRNEW_1_paper_27.pdf [18] 1224 o Wendy Seltzer, "Performance, Security, and Privacy Considerations 1225 for the Mobile Web" at https://www.iab.org/wp-content/IAB- 1226 uploads/2015/08/MaRNEW_1_paper_28.pdf [19] 1228 o Jianjie You, Hanyu Wei and Huaru Yang, "Use Case Analysis and 1229 Potential Bandwidth Optimization Methods for Encrypted Traffic" at 1230 https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1231 MaRNEW_1_paper_29.pdf [20] 1233 o Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and 1234 Encrypted Traffic" at https://www.iab.org/wp-content/IAB- 1235 uploads/2015/08/MaRNEW_1_paper_30.pdf [21] 1237 o Claude Rocray, Mark Santelli and Yves Hupe, "Providing 1238 Optimization of Encrypted HTTP Traffic" at https://www.iab.org/wp- 1239 content/IAB-uploads/2015/08/MaRNEW_1_paper_341.pdf [22] 1241 o Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted 1242 Internet" at https://www.iab.org/wp-content/IAB-uploads/2015/08/ 1243 MaRNEW_1_paper_35.pdf [23] 1245 o Kevin Smith, "Encryption and government regulation: what happens 1246 now?" at https://www.iab.org/wp-content/IAB-uploads/2015/09/ 1247 MaRNEW_1_paper_1.pdf [24] 1249 Authors' Addresses 1251 Natasha Rooney 1252 GSMA 1254 Email: nrooney@gsma.com 1255 URI: https://gsma.com 1257 Spencer Dawkins (editor) 1258 Wonder Hamster 1260 Email: spencerdawkins.ietf@gmail.com