doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc8462.txt b/doc/rfc/rfc8462.txt
new file mode 100644
index 0000000..7fb76db
--- /dev/null
+++ b/doc/rfc/rfc8462.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                              N. Rooney
+Request for Comments: 8462                               S. Dawkins, Ed.
+Category: Informational                                     October 2018
+ISSN: 2070-1721
+
+
+                    Report from the IAB Workshop on
+         Managing Radio Networks in an Encrypted World (MaRNEW)
+
+Abstract
+
+   The Internet Architecture Board (IAB) and GSM Association (GSMA) held
+   a joint workshop on Managing Radio Networks in an Encrypted World
+   (MaRNEW), on September 24-25, 2015.  This workshop aimed to discuss
+   solutions for bandwidth optimization on mobile networks for encrypted
+   content, as current solutions rely on unencrypted content, which is
+   not indicative of the security needs of today's Internet users.  The
+   workshop gathered IETF attendees, IAB members, and participants from
+   various organizations involved in the telecommunications industry
+   including original equipment manufacturers, content providers, and
+   mobile network operators.
+
+   The group discussed Internet encryption trends and deployment issues
+   identified within the IETF and the privacy needs of users that should
+   be adhered to.  Solutions designed around sharing data from the
+   network to the endpoints and vice versa were then discussed; in
+   addition, issues experienced when using current transport-layer
+   protocols were also discussed.  Content providers and Content
+   Delivery Networks (CDNs) gave their own views of their experiences
+   delivering their content with mobile network operators.  Finally,
+   technical responses to regulation were discussed to help the
+   regulated industries relay the issues of impossible-to-implement or
+   bad-for-privacy technologies back to regulators.
+
+   A group of suggested solutions were devised, which will be discussed
+   in various IETF groups moving forward.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 1]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8462.
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 2]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Understanding "Bandwidth Optimization"  . . . . . . . . .   4
+     1.2.  Topics  . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     1.3.  Organization of This Report . . . . . . . . . . . . . . .   5
+     1.4.  Use of Note Well and the Chatham House Rule . . . . . . .   6
+     1.5.  IETF and GSMA . . . . . . . . . . . . . . . . . . . . . .   6
+   2.  Scene-Setting Sessions  . . . . . . . . . . . . . . . . . . .   7
+     2.1.  Scene Setting . . . . . . . . . . . . . . . . . . . . . .   7
+       2.1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .   8
+       2.1.2.  Encryption Statistics and Radio Access Network
+               Differences . . . . . . . . . . . . . . . . . . . . .   8
+     2.2.  Encryption Deployment Considerations  . . . . . . . . . .   9
+     2.3.  Awareness of User Choice (Privacy)  . . . . . . . . . . .  10
+   3.  Network or Transport Solution Sessions  . . . . . . . . . . .  11
+     3.1.  Sending Data Up/Down for Network Management Benefits  . .  11
+       3.1.1.  Competition, Cooperation, and Mobile Network
+               Complexities  . . . . . . . . . . . . . . . . . . . .  12
+   4.  Transport Layer: Issues, Optimization, and Solutions  . . . .  13
+   5.  Application-Layer Optimization, Caching, and CDNs . . . . . .  14
+   6.  Technical Analysis and Response to Potential Regulatory
+       Reaction  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   7.  Suggested Principles and Solutions  . . . . . . . . . . . . .  16
+     7.1.  Better Collaboration  . . . . . . . . . . . . . . . . . .  19
+   8.  Since MaRNEW  . . . . . . . . . . . . . . . . . . . . . . . .  19
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
+   11. Informative References  . . . . . . . . . . . . . . . . . . .  20
+   Appendix A.  Workshop Attendees . . . . . . . . . . . . . . . . .  24
+   Appendix B.  Workshop Position Papers . . . . . . . . . . . . . .  26
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 3]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+1.  Introduction
+
+   The Internet Architecture Board (IAB) and GSM Association (GSMA) held
+   a joint workshop on Managing Radio Networks in an Encrypted World
+   (MaRNEW), on September 24-25, 2015.  This workshop aimed to discuss
+   solutions for bandwidth optimization on mobile networks for encrypted
+   content, as current solutions rely on unencrypted content, which is
+   not indicative of the security needs of today's Internet users.
+
+   Mobile networks have a set of properties that place a large emphasis
+   on sophisticated bandwidth optimization.  The use of encryption is
+   increasing on the Internet, which is positive for consumer and
+   business privacy and security.  Many existing solutions for mobile
+   bandwidth optimization primarily operate on non-encrypted
+   communications; this can lead to performance issues being amplified
+   on mobile networks.  The use of encryption on networks will continue
+   to increase; with this understanding, the workshop aimed to
+   understand how we can solve the issues of bandwidth optimization and
+   performance on radio networks in this encrypted world.
+
+1.1.  Understanding "Bandwidth Optimization"
+
+   For the purposes of this workshop, bandwidth optimization encompasses
+   a variety of technical topics related to traffic engineering,
+   prioritization, optimization, and efficiency enhancements.  It also
+   encompasses user-related topics such as specific subscription or
+   billing models, and it may touch upon regulatory aspects or other
+   issues relating to government-initiated regulatory concerns.
+
+   The first category of bandwidth optimization includes the following:
+
+   o  Caching
+
+   o  Prioritization of interactive traffic over background traffic
+
+   o  Per-user bandwidth limits
+
+   The second category of bandwidth optimization may depend on one or
+   more of the first category optimization strategies, but may, in
+   particular, also encompass business-related topics such as content
+   delivery arrangements with content providers.
+
+   Finally, while not strictly speaking of traffic management, some
+   networks employ policy-based filtering (e.g., requested parental
+   controls), and many networks support some form of legal interception
+   functionality per applicable laws.
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 4]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   Many of these functions can continue as they are performed today,
+   even with increased use of encryption.  Others are using methods that
+   inspect parts of the communication that are not encrypted today, but
+   will be encrypted, and these functions will have to be done
+   differently in an increasingly encrypted Internet.
+
+1.2.  Topics
+
+   The workshop aimed to answer questions that focused on:
+
+   o  understanding the bandwidth optimization use cases particular to
+      radio networks;
+
+   o  understanding existing approaches and how these do not work with
+      encrypted traffic;
+
+   o  understanding reasons why the Internet has not standardized
+      support for lawful intercept and why mobile networks have;
+
+   o  determining how to match traffic types with bandwidth optimization
+      methods
+
+   o  discussing minimal information to be shared to manage networks but
+      ensure user security and privacy;
+
+   o  developing new bandwidth optimization techniques and protocols
+      within these new constraints;
+
+   o  discussing the appropriate network layer(s) for each management
+      function; and
+
+   o  cooperative methods of bandwidth optimization and issues
+      associated with these.
+
+   The further aim was to gather architectural and engineering guidance
+   on future work in the bandwidth optimization area based on the
+   discussions around the proposed approaches.  The workshop also
+   explored possible areas for standardization, e.g., new protocols that
+   can aid bandwidth optimization whilst ensuring that user security is
+   in line with new work in transport-layer protocols.
+
+1.3.  Organization of This Report
+
+   This workshop report summarizes the contributions to and discussions
+   at the workshop, organized by topic.  The workshop began with scene-
+   setting topics that covered the issues around deploying encryption,
+   the increased need for privacy on the Internet, and setting a clear
+   understanding that ciphertext should remain unbroken.  Later sessions
+
+
+
+Rooney & Dawkins              Informational                     [Page 5]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   focused on key solution areas; these included evolution on the
+   transport layer and sending data up or down the path.  A session on
+   application layers and CDNs aimed to highlight both issues and
+   solutions experienced on the application layer.  The workshop ended
+   with a session dedicated to discussing a technical response to
+   regulation with regards to encryption.  The contributing documents
+   identified the issues experienced with encryption on radio networks
+   and suggested solutions.  Of the solutions suggested, some focused on
+   transport evolution, some on trusted middleboxes, and others on
+   collaborative data exchange.  Solutions were discussed within the
+   sessions.  All accepted position papers and detailed transcripts of
+   discussion are available at [MARNEW].
+
+   The outcomes of the workshop are discussed in Sections 7 and 8; they
+   discuss the progress made since the workshop toward each of the
+   identified work items through the time this document was approved for
+   publication.
+
+   Report readers should be reminded that this workshop did not aim to
+   discuss regulation or legislation, although policy topics were
+   mentioned in discussions from time to time.
+
+1.4.  Use of Note Well and the Chatham House Rule
+
+   The workshop was conducted under the IETF [NOTE_WELL] with the
+   exception of the "Technical Analysis and Response to Potential
+   Regulatory Reaction" session, which was conducted under the
+   [CHATHAM_HOUSE_RULE].
+
+1.5.  IETF and GSMA
+
+   The IETF and GSMA [GSMA] have different working practices, standards,
+   and processes.  IETF is an open organization with community-driven
+   standards, with the key aim of functionality and security for the
+   Internet's users, while the GSMA is membership based and serves the
+   needs of its membership base, most of whom are mobile network
+   operators.
+
+   Unlike IETF, GSMA makes few standards.  Within the telecommunications
+   industry, standards are set in various divergent groups depending on
+   their purpose.  Perhaps of most relevance to the bandwidth
+   optimization topic here is the work of the 3rd Generation Partnership
+   Project (3GPP) [SDO_3GPP], which works on radio network and core
+   network standards.  3GPP members include mobile operators and
+   original equipment manufacturers.
+
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 6]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   One of the 3GPP standards relevant to this workshop is Policy and
+   Charging Control QoS [PCC-QOS].  Traditionally, mobile networks have
+   managed different applications and services based on the resources
+   available and priorities given; for instance, emergency services have
+   a top priority, data has a lower priority, and voice services are
+   somewhere in-between.  3GPP defined the PCC-QoS mechanism to support
+   this functionality, and this depends on unencrypted communications
+   [EffectEncrypt].
+
+2.  Scene-Setting Sessions
+
+   Scene-setting sessions aimed to bring all attendees up to a basic
+   understanding of the problem and the scope of the workshop.
+
+   There were three scene-setting sessions:
+
+   o  Section 2.1: Scene Setting
+
+   o  Section 2.2: Encryption Deployment Considerations
+
+   o  Section 2.3: Awareness of User Choice (Privacy)
+
+2.1.  Scene Setting
+
+   The telecommunications industry and Internet standards community are
+   extremely different in terms of ethos and practices.  Both groups
+   drive technical standards in their domain and build technical
+   solutions with some policy-driven use cases.  These technologies, use
+   cases, and technical implementations are different, and the
+   motivators between the two industries are also diverse.
+
+   To ensure all attendees were aligned with contributing to discussions
+   and driving solutions, this "Scene Setting" session worked on
+   generating a clear scope with all attendees involved.  In short, it
+   was agreed that 1) ciphertext encrypted by one party and intended to
+   be decrypted by a second party should not be decrypted by a third
+   party in any solution, 2) the Radio Access Network (RAN) does
+   experience issues with increased encrypted traffic, 3) the RAN issues
+   need to be understood precisely, and 4) the goal is to improve user
+   experience on the Internet.  Proposing new technical solutions based
+   on presumed future regulation was not in scope.  The full scope is
+   given below.
+
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 7]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+2.1.1.  Scope
+
+   The attendees identified and agreed to the scope described here.
+
+   We should do the following:
+
+   o  in discussion, assume that there is no broken crypto; ciphertext
+      is increasingly common; congestion does need to be controlled (as
+      do other transport issues); and network management, including
+      efficient use of resources in RAN and elsewhere, has to work;
+
+   o  identify how/why RAN is different for transport, and attempt to
+      understand the complexities of RAN (i.e., how hard it is to
+      manage) and why those complexities matter;
+
+   o  identify the precise problems caused by increased use of
+      encryption;
+
+   o  identify players (in addition to end users), the resulting
+      tensions, and how ciphertext changes those tensions;
+
+   o  discuss how some solutions will be radically changed by ciphertext
+      (it's ok to talk about that)
+
+   o  assume that the best possible quality of experience for the end
+      user is a goal; and lastly,
+
+   o  for the next two days, aim to analyze the situation and identify
+      specific achievable tasks that could be tackled in the IETF or
+      GSMA (or elsewhere) and that improve the Internet given the
+      assumptions above.
+
+   We should not delve into the following:
+
+   o  ways of doing interception, legal or not, for the reasons
+      described in [RFC2804]; and,
+
+   o  unpredictable political actions.
+
+2.1.2.  Encryption Statistics and Radio Access Network Differences
+
+   According to then-current statistics, attendees were shown that
+   encrypted content reaches around 50% [STATE_BROWSER] [STATE_SERVER].
+   The IAB is encouraging all IETF working groups to consider the effect
+   encryption being "on by default" will have on new protocol work.  The
+   IETF is also working on encryption at lower layers.  One recent
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 8]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   example of this work is opportunistic TCP encryption within the TCP
+   Increased Security [TCPINC] Working Group.  The aims of these work
+   items are greater security and privacy for end users and their data.
+
+   Telecommunications networks often contain middleboxes that operators
+   have previously considered to be trusted, but qualifying trust is
+   difficult and should not be assumed.  Some interesting use cases
+   exist with these middleboxes, such as anti-spam and malware
+   detection, but these need to be balanced against their ability to
+   open up cracks in the network for attacks such as pervasive
+   monitoring.
+
+   When operators increase the number of radio access network cells
+   (base stations), this can improve the radio access network quality of
+   service; however, it also adds to radio pollution.  This is one
+   example of the balancing act required when devising radio access
+   network architecture.
+
+2.2.  Encryption Deployment Considerations
+
+   Encryption across the Internet is on the rise.  However, some
+   organizations and individuals that are mainly driven by commercial
+   perspectives come across a common set of operational issues when
+   deploying encryption.  [RFC8404] explains these network management
+   function impacts, detailing areas around incident monitoring, access
+   control management, and regulation on mobile networks.  The data was
+   collected from various Internet players, including system and network
+   administrators across enterprise, governmental organizations, and
+   personal use.  The aim of the document is to gain an understanding of
+   what is needed for technical solutions to these issues while
+   maintaining security and privacy for users.  Attendees commented that
+   worthwhile additions would be different business environments (e.g.,
+   cloud environments) and service chaining.  Incident monitoring in
+   particular was noted as a difficult issue to solve given the use of
+   URLs in today's incident monitoring middleware.
+
+   Some of these impacts to mobile networks can be resolved using
+   different methods, and the [NETWORK_MANAGEMENT] document details
+   these methods.  The document focuses heavily on methods to manage
+   network traffic without breaching user privacy and security.
+
+   By reviewing encryption deployment issues and the alternative methods
+   of network management, MaRNEW attendees were made aware of the issues
+   that affect radio networks, the deployment issues that are solvable
+   and require no further action, and those issues that have not yet
+   been solved but should be addressed within the workshop.
+
+
+
+
+
+Rooney & Dawkins              Informational                     [Page 9]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+2.3.  Awareness of User Choice (Privacy)
+
+   Some solutions intended to improve delivery of encrypted content
+   could affect some or all of the privacy benefits that encryption
+   provides.  Understanding user needs and desires for privacy is
+   therefore important when designing these solutions.
+
+   From a then-current study [Pew2014], 64% of users said concerns over
+   privacy have increased, and 67% of mobile Internet users would like
+   to do more to protect their privacy.  The World Wide Web Consortium
+   (W3C) and IETF have both responded to user desires for better privacy
+   by recommending encryption for new protocols and web technologies.
+   Within the W3C, new security standards are emerging, and the design
+   principles for HTML maintain that users are the stakeholders with the
+   highest priority, followed by implementors and other stakeholders,
+   which further enforces the "user first" principle.  Users also have
+   certain security expectations from particular contexts and sometimes
+   use new technologies to further protect their privacy, even if those
+   technologies weren't initially developed for that purpose.
+
+   Operators may deploy technologies that can either impact user privacy
+   without being aware of those privacy implications or incorrectly
+   assume that the benefits users gain from the new technology outweigh
+   the loss of privacy.  If these technologies are necessary, they
+   should be opt in.
+
+   Internet stakeholders should understand the priority of other
+   stakeholders.  Users should be considered the first priority.  Other
+   stakeholders include implementors, developers, advertisers,
+   operators, and other ISPs.  Some technologies, such as cookie use and
+   JavaScript injection, have been abused by these parties.  This has
+   caused some developers to encrypt content to circumvent these
+   technologies that are seen as intrusive or bad for user privacy.
+
+   If users and content providers are to opt in to network management
+   services with negative privacy impacts, they should see clear value
+   from using these services and understand the impacts of using these
+   services.  Users should also have easy abilities to opt out.  Some
+   users will always automatically click through consent requests, so
+   any model relying on explicit consent is flawed for these users.
+   Understanding the extent of "auto click-through" may improve
+   decisions about the use of consent requests in the future.  One model
+   (Cooperative Traffic Management) works as an agent of the user; by
+   opting in, metadata can be shared.  Issues with this involve trust
+   only being applied at endpoints.
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 10]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+3.  Network or Transport Solution Sessions
+
+   Network or Transport Solution Sessions discussed proposed solutions
+   for managing encrypted traffic on radio access networks.  Most
+   solutions focus on metadata sharing, whether this sharing takes place
+   from the endpoint to the network, from the network to the endpoint,
+   or cooperatively in both directions.  Transport-layer protocol
+   evolution could be another approach to solve some of the issues radio
+   access networks experience, which cause them to rely on network
+   management middleboxes.  By removing problems at the transport layer,
+   reliance on expensive and complex middleboxes could decrease.
+
+3.1.  Sending Data Up/Down for Network Management Benefits
+
+   Collaboration between network elements and endpoints could bring
+   about better content distribution.  A number of suggestions were
+   given; these included the following:
+
+   o  Mobile Throughput Guidance [MTG]: exchanges metadata between
+      network elements and endpoints via TCP options.  It also allows
+      for better understanding of how the transport protocol behaves and
+      further improves the user experience, although additional work on
+      MTG is still required.
+
+   o  Session Protocol for User Datagrams [SPUD]: a UDP-based
+      encapsulation protocol to allow explicit cooperation with
+      middleboxes while using, new encrypted transport protocols.
+
+   o  Network Status API: an API for operators to share congestion
+      status or the state of a cell before an application starts sending
+      data that could allow applications to change their behavior.
+
+   o  Traffic Classification: classifying traffic and adding these
+      classifications as metadata for analysis throughout the network.
+      This idea has trust and privacy implications.
+
+   o  Congestion Exposure [CONEX]: a mechanism where senders inform the
+      network about the congestion encountered by previous packets on
+      the same flow, in-band at the IP layer.
+
+   o  Latency versus Bandwidth: a bit that allows the content provider
+      to indicate whether higher bandwidth or lower latency is of
+      greater priority and allows the network to react based on that
+      indication.  Where this bit resides in the protocol stack and how
+      it is authenticated would need to be decided.
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 11]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  No Network Management Tools: disabling all network management
+      tools from the network and relying only on end-to-end protocols to
+      manage congestion.
+
+   o  Flow Queue Controlled Delay (FQ-CoDel) [FLOWQUEUE]: a hybrid
+      packet scheduler / Active Queue Management (AQM) [RFC7567]
+      algorithm aiming to reduce bufferbloat and latency.  FQ-CoDel
+      manages packets from multiple flows and reduces the impact of
+      head-of-line blocking from bursty traffic.
+
+   Some of these suggestions rely on signaling from network elements to
+   endpoints.  Others aim to create "hop-by-hop" solutions, which could
+   be more aligned with how congestion is managed today but with greater
+   privacy implications.
+
+   Still others rely on signaling from endpoints to network elements.
+   Some of these rely on implicit signaling and others on explicit
+   signaling.  Some workshop attendees agreed that relying on
+   applications to explicitly declare the quality of service they
+   require was not a good path forward given the lack of success with
+   this model in the past.
+
+3.1.1.  Competition, Cooperation, and Mobile Network Complexities
+
+   One of the larger issues in sharing data about the problems
+   encountered with encrypted traffic in wireless networks is the matter
+   of competition; network operators are reluctant to relinquish data
+   about their own networks because it contains information that is
+   valuable to competitors, and application providers wish to protect
+   their users and reveal as little information as possible to the
+   network.  Some people think that if middleboxes were authenticated
+   and invoked explicitly, this would be an improvement over current
+   transparent middleboxes that intercept traffic without endpoint
+   consent.  Some workshop attendees suggested any exchange of
+   information should be bidirectional in an effort to improve
+   cooperation between the elements.  A robust incentive framework could
+   provide a solution to these issues or at least help mitigate them.
+
+   The radio access network is complex because it must deal with a
+   number of conflicting demands.  Base stations reflect this
+   environment, and information within these base stations can be of
+   value to other entities on the path.  Some workshop participants
+   thought solutions for managing congestion on radio networks should
+   involve the base station if possible.  For instance, understanding
+   how the radio resource controller and AQM [RFC7567] interact (or
+   don't interact) could provide valuable information for solving
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 12]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   issues.  Although many workshop attendees agreed that even though
+   there is a need to understand the base station, not all agreed that
+   the base station should be part of a future solution.
+
+   Some suggested solutions were based on network categorization and on
+   providing this information to the protocols or endpoints.  Completely
+   categorizing radio networks could be impossible due to their
+   complexity, but categorizing essential network properties could be
+   possible and valuable.
+
+4.  Transport Layer: Issues, Optimization, and Solutions
+
+   TCP has been the dominant transport protocol since TCP/IP replaced
+   the Network Control Protocol (NCP) on the ARPANET in March 1983.  TCP
+   was originally devised to work on a specific network model that did
+   not anticipate the high error rates and highly variable available
+   bandwidth scenarios experienced on modern radio access networks.
+
+   Furthermore, new network elements have been introduced (NATs and
+   network devices with large buffers creating bufferbloat), and
+   considerable peer-to-peer traffic is competing with traditional
+   client-server traffic.  Consequently, the transport layer today has
+   requirements beyond what TCP was designed to meet.  TCP has other
+   issues as well; too many services rely on TCP and only TCP, blocking
+   deployment of new transport protocols like the Stream Control
+   Transmission Protocol (SCTP) and Datagram Congestion Control Protocol
+   (DCCP).  This means that true innovation on the transport layer
+   becomes difficult because deployment issues are more complicated than
+   just building a new protocol.
+
+   The IETF is trying to solve these issues through the IAB's IP Stack
+   Evolution program, and the first step in this program is to collect
+   data.  Network and content providers can provide data including: the
+   cost of encryption, the advantages of network management tools, the
+   deployment of protocols, and the effects when network management
+   tools are disabled.  For mostly competitive reasons, network
+   operators do not tend to reveal network information and so are
+   unlikely to donate this information freely to the IETF.  The GSMA is
+   in a position to try to collect this data and anonymize it before
+   bringing it to IETF, which should alleviate the network operator
+   worries but still provide IETF with some usable data.
+
+   Although congestion is only detected when packet loss is encountered
+   and better methods based on detecting congestion would be beneficial,
+   a considerable amount of work has already been done on TCP,
+   especially innovation in bandwidth management and congestion control.
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 13]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   Furthermore, although the deficiencies of TCP are often considered
+   key issues in the evolution of the Internet protocol stack, the main
+   route to resolve these issues may not be a new TCP, but an evolved
+   stack.  Some workshop participants suggested that SPUD [SPUD] and
+   Information-Centric Networking (ICN) [RFC7476] may help here.  Quick
+   UDP Internet Connection [QUIC] engineers stated that the problems
+   solved by QUIC are general problems, rather than TCP issues.  This
+   view was not shared by all attendees of the workshop.  Moreover, TCP
+   has had some improvements in the last few years, which may mean some
+   of the network lower layers should be investigated to see whether
+   improvements can be made.
+
+5.  Application-Layer Optimization, Caching, and CDNs
+
+   Many discussions on the effects of encrypted traffic on radio access
+   networks happen between implementers and the network operators.  This
+   session aimed to gather the opinions of the content and caching
+   providers regarding their experiences running over mobile networks,
+   the quality of experience their users expect, and the content and
+   caching that providers would like to achieve by working with or using
+   the mobile network.
+
+   Content providers explained how even though this workshop cited
+   encrypted data over radio access networks as the main issue, the real
+   issue is network management generally, and all actors (applications
+   providers, networks, and devices) need to work together to overcome
+   these general network management issues.  Content providers explained
+   how they assume the mobile networks are standards compliant.  When
+   the network is not standards compliant (e.g., using non-standards-
+   compliant intermediaries), content providers can experience real
+   costs as users contact their support centers to report issues that
+   are difficult to test for and resolve.
+
+   Content providers cited other common issues concerning data traffic
+   over mobile networks.  Data subscription limits (known as "caps")
+   cause issues for users; users are confused about how data caps work
+   or are unsure how expensive media is and how much data it consumes.
+   Developers build products on networks not indicative of the networks
+   their customers are using, and not every organization has the
+   finances to build a caching infrastructure.
+
+   Strongly related to content providers, content owners consider CDNs
+   to be trusted deliverers of content, and CDNs have shown great
+   success in fixed networks.  Now that more traffic is moving to mobile
+   networks, there is a need to place caches near the user at the edge
+   of the mobile network.  Placing caches at the edge of the mobile
+   network is a solution, but it requires standards developed by content
+   providers and mobile network operators.  The IETF's CDN
+
+
+
+Rooney & Dawkins              Informational                    [Page 14]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   Interconnection [CDNI] Working Group aims to allow global CDNs to
+   interoperate with mobile CDNs, but this causes huge issues for the
+   caching of encrypted data between these CDNs.  Some CDNs are
+   experimenting with approaches like "Keyless SSL" [KeylessSSL] to
+   enable safer storage of content without passing private keys to the
+   CDN.  Blind Caching [BLIND_CACHING] is another proposal aimed at
+   caching encrypted content closer to the user and managing the
+   authentication at the original content provider servers.
+
+   At the end of the session, each panelist was asked to identify one
+   key collaborative work item.  Work items named were: evolving to
+   cache encrypted content, using one bit for latency / bandwidth trade-
+   off (explained below), better collaboration between the network and
+   application, better metrics to aid troubleshooting and innovation,
+   and indications from the network to allow the application to adapt.
+
+6.  Technical Analysis and Response to Potential Regulatory Reaction
+
+   This session was conducted under the Chatham House Rule.  The session
+   aimed to discuss regulatory and political issues, but not their worth
+   or need, and to understand the laws that exist and how technologists
+   can properly respond to them.
+
+   Mobile networks are regulated; compliance is mandatory and can incur
+   costs on the mobile network operator, while non-compliance can result
+   in service license revocation in some nations.  Regulation does vary
+   geographically.  Some regulations are court orders and others are
+   self-imposed regulations, for example, "block lists" of websites such
+   as the Internet Watch Foundation [IWF] list.  Operators are not
+   expected to decrypt sites, so those encrypted sites will not be
+   blocked because of content.
+
+   Parental-control-type filters also exist on the network and are
+   easily bypassed today, vastly limiting their effectiveness.  Better
+   solutions would allow for users to easily set these restrictions
+   themselves.  Other regulations are also hard to meet, such as user
+   data patterns, or will become harder to collect, such as Internet of
+   Things (IoT) cases.  Most attendees agreed that if a government
+   cannot get information it needs (and is legally entitled to have)
+   from network operators, they will approach content providers.  Some
+   governments are aware of the impact of encryption and are working
+   with, or trying to work with, content providers.  The IAB has
+   concluded that blocking and filtering can be done at the endpoints of
+   the communication.
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 15]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   Not all of these regulations apply to the Internet, and the Internet
+   community is not always aware of their existence.  Collectively, the
+   Internet community can work with GSMA and 3GPP and act together to
+   alleviate the risk imposed by encrypted traffic.  Some participants
+   expressed concern that governments might require operators to provide
+   information that they no longer have the ability to provide because
+   previously unencrypted traffic is now being encrypted, and this might
+   expose operators to new liability, but no specific examples were
+   given during the workshop.  A suggestion from some attendees was that
+   if any new technical solutions are necessary, they should easily be
+   "switched off".
+
+   Some mobile network operators are producing transparency reports
+   covering regulations including lawful intercept.  Operators who have
+   done this already are encouraging others to do the same.
+
+7.  Suggested Principles and Solutions
+
+   Based on the talks and discussions throughout the workshop, a set of
+   suggested principles and solutions has been collected.  This is not
+   an exhaustive list, and no attempt was made to come to consensus
+   during the workshop, so there are likely at least some participants
+   who would not agree with any particular principle listed below.  The
+   list is a union of participant thinking, not an intersection.
+
+   o  Encrypted Traffic: Any solution should encourage and support
+      encrypted traffic.
+
+   o  Flexibility: Radio access network qualities vary vastly, and the
+      network needs of content can differ significantly, so any new
+      solution should be flexible across either the network type,
+      content type, or both.
+
+   o  Privacy: New solutions should not introduce new ways for
+      information to be discovered and attributed to individual users.
+
+   o  Minimum data only for collaborative work: User data, application
+      data, and network data all need protection, so new solutions
+      should use minimal information to make a working solution.
+
+   A collection of solutions suggested by various participants during
+   the workshop is given below.  Inclusion in this list does not imply
+   that other workshop participants agreed.  Again, the list is a union
+   of proposed solutions, not an intersection.
+
+   o  Evolving TCP or evolution on the transport layer: This could take
+      a number of forms, and some of this work is already underway
+      within the IETF.
+
+
+
+Rooney & Dawkins              Informational                    [Page 16]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  Congestion Control: Many attendees cited congestion control as a
+      key issue.  Further analysis, investigation, and work could be
+      done in this space.
+
+   o  Sprout [SPROUT]: Researched at MIT, Sprout is a transport protocol
+      for applications that desire high throughput and low delay.
+
+   o  PCC [PCC]: Performance-oriented Congestion Control is a new
+      architecture that aims for consistent high performance, even in
+      challenging scenarios.  PCC endpoints observe the connection
+      between their actions and their known performance, which allows
+      them to adapt their actions.
+
+   o  CDNs and Caches: This suggests that placing caches closer to the
+      edge of the radio network, as close as possible to the mobile
+      user, or making more intelligent CDNs, would result in faster
+      content delivery and less strain on the network.
+
+   o  Blind Caching [BLIND_CACHING]: This is a proposal for caching of
+      encrypted content.
+
+   o  CDN Improvements: This includes Keyless SSL and better CDN
+      placement.
+
+   o  Mobile Throughput Guidance [MTG]: This is a mechanism and protocol
+      elements that allow the cellular network to provide near real-time
+      information on capacity available to the TCP server.
+
+   o  One Bit for Latency / Bandwidth Trade-Off: This suggests
+      determining whether using a single bit in an unencrypted transport
+      header to distinguish between traffic that the sender prefers to
+      be queued and traffic that the sender would prefer to drop rather
+      than delay provides additional benefits beyond what can be
+      achieved without this signaling.
+
+   o  Base Station: Some suggestions involved using the base station,
+      but this was not defined in detail.  The base station holds the
+      radio resource controller and scheduler, which could provide a
+      place to host solutions, or data from the base station could help
+      in devising new solutions.
+
+   o  Identify Traffic Types via 5-Tuple: Information from the 5-tuple
+      could provide understanding of the traffic type, and network
+      management appropriate for that traffic type could then be
+      applied.
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 17]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  Heuristics: Networks can sometimes identify traffic types by
+      observing characteristics, such as data flow rate, and then apply
+      network management to these identified flows.  This is not
+      recommended, as categorizations can be incorrect.
+
+   o  APIs: An API for operators to share congestion status or the state
+      of a cell before an application starts sending data could allow
+      applications to change their behavior.  Alternatively, an API
+      could provide the network with information on the data type,
+      allowing appropriate network management for that data type;
+      however, this method exposes privacy issues.
+
+   o  Standard approach for the operator to offer services to Content
+      Providers: Mobile network operators could provide caching services
+      or other services for content providers to use for faster and
+      smoother content delivery.
+
+   o  AQM [RFC7567] and ECN [RFC3168] deployments: Queuing and
+      congestion management methods have existed for some time in the
+      form of AQM, ECN, and others, which can help the transport and
+      Internet protocol layers adapt to congestion faster.
+
+   o  Trust Model or Trust Framework: Some solutions in this area (e.g.,
+      SPUD) have a reliance on trust when content providers or the
+      network are being asked to add classifiers to their traffic.
+
+   o  Keyless SSL [KeylessSSL]: This allows content providers to
+      maintain their private keys on a key server and host the content
+      elsewhere (e.g., on a CDN).  This could become standardized in the
+      IETF.  [LURK]
+
+   o  Meaningful capacity sharing: This includes the ConEx [CONEX] work,
+      which exposes information about congestion to the network nodes.
+
+   o  Hop-by-hop: Some suggestions offer hop-by-hop methods that allow
+      nodes to adapt flow given the qualities of the networks around
+      them and the congestion they are experiencing.
+
+   o  Metrics and metric standards: In order to evolve current protocols
+      to be best suited to today's networks, data is needed about
+      current network conditions, protocol deployments, packet traces,
+      and middlebox behavior.  Beyond this, proper testing and debugging
+      on networks could provide great insight for stack evolution.
+
+   o  5G: Mobile operator standards bodies are in the process of setting
+      the requirements for 5G.  Requirements for network management
+      could be added.
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 18]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   In the workshop, attendees identified other areas where greater
+   understanding could help the standards process.  These were
+   identified as:
+
+   o  greater understanding of the RAN within the IETF;
+
+   o  reviews and comments on 3GPP perspective; and,
+
+   o  how to do congestion control in the RAN.
+
+7.1.  Better Collaboration
+
+   Throughout the workshop, attendees placed emphasis on the need for
+   better collaboration between the IETF and telecommunications bodies
+   and organizations.  The workshop was one such way to achieve this,
+   but the good work and relationships built in the workshop should
+   continue so the two groups can work on solutions that are better for
+   both technologies and users.
+
+8.  Since MaRNEW
+
+   Since MaRNEW, a number of activities have taken place in various IETF
+   working groups and in groups external to IETF.  The Alternatives to
+   Content Classification for Operator Resource Deployment (ACCORD) BoF
+   was held at IETF 95 in November 2015, which brought the workshop
+   discussion to the wider IETF audiences by providing an account of the
+   discussions that had taken place within the workshop and highlighting
+   key areas to progress on.  Key areas to progress on and an update on
+   their current status are as follows:
+
+   o  The collection of usable metrics and data were requested by a
+      number of MaRNEW attendees, especially for use within the IRTF
+      Measurement and Analysis for Protocols (MAP) Research Group; this
+      data has been difficult to collect due to the closed nature of
+      mobile network operators.
+
+   o  Understanding impediments to protocol stack evolution has
+      continued within the IAB's IP Stack Evolution program and
+      throughout transport-related IETF working groups such as the
+      Transport Area Working Group (TSVWG).
+
+   o  The Mobile Throughput Guidance document [MTG] has entered into a
+      testing and data collection phase, although further advancements
+      in transport technologies (QUIC, among others) may have stalled
+      efforts in TCP-related proposals.
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 19]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  Work on proposals for caching encrypted content continue, albeit
+      with some security flaws that proponents are working on further
+      proposals to fix.  Most often, these are discussed within the IETF
+      HTTPbis Working Group.
+
+   o  The Path Layer UDP Substrate (PLUS) BOF at IETF 96 in July 2016
+      did not result in the formation of a working group, as attendees
+      expressed concern on the privacy issues associated with the
+      proposed data-sharing possibilities of the shim layer.
+
+   o  The Limited Use of Remote Keys (LURK) BOF at IETF 96 in July 2016
+      did not result in the formation of a working group because the BOF
+      identified more problems with the presumed approach than
+      anticipated.
+
+   The most rewarding output of MaRNEW is perhaps the most intangible.
+   MaRNEW gave two rather divergent industry groups the opportunity to
+   connect and discuss common technologies and issues affecting users
+   and operations.  Mobile network providers and key Internet engineers
+   and experts have developed a greater collaborative relationship to
+   aid development of further standards that work across networks in a
+   secure manner.
+
+9.  Security Considerations
+
+   This document is an IAB report from a workshop on interactions
+   between network security, especially privacy, and network
+   performance.
+
+   It does not affect the security of the Internet, taken on its own.
+
+10.  IANA Considerations
+
+   This document has no IANA actions.
+
+11.  Informative References
+
+   [BLIND_CACHING]
+              Thomson, M., Eriksson, G., and C. Holmberg, "Caching
+              Secure HTTP Content using Blind Caches", Work in
+              Progress, draft-thomson-http-bc-01, October 2016.
+
+   [CDNI]     IETF, "Content Delivery Networks Interconnection (cdni)",
+              <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>.
+
+
+
+Rooney & Dawkins              Informational                    [Page 20]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   [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>.
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 21]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   [PCC]      Dong, M., Li, Q., Zarchy, D., Brighten Godfrey, P., and M.
+              Schapira, "PCC: Re-architecting Congestion Control for
+              Consistent High Performance", Proceedings of the 12th
+              USENIX Symposium on Networked Systems Design and
+              Implementation (NSDI '15), USENIX Association, May 2015,
+              <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>.
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 22]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   [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/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 23]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+Appendix A.  Workshop Attendees
+
+   o  Rich Salz, Akamai
+
+   o  Aaron Falk, Akamai
+
+   o  Vinay Kanitkar, Akamai
+
+   o  Julien Maisonneuve, Alcatel Lucent
+
+   o  Dan Druta, AT&T
+
+   o  Humberto La Roche, Cisco
+
+   o  Thomas Anderson, Cisco
+
+   o  Paul Polakos, Cisco
+
+   o  Marcus Ihlar, Ericsson
+
+   o  Szilveszter Nadas, Ericsson
+
+   o  John Mattsson, Ericsson
+
+   o  Salvatore Loreto, Ericsson
+
+   o  Blake Matheny, Facebook
+
+   o  Andreas Terzis, Google
+
+   o  Jana Iyengar, Google
+
+   o  Natasha Rooney, GSMA
+
+   o  Istvan Lajtos, GSMA
+
+   o  Emma Wood, GSMA
+
+   o  Jianjie You, Huawei
+
+   o  Chunshan Xiong, Huawei
+
+   o  Russ Housley, IAB
+
+   o  Mary Barnes, IAB
+
+   o  Joe Hildebrand, IAB / Cisco
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 24]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  Ted Hardie, IAB / Google
+
+   o  Robert Sparks, IAB / Oracle
+
+   o  Spencer Dawkins, IETF AD
+
+   o  Benoit Claise, IETF AD / Cisco
+
+   o  Kathleen Moriarty, IETF AD / EMC
+
+   o  Barry Leiba, IETF AD / Huawei
+
+   o  Ben Campbell, IETF AD / Oracle
+
+   o  Stephen Farrell, IETF AD / Trinity College Dublin
+
+   o  Jari Arkko, IETF Chair / Ericsson
+
+   o  Karen O'Donoghue, ISOC
+
+   o  Phil Roberts, ISOC
+
+   o  Olaf Kolkman, ISOC
+
+   o  Christian Huitema, Microsoft
+
+   o  Patrick McManus, Mozilla
+
+   o  Dirk Kutscher, NEC Europe Network Laboratories
+
+   o  Mark Watson, Netflix
+
+   o  Martin Peylo, Nokia
+
+   o  Mohammed Dadas, Orange
+
+   o  Diego Lopez, Telefonica
+
+   o  Matteo Varvello, Telefonica
+
+   o  Zubair Shafiq, The University of Iowa
+
+   o  Vijay Devarapalli, Vasona Networks
+
+   o  Sanjay Mishra, Verizon
+
+   o  Gianpaolo Scassellati, Vimplecom
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 25]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   o  Kevin Smith, Vodafone
+
+   o  Wendy Seltzer, W3C
+
+Appendix B.  Workshop Position Papers
+
+   o  Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu,
+      "Cooperation Framework between Application layer and Lower Layers"
+      at <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>
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 26]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   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>
+
+
+
+Rooney & Dawkins              Informational                    [Page 27]
+
+RFC 8462                         MaRNEW                     October 2018
+
+
+   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>
+
+Acknowledgements
+
+   Stephen Farrell reviewed this report in draft form and provided
+   copious comments and suggestions.
+
+   Barry Leiba provided some clarifications on specific discussions
+   about Lawful Intercept that took place during the workshop.
+
+   Bob Hinden and Warren Kumari provided comments and suggestions during
+   the IAB Call for Comments.
+
+   Amelia Andersdotter and Shivan Kaul Sahib provided comments from the
+   Human Rights Review Team during the IAB Call for Comments.
+
+Authors' Addresses
+
+   Natasha Rooney
+   GSMA
+
+   Email: nrooney@gsma.com
+   URI:   https://gsma.com
+
+
+   Spencer Dawkins (editor)
+   Wonder Hamster
+
+   Email: spencerdawkins.ietf@gmail.com
+
+
+
+
+
+
+
+
+Rooney & Dawkins              Informational                    [Page 28]
+