idnits 2.17.1 draft-nrooney-marnew-report-03.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 (May 5, 2017) is 2538 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) == Missing Reference: 'AQM' is mentioned on line 681, but not defined Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: November 6, 2017 May 5, 2017 6 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) 7 Report 8 draft-nrooney-marnew-report-03 10 Abstract 12 The MarNEW workshop aimed to discuss solutions for badnwidth 13 optimisation on mobile networks for encrypted content, as current 14 solutions rely on unencrypted content which is not indicative of the 15 security needs of today's internet users. The workshop gathered IETF 16 attendees, IAB members and various organisations involved in the 17 telecommunications industry including original equipment 18 manufacturers and mobile network operators. 20 The group discussed the current internet encryption trends and 21 deployment issues identified within the IETF, and the privacy needs 22 of users which should be adhered. Solutions designed around sharing 23 data from the network to the endpoints and vice versa were then 24 discussed as well as analysing whether the current issues experienced 25 on the transport layer are also playing a role here. Content 26 providers and CDNs gave an honest view of their experiences delivery 27 content with mobile network operators. Finally, technical responses 28 to regulation was discussed to help the regulated industries relay 29 the issues of impossible to implement or bad-for-privacy technologies 30 back to regulators. 32 A group of suggested solutions were devised which will be discussed 33 in various IETF groups moving forward. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 6, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 1. Introduction 68 Mobile networks have a set of requirements and properties which 69 places a large emphasis on sophisticated bandwidth optimization. 70 Encryption is increasing on the internet which is positive for 71 consumer and business privacy and security. Many existing mobile 72 bandwidth optimization solutions primarily operate on non-encrypted 73 communications; this can lead to performance issues being amplified 74 on mobile networks. Encryption on networks will continue to 75 increase; and with this understanding the workshop aimed to 76 understand how we can solve the issues of bandwidth optimization and 77 performance on radio networks in this encrypted world. 79 1.1. Understanding "Bandwidth Optimization" 81 For the purposes of this workshop, bandwidth optimization encompasses 82 a variety of technical topics related to traffic engineering, 83 prioritisation, optimisation, efficiency enhancements, as well as 84 user-related topics such as specific subscription or billing models. 85 These can include: 87 o Caching 89 o Prioritisation of interactive traffic over background traffic 91 o Per-user bandwidth limit 93 o Business-related topics such as content delivery arrangements with 94 specific content providers. 96 Many of these functions can continue as they're performed today, even 97 with more encryption. Others use methods which require them to 98 inspect parts of the communication that are encrypted, and these will 99 have to be done differently in an encrypted Internet. 101 Finally, while not strictly speaking traffic management, some 102 networks employ policy-based filtering (e.g., requested parental 103 controls) and all networks support some form of legal interception 104 functionality per applicable laws. 106 1.2. Topics 108 The workshop aimed to answer questions including: 110 o Understanding the bandwidth optimization use cases particular to 111 radio networks 113 o Understanding existing approaches and how these do not work with 114 encrypted traffic 116 o Understanding reasons why the Internet has not standardised 117 support for lawful intercept and why mobile networks have 119 o Determining how to match traffic types with bandwidth optimization 120 methods 122 o Discussing minimal information to be shared to manage networks but 123 ensure user security and privacy 125 o Developing new bandwidth optimization techniques and protocols 126 within these new constraints 128 o Discussing the appropriate network layer(s) for each management 129 function 131 o Cooperative methods of bandwidth optimization and issues 132 associated with these 134 The further aim was to gather architectural and engineering guidance 135 on future work in the bandwidth optimisation area based on the 136 discussions around the proposed approaches. The workshop also 137 explored possible areas for standardization, e.g. new protocols that 138 can aid bandwidth optimization whilst ensuring user security inline 139 with new work in the transport layer. 141 1.3. Organization of this report 143 This workshop report summarizes the contributions to and discussions 144 at the workshop, organized by topic. The workshop began with scene 145 setting topics which covered the issues around deploying encryption, 146 the increased need for privacy on the internet and setting a clear 147 understanding that ciphertext should remain unbroken. Later sessions 148 focused on key solution areas; these included evolution on the 149 transport layer and sending data up or down the path. A session on 150 application layers and CDNs aimed to highlight both issues and 151 solutions experienced on the application layer. The workshop ended 152 with a session dedicated to technical response to regulation with 153 regards to encryption. The contributing documents were split between 154 identifying the issues experienced with encryption on radio networks 155 and suggested solutions. Of the solutions suggested some focused on 156 transport evolution, some on trusted middleboxes and others on 157 collaborative data exchange. Solutions were discussed within the 158 sessions. All accepted position papers and detailed transcripts of 159 discussion are available at [MARNEW]. 161 The outcomes of the workshop are discussed in Section 7 and 8, and 162 discuss progress after the workshop toward each of the identified 163 work items as of the time of publication of this report. 165 Although policy related topics were out of scope for this workshop 166 they were infrequently referred to. Report readers should be 167 reminded that this workshop did not and did not aim to discuss policy 168 or policy recommendations. 170 1.4. Use of Note Well and Charter House Rule 172 The workshop was conducted under the IETF [NOTE_WELL] with the 173 exception of the "Technical Analysis and Response to Potential 174 Regulatory Reaction" session which was conducted under 175 [CHATHAM_HOUSE_RULE]. 177 1.5. IETF and GSMA 179 The IETF and GSMA [GSMA] have divergent working pratices, standards 180 and processes. IETF is an open organisation with community driven 181 standards with the key aim of functionality and security for the 182 internet's users, the GSMA is membership based and serves the needs 183 of its membership base most of whom are mobile network operators. 185 Unlike IETF, GSMA makes few standards. Within the telecommunications 186 industry standards are set in various divergent groups depending on 187 their purpose. Perhpas of most relevance to the bandwidth 188 optimisation topic here is the work of the [SDO_3GPP] which work on 189 radio network and core network standards with their members which 190 include mobile operators and original equipment manufacturers. 192 One of the [SDO_3GPP] standards relevant to this workship is PCC-QoS 193 [PCC-QOS]. Traditionally mobile networks have managed different 194 applications and services based on the resources available and 195 priorities given; for instance, emergency services have a top 196 priority, data has a lower prioirty and voice services are somewhere 197 inbetween. [SDO_3GPP] defined the PCC-QoS mechanism to support this 198 functionality, some of which cannot occur for encrypted 199 communications. 201 2. Scene Setting Sessions 203 Scene setting sessions aimed to bring all attendees up to a basic 204 understanding of the problem and the scope of the workhop. There 205 were three scene setting sessions: Scene Setting (defining scope), 206 Encryption Deployment Considerations and Trust Models and User Choice 207 (Privacy). 209 2.1. Scene Setting 211 The telecommunications industry and internet standards are extremely 212 different in terms of ethos and business practices. Both industries 213 drive technical standards in their domain and build technical 214 solutions with some policy-driven use cases. These technologies, use 215 cases and technical implementations are different; not only this but 216 motivators between the two industries are also diverse. 218 To ensure all attendees were aligned with contributing to discussions 219 and driving solutions this "Scene Setting" session worked on 220 generating a clear scope with all attendees involved. In short: it 221 was agreed that ciphertext should not be broken by any solution, that 222 the radio access network (RAN) is different and does experience 223 issues with increased encrypted traffic, that we need to understand 224 what those problems are precisely and that our goal is to improve 225 user experience on the Internet. Technical solutions for regulation 226 was not in scope. The full scope is given below. 228 2.1.1. Scope 230 The attendees identified and agreed the following scope: 232 o In discussion we should assume: No broken crypto, Ciphertext 233 increasingly common, congestion does need to be controlled as do 234 other transport issues and Network management including efficient 235 use of resources, in RAN and elsewhere, has to work 237 o How/why is RAN different for transport; help us understand the 238 complexities of the RAN and how hard it is to manage and why those 239 matter 241 o What are the precise problems caused by more ciphertext 243 o Identify players, incl. Users, and resulting tensions and how 244 ciphertext changes those 246 o Some solutions will be radically changed by ciphertext, it's ok to 247 talk about that 249 o As good as possible Quality of experience for end user is a goal 251 o Our aim for the next two days is to analyse the situation and 252 identify specific achievable tasks that could be tackled in the 253 IETF or GSMA (or elsewhere?) and that improve the Internet given 254 the assumptions above 256 o We should not delve into: 258 o Ways of doing interception (legal or not), see RFC2804 for why 260 o Unpredictable political actions. 262 2.1.2. Encryption Statistics and Radio Access Network Differences 264 Attendees were shown that encrypted content is reaching around 50% 265 according to recent statistics [STATE_BROWSER] and [STATE_SERVER]. 266 The IAB are encouraging all IETF groups to consider encryption by 267 default on their new protocol work and the IETF are also working on 268 encryption on lower layers, for example TCP encryption within the 269 [TCPINC] Working Group. The aims of these items of work are greater 270 security and privacy for users and their data. 272 Within telecommunications middleboxes exist on operator networks 273 which have previously considered themselves trusted; but qualifying 274 trust is difficult and should not be assumed. Some interesting use 275 cases exist with these middleboxes; such as anti-spam and malware, 276 but these need to be balanced against their ability to open up cracks 277 in the network for attacks such as pervasive monitoring. Some needs 278 to improve the radio access network quality of service could come 279 from increasing radio access network cells ("Base Stations"), but 280 this adds to radio pollution; this shows the balancing act when 281 deivising radio access network architecture. 283 2.2. Encryption Deployment Considerations 285 Encryption across the internet is on the rise. However, some 286 organisations and individuals come across a common set of operational 287 issues when deploying encryption, mainly driven by commercial 288 perspectives. The [UBIQUITOUS] draft explains these network 289 management function impacts, detailing areas around incident 290 monitoring, access control management, and regulation on mobile 291 networks. The data was collected from various internet players, 292 including system and network administrators across enterprise, 293 governmental organisations and personal use. The aim of the document 294 is to gain an understanding of what is needed for technical solutions 295 to these issues, maintaining security and privacy for users. 296 Attendees commented that worthwhile additions would be: different 297 business environments (e.g. cloud environments) and service chaining. 298 Incident monitoring in particular was noted as a difficult issue to 299 solve given the use of URL in today's inicident monitoring 300 middleware. 302 Some of these impacts to mobile networks can be resolved using 303 difference methods and the [NETWORK_MANAGEMENT] draft details these 304 methods. The draft focuses heavily on methods to manage network 305 traffic whithout breaching user privacy and security. 307 By reviewing encryption depoyment issues and the alternative methods 308 of network management MaRNEW attendees were made aware of the issues 309 which affect radio networks, the deployment issues which are solvable 310 and require no further action, and those which aren't currently 311 solveable and which should be addressed within the workshop. 313 2.3. Trust Models and User Choice (Privacy) 315 Solutions of how to improve delivery of encrypted content could 316 affect some of all of the privacy benefits that encryption brings. 317 Understanding user needs and desires for privacy is therefore 318 important when designing these solutions. 320 From a recent study [Pew2014] 64% of users said concerns over privacy 321 have increased, 67% of mobile internet users would like to do more to 322 protect their privacy. The W3C and IETF have both responded to user 323 desires for better privacy by recommending encryption for new 324 protocols and web technologies. Within the W3C new security 325 standards are emerging and the design principles for HTML hold that 326 users are the stakeholders with most priority, followed by 327 implementors and other stakeholders, further inforcing the "user 328 first" principle. Users also have certain security expectations from 329 particular contexts, and sometimes use new technologies to further 330 protect their privacy even if those technologies weren't initially 331 developed for that purpose. 333 Technologies which can impact user privacy sometimes do this ignorant 334 of the privacy implications or incorrectly assume that the benefits 335 users gain from the new technology outweigh the loss of private 336 information. Any new technology which introduces bad security 337 vectors will be used by attackers. If these technologies are 338 necessary they should be opt-in. 340 Internet stakeholders should understand the priority of other 341 stakeholders. Users should be considered the first priority, other 342 stakeholders include implementors, developers, advertisers, operators 343 and other ISPs. Some technologies have been absued by these parties, 344 such as cookie use or JavaScript injection. This has caused some 345 developers to encrypt content to circumnavigate these technologies 346 which they find intrusive or bad for their users privacy. 348 Some suggested solutions for network management of encrypted traffic 349 have suggested "trust models". If users and content providers are to 350 opt-in to user network management services with negative privacy 351 impacts they should see clear value from using these services, and 352 understand the impacts on clear interfaces. Users should also have 353 easy abilities to opt-out. Some users will always automatically 354 click through consent requests, so any trust model is flawed for 355 these users. Understanding the extent of "auto click through" may 356 help make better decisions for consent requests in the future. One 357 trust model (Cooperative Traffic Management) works as an agent of the 358 user; by opting-in metadata can be shared. Issues with this involve 359 trust only being applied on end. 361 3. Network or Transport Solution Sessions 363 Network or Transport Solution Sessions aimed to discuss suggested and 364 new solutions for managing encrypted traffic on radio access 365 networks. Most solutions focus on the sharing of metadata; either 366 from the enpoint to the network, from the network to the endpoint, or 367 cooperative sharing between both. Evolutions on the transport layer 368 could be another approach to solve some of the issues radio access 369 networks experience which cause them to require network management 370 middleboxes. By removing problems on the transport layer the need to 371 expesnive middleboxes could decrease. 373 3.1. Sending Data Up / Down for Network Management Benefits 375 Middleboxes in the network have a number of uses, some which are more 376 beneficial than they are controversial. Collaboration between these 377 network elements and the endpoints could bring about better content 378 distribution. A number of suggestions were given, these included: 380 o Mobile Throughput Guidance [MTG]: exchanges data between the 381 network elements and the endpoints via TCP Options. It also 382 allows for gaining a better idea of how the transport protocol 383 behaves and improving user experience further, although the work 384 still needs to evolve. 386 o SPUD [SPUD]: a UDP-based encapsulation protocol to allow explicit 387 cooperation with middleboxes while using new, encrypted transport 388 protocols. 390 o Network Status API: An API for operators to share congestion 391 status or the state of a cell before an application starts sending 392 data could allow applications to change their behaviour. 394 o Traffic classification: classfying traffic and adding this as 395 metadata for analysis throughout the network. This idea has trust 396 and privacy implications. 398 o ConEx [CONEX]: a mechanism where senders inform the network about 399 the congestion encountered by previous packets on the same flow, 400 in-band at the IP layer. 402 o Latency versus Bandwith: allowing the content provider to indicate 403 whether a better bandwidth or lower latency is of greater priority 404 and allowing the network to react. Where this bit resides and how 405 to authenticate it would need to be decided. 407 o No network management tools: disabling all network management 408 tools from the network and allow the protocols to manage 409 congestion alone. 411 o FlowQueue Codel [FLOWQUEUE]: a hybrid packet scheduler/AQM 412 algorithm, aiming to reduce bufferbloat and latency. FQ-CoDel 413 mixes packets from multiple flows and reduces the impact of head 414 of line blocking from bursty traffic. 416 Many of these suggestions could be labeled "Network-to-App", a better 417 approach may be "Network-to-User", to achieve this these ideas would 418 need to be expanded. Others aim to create "hop-to-hop" solutions, 419 which could be more inline with how congestion is managed today, but 420 with greater privacy implications. 422 "App-to-Network" style solutions have either existed for a long time 423 by implicit solutions, or explicitly defined but never implemented or 424 properly deployed. Some workshop attendees agreed that applications 425 declaring was quality of service they require was not a good route 426 given the lack of success in the past. 428 3.1.1. Trust and the Mobile Network Complexities 430 One of the larger issues in the sharing of data is the matter of 431 trust; networks operators find difficulties in relinquishing data for 432 reasons such as revealing competitive information and applications 433 wish to protect their users and only reveal little information to the 434 network. Authentication in that case could be a key design element 435 of any new work, as well as explictness rather than the transparent 436 middleboxes used more recently. Some workshop attendees suggested 437 any exchange of information should be biodirectional, in an effort to 438 improve trust between the elements. A robust incentive framework 439 could provide a solution to the trust issue, or at least help 440 mitigate it. 442 The radio access network is complex and manages a number of 443 realities. Base stations understand many of these realities, and 444 information within these base stations can be of value other entities 445 on the path. Solutions for managing congestion on radio networks 446 should involve the base station if possible. For instance, 447 understanding how the Radio Resource Controller and AQM [RFC7567] 448 interact (or don't interact) could provide valuable information for 449 solving issues. Although many workshop attendees agreed that even 450 though there is a need to understand the base station not all agreed 451 that the base station should be part of a future solution. 453 Some suggested solutions were based on network categorisation and 454 providing this information to the protocols or endpoints. 455 Categorising radio networks could be impossible due to their 456 complexity, but categorising essential network properties could be 457 possible and valuable. 459 4. Transport Layer: Issues, Optimisation and Solutions 461 TCP has been the dominant transport protocol since TCP/IP replaced 462 NCP on the Arpanet in March 1983. TCP was originally devised to work 463 on a specific network model that did not anticipate the high error 464 rates and highly variable available bandwidth scenarios experienced 465 on modern radio access networks. Furthermore new network elements 466 have been introduced (NATs and network devices with large buffers 467 creating bufferbloat), and considerable peer-to-peer traffic is 468 competing with traditional client-server traffic. Consequently the 469 transport layer today has requirements beyond what TCP was designed 470 to meet. TCP has other issues as well; too many services rely on TCP 471 and only TCP, blocking deployment of new transport protocols like 472 SCTP and DCCP. This means that true innovation on the transport 473 layer becomes difficult because deployment issues are more 474 complicated than just building a new protocol. 476 The IETF is trying to solve these issues through the "Stack 477 Evolution" programme, and the first step in this programme is to 478 collect data. Network and content providers can provide data 479 including: the cost of encryption, the advantages of network 480 management tools, the deployment of protocols, and the effects when 481 network management tools are disabled. Network operators do not tend 482 to reveal network information mostly for competition reasons and so 483 is unlikely to donate this information freely to IETF. The GSMA is 484 in the position to collect this data and anonymise it before bringing 485 it to IETF which should alleviate the network operator worries but 486 still provide IETF with some usable data. 488 A considerable amount of work has already been done on TCP, 489 especially innovation in bandwidth management and congestion control; 490 although congestion is usually detected by detecting loss, and better 491 methods based on detecting congestion would be beneficial. 493 Furthemore, although the deficiencies of TCP are often considered as 494 key issues in the evolution of the stack, the main route to resolve 495 these issues may not be a new TCP, but an evolved stack. SPUD [SPUD] 496 and ICN [RFC7476] are two suggestions which may help here. QUIC 497 [QUIC] engineers stated that the problems solves by QUIC are general 498 problems, rather than TCP issues. This view was not shared by all 499 attendees of the workshop. Moreover, TCP has had some improvements 500 in the last few years which may mean some of the network lower layers 501 should be investigated to see whether improvements can be made here. 503 5. Application Layer Optimisation, Caching and CDNs 505 Many discussions on the effects of encrypted traffic on radio access 506 networks happen between implementers and the network operators; this 507 session aimed to gather the opinions of the content and caching 508 providers including their experiences running over mobile networks, 509 the experience their users expect, and what they would like to 510 achieve by working with or using the mobile network. 512 Content providers explained how even though this workshop cited 513 encrypted data over radio access networks as the main issue the real 514 issue is network management generally, and all actors (applications 515 providers, networks and devices) need to work together to overcome 516 theese general network management issues. Content providers 517 explained how they assume the mobile networks are standard compliant. 518 When the network is not standards compliant (e.g. using non standards 519 compliant intermediaries) content providers can experience real costs 520 as users contact their support centres to report issues which are 521 difficult to test for and build upon. 523 Content providers cited other common issues concerning data traffic 524 over mobile networks. Data caps cause issues for users; users are 525 confused about how data caps work or are unsure how expensive media 526 is and how much data it consumes. DNS and DNS caching cause 527 unpredictable results. Developers build products on networks not 528 indicative of the networks their customers are using and not every 529 organisation has the finances to build a caching infrastructure. 531 Strongly related to content providers, CDNs are understood to be a 532 trusted deliver of content and have shown great success in fixed 533 networks. Now traffic is moving more to mobile networks there is a 534 need to place caches at the edge of the network (e.g. in the Gi LAN 535 or the radio network) within the mobile network. Places caches at 536 the edge of the mobile network is a solution, but requires standards 537 developed by content providers and mobile network operators. The 538 CNDi Working Group [CDNI] at IETF aims to allow global CDNs to 539 interoperate with mobile CDNs; but this causes huge trust issues for 540 the caching of encrypted data between these CDNs. Some CDNs are 541 experimenting with "Keyless SSL" to enable safer storage of content 542 without passing private keys to the CDN. Blind Caching is another 543 proposal aimed at caching encrypted content closer to the user and 544 managing the authentication at the original content provider servers. 546 At the end of the session the panelists were asked to identify one 547 key collaborative work item, these were: evolving caching to cache 548 encrypted content, uing one-bit for latency / bandwidth trade-off 549 (explained below), better collaboration between the network and 550 application, better metrics to aid bug solving and innovation, and 551 indications from the network to allow the application to adapt. 553 6. Technical Analysis and Response to Potential Regulatory Reaction 555 This session was conducted under Chatham House Rule. The session 556 aimed to discuss regulatory and politcal issues; but not their worth 557 or need, rather to understand the laws that exist and how 558 technologists can properly respond to these. 560 Mobile networks are regulated, compliance is mandatory (and can 561 result in service license revocation in some nations round the world) 562 and can incur costs on the mobile network operator. Regulation does 563 vary geographically. Some regulations are court orders, others are 564 "block lists" of websites such as the Internet Watch Foundation list 565 [IWF]. Operators are not expected to decrypt sites, so those 566 identified sites which are encrypted will not be blocked. 568 Parental control-type filters also exist on the network and are 569 easily bypassed today, vastly limiting their effectiveness. Better 570 solutions would allow for users to easily set these restirctions 571 themselves. Other regulations are also hard to meet - such as user 572 data patterns, or will become harder to collect - such as IoT cases. 573 Most attendees agreed that if the governments cannot get the 574 information from network operators they will approach the content 575 providers. Some governments are aware of the impact of encryption 576 and are working with or trying to work with content providers. The 577 IAB have concluded blocking and filtering can be done at the endpoint 578 of the communication. 580 These regulations do not always apply to the internet, and the 581 internet community is not always aware of their existance. 582 Collectively the internet community can work with GSMA and 3GPP and 583 act collectively to alleviate the risk imposed by encrypted traffic 584 for lawful intercept. The suggestion from attendees was that if any 585 new technical solutions built should have the ability to be easily 586 switched off. 588 Some mobile network operators are producing transparency reports 589 covering regulations including lawful intercept. Operators who have 590 done this already are encouraging others to do the same. 592 7. Requirements and Suggestions for Future Solutions 594 Based on the talks and discussions throughout the workshop a set of 595 requirements and suggested solutions has been collected. This is not 596 an exhaustve list. 598 o Encrypted Traffic: any solution should encourage and support 599 encrypted traffic. 601 o Flexibility: radio access network qualities vary vastly and 602 different network needs in content can be identified, so any new 603 solution should be flexible to either the network type or content 604 type or both. 606 o Privacy: new solutions should not introduce ways where information 607 can be discovered flows and attribute them to users. 609 o Minimum data only for collaborative work: user data, app data and 610 network data all needs protecting, so new solutions should use the 611 minimum information to make a working solution. 613 A collection of solutions suggested throughout the workshop is given 614 below. These solutions haven't been matched to the requirements 615 above, so this step will need to come later. 617 o Evolving TCP or evolution on the transport layer: this could take 618 a number of forms and some of this work is already existing within 619 IETF. Other suggestions include: 621 o Congestion Control: many attendees cited congestion control as a 622 key issue, further analysis, investigation and work could be done 623 here. 625 o SPROUT: research at MIT which is a transport protocol for 626 interactive applications that desire high throughput and low 627 delay. [SPROUT] 629 o PCC: Performance-oriented Congestion Control: is a new 630 architecture that aims for consistent high performance even in 631 challenging scenarios. PCC enpoints observe the connection 632 between their actions and their known performance, which allows 633 them to adapt their actions. [PCC] 635 o CDNs and Caches: placing caches closer to the mobile user or 636 making more intelligent CDNs would result in faster content 637 delivery and less train on the network. Related work includes: 639 o Blind Caching: a proposal for caching of encrypted content 640 [BLIND_CACHING]. 642 o CDN improvements: including keyless SSL and better CDN placement. 644 o Mobile Throughput Guidance: a mechanism and protocol elements that 645 allow the cellular network to provide near real-time information 646 on capacity available to the TCP server. [MTG] 648 o One bit for latency / bandwidth tradeoff: using one bit to 649 identify whether a stream prefers low latency at the expense of 650 throughput. This rids solutions of the trust issue as 651 applications will need to select the best scenario for their 652 traffic type. 654 o Base Station: some suggestions involved "using the Base Station", 655 but this was not defined in detail. The Base Station holds the 656 Radio Resource Controller and scheduler which could provide either 657 a place to host solutions or data from the Base Station could help 658 in devising new solutions. 660 o Identify traffic types via 5-tuple: information from the 5-tuple 661 could provide understanding of the traffic type which network 662 management could then be applied. 664 o Heuristics: Networks can sometimes identify traffic types through 665 specifics such as data flow rate and then apply network management 666 to these identified flows. This is not recommended as 667 categorisations can be incorrect. 669 o APIs: An API for operators to share congestion status or the state 670 of a cell before an application starts sending data could allow 671 applications to change their behaviour. Alternatively an API 672 could provide the network with some information on the data type 673 to provide network management to, although this method exposes 674 privacy issues. 676 o Standard approach for operator to offer services to Content 677 Providers: mobile network operators could provide caching services 678 or other services for content providers to use for faster and 679 smoother content delivery. 681 o AQM [AQM] and ECN [RFC3168] deployments: queueing and congestion 682 management methods have existed for sometime in the form of AQM, 683 ECN and others which can help the transport and internet layer 684 adapt to congestion faster. 686 o Trust Model or Trust Framework: some solutions in this area (e.g. 687 SPUD) have a reliance on trust when content providers or the 688 network are being asked to add classifiers to their traffic. 690 o Keyless SSL: allows content providers to maintain their private 691 keys on a "key server" and host the content elsewhere (e.g. on a 692 CDN). This could become standardised in IETF. [LURK] 694 o Meaningful capacity sharing: including the ConEx [CONEX] work 695 which exposes information about congestion to the network nodes. 697 o Hop-by-hop: some suggestions offer hop-by-hop methods allowing 698 nodes to adapt flow given the qualities of the networks around 699 them and the congestion they are experiencing. 701 o Metrics and metric standards: in order to evolve current protocols 702 to be best suited to today's networks data is needed on the 703 current network situations, protocol deployments, packet traces 704 and middlebox behaviour. Futher than this proper testing and 705 debugging on networks could provide great insight for stack 706 evolution. 708 o 5G: Mobile operator standards bodies are in the process of setting 709 the requirements for 5G, requirements for network management could 710 be added. 712 In the workshop attendees identified other areas where greater 713 understand could help the standards process. These were identified 714 as: 716 o Greater understanding of the RAN at IETF 718 o Reviews and comments on 3GPP perspective 720 o How to do congestion controlling in RAN. 722 7.1. Better Collaboration 724 Throughout the workshop attendees placed emphasis on the need for 725 better collaboration between the IETF and telecommunications bodies 726 and organisations. The workshop was one such way to achieve this, 727 but the good work and relationships built in the workshop should 728 continue so the two groups can work on solutions which are better for 729 both technologies and users. 731 8. Next Steps 733 The next steps for MaRNEW attendees are to begin work on a select 734 list of the above recommended solutions and other suggestions within 735 the IETF and within other organisations. At IETF95 the ACCORD BoF 736 will be held which will bring the workshop discussion to the wider 737 IETF attendance and select key areas to progress on; these are likely 738 to be definitions of the metrics to be collected, more information on 739 the stack evolution ideas and their impact to network management, 740 Mobile Throughput Guidance evolution, evolution of the Blind Caching 741 work and draft definitions of the "1 bit for latency / bandwidth 742 tradeoff" idea. As identified in the "Better Collaboration" section 743 together we need to ensure that both groups continue the positive 744 relationship to move these ideas forward into being real and workable 745 solutions and both groups need to understand that even though 746 collaboration between the operator network and the internet is of 747 great importance the item of most importance is the experience and 748 security for the users using these services. 750 9. Informative References 752 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 753 Recommendations Regarding Active Queue Management", 754 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 755 . 757 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 758 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 759 "Information-Centric Networking: Baseline Scenarios", 760 RFC 7476, DOI 10.17487/RFC7476, March 2015, 761 . 763 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 764 of Explicit Congestion Notification (ECN) to IP", 765 RFC 3168, DOI 10.17487/RFC3168, September 2001, 766 . 768 [NOTE_WELL] 769 "IETF Note Well", n.d., . 772 [MARNEW] "MaRNEW Workshop IAB Homepage", n.d., 773 . 775 [CHATHAM_HOUSE_RULE] 776 "Chatham House Rule", n.d., 777 . 779 [GSMA] "GSMA Homepage", n.d., . 781 [SDO_3GPP] 782 "3GPP Homepage", n.d., . 784 [PCC-QOS] "Policy and charging control signalling flows and Quality 785 of Service (QoS) parameter mapping", March 2016, 786 . 788 [STATE_BROWSER] 789 Barnes, R., "Some observations of TLS in the web", July 790 2015, . 793 [STATE_SERVER] 794 Salz, R., "Some observations of TLS in the web", July 795 2015, . 798 [TCPINC] "TCP Increased Security Working Group", n.d., 799 . 801 [UBIQUITOUS] 802 Morton, K., "Effect of Ubiquitous Encryption", March 2015, 803 . 806 [NETWORK_MANAGEMENT] 807 Smith, K., "Network management of encrypted traffic", May 808 2015, . 811 [Pew2014] "Public Perceptions of Privacy and Security in the Post- 812 Snowden Era", November 2014, 813 . 816 [MTG] Smith, A., "Mobile Throughput Guidance Inband Signaling 817 Protocol", September 2015, 818 . 821 [SPUD] "Session Protocol for User Datagrams", n.d., 822 . 824 [CONEX] "Congestion Exposure Working Group", n.d., 825 . 827 [FLOWQUEUE] 828 Dumazet, P., "FlowQueue-Codel", March 2014, 829 . 832 [QUIC] Swett, J., "QUIC, A UDP-Based Secure and Reliable 833 Transport for HTTP/2", June 2015, 834 . 837 [CDNI] "Content Delivery Networks Interconnection Working Group", 838 n.d., . 840 [IWF] "Internet Watch Foundation", n.d., 841 . 843 [SPROUT] Balakrishnan, K., "Stochastic Forecasts Achieve High 844 Throughput and Low Delay over Cellular Networks", April 845 2013, 846 . 849 [PCC] Schapira, M., "PCC, Re-architecting Congestion Control for 850 Consistent High Performance", May 2015, 851 . 853 [BLIND_CACHING] 854 Holmberg, M., "An Architecture for Secure Content 855 Delegation using HTTP", n.d., 856 . 858 [LURK] Ma, D., "TLS/DTLS Content Provider Edge Server Split Use 859 Case", January 2016, . 862 Author's Address 864 Natasha Rooney 865 GSMA 867 Email: nrooney@gsma.com 868 URI: https://gsma.com