One document matched: draft-ietf-tram-alpn-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-tram-alpn-00"
     ipr="trust200902">
  <front>
    <title abbrev="ALPN for STUN/TURN">Application Layer Protocol
    Negotiation (ALPN) for Session Traversal Utilities for NAT
    (STUN)</title>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <street/>

          <city>Bangalore</city>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T."
            surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Gonzalo Salgueiro" initials="G."
            surname="Salgueiro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

          <country>US</country>
        </postal>

        <email>gsalguei@cisco.com</email>
      </address>
    </author>

    <author fullname="Marc Petit-Huguenin" initials="M."
            surname="Petit-Huguenin">
      <organization>Jive Communications</organization>

      <address>
        <postal>
          <street>1275 West 1600 North, Suite 100</street>

          <city>Orem</city>

          <region>UT</region>

          <code>84057</code>

          <country>USA</country>
        </postal>

        <email>marcph@getjive.com</email>
      </address>
    </author>

    <date year="2014"/>

    <workgroup>TRAM</workgroup>

    <abstract>
      <t>An Application Layer Protocol Negotiation (ALPN) label for
      the Session Traversal Utilities for NAT (STUN) protocol is
      defined in this document to allow the application layer to
      negotiate STUN within the Transport Layer Security (TLS)
      connection. The STUN ALPN protocol identifier applies to both
      TLS and Datagram Transport Layer Security (DTLS).</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>STUN can be securely transported using TLS-over-TCP (referred
      to as TLS <xref target="RFC5246"/>), as specified in <xref
      target="RFC5389"/>, or TLS-over-UDP (referred to as DTLS <xref
      target="RFC6347"/>), as specified in <xref
      target="I-D.petithuguenin-tram-turn-dtls"/>.</t>

      <t>ALPN <xref target="I-D.ietf-tls-applayerprotoneg"/> enables
      an endpoint to positively identify STUN protocol uses in
      TLS/DTLS and distinguish them from other TLS/DTLS protocols.
      With ALPN, the client sends the list of supported application
      protocols as part of the TLS/DTLS ClientHello message. The
      server chooses a protocol and sends the selected protocol as
      part of the TLS/DTLS ServerHello message. The application
      protocol negotiation can thus be accomplished within the
      TLS/DTLS handshake, without adding network round-trips, and
      allows the server to associate a different certificate with each
      application protocol, if desired.</t>

      <t>For example, a firewall could block all outgoing traffic
      except for TCP traffic to specific ports (e.g., 443 for HTTPS).
      A TURN server listening on its default ports (3478 for TCP/UDP,
      5349 for TLS) would not be reachable in this case. However,
      despite the restrictions imposed by the firewall, the TURN
      server can still be reached on the allowed HTTPS port if an ALPN
      STUN protocol identifier is used to establish the STUN
      application layer protocol as part of the TLS handshake. In this
      case, the STUN ALPN identifier sent by the client will be used
      by the server to identify that the client intends to make a TURN
      request and it must act as a TURN server to relay the traffic to
      and from the remote peer. Similarly, with Quick UDP Internet
      Connections (QUIC) <xref target="QUIC"/>, a UDP-based transport
      protocol that operates under SPDY <xref
      target="I-D.mbelshe-httpbis-spdy"/>, a TURN server could be
      operated on the same ports as that of a SPDY server.</t>

      <t>This document defines an entry ("stun") in the "Application
      Layer Protocol Negotiation (ALPN) Protocol IDs" registry
      established by <xref target="I-D.ietf-tls-applayerprotoneg"/> to
      identify the STUN protocol.</t>

      <t>[[TODO: In various offline discussions some have expressed a
      desire to add an additional ALPN protocol identifier for TURN
      (see IANA Considerations below for example registration). ALPN
      can be used more granularly to externally identify more of the
      protocol variants and their different properties (i.e., STUN and
      TURN over TLS/DTLS). The advantage in dividing it this way is
      that these different forms can be externally identified
      (obviously, there isn't any inherent value in the different
      identifiers from within the TLS handshake).There are two main
      disadvantages. the first is that this two application protocol
      approach may make implementations more complicated/confusing.
      The second is that there may be difficulty in differentiating
      the two with ALPN when TURN was specifically designed to be able
      to run on the same port as STUN usage (in section 13 of RFC
      5389). Section 4.1.1.2 of RFC 5245 explicitly says that "If the
      Allocate request is rejected because the server lacks resources
      to fulfill it, the agent SHOULD instead send a Binding request
      to obtain a server reflexive candidate." Does that prove there
      is no need to differentiate TURN and STUN request on UDP/TCP or
      TLS and now DTLS? Are there sufficiently meaningful differences
      between the usages to warrant separate STUN and TURN ALPN
      identifiers?]]</t>
    </section>

    <section anchor="term" title="Terminology">
      <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"/>.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>The following entry is to be added to the "Application Layer
      Protocol Negotiation (ALPN) Protocol IDs" registry established
      by <xref target="I-D.ietf-tls-applayerprotoneg"/>.</t>

      <t>The "stun" label identifies STUN over TLS/DTLS:</t>

      <t><list style="empty">
          <t>Protocol: Session Traversal Utilities for NAT (STUN)</t>

          <t>Identification Sequence: 0x73 0x74 0x75 0x6E ("stun")</t>

          <t>Specification: This document (RFCXXXX)</t>
        </list></t>

      <t>[[TODO: Shown only as an example. Remove the below registry
      entry if open issue above dictates a single STUN ALPN identifier
      is sufficient.]]</t>

      <t>The "turn" label identifies TURN over TLS/DTLS:</t>

      <t><list style="empty">
          <t>Protocol: Traversal Using Relays around NAT (TURN)</t>

          <t>Identification Sequence: 0x74 0x75 0x72 0x6E ("turn")</t>

          <t>Specification: This document (RFCXXXX)</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The ALPN STUN protocol identifier does not introduce any
      specific security considerations beyond those detailed in the
      TLS ALPN Extension specification <xref
      target="I-D.ietf-tls-applayerprotoneg"/>. It also does not
      impact the security of TLS/DTLS session establishment nor the
      application data exchange.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>This work benefited from the discussions and invaluable input
      by the various members of the TRAM working group. These include
      Simon Perrault, Paul Kyzivat, and Andrew Hutton. Special thanks
      to Martin Thomson and Oleg Moskalenko for their constructive
      comments, suggestions, and early reviews that were critical to
      the formulation and refinement of this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5246"?>

      <?rfc include="reference.RFC.5389"?>

      <?rfc include="reference.RFC.6347"?>

      <?rfc include="reference.I-D.ietf-tls-applayerprotoneg"
?>

      <?rfc include="reference.I-D.petithuguenin-tram-turn-dtls"
?>

      <?rfc include="reference.I-D.mbelshe-httpbis-spdy"?>

      <reference anchor="QUIC">
        <front>
          <title>QUIC Slide Deck at IETF88,</title>

          <author>
            <organization>http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf</organization>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5766'
?>

      <!---->
    </references>
  </back>
</rfc>