One document matched: draft-ietf-tram-alpn-06.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-06" ipr="trust200902">
  <front>
    <title abbrev="ALPN for STUN/TURN">Application Layer Protocol Negotiation
    (ALPN) labels for Session Traversal Utilities for NAT (STUN)
    Usages</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>Impedance Mismatch</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

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

        <email>marc@petit-huguenin.org</email>
      </address>
    </author>

    <date year="2014"/>

    <workgroup>TRAM</workgroup>

    <abstract>
      <t>Application Layer Protocol Negotiation (ALPN) labels for Session
      Traversal Utilities for NAT (STUN) usages, such as Traversal Using
      Relays around NAT (TURN) and NAT discovery, are defined in this document
      to allow an application layer negotiate STUN usages within the Transport
      Layer Security (TLS) connection. ALPN protocol identifiers defined in
      this document apply 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="RFC7350"/>.</t>

      <t>ALPN <xref target="RFC7301"/> enables an endpoint to positively
      identify an application protocol in TLS/DTLS and distinguish it 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. Application protocol
      negotiation can thus be accomplished within the TLS/DTLS handshake,
      without adding network round-trips.</t>

      <t>STUN protocol usages, such as TURN <xref target="RFC5766"/>, can be
      used to identify the purpose of a flow without initiating a session.
      This capability is useful and adds efficiency, as shown in the following
      scenarios.</t>

      <t><list style="numbers">
          <t>Consider an Enterprise network that deploys a TURN server in a
          DeMilitarized Zone (DMZ) to audit all media sessions from inside the
          Enterprise premises to any external peer. In this deployment, an
          Enterprise firewall could use the TURN ALPN identifier to detect the
          use of a TURN server that is outside the Enterprise domain (i.e., a
          TURN server provided by an application server, access network,
          etc).</t>

          <t>If a firewall is configured to 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. However, despite the restrictions
          imposed by the firewall, a TURN server can still be reached on the
          allowed HTTPS port if the TURN ALPN identifier is used to establish
          usage of TURN as part of the TLS handshake.</t>
        </list></t>

      <t>This document defines entries in the "Application Layer Protocol
      Negotiation (ALPN) Protocol IDs" registry established by <xref
      target="RFC7301"/> to identify STUN protocol usages.</t>
    </section>

    <section title="ALPN Labels for STUN">
      <t>The document proposes the following ALPN labels to identify STUN
      protocol <xref target="RFC5389"/> usages.<list style="hanging">
          <t hangText="'stun.turn':">Label to identify the specific use of
          STUN over (D)TLS for TURN (Section 4.6 of <xref
          target="RFC7350"/>).</t>

          <t hangText="'stun.nat-discovery':">Label to identify the specific
          use of STUN over (D)TLS for NAT discovery (Section 4.1 of <xref
          target="RFC7350"/>).</t>
        </list></t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>The following entries are to be added to the "Application Layer
      Protocol Negotiation (ALPN) Protocol IDs" registry established by <xref
      target="RFC7301"/>.</t>

      <t>The "stun.turn" label identifies the use of TURN usage (D)TLS:</t>

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

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

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

      <t>The "stun.nat-discovery" label identifies the use of STUN for the
      purposes of NAT discovery over (D)TLS:<list style="empty">
          <t>Protocol: NAT discovery using Session Traversal Utilities for NAT
          (STUN)</t>

          <t>Identification Sequence: 0x73 0x74 0x75 0x6E 0x2E 0x6e 0x61 0x74
          0x2d 0x64 0x69 0x73 0x63 0x6f 0x76 0x65 0x72 0x79
          ("stun.nat-discovery")</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="RFC7301"/>. It also does not impact security
      of TLS/DTLS session establishment nor 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, Brandon Williams 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.5246"?>

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

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

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

      <?rfc include="reference.RFC.7350"
?>
    </references>

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

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