draft-smith-encrypted-traffic-management.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.25 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-smith-encrypted-traffic-management-04" category="info">

  <front>
    <title abbrev="encrypted-traffic-management">Network management of encrypted traffic</title>

    <author initials="K." surname="Smith" fullname="Kevin Smith">
      <organization>Vodafone Group</organization>
      <address>
        <email>kevin.smith@vodafone.com</email>
      </address>
    </author>

    <date year="2015" month="November" day="13"/>

    <area>Security</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Encrypted Internet traffic may pose traffic management challenges to network operators. This document recommends approaches to help manage encrypted traffic, without breaching user privacy or security.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">
<t>Networks utilise various management techniques to ensure efficient throughput, congestion management, anti-SPAM and security measures. Historically these functions have utilised visibility of the Internet application layer.</t>

<t>This visibility is rapidly diminishing - encrypted Internet traffic is expected to continue its upward trend, driven by increased privacy
awareness, uptake by popular services, and advocacy from the <xref target="IAB"/>,  <xref target="RFC7258"/> and W3C <xref target="TAG"/> .</t>

<t><xref target="IAB"/>, <xref target="RFC7258"/> and <xref target="mm-effect-encrypt"/> recognise that network management functions may be impacted by encryption, and that solutions to persist these management functions must not threaten user security or privacy. Such solutions can ensure the benefits of encryption do not degrade network efficiency.</t>

<t>This document lists such solutions, and points to evolving IETF work addressing the problem.</t>

<section anchor="struc" title="Document structure">
<t>This document refers to network management functions that may be hindered by traffic encryption, as described in <xref target="mm-effect-encrypt"/></t>

<t>It then describes the technical details of existing options to fully or partially persist these functions
under encryption. The guidance includes existing techniques as well as ongoing IETF work in this area.‘Encryption’ in this document typically refers to HTTP over TLS <xref target="RFC2818"/>; other forms of encryption are noted where applicable.</t>

<t>Finally, a summary is provided of ongoing IETF work which is investigating how network operators, origin servers and clients may co-operate in efficient traffic delivery without the need for pervasive network monitoring.</t>

<t>The legal, political and commercial aspects of network management are recgnised but not covered in this technical document.</t>

</section>
</section>
<section anchor="netman" title="Network management functions">
<t>Please refer to 'Network Service Provider Monitoring' in <xref target="mm-effect-encrypt"/></t>
</section>
<section anchor="flow" title="Persisting traffic management without breaching encryption">
<t>This section involves utilisation of 'Application-based Flow Information Visible to a Network', <xref target="mm-effect-encrypt"/>.</t>

<section anchor="hint" title="Providing hints to and from the network">
<t>The following protocols aim to support a secure and privacy-aware dialogue between client, server and the network elements. These hints can allow information item exchange between the endpoints and the network, to assist queuing mechanisms and traffic pacing that accounts for network congestion and variable connection strength. These relate to the cooperative path to endpoint signalling as discussed at the IAB SEMI <xref target="SEMI"/> and MaRNEW <xref target="MaRNEW"/> workshops, with the network following a more clearly-defined role in encrypted traffic delivery. </t>

<section anchor="dscp" title="DiffServ Code Points (DSCP)">

<t>Data packets may be flagged with a traffic class (class of service). Network
operators may honour a DiffServ classification <xref target="RFC2474"/> entering their network, or may choose to
override it (since it is potentially open to abuse by a service provider that classifies all its
content as high priority). The purpose is to help manage traffic and congestion in the
network.</t>

<t>This requires the content provider to flag data packets. This is extra work for
the provider, and it has potential for abuse if a content provider simply flags all packets with
high priorities. The network would need to know which flags to trust and which to override.
The use of DiffServ within the operator network is beneficial where the operator determines
the class of service itself; but where content is encrypted then heuristics would be needed to
predict the traffic type entering the network.
HTTP/2 allows several streams to be multiplexed over a single TCP connection. This means
that if a provider decides to send Web pages, videos, chat etc. as individual streams over
the same connection, then DiffServ would be useless as it would apply to the TCP/IP
connection as a whole. However it may be more efficient for such Web providers to serve
each content type from separate, dedicated servers – this will become clearer as HTTP/2
deployments are tuned for optimal delivery.</t>

</section>
<section anchor="ecs" title="Explicit Congestion Notification (ECN)">
<t>Explicit Congestion Notification <xref target="RFC6138"/> routers can exchange congestion
notification headers to ECN compliant endpoints. This is in preference to inferring congestion
from dropped packets (e.g. in TCP). The purpose is to help manage traffic and congestion in
the network.</t>

<t>This solution is required to be implemented at network and service provider. The
service provider will utilise the ECN to reduce throughput until it is notified that congestion
has eased.</t>

<t>As with DiffServ, operators may not trust an external entity to mark packets in a
fair/consistent manner.</t>

</section>
<section anchor="mpls" title="Multiprotocol Label Switching (MPLS)">

<t>On entering an MPLS-compliant network <xref target="RFC3031"/>, IP packets are flagged with a
’Forward Equivalence Class’ (FEC). This allows the network to make packet-forwarding
decisions according to their latency requirements. MPLS routers within the network parse
and act upon the FEC value. The FEC is set according to the source IP address and port.
The purpose is to help managing traffic and congestion in the network. This requires deployment of an MPLS ‘backbone’ with label-aware switches/ routers.</t>

<t>An up-to-date correspondence table between Websites (or service sites in general) and server IP address must be created. Then, the category(s) of traffic have to be consistently mapped to a set of 
MPLS labels ,which entails a significant effort to setup and maintain.</t>

<t>Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be routed over Layer 2 (Data Link);
DiffServ only operates over Layer 3. DiffServ is potentially a less complex integration as it is
applied at the network edge servers only.</t>

</section>


<section anchor="spud" title="Substrate Protocol for User Datagrams (SPUD)">

<t>SPUD <xref target="SPUD"/> is a prototype to research how network devices on the path between endpoints can share information to improve a flow. The network involvement is outside of the end-to-end context, to minimise any privacy or security breach. The initial prototype involves grouping UDP packets into an explicit 'tube', however support of additional transport layers (such as TCP) will also be investigated.</t>

</section>
<section anchor="mtg" title="Mobile throughput Guidance">

<t>Mobile Throughput Guidance In-band Signalling <xref target="MTG"/> is a draft proposal to allows
 the network to inform the server endpoint as to what bandwidth the TCP connection can reasonably expect. This allows the server to adapt their throughput pacing based on dynamic network conditions, which can assist mechanisms such as Adaptive Bitrate Streaming and TCP congestion control.</t>

</section>

<section anchor="pcp" title="Port Control Protocol Flowdata options">

<t>PCP Flowdata options <xref target="PCPFD"/> defines a mechanism for a host to signal flow
   characteristics to the network, and the network to signal its ability
   to accommodate that flow back to the host. This allows certain network flows to receive service that is differentiated from other network flows, and may be used to establish flow priority before connection establishment. PCP Flowdata operates at IPv4/IPv6 level.</t>

</section>

<section anchor="ip6" title="IPv6 Flow label">

<t>IPv6 includes a flow label header field. <xref target="RFC6438"/> details how this may be used to identify flows for load balancing and multipath routing, which may be of particular use for application-layer encrypted traffic. The flow label field is part of  the main header, which means it is not subject to the disadvantages of extension headers (namely their risk of being dropped by intermediary routers). The flow label may also be exposed as part of the outer IP packet in an IP tunnel, thus providing network flow information without compromising the payload.</t>
</section>

<section anchor="discuss" title="DISCUSS">
<t>Differentiated prIorities and Status Code-points Using Stun Signalling <xref target="DISCUSS"/> describes a mechanism for information exchange between an application and the network, viable only for UDP. As such it can be considered in the same bracket as SPUD</t>
</section>

</section><!-- end of Hints-->

<section anchor="inflow" title="Inferred flow information">

<section anchor="heur" title="Heuristics">

<t>Heuristics can be used to map given input data to particular conclusions via some heuristic
reasoning. Examples of input data to this reasoning include IP destination address, TCP destination port, 
server name from SNI, and typical traffic patterns (e.g. occurrence of IP packets and TCP segments over time).
The accuracy of heuristics depends on whether the observed traffic originates from a source 
delivering a single service, or a blend of services. In
many scenarios, this makes it possible to directly classify the traffic related to a specific
server/service even when the traffic is fully encrypted.</t>

<t>If the server/service is co-located on an infrastructure with other services that shares the
same IP-address, the encrypted traffic cannot be directly classified. However, commercial
traffic classifiers today typically apply heuristic methods, using traffic pattern matching 
algorithms to be able to identify the traffic. As an example, classifier products are able to 
identify popular VoIP services using heuristic methods although the traffic is encrypted and
mostly peer-to-peer.</t>

</section>
</section><!-- end of Inferred -->

<section anchor="coop" title="Co-operation on congestion control">
<t>One idea from the IAB 'Managing Radio Networks in an Encrypted World' workshop <xref target="MaRNEW"/> was that  of better co-operation between 3GPP mobile networks and Internet services on congestion management. . 3GPP networks are concerned with ensuring that all devices attached to a particular cell receive a fair share of radio resources. This is critical, since these resources are constrained to various licenced spectrum bands, and volatile due to signal strength variation/cell handover/interference etc. The resource sharing process occurs independently to TCP congestion management performed between the client and server connected via the mobile network: the result is that TCP may wrongly infer congestion and react accordingly, or attempt to accelerate throughput without consideration of the available radio resources.  Therefore the notion is to investigate co-operation between radio and TCP congestion controls to better manage connection throughput. </t>
</section><!-- end of Co-op-->

</section><!-- end of Persisting -->


<section anchor="ack" title="Acknowledgements">
<t>The editor would like to thank the GSMA Web Working Group for their contributions, in particular to the technical solutions and network management functions; the contributions via the SAAG mailing list (Panos Kampanakis, Brian Carpenter); and Kathleen Moriarty and Al Morton for their guidance in aligning this draft with <xref target="mm-effect-encrypt"/> </t>

</section>
<section anchor="iana" title="IANA Considerations">

<t>There are no IANA considerations.</t>

</section>
<section anchor="sec" title="Security Considerations">

<t>The intention of this document is to consider how to persist network management of encrypted traffic, without breaching user privacy or end-to-end security. In particular this document does not recommend any approach that intercepts or modifies client-server Transport Layer Security.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC7258'>

<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract></front>

<seriesInfo name='BCP' value='188' />
<seriesInfo name='RFC' value='7258' />
<format type='TXT' octets='13396' target='http://www.rfc-editor.org/rfc/rfc7258.txt' />
</reference>

<reference anchor='RFC2474'>

<front>
<title>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title>
<author initials='K' surname='Nichols' fullname='K. Nichols'>
<organization /></author>
<date year='1998' month='Dec' />
<abstract>
<t>Differentiated services enhancements to the Internet protocol are
   intended to enable scalable service discrimination in the Internet
   without the need for per-flow state and signaling at every hop.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='2474' />
<format type='TXT' target='https://tools.ietf.org/html/rfc2474' />
</reference>

<reference anchor='RFC6138'>
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author initials='K' surname='Ramakrishnan' fullname='K. Ramakrishnan'>
<organization /></author>
<date year='2001' month='Sep' />
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion
   Notification) to TCP and IP, including ECN's use of two bits in the
   IP header.</t></abstract></front>
<seriesInfo name='RFC' value='6138' />
<format type='TXT' target='https://tools.ietf.org/html/rfc2474' />
</reference>


<reference anchor='RFC3031'>
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials='E' surname='Rosen' fullname='E. Rosen'>
<organization /></author>
<date year='2001' month='Jan' />
<abstract>
<t>This document specifies the architecture for Multiprotocol Label
   Switching (MPLS).</t></abstract></front>
<seriesInfo name='RFC' value='3031' />
<format type='TXT' target='https://tools.ietf.org/html/rfc3031' />
</reference>




<reference anchor='RFC2818'>

<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2000' month='May' />
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='2818' />
<format type='TXT' octets='15170' target='http://www.rfc-editor.org/rfc/rfc2818.txt' />
</reference>

<reference anchor='RFC6438'>
<front>
<title>Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels</title>
<author initials='B.' surname='Carpenter' fullname='B. Carpenter'>
<organization/></author>
<author initials='S.' surname='Amante' fullname='S. Amante'>
<organization /></author>
<date year='2011' />
<abstract>
<t>The IPv6 flow label has certain restrictions on its use.  This
   document describes how those restrictions apply when using the flow
   label for load balancing by equal cost multipath routing and for link
   aggregation, particularly for IP-in-IPv6 tunneled traffic.</t></abstract></front>

<seriesInfo name='RFC' value='6438' />
<format type='HTML' target='https://tools.ietf.org/html/rfc6438' />
</reference>

</references>

<references title='Informative References'>

<reference anchor="IAB" target="https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/">
  <front>
    <title>IAB statement on Internet confidentiality</title>
    <author fullname="Internet Architecture Board">
      <organization>IAB</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="mm-effect-encrypt" target="https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/">
  <front>
    <title>Effect of Ubiquitous Encryption</title>
    <author fullname="K. Moriarty, A. Morton">
      <organization>IETF</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="MTG" target="https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/">
  <front>
    <title>Mobile Throughput Guidance Inband Signaling Protocol</title>
    <author fullname="H. Flinck et al.">
      <organization>IETF</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="SEMI" target="https://www.iab.org/activities/workshops/semi/">
  <front>
    <title>IAB workshop, 'Stack Evolution in a Middlebox Internet'</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="SPUD" target="https://tools.ietf.org/html/draft-hildebrand-spud-prototype-03">
  <front>
    <title>Substrate Protocol for User Datagrams</title>
    <author fullname="J. Hildebrand, B. Trammell">
      <organization>IETF</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="TAG" target="https://w3ctag.github.io/web-https/">
  <front>
    <title>Securing the Web</title>
    <author fullname="W3C TAG">
      <organization>W3C</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="PCPFD" target="https://tools.ietf.org/html/draft-wing-pcp-flowdata-00">
  <front>
    <title>PCP Flowdata option</title>
    <author fullname="D. Wing">
      <organization>Cisco</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="DISCUSS" target="https://tools.ietf.org/html/draft-martinsen-tram-discuss-02">
  <front>
    <title>Differentiated prIorities and Status Code-points Using Stun Signalling</title>
    <author fullname="P. Martinsen">
      <organization>Cisco</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="MaRNEW" target="https://www.iab.org/activities/workshops/marnew/">
  <front>
    <title>Managing Radio Networks in an Encrypted World (MaRNEW)</title>
    <author fullname="J. Hildebrand">
      <organization>IAB</organization>
    </author>
    <author fullname="N. Rooney">
      <organization>GSMA</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>


    </references>



  </back>
</rfc>