draft-ietf-httpbis-tunnel-protocol.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3864 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3864.xml">
<!ENTITY RFC3986 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC5246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5766 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5766.xml">
<!ENTITY RFC7230 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7231 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7301 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml">
]>
<?xml-stylesheet type='text/xsl' href='lib/rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-httpbis-tunnel-protocol-latest" ipr="trust200902"      xmlns:x="http://purl.org/net/xml2rfc/ext">
  <x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
  <front>
    <title abbrev="The ALPN Header">The ALPN HTTP Header Field</title>

    <author fullname="Andrew Hutton" initials="A." surname="Hutton">
      <organization>Unify</organization>
      <address>
        <postal>
          <street>Technology Drive</street>
          <city>Nottingham</city>
          <code>NG9 1LA</code>
          <country>UK</country>
        </postal>
        <email>andrew.hutton@unify.com</email>
      </address>
    </author>

   <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization>Google</organization>
      <address>
        <postal>
          <street>747 6th Ave S</street>
          <city>Kirkland</city>
          <region>WA</region>
          <code>98033</code>
          <country>US</country>
        </postal>
        <email>justin@uberti.name</email>
      </address>
    </author>

    <author fullname="Martin Thomson" initials="M." surname="Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>331 E Evelyn Street</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>US</country>
        </postal>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2015"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>HTTP CONNECT</keyword>
    <keyword>Firewall</keyword>
    <keyword>HTTP proxy</keyword>

    <abstract>
      <t>
        This specification allows HTTP CONNECT requests to indicate what
        protocol is intended to be used within the tunnel once established,
        using the ALPN header field.
       </t>
    </abstract>
  </front>

 <middle>
    <section title="Introduction">
      <t>
        The HTTP CONNECT method (<xref target="RFC7231" x:fmt="of" x:sec="4.3.6"/>)
        requests that the recipient establish a tunnel to the identified origin
        server and thereafter forward packets, in both directions, until the
        tunnel is closed. Such tunnels are commonly used to create end-to-end
        virtual connections, through one or more proxies.
      </t>
      <t>
        The HTTP ALPN header field identifies the protocol or protocols that the
        client intends to use within a tunnel that is established using CONNECT.
        This uses the Application Layer Protocol Negotiation identifier (ALPN,
        <xref target="RFC7301"/>).
      </t>
      <t>
        For a tunnel that is then secured using <xref
        target="RFC5246">TLS</xref>, the header field carries the same
        application protocol label as will be carried within the TLS handshake
        <xref target="RFC7301"/>.  If there are multiple possible application
        protocols, all of those application protocols are indicated.
      </t>
      <t>
        The ALPN header field carries an indication of client intent only.  An
        ALPN identifier is used here only to identify the application protocol
        or suite of protocols that the client intends to use in the tunnel.  No
        negotiation takes place using this header field.  In TLS, the final
        choice of application protocol is made by the server from the set of
        choices presented by the client.  Other substrates could negotiate the
        application protocol differently.
      </t>
      <t>
        Proxies do not implement the tunneled protocol, though they might choose
        to make policy decisions based on the value of the header field.  For
        example, a proxy could use the application protocol to select
        appropriate traffic prioritization.
      </t>

      <section title="Requirements Language">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
          document are to be interpreted as described in <xref
          target="RFC2119">RFC 2119</xref>.
        </t>
      </section>
    </section>

   <section title="The ALPN HTTP Header Field" anchor="tp">
      <t>
        Clients include the ALPN header field in an HTTP CONNECT request to
        indicate the application layer protocol that a client intends to use
        within the tunnel, or a set of protocols that might be used within the
        tunnel.
      </t>

      <section title="Header Field Values">
        <t>
          Valid values for the protocol field are taken from the
          "Application-Layer Protocol Negotiation (ALPN) Protocol ID" registry
          (<eref target="http://www.iana.org/assignments/tls-extensiontype-values/#alpn-protocol-ids"/>)
          established by <xref target="RFC7301"/>.
        </t>
      </section>

      <section title="Syntax">
        <t>
          The ABNF (Augmented Backus-Naur Form) syntax for the ALPN
          header field value is given below. It uses the syntax defined
          in <xref x:sec="1.2" x:fmt="of" target="RFC7230"/>.
        </t>
        <figure>
          <artwork type="abnf2616"><![CDATA[
ALPN = 1#protocol-id
protocol-id     = token ; percent-encoded ALPN protocol identifier
]]></artwork>
        </figure>
        <t>
          ALPN protocol names are octet sequences with no additional constraints
          on format. Octets not allowed in tokens (<xref target="RFC7230"
          x:fmt="," x:sec="3.2.6"/>) MUST be percent-encoded as per <xref
          x:fmt="of" x:sec="2.1" target="RFC3986"/>.  Consequently, the octet
          representing the percent character "%" (hex 25) MUST be
          percent-encoded as well.
        </t>
        <t>
          In order to have precisely one way to represent any ALPN protocol
          name, the following additional constraints apply:
          <list style="symbols">
            <t>
              Octets in the ALPN protocol MUST NOT be percent-encoded if they
              are valid token characters except "%", and
            </t>
            <t>
              When using percent-encoding, uppercase hex digits MUST be used.
            </t>
          </list>
        </t>
        <t>
          With these constraints, recipients can apply simple string comparison
          to match protocol identifiers.
        </t>
        <figure>
          <preamble>
            For example:
          </preamble>
          <artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
CONNECT www.example.com HTTP/1.1
Host: www.example.com
ALPN: h2, http%2F1.1
</artwork>
        </figure>
      </section>

      <section title="Usage">
        <t>
          When used in the ALPN header field, an ALPN identifier is used to
          identify an entire application protocol stack, not a single protocol
          layer or component.
        </t>
        <t>
          For a CONNECT tunnel that conveys a protocol secured with TLS, the
          value of the ALPN header field contains the same list of ALPN
          identifiers that will be sent in the TLS ClientHello message <xref
          target="RFC7301"/>.
        </t>
        <t>
          Where no protocol negotiation is expected to occur, such as in
          protocols that do not use TLS, the ALPN header field contains a single
          ALPN Protocol Identifier corresponding to the application protocol
          that is intended to be used.  If an alternative form of protocol
          negotiation is possible, the ALPN header field contains the set of
          protocols that might be negotiated.
        </t>
        <t>
          A proxy can use the value of the ALPN header field to more cleanly and
          efficiently reject requests for a CONNECT tunnel.  Exposing protocol
          information at the HTTP layer allows a proxy to deny requests earlier,
          with better error reporting (such as a 403 status code).  The ALPN
          header field can be falsified and is therefore not sufficient basis
          for authorizing a request.
        </t>
        <t>
          A proxy could attempt to inspect packets to determine the protocol in
          use.  This requires that the proxy understand each ALPN identifier.
          Protocols like TLS could hide negotiated protocols, or protocol
          negotiation details could change over time.  Proxies SHOULD NOT break
          a CONNECT tunnel solely on the basis of a failure to recognize the
          protocol.
        </t>
        <t>
          A proxy can use the ALPN header field value to change how it
          manages or prioritizes connections.
        </t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
        HTTP header fields are registered within the "Permanent Message Header
        Field Names" registry maintained at <eref
        target="https://www.iana.org/assignments/message-headers"/>.  This
        document defines and registers the ALPN header field, according to <xref
        target="RFC3864"/> as follows:
        <list style="hanging">
          <t hangText="Header Field Name:">
            ALPN
          </t>
          <t hangText="Protocol:">
            http
          </t>
          <t hangText="Status:">
            Standard
          </t>
          <t hangText="Reference:">
            <xref target="tp"/>
          </t>
          <t hangText="Change Controller:">
            IETF (iesg@ietf.org) - Internet Engineering Task Force
          </t>
        </list>
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        In case of using HTTP CONNECT to a TURN server ("Traversal Using Relays
        around NAT", <xref target="RFC5766"/>) the security considerations of
        <xref target="RFC7231" x:fmt="of" x:sec="4.3.6"/> apply. It states that
        there "are significant risks in establishing a tunnel to arbitrary
        servers, particularly when the destination is a well-known or reserved
        TCP port that is not intended for Web traffic. Proxies that support
        CONNECT SHOULD restrict its use to a limited set of known ports or a
        configurable whitelist of safe request targets."
      </t>
      <t>
        The ALPN header field described in this document is OPTIONAL. Clients
        and HTTP proxies could choose to not support it and therefore either
        fail to provide it, or ignore it when present. If the header field is
        not available or ignored, a proxy cannot identify the purpose of the
        tunnel and use this as input to any authorization decision regarding the
        tunnel. This is indistinguishable from the case where either client or
        proxy does not support the ALPN header field.
      </t>
      <t>
        There is no confidentiality protection for the ALPN header field.  ALPN
        identifiers that might expose confidential or sensitive information
        SHOULD NOT be sent, as described in <xref x:sec="5" x:fmt="of"
        target="RFC7301"/>.
      </t>
      <t>
        The value of the ALPN header field could be falsified by a
        client.  If the data being sent through the tunnel is encrypted (for
        example, with <xref target="RFC5246">TLS</xref>), then the proxy might
        not be able to directly inspect the data to verify that the claimed
        protocol is the one which is actually being used, though a proxy might
        be able to perform traffic analysis <xref target="TRAFFIC"/>.  A proxy
        therefore cannot rely on the value of the ALPN header field
        as a policy input in all cases.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC3864;
      &RFC3986;
      &RFC7230;
      &RFC7231;
      &RFC7301;
    </references>

   <references title="Informative References">
      &RFC5246;
      &RFC5766;

      <reference anchor="TRAFFIC"
                 target="https://alfredo.pironti.eu/research/publications/full/identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme">
        <front>
          <title>
            Website Users by TLS Traffic Analysis: New Attacks and Effective
            Countermeasures, Revision 1
          </title>
          <author initials="A." surname="Pironti"/>
          <author initials="P-Y." surname="Strub"/>
          <author initials="K." surname="Bhargavan"/>
          <date year="2012"/>
        </front>
      </reference>

    </references>
  </back>
</rfc>