One document matched: draft-reddy-tram-turn-ipaddress-privacy-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-reddy-tram-turn-ipaddress-privacy-00"
     ipr="trust200902">
  <front>
    <title abbrev="IP address privacy  by TURN server">IP address privacy by
    TURN server</title>

    <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="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>

    <date />

    <workgroup>TRAM</workgroup>

    <abstract>
      <t>A TURN server allocates an IP address for a user. If this address is
      dis-associated from the user's actual network, the allocated IP address
      increases the user's privacy. This document describes a means for an
      client to discover that the TURN server can provide IP address
      privacy.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Disclosing a host's IP address and connected network's IP address can
      disclose the user's location or network connection point, which is a
      privacy concern. These addresses are disclosed during normal operation
      of WebRTC <xref target="I-D.ietf-rtcweb-overview"></xref>. To prevent
      this disclosure, the local address (called "host address" by ICE <xref
      target="RFC5245"></xref>) and the connected network's IP address (called
      "server reflexive" by ICE) cannot be disclosed to the remote peer.
      Instead, only the address allocated by a TURN (Traversal Using Relays
      around NAT) <xref target="RFC5766"></xref> server is disclosed to the
      remote peer. However, if the TURN server is dedicated to a specific
      network (e.g., it is deployed by a network operator for the sole use of
      users on that network), that TURN server will similarly leak information
      about the user's connected network.</t>

      <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 can provide IP address privacy.</t>

      <t>The ADDRESS-PRIVACY attribute introduced in this specification can be
      used by the client to determine if the TURN server can provide IP
      address privacy from the remote peer.</t>

      <t>This technique also solves the following other problems:<list
          style="symbols">
          <t>User may or may not trust the calling service or WebRTC
          application. <xref target="I-D.ietf-rtcweb-security-arch"></xref>
          discusses users using privacy techniques like Tor so that malicious
          calling service does not learn the user's IP address. The Poker
          example given in section 4 of <xref
          target="I-D.ietf-rtcweb-security-arch"></xref>discusses that the
          users in the call do not trust the calling service. In this scenario
          if the user wants IP address privacy then the TURN server provided
          by the calling service must be avoided and the client must only
          select a TURN server whose authenticity can be ascertained and can
          offer IP address privacy.</t>

          <t>Enterprise Firewall policy typically has a white-list of
          permitted outside applications/sites and can blacklist HTTP(S)
          connections via various forms of detections (DNS lookup, ALPN, HTTP
          URL Filtering, DPI proxy that at least performs HTTPS inspection of
          SNI in TLS exchange and validates SSL records, HTTP(S) proxy etc.).
          Firewall in this configuration would block TCP/UDP connection to
          external peers in the Internet and arbitrary TURN servers. For
          example firewall would block usage of STUN with external peers and
          force the clients to use enterprise provided TURN server for all
          external WebRTC media communications. Enterprise network could
          leverage firewall and TURN services provided by a third party
          provider. If the third party offered TURN server can provide IP
          address privacy then the application can avoid TURN-in-TURN
          mechanism discussed in <xref
          target="I-D.schwartz-rtcweb-return"></xref> and thus avoid the
          overhead of using RETURN proxying.</t>
        </list></t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <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>

      <t>This note uses terminology defined in STUN <xref
      target="RFC5389"></xref>.</t>
    </section>

    <section anchor="alg_over"
             title="IP address privacy determination procedure">
      <t>If a client wants IP address privacy, it includes the ADDRESS-PRIVACY
      attribute in its TURN Allocate request. If the server can provide IP
      address privacy then it would echo back ADDRESS-PRIVACY attribute in the
      Allocate response.</t>

      <t>This specification defines a new comprehension-optional STUN
      attribute ADDRESS-PRIVACY will have a STUN Type TBD-CA. This type is in
      the comprehension-optional range, which means that TURN servers can
      safely ignore the attribute if they do not understand it.</t>

      <section title="The ADDRESS-PRIVACY attribute in request">
        <t>This attribute is used by the client to ask the server if it can
        provide IP address privacy. This attribute has no value part and thus
        the attribute length field is 0.</t>
      </section>

      <section title="The ADDRESS-PRIVACY attribute in response">
        <t>When a server receives a STUN request that includes a
        ADDRESS-PRIVACY attribute, it processes the request as per the STUN
        specification <xref target="RFC5389"></xref> plus the specific rules
        mentioned here. The server checks the following:</t>

        <t><list style="symbols">
            <t>If the ADDRESS-PRIVACY attribute is not recognized, ignore the
            attribute because its type indicates that it is comprehension-
            optional. This should be the existing behavior as explained in
            section 3.1 of <xref target="RFC5389"></xref>.</t>

            <t>If the server can provide IP address privacy then it will
            include ADDRESS-PRIVACY attribute in the response.</t>

            <t>If the server determines that the relayed address it will
            allocate and client IP address are in the same geolocation then
            the server will redirect the client to another server that can
            provide IP address privacy by replying to the request message with
            an error response with error code 300 (Try Alternate). (TBD: Is
            there a need for privacy levels ? (same country different town,
            same continent different country, different continent etc)).</t>

            <t>If the server cannot provide IP address privacy or does not
            want to provide IP address privacy then it will ignore this
            attribute.</t>
          </list></t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>[Paragraphs in braces should be removed by the RFC Editor upon
      publication]</t>

      <t>[The ADDRESS-PRIVACY attribute requires that IANA allocate a value in
      the "STUN attributes Registry" from the comprehension-optional range
      (0x8000-0xBFFF), to be replaced for TBD-CA throughout this document]</t>

      <t>This document defines the ADDRESS-PRIVACY STUN attribute, described
      in <xref target="alg_over"></xref>. IANA has allocated the
      comprehension-optional codepoint TBD-CA for this attribute.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>It is possible the TURN server provides inadequate IP address privacy
      to meet the client's needs. For example, the TURN server might be
      located in the same city as the client, but the client wants to
      obfuscate its location to the same continent or to a different continent
      or a different planet. The client should find its geolocation using
      server-reflexive candidate. The client should also determine the
      geolocation of the relayed address learned from the TURN server and
      compare with its geolocation to determine if the TURN server is indeed
      providing IP address privacy.</t>

      <t>Security considerations discussed in <xref target="RFC5766"></xref>
      are to be taken into account.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Thanks to Dan Wing and Pal Martinsen for the review and comments.</t>
    </section>
  </middle>

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-tram-turn-server-discovery'?>

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

      <?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>
    </references>
  </back>
</rfc>