One document matched: draft-patil-tram-turn-serv-selection-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="info" docName="draft-patil-tram-turn-serv-selection-00"
     ipr="trust200902">
  <front>
    <title abbrev="TURN server selection">Traversal Using Relays around NAT
    (TURN) Server Selection</title>

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

      <address>
        <postal>
          <street></street>

          <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>Cisco</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>

    <date />

    <workgroup>TRAM</workgroup>

    <abstract>
      <t>A TURN client may discover multiple TURN servers. In such a case,
      there are no guidelines that a client can follow to choose or prefer a
      particular TURN server among those discovered. This document details
      selection criteria, as guidelines, that can be used by a client to
      perform an informed TURN server selection decision.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Using any of the discovery mechanisms described in <xref
      target="I-D.ietf-tram-turn-server-discovery"></xref>, a client may
      discover multiple Traversal Using Relays around NAT (TURN) servers. The
      TURN servers discovered could be provided by an enterprise network, an
      access network, an application service provider or a third party
      provider. Therefore, the client needs to be able to choose a TURN server
      that best suits its needs.</t>

      <t>Selection criteria could be based on parameters such as:</t>

      <t><list style="symbols">
          <t>Security</t>

          <t>Location Privacy</t>

          <t>Authentication</t>

          <t>User Experience</t>

          <t>Interface Selection (if the client is multi-interfaced)</t>

          <t>Mobility Support</t>
        </list></t>

      <t>This document describes procedures that a client can use to choose
      the most appropriate TURN server based on any one or more combinations
      of the above parameters. A client could also use the aforementioned
      selection criteria to prioritize the discovered TURN servers based on
      these parameters if backup servers are implemented for added resiliency
      and robustness.</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"></xref>.</t>
    </section>

    <section title="TURN Server Selection Criteria">
      <t>The accessibility of possible TURN servers SHOULD be tested and
      verified prior to beginning Interactive Connectivity Establishment (ICE)
      <xref target="RFC5245"></xref>. Any TURN servers that fail such
      accessibility tests (including credentials verification) SHOULD be
      excluded. These early tests are an often an optimal opportunity to
      calculate performance metrics, such as the round-trip time (RTT), that
      might be used as TURN server prioritization factors, as discussed in
      <xref target="UE"></xref>. Throughout the lifetime of the application,
      it is RECOMMENDED to periodically test the entire selection list, in
      case better TURN servers suddenly appear or connectivity to others is
      unexpectedly lost.</t>

      <t>The parameters described in this Section are intended as TURN server
      selection criteria or as weighting factors for TURN server
      prioritization.</t>

      <section title="Local Configuration">
        <t>Local or manual configuration takes precedence for TURN server
        selection. A client could be configured with an explicit preferred
        list of TURN servers. Local configuration could list servers in order
        of preference. For example, a TURN client could opt for a TURN server
        offered by the Enterprise and fall back to a TURN server offered by
        the Internet Service Provider (ISP) or a cloud service if the
        Enterprise TURN server wasn't available.</t>

        <t>An implementation MAY give the user an opportunity (e.g., by means
        of configuration file options or menu items) to specify this
        preference.</t>
      </section>

      <section anchor="Sec" title="Security">
        <t>If a TURN client wants security for its connections, it should opt
        for a TURN server that supports the usage of Transport Layer Security
        (TLS) <xref target="RFC5246"></xref> and Datagram Transport Layer
        Security (DTLS) <xref target="RFC6347"></xref> as a transport protocol
        for Session Traversal Utilities for NAT (STUN), as defined in <xref
        target="RFC5389"></xref> and <xref target="RFC7350"></xref>. If
        multiple servers offer this support, the client could use Location
        Privacy (<xref target="LP"></xref>) and Authentication (<xref
        target="Auth"></xref>) criteria to determine which among the list is
        most suitable.</t>

        <t>The need for security depends on the type of connected network
        (i.e., whether the host is connected to a home network versus an
        Enterprise network versus a coffee shop network). It is recommended
        that a client always choose security, but this condition could vary
        depending on the degree of trust with the connected network.</t>

        <section anchor="LP" title="Location Privacy">
          <t>In addition to security, a TURN client may require additional
          location privacy from an external peer.</t>

          <t><list style="hanging">
              <t hangText="Scenario 1:">A client may not wish to use a TURN
              server in its Enterprise or access network because the client
              location could be determined by the external peer. In such a
              case, the client may choose to use a distributed multi-tenant or
              a cloud-based TURN server that can provide privacy by obscuring
              the network from which the client is communicating with the
              remote peer.</t>

              <t hangText="Scenario 2:">A TURN client that desires to perform
              Scenario 1, but cannot because of firewall policy that forces
              the client to pick Enterprise-provided TURN server for external
              communication, can use TURN-in-TURN through the enterprise's
              TURN server as described in <xref
              target="I-D.schwartz-rtcweb-return"></xref>.</t>
            </list></t>

          <t>Location privacy may not be critical if the client attempts to
          communicate with a peer within the same domain.</t>
        </section>

        <section anchor="Auth" title="Authentication">
          <t>A TURN client should prefer a TURN server whose authenticity can
          be ascertained. A simple certificate trust chain validation during
          the process of (D)TLS handshake should be able to validate the
          server.</t>

          <t>A TURN client could also be pre-configured with the names of
          trusted TURN servers. When connecting to a TURN server, a TURN
          client should start with verifying that the TURN server name matches
          the pre-configured list of TURN servers, and finally validating its
          certificate trust chain. For TURN servers that don't have a
          certificate trust chain, the configured list of TURN servers can
          contain the certificate fingerprint of the TURN server (i.e., a
          simple whitelist of name and certificate fingerprint).</t>

          <t>DNS-based Authentication of Named Entities (DANE) can also be
          used to validate the certificate presented by TURN server as
          described in <xref
          target="I-D.petithuguenin-tram-stun-dane"></xref>.</t>
        </section>
      </section>

      <section anchor="UE" title="User Experience">
        <t>All else being equal (or if a TURN client is able to converge on a
        set of TURN servers based on parameters described in <xref
        target="Sec"></xref>), a TURN client should choose a TURN server that
        provides the best user experience at that point in time (based on
        factors such as RTT, real-time clock (RTC), etc).</t>

        <t>If using ICE regular nomination, ICE connectivity check round-trip
        time can influence the selection amongst the valid pairs. This way a
        candidate pair with relayed candidate could be selected even if it has
        lower-priority than other valid pairs.</t>
      </section>

      <section title="Interface">
        <t>With a multi-interfaced node, selection of the correct interface
        and source address is often crucial. How to select an interface and IP
        address family is out of scope for this document. A client could
        account for the provisioning domain described in <xref
        target="I-D.ietf-mif-mpvd-arch"></xref> to determine which interface
        to choose.</t>
      </section>

      <section title="Mobility Support">
        <t>If a TURN client is aware that the host is mobile, and all other
        parameters being equal, the client SHOULD choose a TURN server that
        supports mobility <xref
        target="I-D.wing-tram-turn-mobility"></xref>.</t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document does not itself introduce security issues, rather it
      merely presents best practices for TURN server selection. Security
      considerations described in <xref target="RFC5766"></xref> are
      applicable to for all TURN usage.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>The authors would like to thank Dan Wing, Marc Petit-Huguenin for
      their review and valuable comments.</t>
    </section>
  </middle>

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

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

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

      <?rfc include="reference.I-D.ietf-tram-turn-server-discovery"?>

      <?rfc include="reference.I-D.schwartz-rtcweb-return"?>

      <?rfc include='reference.I-D.wing-tram-turn-mobility'?>

      <?rfc include='reference.I-D.ietf-mif-mpvd-arch'?>

      <?rfc include="reference.I-D.petithuguenin-tram-stun-dane"?>
    </references>

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

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

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

      <?rfc include='reference.RFC.6347'?>
    </references>
  </back>
</rfc>