Internet Architecture Board (IAB) N. Rooney Request for Comments: 8462 S. Dawkins, Ed. Category: Informational October 2018 ISSN: 2070-1721 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
AbstractThe Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators. The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators. A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8462. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Understanding "Bandwidth Optimization" . . . . . . . . . 4 1.2. Topics . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Organization of This Report . . . . . . . . . . . . . . . 5 1.4. Use of Note Well and the Chatham House Rule . . . . . . . 6 1.5. IETF and GSMA . . . . . . . . . . . . . . . . . . . . . . 6 2. Scene-Setting Sessions . . . . . . . . . . . . . . . . . . . 7 2.1. Scene Setting . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Encryption Statistics and Radio Access Network Differences . . . . . . . . . . . . . . . . . . . . . 8 2.2. Encryption Deployment Considerations . . . . . . . . . . 9 2.3. Awareness of User Choice (Privacy) . . . . . . . . . . . 10 3. Network or Transport Solution Sessions . . . . . . . . . . . 11 3.1. Sending Data Up/Down for Network Management Benefits . . 11 3.1.1. Competition, Cooperation, and Mobile Network Complexities . . . . . . . . . . . . . . . . . . . . 12 4. Transport Layer: Issues, Optimization, and Solutions . . . . 13 5. Application-Layer Optimization, Caching, and CDNs . . . . . . 14 6. Technical Analysis and Response to Potential Regulatory Reaction . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Suggested Principles and Solutions . . . . . . . . . . . . . 16 7.1. Better Collaboration . . . . . . . . . . . . . . . . . . 19 8. Since MaRNEW . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . 20 Appendix A. Workshop Attendees . . . . . . . . . . . . . . . . . 24 Appendix B. Workshop Position Papers . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Many of these functions can continue as they are performed today, even with increased use of encryption. Others are using methods that inspect parts of the communication that are not encrypted today, but will be encrypted, and these functions will have to be done differently in an increasingly encrypted Internet.
focused on key solution areas; these included evolution on the transport layer and sending data up or down the path. A session on application layers and CDNs aimed to highlight both issues and solutions experienced on the application layer. The workshop ended with a session dedicated to discussing a technical response to regulation with regards to encryption. The contributing documents identified the issues experienced with encryption on radio networks and suggested solutions. Of the solutions suggested, some focused on transport evolution, some on trusted middleboxes, and others on collaborative data exchange. Solutions were discussed within the sessions. All accepted position papers and detailed transcripts of discussion are available at [MARNEW]. The outcomes of the workshop are discussed in Sections 7 and 8; they discuss the progress made since the workshop toward each of the identified work items through the time this document was approved for publication. Report readers should be reminded that this workshop did not aim to discuss regulation or legislation, although policy topics were mentioned in discussions from time to time. NOTE_WELL] with the exception of the "Technical Analysis and Response to Potential Regulatory Reaction" session, which was conducted under the [CHATHAM_HOUSE_RULE]. GSMA] have different working practices, standards, and processes. IETF is an open organization with community-driven standards, with the key aim of functionality and security for the Internet's users, while the GSMA is membership based and serves the needs of its membership base, most of whom are mobile network operators. Unlike IETF, GSMA makes few standards. Within the telecommunications industry, standards are set in various divergent groups depending on their purpose. Perhaps of most relevance to the bandwidth optimization topic here is the work of the 3rd Generation Partnership Project (3GPP) [SDO_3GPP], which works on radio network and core network standards. 3GPP members include mobile operators and original equipment manufacturers.
One of the 3GPP standards relevant to this workshop is Policy and Charging Control QoS [PCC-QOS]. Traditionally, mobile networks have managed different applications and services based on the resources available and priorities given; for instance, emergency services have a top priority, data has a lower priority, and voice services are somewhere in-between. 3GPP defined the PCC-QoS mechanism to support this functionality, and this depends on unencrypted communications [EffectEncrypt]. Section 2.1: Scene Setting o Section 2.2: Encryption Deployment Considerations o Section 2.3: Awareness of User Choice (Privacy)
RFC2804]; and, o unpredictable political actions. STATE_BROWSER] [STATE_SERVER]. The IAB is encouraging all IETF working groups to consider the effect encryption being "on by default" will have on new protocol work. The IETF is also working on encryption at lower layers. One recent
example of this work is opportunistic TCP encryption within the TCP Increased Security [TCPINC] Working Group. The aims of these work items are greater security and privacy for end users and their data. Telecommunications networks often contain middleboxes that operators have previously considered to be trusted, but qualifying trust is difficult and should not be assumed. Some interesting use cases exist with these middleboxes, such as anti-spam and malware detection, but these need to be balanced against their ability to open up cracks in the network for attacks such as pervasive monitoring. When operators increase the number of radio access network cells (base stations), this can improve the radio access network quality of service; however, it also adds to radio pollution. This is one example of the balancing act required when devising radio access network architecture. RFC8404] explains these network management function impacts, detailing areas around incident monitoring, access control management, and regulation on mobile networks. The data was collected from various Internet players, including system and network administrators across enterprise, governmental organizations, and personal use. The aim of the document is to gain an understanding of what is needed for technical solutions to these issues while maintaining security and privacy for users. Attendees commented that worthwhile additions would be different business environments (e.g., cloud environments) and service chaining. Incident monitoring in particular was noted as a difficult issue to solve given the use of URLs in today's incident monitoring middleware. Some of these impacts to mobile networks can be resolved using different methods, and the [NETWORK_MANAGEMENT] document details these methods. The document focuses heavily on methods to manage network traffic without breaching user privacy and security. By reviewing encryption deployment issues and the alternative methods of network management, MaRNEW attendees were made aware of the issues that affect radio networks, the deployment issues that are solvable and require no further action, and those issues that have not yet been solved but should be addressed within the workshop.
MTG]: exchanges metadata between network elements and endpoints via TCP options. It also allows for better understanding of how the transport protocol behaves and further improves the user experience, although additional work on MTG is still required. o Session Protocol for User Datagrams [SPUD]: a UDP-based encapsulation protocol to allow explicit cooperation with middleboxes while using, new encrypted transport protocols. o Network Status API: an API for operators to share congestion status or the state of a cell before an application starts sending data that could allow applications to change their behavior. o Traffic Classification: classifying traffic and adding these classifications as metadata for analysis throughout the network. This idea has trust and privacy implications. o Congestion Exposure [CONEX]: a mechanism where senders inform the network about the congestion encountered by previous packets on the same flow, in-band at the IP layer. o Latency versus Bandwidth: a bit that allows the content provider to indicate whether higher bandwidth or lower latency is of greater priority and allows the network to react based on that indication. Where this bit resides in the protocol stack and how it is authenticated would need to be decided.
o No Network Management Tools: disabling all network management tools from the network and relying only on end-to-end protocols to manage congestion. o Flow Queue Controlled Delay (FQ-CoDel) [FLOWQUEUE]: a hybrid packet scheduler / Active Queue Management (AQM) [RFC7567] algorithm aiming to reduce bufferbloat and latency. FQ-CoDel manages packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. Some of these suggestions rely on signaling from network elements to endpoints. Others aim to create "hop-by-hop" solutions, which could be more aligned with how congestion is managed today but with greater privacy implications. Still others rely on signaling from endpoints to network elements. Some of these rely on implicit signaling and others on explicit signaling. Some workshop attendees agreed that relying on applications to explicitly declare the quality of service they require was not a good path forward given the lack of success with this model in the past. RFC7567] interact (or don't interact) could provide valuable information for solving
issues. Although many workshop attendees agreed that even though there is a need to understand the base station, not all agreed that the base station should be part of a future solution. Some suggested solutions were based on network categorization and on providing this information to the protocols or endpoints. Completely categorizing radio networks could be impossible due to their complexity, but categorizing essential network properties could be possible and valuable.
Furthermore, although the deficiencies of TCP are often considered key issues in the evolution of the Internet protocol stack, the main route to resolve these issues may not be a new TCP, but an evolved stack. Some workshop participants suggested that SPUD [SPUD] and Information-Centric Networking (ICN) [RFC7476] may help here. Quick UDP Internet Connection [QUIC] engineers stated that the problems solved by QUIC are general problems, rather than TCP issues. This view was not shared by all attendees of the workshop. Moreover, TCP has had some improvements in the last few years, which may mean some of the network lower layers should be investigated to see whether improvements can be made.
Interconnection [CDNI] Working Group aims to allow global CDNs to interoperate with mobile CDNs, but this causes huge issues for the caching of encrypted data between these CDNs. Some CDNs are experimenting with approaches like "Keyless SSL" [KeylessSSL] to enable safer storage of content without passing private keys to the CDN. Blind Caching [BLIND_CACHING] is another proposal aimed at caching encrypted content closer to the user and managing the authentication at the original content provider servers. At the end of the session, each panelist was asked to identify one key collaborative work item. Work items named were: evolving to cache encrypted content, using one bit for latency / bandwidth trade- off (explained below), better collaboration between the network and application, better metrics to aid troubleshooting and innovation, and indications from the network to allow the application to adapt. IWF] list. Operators are not expected to decrypt sites, so those encrypted sites will not be blocked because of content. Parental-control-type filters also exist on the network and are easily bypassed today, vastly limiting their effectiveness. Better solutions would allow for users to easily set these restrictions themselves. Other regulations are also hard to meet, such as user data patterns, or will become harder to collect, such as Internet of Things (IoT) cases. Most attendees agreed that if a government cannot get information it needs (and is legally entitled to have) from network operators, they will approach content providers. Some governments are aware of the impact of encryption and are working with, or trying to work with, content providers. The IAB has concluded that blocking and filtering can be done at the endpoints of the communication.
Not all of these regulations apply to the Internet, and the Internet community is not always aware of their existence. Collectively, the Internet community can work with GSMA and 3GPP and act together to alleviate the risk imposed by encrypted traffic. Some participants expressed concern that governments might require operators to provide information that they no longer have the ability to provide because previously unencrypted traffic is now being encrypted, and this might expose operators to new liability, but no specific examples were given during the workshop. A suggestion from some attendees was that if any new technical solutions are necessary, they should easily be "switched off". Some mobile network operators are producing transparency reports covering regulations including lawful intercept. Operators who have done this already are encouraging others to do the same.
o Congestion Control: Many attendees cited congestion control as a key issue. Further analysis, investigation, and work could be done in this space. o Sprout [SPROUT]: Researched at MIT, Sprout is a transport protocol for applications that desire high throughput and low delay. o PCC [PCC]: Performance-oriented Congestion Control is a new architecture that aims for consistent high performance, even in challenging scenarios. PCC endpoints observe the connection between their actions and their known performance, which allows them to adapt their actions. o CDNs and Caches: This suggests that placing caches closer to the edge of the radio network, as close as possible to the mobile user, or making more intelligent CDNs, would result in faster content delivery and less strain on the network. o Blind Caching [BLIND_CACHING]: This is a proposal for caching of encrypted content. o CDN Improvements: This includes Keyless SSL and better CDN placement. o Mobile Throughput Guidance [MTG]: This is a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. o One Bit for Latency / Bandwidth Trade-Off: This suggests determining whether using a single bit in an unencrypted transport header to distinguish between traffic that the sender prefers to be queued and traffic that the sender would prefer to drop rather than delay provides additional benefits beyond what can be achieved without this signaling. o Base Station: Some suggestions involved using the base station, but this was not defined in detail. The base station holds the radio resource controller and scheduler, which could provide a place to host solutions, or data from the base station could help in devising new solutions. o Identify Traffic Types via 5-Tuple: Information from the 5-tuple could provide understanding of the traffic type, and network management appropriate for that traffic type could then be applied.
o Heuristics: Networks can sometimes identify traffic types by observing characteristics, such as data flow rate, and then apply network management to these identified flows. This is not recommended, as categorizations can be incorrect. o APIs: An API for operators to share congestion status or the state of a cell before an application starts sending data could allow applications to change their behavior. Alternatively, an API could provide the network with information on the data type, allowing appropriate network management for that data type; however, this method exposes privacy issues. o Standard approach for the operator to offer services to Content Providers: Mobile network operators could provide caching services or other services for content providers to use for faster and smoother content delivery. o AQM [RFC7567] and ECN [RFC3168] deployments: Queuing and congestion management methods have existed for some time in the form of AQM, ECN, and others, which can help the transport and Internet protocol layers adapt to congestion faster. o Trust Model or Trust Framework: Some solutions in this area (e.g., SPUD) have a reliance on trust when content providers or the network are being asked to add classifiers to their traffic. o Keyless SSL [KeylessSSL]: This allows content providers to maintain their private keys on a key server and host the content elsewhere (e.g., on a CDN). This could become standardized in the IETF. [LURK] o Meaningful capacity sharing: This includes the ConEx [CONEX] work, which exposes information about congestion to the network nodes. o Hop-by-hop: Some suggestions offer hop-by-hop methods that allow nodes to adapt flow given the qualities of the networks around them and the congestion they are experiencing. o Metrics and metric standards: In order to evolve current protocols to be best suited to today's networks, data is needed about current network conditions, protocol deployments, packet traces, and middlebox behavior. Beyond this, proper testing and debugging on networks could provide great insight for stack evolution. o 5G: Mobile operator standards bodies are in the process of setting the requirements for 5G. Requirements for network management could be added.
In the workshop, attendees identified other areas where greater understanding could help the standards process. These were identified as: o greater understanding of the RAN within the IETF; o reviews and comments on 3GPP perspective; and, o how to do congestion control in the RAN. MTG] has entered into a testing and data collection phase, although further advancements in transport technologies (QUIC, among others) may have stalled efforts in TCP-related proposals.
o Work on proposals for caching encrypted content continue, albeit with some security flaws that proponents are working on further proposals to fix. Most often, these are discussed within the IETF HTTPbis Working Group. o The Path Layer UDP Substrate (PLUS) BOF at IETF 96 in July 2016 did not result in the formation of a working group, as attendees expressed concern on the privacy issues associated with the proposed data-sharing possibilities of the shim layer. o The Limited Use of Remote Keys (LURK) BOF at IETF 96 in July 2016 did not result in the formation of a working group because the BOF identified more problems with the presumed approach than anticipated. The most rewarding output of MaRNEW is perhaps the most intangible. MaRNEW gave two rather divergent industry groups the opportunity to connect and discuss common technologies and issues affecting users and operations. Mobile network providers and key Internet engineers and experts have developed a greater collaborative relationship to aid development of further standards that work across networks in a secure manner. [BLIND_CACHING] Thomson, M., Eriksson, G., and C. Holmberg, "Caching Secure HTTP Content using Blind Caches", Work in Progress, draft-thomson-http-bc-01, October 2016. [CDNI] IETF, "Content Delivery Networks Interconnection (cdni)", <https://datatracker.ietf.org/wg/cdni/charter/>. [CHATHAM_HOUSE_RULE] Chatham House, "Chatham House Rule | Chatham House", <https://www.chathamhouse.org/about/chatham-house-rule>.
[CONEX] IETF, "Congestion Exposure (conex) - Documents", <https://datatracker.ietf.org/wg/conex/documents/>. [EffectEncrypt] Xiong, C. and M. Patel, "The effect of encrypted traffic on the QoS mechanisms in cellular networks", August 2015, <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_25.pdf>. [FLOWQUEUE] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "FlowQueue-Codel", Work in Progress, draft-hoeiland-joergensen-aqm-fq-codel-01, November 2014. [GSMA] GSMA, "GSMA Homepage", <http://gsma.com>. [IWF] IWF, "Internet Watch Foundation Homepage", <https://www.iwf.org.uk/>. [KeylessSSL] Sullivan, N., "Keyless SSL: The Nitty Gritty Technical Details", September 2014, <https://blog.cloudflare.com/ keyless-ssl-the-nitty-gritty-technical-details/>. [LURK] Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, "LURK TLS/DTLS Use Cases", Work in Progress, draft-mglt-lurk-tls-use-cases-02, June 2016. [MARNEW] IAB, "Managing Radio Networks in an Encrypted World (MaRNEW) Workshop 2015", <https://www.iab.org/activities/workshops/marnew/>. [MTG] Jain, A., Terzis, A., Flinck, H., Sprecher, N., Arunachalam, S., Smith, K., Devarapalli, V., and R. Yanai, "Mobile Throughput Guidance Inband Signaling Protocol", Work in Progress, draft-flinck-mobile-throughput-guidance- 04, March 2017. [NETWORK_MANAGEMENT] Smith, K., "Network management of encrypted traffic", Work in Progress, draft-smith-encrypted-traffic-management-05, May 2016. [NOTE_WELL] IETF, "IETF Note Well", <https://www.ietf.org/about/note-well.html>.
[PCC] Dong, M., Li, Q., Zarchy, D., Brighten Godfrey, P., and M. Schapira, "PCC: Re-architecting Congestion Control for Consistent High Performance", Proceedings of the 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI '15), USENIX Association, May 2015, <https://www.usenix.org/system/files/conference/nsdi15/ nsdi15-paper-dong.pdf>. [PCC-QOS] 3GPP, "Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping", 3GPP TS 29.213, version 15.3.0, Release 15, June 2018, <http://www.3gpp.org/DynaReport/29213.htm>. [Pew2014] Madden, M., "Public Perceptions of Privacy and Security in the Post-Snowden Era", November 2014, <http://www.pewinternet.org/2014/11/12/ public-privacy-perceptions/>. [QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Work in Progress, draft-tsvwg-quic-protocol-02, January 2016. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, <https://www.rfc-editor.org/info/rfc2804>. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>. [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>. [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>. [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[SDO_3GPP] 3GPP, "3GPP Homepage", <http://www.3gpp.org/>. [SPROUT] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks", 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI '13), USENIX Association, April 2013, <https://www.usenix.org/system/files/conference/nsdi13/ nsdi13-final113.pdf>. [SPUD] IETF, "Session Protocol for User Datagrams (spud)", <https://datatracker.ietf.org/wg/spud/about/>. [STATE_BROWSER] Barnes, R., "Some observations of TLS in the web", July 2015, <https://www.ietf.org/proceedings/93/slides/ slides-93-saag-3.pdf>. [STATE_SERVER] Salz, R., "Some observations of TLS in the web", July 2015, <https://www.ietf.org/proceedings/93/slides/ slides-93-saag-4.pdf>. [TCPINC] "TCP Increased Security (tcpinc)", <https://datatracker.ietf.org/wg/tcpinc/charter/>.
o Ted Hardie, IAB / Google o Robert Sparks, IAB / Oracle o Spencer Dawkins, IETF AD o Benoit Claise, IETF AD / Cisco o Kathleen Moriarty, IETF AD / EMC o Barry Leiba, IETF AD / Huawei o Ben Campbell, IETF AD / Oracle o Stephen Farrell, IETF AD / Trinity College Dublin o Jari Arkko, IETF Chair / Ericsson o Karen O'Donoghue, ISOC o Phil Roberts, ISOC o Olaf Kolkman, ISOC o Christian Huitema, Microsoft o Patrick McManus, Mozilla o Dirk Kutscher, NEC Europe Network Laboratories o Mark Watson, Netflix o Martin Peylo, Nokia o Mohammed Dadas, Orange o Diego Lopez, Telefonica o Matteo Varvello, Telefonica o Zubair Shafiq, The University of Iowa o Vijay Devarapalli, Vasona Networks o Sanjay Mishra, Verizon o Gianpaolo Scassellati, Vimplecom
o Kevin Smith, Vodafone o Wendy Seltzer, W3C https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_33.pdf> o Julien Maisonneuve, Vijay Gurbani, and Thomas Fossati, "The security pendulum" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf> o Martin Peylo, "Enabling Secure QoE Measures for Internet Applications over Radio Networks is a MUST" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_32.pdf> o Vijay Devarapalli, "The Bandwidth Balancing Act: Managing QoE as encrypted services change the traffic optimization game" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_10.pdf> o Humberto J. La Roche, "Use Cases for Communicating End-Points in Mobile Network Middleboxes" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_12.pdf> o Patrick McManus and Richard Barnes, "User Consent and Security as a Public Good" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_13.pdf> o Iuniana Oprescu, Jon Peterson, and Natasha Rooney, "A Framework for Consent and Permissions in Mediating TLS" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_31.pdf> o Jari Arkko and Goran Eriksson, "Characteristics of Traffic Type Changes and Their Architectural Implications" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_15.pdf> o Szilveszter Nadas and Attila Mihaly, "Concept for Cooperative Traffic Management" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf>
o Gianpaolo Scassellati, "Vimpelcom Position paper for MaRNEW Workshop" at <https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_17.pdf> o Mirja Kuhlewind, Dirk Kutscher, and Brian Trammell, "Enabling Traffic Management without DPI" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_18.pdf> o Andreas Terzis and Chris Bentzel, "Sharing network state with application endpoints" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_19.pdf> o Marcus Ihlar, Salvatore Loreto, and Robert Skog, "The needed existence of PEP in an encrypted world" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_20.pdf> o John Mattsson, "Network Operation in an All-Encrypted World" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_21.pdf> o Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello, and Paul Polakos, "Maintaining Efficiency and Privacy in Mobile Networks through Information-Centric Networking" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_23.pdf> o Chunshan Xiong and Milan Patel, "The effect of encrypted traffic on the QoS mechanisms in cellular networks" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_25.pdf> o Thomas Anderson, Peter Bosch, and Alessandro Duminuco, "Bandwidth Control and Regulation in Mobile Networks via SDN/NFV-Based Platforms" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_26.pdf> o Karen O'Donoghue and Phil Roberts, "Barriers to Deployment: Probing the Potential Differences in Developed and Developing Infrastructure" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_27.pdf> o Wendy Seltzer, "Security, Privacy, and Performance Considerations for the Mobile Web" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_28.pdf> o Jianjie You, Hanyu Wei, and Huaru Yang, "Use Case Analysis and Potential Bandwidth Optimization Methods for Encrypted Traffic" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_29.pdf>
o Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and Encrypted Traffic" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_30.pdf> o Yves Hupe, Claude Rocray, and Mark Santelli, "Providing Optimization of Encrypted HTTP Traffic" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_341.pdf> o M. Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted Internet" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_35.pdf> o Kevin Smith, "Encryption and government regulation: what happens now?" at <https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_1.pdf> https://gsma.com Spencer Dawkins (editor) Wonder Hamster Email: email@example.com