Network Working Group                                          N. Rooney
Internet-Draft                                                      GSMA
Expires: December 24, 2017                                 June 22, 2017 August 23, 2018                                 S. Dawkins, Ed.
                                                          Wonder Hamster
                                                       February 19, 2018

 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)


   The MarNEW workshop aimed to discuss solutions for badnwidth bandwidth
   optimisation 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 Internet users.  The workshop gathered IETF
   attendees, IAB members and various organisations involved in the
   telecommunications industry including original equipment
   manufacturers and mobile network operators.

   The group discussed the current internet Internet encryption trends and
   deployment issues identified within the IETF, and the privacy needs
   of users which should be adhered.  Solutions designed around sharing
   data from the network to the endpoints and vice versa were then
   discussed as well as analysing whether the current issues experienced
   on the transport layer are also playing a role here.  Content
   providers and CDNs gave an honest view of their experiences delivery
   content with mobile network operators.  Finally, technical responses
   to regulation was 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 24, 2017. August 23, 2018.

Copyright Notice

   Copyright (c) 2017 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
   ( 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Understanding "Bandwidth Optimization"  . . . . . . . . .   3
     1.2.  Topics  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Organization of this report . . . . . . . . . . . . . . .   4
     1.4.  Use of Note Well and Charter House Rule . . . . . . . . .   5
     1.5.  IETF and GSMA . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Scene Setting Sessions  . . . . . . . . . . . . . . . . . . .   6
     2.1.  Scene Setting . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Encryption Statistics and Radio Access Network
               Differences . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Encryption Deployment Considerations  . . . . . . . . . .   7
     2.3.  Awareness of User Choice (Privacy)  . . . . . . . . . . .   8
   3.  Network or Transport Solution Sessions  . . . . . . . . . . .   9
     3.1.  Sending Data Up / Down for Network Management Benefits  .   9
       3.1.1.  Competition, Cooperation, and Mobile Network
               Complexities  . . . . . . . . . . . . . . . . . . . .  10
   4.  Transport Layer: Issues, Optimisation and Solutions . . . . .  11
   5.  Application Layer Optimisation, Caching and CDNs  . . . . . .  12
   6.  Technical Analysis and Response to Potential Regulatory
       Reaction  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Suggested Principles and Solutions  . . . . . . . . . . . . .  14
     7.1.  Better Collaboration  . . . . . . . . . . . . . . . . . .  17
   8.  Since MaRNEW  . . . . . . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   10. Informative References  . . . . . . . . . . . . . . . . . . .  18
   Appendix A.  Workshop Attendees . . . . . . . . . . . . . . . . .  23
   Appendix B.  Workshop Position Papers . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   Mobile networks have a set of requirements and properties which
   places a large emphasis on sophisticated bandwidth optimization.
   Encryption is increasing on the internet Internet which is positive for
   consumer and business privacy and security.  Many existing mobile
   bandwidth optimization solutions primarily operate on non-encrypted
   communications; this can lead to performance issues being amplified
   on mobile networks.  Encryption on networks will continue to
   increase; and 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,
   prioritisation, optimisation, efficiency enhancements, as well as
   user-related topics such as specific subscription or billing models.
   These can include:

   o  Caching

   o  Prioritisation of interactive traffic over background traffic

   o  Per-user bandwidth limit

   o  Business-related topics such as content delivery arrangements with
      specific content providers.

   Many of these functions can continue as they're performed today, even
   with more encryption.  Others use are using methods which require them to inspect parts
   of the communication that are encrypted, and these will have to be
   done differently in an encrypted Internet.

   Finally, while not strictly speaking traffic management, some
   networks employ policy-based filtering (e.g., requested parental
   controls) and all many networks support some form of legal interception
   functionality per applicable laws.

1.2.  Topics

   The workshop aimed to answer questions including:

   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 standardised
      support for lawful intercept and why mobile networks have

   o  Determining how to match traffic types with bandwidth optimization

   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

   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 optimisation 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 user security inline
   with new work in the transport layer.

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 which covered the issues around deploying encryption,
   the increased need for privacy on the internet Internet and setting a clear
   understanding that ciphertext should remain unbroken.  Later sessions
   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 technical response to regulation with
   regards to encryption.  The contributing documents were split between
   identifying 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 Section 7 and 8, and
   discuss progress after the workshop toward each of the identified
   work items as of the time of publication of this report.

   Although policy related topics were out of scope for this workshop
   they were infrequently referred to.

   Report readers should be reminded that this workshop did not and did not aim to
   discuss policy regulation or legislation, although policy recommendations. topics were
   mentioned in discussions from time to time.

1.4.  Use of Note Well and Charter 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

1.5.  IETF and GSMA

   The IETF and GSMA [GSMA] have divergent working pratices, practices, standards
   and processes.  IETF is an open organisation with community driven
   standards with the key aim of functionality and security for the
   Internet's users, 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.  Perhpas  Perhaps of most relevance to the bandwidth
   optimisation topic here is the work of the [SDO_3GPP] which work on
   radio network and core network standards with their members which
   include mobile operators and original equipment manufacturers.

   One of the [SDO_3GPP] standards relevant to this workship workshop is PCC-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 prioirty priority and voice services are somewhere
   in-between.  [SDO_3GPP] defined the PCC-QoS mechanism to support this
   functionality, some of which cannot occur for encrypted
   communications. and this depends on unencrypted communications

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 workhop. workshop.  There
   were three scene setting sessions: Scene Setting (defining scope),
   Encryption Deployment Considerations and Trust Models and User Choice

2.1.  Scene Setting

   The telecommunications industry and internet Internet standards community are
   extremely different in terms of ethos and business practices.  Both industries 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; not only this but
   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 ciphertext encrypted by one party and intended to be
   decrypted by a second party should not be broken decrypted by a third party
   in any solution, that the radio access network (RAN) is different and
   does experience issues with increased encrypted traffic, that we need
   to understand what those problems are precisely and that our goal is
   to improve user experience on the Internet.  Technical  Proposing new technical
   solutions for based on presumed future regulation was not in scope.  The
   full scope is given below.

2.1.1.  Scope

   The attendees identified and agreed the following scope:

   o  In discussion we should assume: No broken crypto, Ciphertext
      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  How/why is RAN different for transport; help us understand the
      complexities of the RAN and how hard it is to manage and why those

   o  What are the precise problems caused by more ciphertext

   o  Identify players, incl.  Users, and resulting tensions and how
      ciphertext changes those

   o  Some solutions will be radically changed by ciphertext, it's ok to
      talk about that

   o  As good as possible Quality of experience for end user is a goal

   o  Our aim for the next two days is to analyse 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

   o  We should not delve into:


      *  Ways of doing interception (legal or not), see RFC2804 [RFC2804] for


      *  Unpredictable political actions.

2.1.2.  Encryption Statistics and Radio Access Network Differences

   Attendees were shown that encrypted content is reaching around 50%
   according to recent statistics [STATE_BROWSER] and [STATE_SERVER].
   The IAB are encouraging all IETF groups to consider encryption by
   default on their new protocol work and the IETF are also working on
   encryption on lower layers, for example TCP encryption within the
   [TCPINC] Working Group.  The aims of these items of work are greater
   security and privacy for users and their data.

   Within telecommunications middleboxes exist on operator

   Telecommunications networks
   which often contain middleboxes that operators
   have previously considered themselves 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, malware
   detection, but these need to be balanced against their ability to
   open up cracks in the network for attacks such as pervasive
   monitoring.  Some needs
   to improve

   When operators increase the radio access network quality number of service could come
   from increasing radio access network cells
   ("Base Stations"), but this can improve the radio access network quality
   of service , but also adds to radio pollution; this shows pollution.  This is one example
   of the balancing act required when
   deivising devising radio access network

2.2.  Encryption Deployment Considerations

   Encryption across the internet Internet is on the rise.  However, some
   organisations and individuals come across a common set of operational
   issues when deploying encryption, mainly driven by commercial
   perspectives.  The [UBIQUITOUS] draft 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 Internet players,
   including system and network administrators across enterprise,
   governmental organisations and personal use.  The aim of the document
   is to gain an understanding of what is needed for technical solutions
   to these issues, 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 URL in today's inicident incident monitoring middleware.

   Some of these impacts to mobile networks can be resolved using
   difference methods and the [NETWORK_MANAGEMENT] draft details these
   methods.  The draft focuses heavily on methods to manage network
   traffic whithout without breaching user privacy and security.

   By reviewing encryption depoyment issues and the alternative methods
   of network management MaRNEW attendees were made aware of the issues
   which affect radio networks, the deployment issues which are solvable
   and require no further action, and those which aren't currently
   solveable and which should be addressed within the workshop.

2.3.  Trust Models and  Awareness of User Choice (Privacy)

   Solutions of how

   Some solutions intended to improve delivery of encrypted content
   could affect some of or all of the privacy benefits that encryption brings.
   provides.  Understanding user needs and desires for privacy is
   therefore important when designing these solutions.

   From a recent study [Pew2014] 64% of users said concerns over privacy
   have increased, 67% of mobile internet Internet users would like to do more to
   protect their privacy.  The 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 hold that
   users are the stakeholders with most priority, followed by
   implementors and other stakeholders, further inforcing enforcing 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 which can impact user privacy sometimes do this ignorant
   without being aware of the those privacy implications or incorrectly
   assume that the benefits users gain from the new technology outweigh
   the loss of private
   information.  Any new technology which introduces bad security
   vectors will be used by attackers. 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 have been absued by these parties,
   such as cookie use or JavaScript injection.  This has caused some
   developers to encrypt content to circumnavigate circumvent these technologies which
   they find intrusive or bad for their users privacy.

   Some suggested solutions for network management of encrypted traffic
   have suggested "trust models".

   If users and content providers are to opt-in to user network
   management services with negative privacy impacts they should see
   clear value from using these services, and understand the impacts on
   clear interfaces.  Users should also have easy abilities to opt-out.
   Some users will always automatically click through consent requests,
   so any trust model relying on explicit consent is flawed for these users.
   Understanding the extent of "auto click through" may help make better
   decisions for consent requests in the future.  One
   trust 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 on end. at endpoints.

3.  Network or Transport Solution Sessions

   Network or Transport Solution Sessions aimed to discuss suggested and
   new solutions for managing encrypted traffic on radio access
   networks.  Most solutions focus on the sharing of metadata; either
   from the enpoint endpoint to the network, from the network to the endpoint,
   or cooperative sharing between both.  Evolutions on the transport
   layer could be another approach to solve some of the issues radio
   access networks experience erience which cause them to require network
   management middleboxes.  By removing problems on at the transport layer the need to
   expesnive layer,
   reliance on expensive middleboxes could decrease.

3.1.  Sending Data Up / Down for Network Management Benefits

   Middleboxes in the network have a number of uses, some which are more
   beneficial than they are controversial.

   Collaboration between these network elements and the endpoints could bring
   about better content distribution.  A number of suggestions were
   given, these included:

   o  Mobile Throughput Guidance [MTG]: exchanges data between the
      network elements and the endpoints via TCP Options.  It also
      allows for gaining a better idea of how the transport protocol
      behaves and improving user experience further, although the work
      still needs to evolve.

   o  SPUD [SPUD]: a UDP-based encapsulation protocol to allow explicit
      cooperation with middleboxes while using new, encrypted transport

   o  Network Status API: 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 behaviour.

   o  Traffic classification: classfying classifying traffic and adding this as
      metadata for analysis throughout the network.  This idea has trust
      and privacy implications.

   o  ConEx [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 Bandwith: Bandwidth: allowing the content provider to
      indicate whether a better bandwidth or lower latency is of greater
      priority and allowing the network to react.  Where this bit
      resides and how to authenticate it would need to be decided.

   o  No network management tools: disabling all network management
      tools from the network and allow the protocols to manage
      congestion alone.

   o  FlowQueue Codel [FLOWQUEUE]: a hybrid packet scheduler/AQM
      algorithm, aiming to reduce bufferbloat and latency.  FQ-CoDel
      mixes packets from multiple flows and reduces the impact of head
      of line blocking from bursty traffic.


   Some of these suggestions could be labeled "Network-to-App", a better
   approach may be "Network-to-User", to achieve this these ideas would
   need rely on signaling from network elements to be expanded.

   Others aim to create "hop-to-hop" solutions, which could be more
   inline with how congestion is managed today, but with greater privacy

   "App-to-Network" style solutions have either existed for a long time

   Still others rely on signaling from endpoints to network elements.
   Some of these rely on implicit solutions, or explicitly defined but never implemented or
   properly deployed. signaling, and others on explicit
   signaling.  Some workshop attendees agreed that applications
   explicitly declaring was what quality of service they require was not a
   good route route, given the lack of success with this model in the past.

3.1.1.  Trust  Competition, Cooperation, and the Mobile Network Complexities

   One of the larger issues in the sharing of data is the matter of
   trust; networks
   competition; network operators find difficulties in relinquishing are reluctant to relinquish data for
   reasons such as revealing about
   their own networks because it can competitive information information, and applications
   application providers wish to protect their users and only reveal as
   little information as possible to the network.  Authentication in  Some people think
   that case could if middleboxes were authenticated and invoked explicitly, this
   would be a key design element
   of any new work, as well as explictness rather than the an improvement over current transparent middleboxes used more recently. that
   intercept traffic without endpoint consent.  Some workshop attendees
   suggested any exchange of information should be biodirectional, bidirectional, in an
   effort to improve trust cooperation between the elements.  A robust
   incentive framework could provide a solution to the trust issue, these issues, or at
   least help mitigate it. them.

   The radio access network is complex and manages because it must deal with a
   number of
   realities. conflicting demands.  Base stations understand many of these realities, reflect this
   environment, and information within these base stations can be of
   value to other entities on the path.  Solutions  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
   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 categorisation and
   providing this information to the protocols or endpoints.
   Categorising radio networks could be impossible due to their
   complexity, but categorising essential network properties could be
   possible and valuable.

4.  Transport Layer: Issues, Optimisation and Solutions

   TCP has been the dominant transport protocol since TCP/IP replaced
   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
   SCTP and 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 "Stack
   Evolution" programme, and the first step in this programme 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.  Network operators do not tend
   to reveal network information mostly for competition reasons and so
   is unlikely to donate this information freely to IETF.  The GSMA is
   in the a position to try to collect this data and anonymise it before
   bringing it to IETF which should alleviate the network operator
   worries but still provide IETF with some usable data.

   A considerable amount of work has already been done on TCP,
   especially innovation in bandwidth management and congestion control;
   although congestion is usually detected by detecting loss, and better
   methods based on detecting congestion would be beneficial.


   Furthermore, although the deficiencies of TCP are often considered as
   key issues in the evolution of the stack, the main route to resolve
   these issues may not be a new TCP, but an evolved stack.  Some
   workshop participants thought SPUD [SPUD] and ICN [RFC7476] are two
   suggestions which may help here.  QUIC [QUIC] engineers stated that
   the problems solves 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 here.

5.  Application Layer Optimisation, 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 including their experiences running over mobile networks,
   the experience their users expect, and what they 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 standard compliant.  When the
   network is not standards compliant (e.g. using non standards non-standards-
   compliant intermediaries) content providers can experience real costs
   as users contact their support centres to report issues which are
   difficult to test for and build upon.

   Content providers cited other common issues concerning data traffic
   over mobile networks.  Data 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.  DNS and DNS caching cause
   unpredictable results.  Developers build products on
   networks not indicative of the networks their customers are using and
   not every organisation has the finances to build a caching

   Strongly related to content providers, Content owners consider CDNs are understood
   to be a trusted deliver deliverers of content and CDNs have shown great success
   in fixed networks.  Now traffic is moving more to mobile networks
   there is a need to place caches at the edge of the network (e.g. in the Gi LAN
   or the radio network) within the mobile network.  Places network,
   near the users.  Placing caches at the edge of the mobile network is
   a solution, but requires standards developed by content providers and
   mobile network operators.  The CNDi Working Group [CDNI] at IETF aims
   to allow global CDNs to interoperate with mobile CDNs; but this
   causes huge trust 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 the panelists were asked to identify one
   key collaborative work item, these were: evolving caching to cache
   encrypted content, uing using one-bit for latency / bandwidth trade-off
   (explained below), better collaboration between the network and
   application, better metrics to aid bug solving 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 Chatham House Rule.  The session
   aimed to discuss regulatory and politcal political issues; but not their worth
   or need, rather to understand the laws that exist and how
   technologists can properly respond to these.

   Mobile networks are regulated, compliance is mandatory (and non-
   compliance can result in service license revocation in some nations
   round the world) and can incur costs on the mobile network operator.
   Regulation does vary geographically.  Some regulations are court
   orders, others are self-imposed regulations, for example, "block
   lists" of websites such as the Internet Watch Foundation list [IWF].
   Operators are not expected to decrypt sites, so those identified
   sites which are encrypted will not be blocked.

   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 restirctions restrictions
   themselves.  Other regulations are also hard to meet - such as user
   data patterns, or will become harder to collect - such as IoT cases.
   Most attendees agreed that if the governments a government cannot get the information it
   needs and is legally entitled to have from network operators they
   will approach the content providers.  Some governments are aware of the
   impact of encryption and are working with or trying to work with
   content providers.  The IAB have concluded blocking and filtering can
   be done at the endpoint of the communication.


   Not all of these regulations do not always apply to the internet, Internet, and the
   internet Internet
   community is not always aware of their existance. existence.  Collectively the internet
   Internet community can work with GSMA and 3GPP and act collectively
   to alleviate the risk imposed by encrypted traffic.  Some
   participants expressed the concern that governments might require
   operators to provide information that they no longer have the ability
   to provide, because traffic
   for lawful intercept.  The has been 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 built are necessary, they should have the
   ability to be easily 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.  Requirements  Suggested Principles and Suggestions for Future Solutions

   Based on the talks and discussions throughout the workshop a set of
   requirements and
   suggested principles and solutions has been collected.  This is not
   an exhaustve list. exhaustive list, and no attempt was made to come to consensus
   during the workshop, so there are likely participants who would not
   agree with any particular principle listed below.

   o  Encrypted Traffic: any solution should encourage and support
      encrypted traffic.

   o  Flexibility: radio access network qualities vary vastly and
      different network needs in content can be identified, so any new
      solution should be flexible to either the network type or content
      type or both.

   o  Privacy: new solutions should not introduce ways where information
      can be discovered flows and attribute them to users.

   o  Minimum data only for collaborative work: user data, app data and
      network data all needs protecting, so new solutions should use the
      minimum information to make a working solution.

   A collection of solutions suggested throughout by various participants during
   the workshop is given below.  These solutions haven't been matched to the requirements
   above, so  Inclusion in this step will need to come later. list does not imply
   that other workshop participants agreed.

   o  Evolving TCP or evolution on the transport layer: this could take
      a number of forms and some of this work is already existing within
      IETF.  Other suggestions include:

   o  Congestion Control: many attendees cited congestion control as a
      key issue, further analysis, investigation and work could be done

   o  SPROUT: research at MIT which is a transport protocol for
      interactive applications that desire high throughput and low
      delay.  [SPROUT]

   o  PCC: Performance-oriented Congestion Control: is a new
      architecture that aims for consistent high performance even in
      challenging scenarios.  PCC enpoints endpoints observe the connection
      between their actions and their known performance, which allows
      them to adapt their actions.  [PCC]

   o  CDNs and Caches: placing caches closer to the mobile user or
      making more intelligent CDNs would result in faster content
      delivery and less train on the network.  Related work includes:

   o  Blind Caching: a proposal for caching of encrypted content

   o  CDN improvements: including keyless SSL and better CDN placement.

   o  Mobile Throughput Guidance: a mechanism and protocol elements that
      allow the cellular network to provide near real-time information
      on capacity available to the TCP server.  [MTG]

   o  One bit for latency / bandwidth tradeoff: trade-off: determining whether
      using one a single bit to
      identify whether a stream prefers low latency at the expense of
      throughput.  This rids solutions of distinguish between traffic that the trust issue as
      applications will need sender
      prefers to select the best scenario for their be queued and traffic type. 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 either
      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 which network
      management could then be applied.

   o  Heuristics: Networks can sometimes identify traffic types through
      specifics such as data flow rate and then apply network management
      to these identified flows.  This is not recommended as
      categorisations 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 behaviour.  Alternatively an API
      could provide the network with some information on the data type
      to provide network management to, although this method exposes
      privacy issues.

   o  Standard approach for 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 [AQM] [RFC7567] and ECN [RFC3168] deployments: queueing queuing and
      congestion management methods have existed for sometime in the
      form of AQM, ECN and others which can help the transport and internet
      Internet layer 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: SSL [KeylessSSL]: 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 standardised in
      IETF.  [LURK]

   o  Meaningful capacity sharing: including the ConEx [CONEX] work
      which exposes information about congestion to the network nodes.

   o  Hop-by-hop: some suggestions offer hop-by-hop methods allowing
      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 networks, data is needed on from the
      current network situations, conditions, protocol deployments, packet traces
      and middlebox behaviour.  Futher than this  Beyond this, proper testing and
      debugging on networks could provide great insight for stack

   o  5G: Mobile operator standards bodies are in the process of setting
      the requirements for 5G, requirements 5G.  Requirements for network management
      could be added.

   In the workshop attendees identified other areas where greater
   understandinf could help the standards process.  These were
   identified as:

   o  Greater understanding of the RAN at IETF

   o  Reviews and comments on 3GPP perspective

   o  How to do congestion controlling in RAN.

7.1.  Better Collaboration

   Throughout the workshop attendees placed emphasis on the need for
   better collaboration between the IETF and telecommunications bodies
   and organisations.  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 which are better for
   both technologies and users.

8.  Next Steps

   The next steps for  Since MaRNEW

   Since MaRNEW attendees are to begin work on a select
   list number of the above recommended solutions and other suggestions within
   the IETF and within other organisations.  At IETF95 the activities have taken place in various
   seperate working groups or groups external to IETF.  The ACCORD BoF
   will be
   was held at IETF95 which will bring brough the workshop discussion to the wider
   IETF attendance audiences by providing an account of the discussions within the
   workshop and select highlighting key areas to progress on; these are likely on.  Key areas to be definitions
   progress and an update on their current status follows:

   o  The collection of the useable metrics to be collected, more information on
   the stack evolution ideas and their impact data were requested by a
      number of MaRNEW attendees; this has been difficult to collect due
      to the closed nature of mobile network management,
   Mobile Throughput Guidance evolution, evolution operations.

   o  The IAB's Stack Evolution programme has continued discussion and
      development of guidance on the Blind Caching
   work evolvability of protocols.

   o  The Measurement and draft definitions Analysis of the "1 bit Protocols (MAP) Research Group was
      chartered before IETF 96, and provides a venue for latency / bandwidth
   tradeoff" idea.  As identified in the "Better Collaboration" section
   together we need to ensure that both groups continue discussion
      of data and research on many of the positive
   relationship topics addressed at MaRNEW,
      including the deployment of encryption and the prevalence of in-
      network inpairments to move these ideas forward protocol evolution.

   o  The Mobile Throughput Guidance draft has entered into being real and workable
   solutions a testing
      and both groups need data collection phase; although further advancements in
      transport technologies (noteably QUIC) may have stalled efforts in
      TCP-related proposals.

   o  Attempts on proposals for caching of encrypted content continue
      albeit with some security flaws which proponents are working on
      further proposals to understand that even though
   collaboration between fix.  Most often these are discussed within
      the operator network and HTTP WG.

   o  The PLUS BOF did not result in the internet is formation of
   great importance a working group,
      with attendees expressing concern on the privacy issues associated
      with the data sharing possibilities of the shim layer proposed.

   o  The LURK BOF did not result in the item formation of a working group,
      because the BOF identified more problems than anticipated with
      this approach.

   The most importance rewarding output of MaRNEW is perhaps the experience and
   security for most intangible.
   MaRNEW gave two rather divergent industry groups the opportunity to
   connect and discuss common technologies and issues affecting users using these services.

9.  Informative References

   [RFC7567]  Baker, F., Ed.
   and G. Fairhurst, Ed., "IETF
              Recommendations Regarding Active Queue Management",
              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., operations.  Mobile Network providers and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,

   [RFC3168]  Ramakrishnan, K., Floyd, S., key Internet engineers
   and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) experts have developed a greater collaborative relationship to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,

              "IETF Note Well", n.d., <

   [MARNEW]   "MaRNEW Workshop IAB Homepage",
   aid development of further standards which work across networks in a
   secure manner.

9.  Acknowledgements

   Stephen Farrell reviewed this report in draft form and provided
   copious comments and suggestions.

   Barry Leiba provided corrections.

10.  References

10.1.  Informative References

              Holmberg, M., "Caching Secure HTTP Content using Blind
              Caches", October 2016, <

   [CDNI]     "Content Delivery Networks Interconnection Working Group",
              <>. <>.

              "Chatham House Rule", n.d.,

   [CONEX]    "Congestion Exposure Working Group", n.d.,

              Patel, C., "The effect of encrypted traffic on the QoS
              mechanisms in cellular networks", August 2015,

              Dumazet, P., "FlowQueue-Codel", March 2014,

   [GSMA]     "GSMA Homepage", n.d., <>.


   [IWF]      "Internet Watch Foundation", n.d.,

              Sullivan, N., "Keyless SSL: The Nitty Gritty Technical
              Details", September 2014, <

   [LURK]     Ma, D., "TLS/DTLS Content Provider Edge Server Split Use
              Case", January 2016, <

   [MARNEW]   "MaRNEW Workshop IAB Homepage", n.d., <>.

   [MTG]      Smith, A., "Mobile Throughput Guidance Inband Signaling
              Protocol", September 2015,

              Smith, K., "Network management of encrypted traffic", May
              2015, <

              "IETF Note Well", n.d.,

   [PCC]      Schapira, M., "PCC, Re-architecting Congestion Control for
              Consistent High Performance", May 2015,

   [PCC-QOS]  "Policy and charging control signalling flows and Quality
              of Service (QoS) parameter mapping", March 2016,

              Barnes, R., "Some observations of TLS in the web", July
              2015, <

              Salz, R., "Some observations of TLS in the web", July
              2015, <

   [TCPINC]   "TCP Increased Security Working Group", n.d.,

              Morton, K., "Effect of Ubiquitous Encryption", March 2015,

              Smith, K., "Network management of encrypted traffic", May
              2015, <

   [Pew2014]  "Public Perceptions of Privacy and Security in the Post-
              Snowden Era", November 2014,

   [MTG]      Smith, A., "Mobile Throughput Guidance Inband Signaling
              Protocol", September 2015,

   [SPUD]     "Session Protocol for User Datagrams", n.d.,

   [CONEX]    "Congestion Exposure Working Group",

   [PLUS]     "Proceedings of the PLUS BoF at IETF 96, Berlin, July
              2016", n.d.,

              Dumazet, P., "FlowQueue-Codel", March 2014,

   [QUIC]     Swett, J., "QUIC, A UDP-Based Secure and Reliable
              Transport for HTTP/2", June 2015,

   [CDNI]     "Content Delivery Networks Interconnection Working Group",
              n.d., <>.

   [IWF]      "Internet Watch Foundation",

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              DOI 10.17487/RFC2804, May 2000,

   [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,

   [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,

   [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
              Recommendations Regarding Active Queue Management",
              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,

              "3GPP Homepage", n.d.,
              <>. <>.

   [SPROUT]   Balakrishnan, K., "Stochastic Forecasts Achieve High
              Throughput and Low Delay over Cellular Networks", April

   [PCC]      Schapira, M., "PCC, Re-architecting Congestion Control

   [SPUD]     Kuehlewind, B., "Requirements for
              Consistent High Performance", May 2015,

              Holmberg, M., "An Architecture the design of a Session
              Protocol for Secure Content
              Delegation using HTTP", User Datagrams (SPUD)", n.d.,

   [LURK]     Ma, D., "TLS/DTLS Content Provider Edge Server Split Use
              Case", January 2016, <

Author's Address

              Barnes, R., "Some observations of TLS in the web", July
              2015, <

              Salz, R., "Some observations of TLS in the web", July
              2015, <

   [TCPINC]   "TCP Increased Security Working Group", n.d.,

              Morton, K., "Effect of Ubiquitous Encryption", March 2015,

10.2.  URIs

























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
   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

Appendix B.  Workshop Position Papers

   o  Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu,
      "Cooperation Framework between Application layer and Lower Layers"
      MaRNEW_1_paper_33.pdf [1]

   o  Julien Maisonneuve, Thomas Fossati and Vijay Gurbani, "The
      security pendulum and the network" at
      content/IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf [2]

   o  Martin Peylo, "Enabling Secure QoE Measures for Internet
      Applications over Radio Networks is a MUST" at
      MaRNEW_1_paper_32.pdf [3]

   o  Vijay Devarapalli, "The bandwidth balancing act: Managing QoE as
      encrypted services change the traffic optimization game" at
      MaRNEW_1_paper_10.pdf [4]

   o  Humberto La Roche, "Use Cases for Communicating End-Points in
      Mobile Network Middle-Boxes" at
      IAB-uploads/2015/08/MaRNEW_1_paper_12.pdf [5]

   o  Richard Barnes and Patrick McManus, "User Consent and Security as
      a Public Good" at
      uploads/2015/08/MaRNEW_1_paper_13.pdf [6]

   o  Iuniana Oprescu, Jon Peterson and Natasha Rooney, "A Framework for
      Consent and Permissions in Mediating TLS" at
      wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_31.pdf [7]

   o  Jari Arkko and Goeran Eriksson, "Characteristics of Traffic Type
      Changes and Their Architectural Implications" at
      MaRNEW_1_paper_15.pdf [8]

   o  Szilveszter Nadas and Attila Mihaly, "Traffic Management for
      Encrypted Traffic focusing on Cellular Networks" at
      MaRNEW_1_paper_16.pdf [9]

   o  Gianpaolo Scassellati, "Vimpelcom Position Paper for MaRNEW
      Meeting" at
      MaRNEW_1_paper_17.pdf [10]

   o  Mirja Kuehlewind, Dirk Kutscher and Brian Trammell, "Enabling
      Traffic Management without DPI" at
      IAB-uploads/2015/08/MaRNEW_1_paper_18.pdf [11]

   o  Andreas Terzis and Chris Bentzel, "Sharing network state with
      application endpoints" at
      uploads/2015/08/MaRNEW_1_paper_19.pdf [12]

   o  Marcus Ihlar, Robert Skog and Salvatore Loreto, "The needed
      existence of Performance Enhancing Proxies in an Encrypted World"
      MaRNEW_1_paper_20.pdf [13]

   o  John Mattsson, "Network Operation in an All-Encrypted World" at
      MaRNEW_1_paper_21.pdf [14]

   o  Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello and Paul
      Polakos, "Maintaining Efficiency and Privacy in Mobile Networks
      through Information-Centric Networking" at
      content/IAB-uploads/2015/08/MaRNEW_1_paper_23.pdf [15]

   o  Chunshan Xiong and Milan Patel, "The effect of encrypted traffic
      on the QoS mechanisms in cellular networks" at
      MaRNEW_1_paper_25.pdf [16]

   o  Thomas Anderson, Peter Bosch and Alessandro Duminuco, "Bandwidth
      Control and Regulation in Mobile Networks via SDN/NFV-Based
      Platforms" at
      MaRNEW_1_paper_26.pdf [17]

   o  Karen O'Donoghue and Phil Roberts, Barriers to Deployment:
      "Probing the Potential Differences in Developed and Developing
      Infrastructure" at
      uploads/2015/08/MaRNEW_1_paper_27.pdf [18]

   o  Wendy Seltzer, "Performance, Security, and Privacy Considerations
      for the Mobile Web" at
      uploads/2015/08/MaRNEW_1_paper_28.pdf [19]

   o  Jianjie You, Hanyu Wei and Huaru Yang, "Use Case Analysis and
      Potential Bandwidth Optimization Methods for Encrypted Traffic" at
      MaRNEW_1_paper_29.pdf [20]

   o  Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and
      Encrypted Traffic" at
      uploads/2015/08/MaRNEW_1_paper_30.pdf [21]

   o  Claude Rocray, Mark Santelli and Yves Hupe, "Providing
      Optimization of Encrypted HTTP Traffic" at
      content/IAB-uploads/2015/08/MaRNEW_1_paper_341.pdf [22]

   o  Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted
      Internet" at
      MaRNEW_1_paper_35.pdf [23]

   o  Kevin Smith, "Encryption and government regulation: what happens
      now?" at
      MaRNEW_1_paper_1.pdf [24]

Authors' Addresses

   Natasha Rooney


   Spencer Dawkins (editor)
   Wonder Hamster