<?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.22 -->

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

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-transport-metadata-impact-00" category="info">

  <front>
    <title abbrev="Transport Metadata Impact">User Impact of Transport Metadata</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <author initials="J." surname="Hall" fullname="Joseph Lorenzo Hall">
      <organization>CDT</organization>
      <address>
        <email>joe@cdt.org</email>
        <uri>https://cdt.org/</uri>
      </address>
    </author>
    <author initials="N." surname="ten Oever" fullname="Niels ten Oever">
      <organization>Article19</organization>
      <address>
        <email>niels@article19.org</email>
        <uri>https://www.article19.org/</uri>
      </address>
    </author>
    <author initials="W." surname="Seltzer" fullname="Wendy Seltzer">
      <organization>W3C</organization>
      <address>
        <email>wseltzer@w3.org</email>
        <uri>http://wendy.seltzer.org/</uri>
      </address>
    </author>

    <date year="2015"/>

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

    <abstract>


<t>This draft attempts to identify potential impacts associated with new, extensible metadata facilities in Internet protocols, and suggests possible mitigations. Its goal is to have the discussion of these tradeoffs up-front, rather than after the development of such mechanisms.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Recently, there has been an increasing amount of discussion in the IETF about adorning protocol flows with metadata about the network’s state for consumption by applications, as well as that of the application in order to inform decisions in the network. For examples, see <xref target="I-D.nottingham-gin"/>, <xref target="I-D.sprecher-mobile-tg-exposure-req-arch"/> and <xref target="I-D.hildebrand-spud-prototype"/>.</t>

<t>These discussions are being at least partially motivated by the increasing use of encryption, both in deployment (thanks to the Snowden revelations) and standards (thanks in some part to <xref target="RFC7258"/>, <xref target="IAB-confidentiality"/>, and <xref target="TAG-securing-web"/>); while it’s becoming widely accepted that networks don’t have legitimate need to access the content of flows in most cases, they still wish to meet certain use cases that require more information.</t>

<t>For example, networks may wish to communicate their state to applications, so that link limitations and transient problems can be accounted for in applications, by doing things like degrading (or improving) video streaming quality. </t>

<t>Applications also need to give enough information to networks to enable proper function; e.g., packets in UDP flows need to be associated to be able to cleanly transit NAT and firewalls. See <xref target="I-D.trammell-stackevo-newtea"/> and <xref target="I-D.hardie-spud-use-cases"/> for more discussion.</t>

<t>At the same time, it has been widely noted that “metadata” in various forms can be profoundly sensitive information, particularly when aggregated into large sets over extensive periods of time.</t>

<t>Indeed, much of the effort in combatting pervasive monitoring (as per <xref target="RFC7258"/>) has focused on minimizing metadata in existing, known protocols (such as TLS and HTTP).</t>

<t>Any new metadata facility, then – whether it be introduced to an existing protocol, or as part of a new one – needs to be carefully scrutinized and narrowly tailored to conservatively emit metadata. Of particular concern is an observed trend towards arbitrarily extensible metadata.</t>

<t>This draft attempts to identify potential impacts associated with new metadata facilities in Internet protocols, and suggest possible mitigations. Its goal is to initiate a discussion of these tradeoffs up-front, rather than waiting until after the development of such mechanisms.</t>

<t>Adding metadata to protocols is not an inherent harm – i.e., there are some legitimate uses of metadata, particularly if it eases the adoption of encrypted protocols or aligns well with both the interests of users and service or network operations, e.g., traffic management on mobile networks. However, the balance between the interests of constituents like end users, content providers and network operators needs to be carefully considered.</t>

</section>
<section anchor="potential-impact" title="Potential Impact">

<section anchor="security-and-privacy" title="Security and Privacy">

<t>It’s been established <xref target="Injection"/> that many network operators inject HTTP headers into requests, in order to identify their customers using a unique identifier, thereby allowing “third-party advertisers and websites to assemble a deep, permanent profile of visitors’ web browsing habits without their consent.” <xref target="X-UIDH"/></t>

<t>In doing so, these networks are taking advantage of a relatively unconstrained extension point in the HTTP protocol – header fields. While HTTP header fields do require registration <xref target="RFC3864"/>, the requirements are lax, and fields are often used without registration, because there is no technical enforcement of the requirements, due to HTTP’s policy of ignoring unrecognized header fields <xref target="RFC7230"/>.</t>

<t>HTTP header fields can be made a protected end-to-end facility by using HTTPS, avoiding the risk of such injection. A new transport metadata facility that explicitly allows any node on the path to add arbitrary metadata cannot.</t>

<t>Well-intentioned metadata can also put the user at substantial risk without careful consideration. For example, if a Web browser “labels” flows based upon what they contain (e.g., “video”, “image”, “interactive”), an observer on the network path – including pervasive ones – can more effectively perform traffic analysis to determine what the user is doing. Similarly, metadata adornment might reveal sensitive information; for example the Server Name Indicator (SNI) in the TLS handshake would reveal if a web visitor intends to go to <spanx style="verb">bannedcontent.github.com</spanx> versus <spanx style="verb">kitties.github.com</spanx>.</t>

<t>Standardizing an extensible transport metadata mechanism could also trigger various jurisdictions to define and require insertion of in-band metadata, an extension of current practices <xref target="AU-data-retention"/>. While the IETF would not be directly responsible for such an outcome, it is notable that in the past we’ve explicitly said we won’t serve conceptually similar use cases <xref target="RFC1984"/>.</t>

</section>
<section anchor="network-neutrality" title="Network Neutrality">

<t>There is obvious potential for network neutrality impact from a mechanism that allows networks to communicate with endpoints about flows. </t>

<t>For example, if a network can instruct content servers to throttle back bandwidth available to users for video based upon a commercial arrangement (or lack thereof), the network can achieve their goals without directly throttling traffic, thereby offering the potential to circumvent a regulatory regime that’s designed to effect network neutrality.</t>

<t>While the IETF has not take as firm a stance on network neutrality as it has for Pervasive Monitoring (for good reasons, since network neutrality problems are at their heart a sign of market failure, not a technical issue), new metadata facilities that enable existing regulatory regimes – thereby upsetting “the tussle” – must be carefully considered.</t>

</section>
</section>
<section anchor="possible-mitigations" title="Possible Mitigations">

<section anchor="constrained-vocabulary" title="Constrained Vocabulary">

<t>Much of the potential for harm above comes about because a transport-level metadata mechanism effectively becomes a side channel for arbitrary data, for use by any node on the path. The risks of questionable use could be mitigated by constraining the data that’s allowed in this side channel.</t>

<t>In other words, if the network doesn’t have a means of inserting a unique identifier for customers, they won’t be able to do so. If notification of constrained network conditions takes place using well-defined terms, regulatory regimes can be adjusted to achieve desired outcomes. And, information about application semantics can be carefully vetted for security considerations before being included in transport metadata.</t>

<t>One way to technically enforce such constraints would be to require nodes to silently drop non-standard metadata. Another would be to not make metadata extensible at all.</t>

<t>Naturally, this would constrain the ability of networks and applications to add new terms to metadata, thereby requiring more careful thought to go into the metadata that is standardised “up front.” </t>

</section>
<section anchor="transparency" title="Transparency">

<t>Many proposals for transport metadata assert that it will be encrypted, to improve security. While well-intentioned, it also creates an opaque side channel with a third party (the first and second being the endpoints). </t>

<t>The effect of of such designs should be carefully considered before standardisation; it may be that the community is better served by keeping this metadata “in the clear”, albeit possibly with some form of authentication and integrity available (or required).</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document describes security and privacy aspects of metadata adornment to internet protocols that protocol designers should consider.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference anchor='I-D.nottingham-gin'>
<front>
<title>Granular Information about Networks</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<date month='July' day='3' year='2014' />

<abstract><t>Protocol endpoints often want to adapt their behavior based upon the current properties of the network path, but have limited information available to aid these decisions.  This document motivates discussion of protocol work to make this information available.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-nottingham-gin-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-nottingham-gin-00.txt' />
</reference>



<reference anchor='I-D.sprecher-mobile-tg-exposure-req-arch'>
<front>
<title>Requirements and reference architecture for Mobile Throughput Guidance Exposure</title>

<author initials='A' surname='Jain' fullname='Ankur Jain'>
    <organization />
</author>

<author initials='A' surname='Terzis' fullname='Andreas Terzis'>
    <organization />
</author>

<author initials='N' surname='Sprecher' fullname='Nurit Sprecher'>
    <organization />
</author>

<author initials='S' surname='Swaminathan' fullname='Swaminathan'>
    <organization />
</author>

<author initials='K' surname='Smith' fullname='Kevin Smith'>
    <organization />
</author>

<author initials='G' surname='Klas' fullname='Guenter Klas'>
    <organization />
</author>

<date month='February' day='20' year='2015' />

<abstract><t>Rapidly-varying conditions in a cellular network can cause problems for the Transmission Control Protocol (TCP), which in turn can degrade application performance.  This document presents the problem statement and proposes solution principles.  It specifies the requirements and reference architecture for a mobile throughput guidance exposure mechanism that can be used to assist TCP in cellular networks, ensuring better network efficiency and enhanced service delivery performance.  The proposed mechanism can be applied to any content or TCP/IP based application content delivery.  This document describes the applicability of the mechanism for Intelligent Video Acceleration over cellular networks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-sprecher-mobile-tg-exposure-req-arch-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-sprecher-mobile-tg-exposure-req-arch-01.txt' />
</reference>



<reference anchor='I-D.hildebrand-spud-prototype'>
<front>
<title>Substrate Protocol for User Datagrams (SPUD) Prototype</title>

<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
    <organization />
</author>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<date month='March' day='9' year='2015' />

<abstract><t>SPUD is a prototype for grouping UDP packets together in a "tube", also allowing network devices on the path between endpoints to participate explicitly in the tube outside the end-to-end context.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-hildebrand-spud-prototype-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-hildebrand-spud-prototype-03.txt' />
</reference>



<reference  anchor='RFC7258' target='http://www.rfc-editor.org/info/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'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>


<reference anchor="IAB-confidentiality" target="http://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/">
  <front>
    <title>IAB Statement on Internet Confidentiality</title>
    <author >
      <organization>Internet Architecture Board</organization>
    </author>
    <date year="2014" month="November"/>
  </front>
</reference>
<reference anchor="TAG-securing-web" target="http://www.w3.org/2001/tag/doc/web-https">
  <front>
    <title>Securing the Web</title>
    <author >
      <organization>W3C Technical Architecture Group</organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>




<reference anchor='I-D.trammell-stackevo-newtea'>
<front>
<title>Thoughts a New Transport Encapsulation Architecture</title>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<date month='May' day='7' year='2015' />

<abstract><t>This document explores architectural considerations for using encapsulation in support of stack evolution and new transport protocol deployment in an increasingly encrypted Internet.  These architectural considerations are based on an idealized architecture where all interactions among applications, endpoints, and the path occur explicitly, with this cooperation enforced cryptographically. This idealized architecture is then lensed through the state of devices in the present Internet and how they would impair the deployability of such an architecture, in order to support an incremental deployment of this approach.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-trammell-stackevo-newtea-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-01.txt' />
</reference>



<reference anchor='I-D.hardie-spud-use-cases'>
<front>
<title>Use Cases for SPUD</title>

<author initials='T' surname='Hardie' fullname='Ted Hardie'>
    <organization />
</author>

<date month='February' day='12' year='2015' />

<abstract><t>SPUD is a prototype for grouping UDP packets together.  This grouping allows on-path network devices, especially middleboxes such as NATs or firewalls, to understand some basic semantics and potentially to offer salient information about their functions or the path to the endpoints.  This document describes basic use cases for sharing that semantic and for using the information shared.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-hardie-spud-use-cases-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-hardie-spud-use-cases-01.txt' />
</reference>


<reference anchor="X-UIDH" target="https://www.eff.org/deeplinks/2014/11/verizon-x-uidh">
  <front>
    <title>Verizon Injecting Perma-Cookies to Track Mobile Customers, Bypassing Privacy Controls</title>
    <author initials="J." surname="Hoffman-Andrews" fullname="Jacob Hoffman-Andrews">
      <organization>Electronic Frontier Foundation</organization>
    </author>
    <date year="2014" month="November"/>
  </front>
</reference>
<reference anchor="Injection" target="https://www.accessnow.org/blog/2015/08/17/read-our-new-report-on-the-troubling-rise-of-tracking-headers-worldwide2">
  <front>
    <title>The Rise of Mobile Tracking Headers: How Telcos Around the World Are Threatening Your Privacy</title>
    <author initials="N." surname="Ammari" fullname="Nader Ammari">
      <organization>Access</organization>
    </author>
    <author initials="G." surname="Björksten" fullname="Gustaf Björksten">
      <organization>Access</organization>
    </author>
    <author initials="P." surname="Micek" fullname="Peter Micek">
      <organization>Access</organization>
    </author>
    <author initials="D." surname="Olukotun" fullname="Deji Olukotun">
      <organization>Access</organization>
    </author>
    <date year="2015" month="August"/>
  </front>
</reference>




<reference  anchor='RFC3864' target='http://www.rfc-editor.org/info/rfc3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<date year='2004' month='September' />
<abstract><t>This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>



<reference  anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor='RFC1984' target='http://www.rfc-editor.org/info/rfc1984'>
<front>
<title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
<author><organization>IAB</organization></author>
<author initials='IESG' surname='' fullname='IESG'><organization /></author>
<date year='1996' month='August' />
<abstract><t>The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='1984'/>
<seriesInfo name='DOI' value='10.17487/RFC1984'/>
</reference>


<reference anchor="AU-data-retention" target="http://www.crikey.com.au/2015/03/18/your-guide-to-the-data-retention-debate-what-it-is-and-why-it’s-bad/">
  <front>
    <title>Your guide to the data retention debate: what it is and why it’s bad</title>
    <author initials="B." surname="Keane" fullname="Bernard Keane">
      <organization>Crikey</organization>
    </author>
    <date year="2015" month="March"/>
  </front>
</reference>


    </references>



  </back>
</rfc>

