One document matched: draft-cbran-rtcweb-nat-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-cbran-rtcweb-nat-00"
     ipr="noDerivativesTrust200902">
  <front>
    <title abbrev="Abbreviated-Title">RTC-Web Network Address
    Translation</title>

    <author fullname="Cary Bran" initials="C." surname="Bran">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <phone>+1 206 256-3502</phone>

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

    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <phone>+1 408 421-9990</phone>

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

    <date day="1" month="July" year="2011" />

    <abstract>
      <t>This document outlines the network address translation (NAT)
      mechanisms and requirements for RTC-Web client applications.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>An integral part of the success and adoption of the Real-Time
      Communications Web (RTC-WEB) will be the ability for RTC-Web
      applications to have native, secure Network Address Translation (NAT)
      traversal capabilities. This specification proposes NAT traversal
      requirements and implementation specification for RTC-Web client
      applications.</t>

      <t>The NAT requirements fit into a series of specifications have been
      created to address RTC-Web codec, security, data transmission, non-media
      data, signaling and negotiation and use case requirements. More
      information on the RTC-Web can be found here:</t>

      <t>[TODO put links to supporting drafts here]</t>
    </section>

    <section 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">RFC 2119</xref>.</t>
    </section>

    <section title="Connection Management Requirements">
      <t>It is quite probable that many RTC-WEB client applications, such as
      web browsers will be deployed behind a NAT. To set up secure data plane
      sessions, all RTC-WEB client application implementations are REQUIRED to
      implement ICE <xref target="RFC5245"></xref> or ICE-Lite Section 2.7 of
      <xref target="RFC5245"></xref>. Implicit to supporting ICE, all RTC-WEB
      client applications are REQUIRED to implement Simple Traversal of User
      Datagram Protocol (UDP) Through Network Address Translators (NATs)
      (STUN) <xref target="RFC3489"></xref> and Traversal Using Relays around
      NAT (TURN) <xref target="RFC5766"></xref>.</t>

      <t>There are two deployment scenarios for RTC-WEB client applications.
      The first scenario is when applications are deployed behind NAT and have
      to worry about NAT traversal. The second scenario is when the
      application is not behind a NAT, such as an RTC-WEB application that is
      always connected to the public Internet. As stated in section 2.7 of
      <xref target="RFC5245"></xref>, ICE requires that both endpoints to
      support it in order for ICE to be used on a call.</t>

      <t>With regards to RTC-WEB client applications that are deployed behind
      a NAT or do not have a public IP address are REQUIRED to support ICE
      <xref target="RFC5245"></xref>, applications that are not behind a NAT
      and have a public IP address are REQUIRED to support ICE-Lite and MAY
      fully support ICE. RTC-WEB client applications that fully support ICE
      are REQUIRED to support AGGRESSIVE NOMINATION, and MAY support REGULAR
      NOMINATION.</t>

      <t>[Open Issue: there is a strong interest to define a TURN-like
      protocol that looks like HTTP to intermediaries, so that media can be
      tunneled over HTTP. Should this be done?]</t>
    </section>

    <section title="ICE for Web Browsers Via a JavaScript Library">
      <t>There have been discussions regarding the responsibility of where ICE
      will be implemented this is best illustrated via a concrete example.
      Given that the dominant RTC-Web application will be the web browser, it
      has been proposed that the ICE implementation reside within a JavaScript
      library and not natively available within the web browser.</t>

      <t>The reasoning behind requiring RTC-Web web apps to use a JavaScript
      library for ICE negotiation falls along two primary assumptions.</t>

      <t><list style="numbers">
          <t>Modern JavaScript engines can handle the ICE timing and pacing
          requirements</t>

          <t>JavaScript libraries provide the best deployment strategy for
          maintaining compatibility and versioning</t>
        </list></t>

      <section title="ICE Timing and Pacing Requirements">
        <t>The ICE pacing requirements have a lower bound of 20 ms [RFC5245,
        section B.1. Pacing of STUN Transactions]. At the writing of this
        document it is unclear if the resolution of modern JavaScript timers
        across the major operating systems could meet the lower boundary
        requirements for ICE. It has been suggested that the best way to
        determine if the ICE timing and pacing requirements were actually
        feasible was to create browser ready sample applications could prove
        or disprove the feasibility of ICE as a JavaScript library.</t>

        <t>If and when the testing is performed, there are several factors
        that have to be taken into consideration. The first being the testing
        environment. The testing environment must represent a real world
        user's environment as close as possible. A partial listing of user
        environments to consider for JavaScript/ICE testing would be the
        operating system, virtualization, browser vendor selection, hardware
        platform (notebook, desktop, tablet, netbook, smart phone, etc) and
        network connectivity.</t>

        <t>In addition to the underlying hardware, operating system, browser
        software and network, a crucial piece of testing JavaScript ICE MUST
        include testing performance under real-world web page conditions.
        Inline advertisements in web pages are a commonplace on the web. A
        page with advertisements may also include long-running JavaScripts
        that prevent web application timers from firing in correctly. Handling
        long running JavaScripts while meeting the ICE pacing requirements
        should be part of the evaluation criteria.</t>

        <t>[TODO - is someone going to write sample code that can prove,
        disprove the timer issue?]</t>
      </section>

      <section title="Compatibility, Fixes and Update Rollout">
        <t>It has been proposed that JavaScript ICE libraries would be easier
        to manage with regards to compatibility and updates when compared to
        ICE native within the web browser. While JavaScript libraries would
        make it easy to add fixes and enhancements to an ICE implementation
        this approach will not scale when it comes to interoperability and
        rapid deployment. With ICE as a JavaScript library, there can
        literally be a copy of the library on a per website basis, given that
        there are over 250 million individual websites on the internet, in
        addition to the millions of intranet hosted sites, upgrading a
        JavaScript library will simply not scale in a time friendly
        manner.</t>

        <t>With ICE native within the browser, there are fewer than a dozen
        implementations world wide that have to interoperate with each other,
        which means that enhancements to ICE can be coordinated between
        browser vendors. When it comes time to enhance or fix a defect with
        the browser's native ICE implementation, updates to browsers can be
        deployed, at scale, to hundreds of millions of users in the span of a
        few weeks. The rapid updates have proven effective and most if not all
        the major browser vendors have short term update mechanisms.</t>

        <t>Given that web browsers will be the dominant RTC-Web endpoint and
        that a native implementation of ICE within the browser will
        significantly narrow the complexities of ICE interoperability, defect
        fixes and enhancements at scale it is RECOMMENDED that ICE be
        implemented natively within all RTC-Web client applications.</t>

        <t>A question may arise regarding the above recommendation if a
        JavaScript ICE library could meet the ICE performance requirements.
        While such a library may meet the ICE performance requirements, until
        a deployment solution is proposed to propagate bug fixes and
        enhancements to the JavaScript library at internet scale, a JavaScript
        library approach would be an inferior recommendation compared to the
        native in the browser approach.</t>

        <t>[NOTE: This recommendation is based on current criteria and is
        subject to change should new criteria or techniques be discovered
        during the working of this draft]</t>
      </section>
    </section>

    <section title="Negotiation Architecture">
      <t>[WORK IN PROGRESS] An example of this will be showing how a RTC-Web
      capable web browser that natively supports ICE does signaling and
      negotiation to set up a DTLS [REF] connection. Once the DTLS connection
      has been established, the RTC-Web client application will use the secure
      channel for SIP signaling and media transmission.</t>

      <t>[OPEN issue - add architecture diagram and content]</t>

      <t></t>
    </section>

    <section title="Legacy VoIP Interoperability">
      <t>There is no way to meet all the security requirements and maintain
      comparability with all legacy VoIP equipment. This draft tries to
      minimize the impedance mismatch. The requirements here would allow
      interoperability with legacy VoIP equipment as long as that equipment
      either directly supported, or was fronted by an SBC that supported ICE
      or ICE-Lite.</t>

      <t>Support for ICE-Lite has historically been lacking in VoIP equipment,
      this is changing and ICE-Lite becoming increasingly prevalent,
      particularly on devices designed to sit on the edge of a domain and
      connect to remote user agents that may be behind NATs. Given the
      increasing adoption of ICE-Lite, it could be conjectured that a
      substantial fraction of VoIP equipment meets the RTC-WEB
      interoperability list.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Because there are a number of security issues, considerations and
      requirements for RTC-WEB client applications there is a draft that
      specifically addresses the RTC-WEB application security considerations.
      This draft defers it’s security considerations and requirements to
      the security considerations for RTC-Web draft <xref
      target="I-D.ekr-security-considerations-for-rtc-web"></xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This draft incorporates ideas and text from the IETF mailing list. In
      particularly we would like to acknowledge, and say thanks for, work we
      incorporated from Timothy Terriberry, Jonathan Rosenburg and Christopher
      Blizzard.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml'?>

      <reference anchor="I-D.ekr-security-considerations-for-rtc-web">
        <front>
          <title abbrev="RTC-Web Security">Security Considerations for
          RTC-Web</title>

          <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
            <organization>RTFM, Inc.</organization>

            <address>
              <postal>
                <street>2064 Edgewood Drive</street>

                <city>Palo Alto</city>

                <region>CA</region>

                <code>94303</code>

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

              <phone>+1 650 678 2350</phone>

              <email>ekr@rtfm.com</email>
            </address>
          </author>

          <date day="30" month="May" year="2011" />

          <area>RAI</area>

          <workgroup>RTC-Web</workgroup>

          <abstract>
            <t>The Real-Time Communications on the Web (RTC-Web) working group
            is tasked with standardizing protocols for real-time
            communications between Web browsers. The two major use cases for
            RTC-Web technology are real-time audio and/or video calls and
            direct data transfer. Unlike most conventional real-time systems
            (e.g., SIP-based soft phones) RTC-Web communications are directly
            controlled by some Web server, which poses new security
            challenges. For instance, a Web browser might expose a JavaScript
            API which allows a server to place a video call. Unrestricted
            access to such an API would allow any site which a user visited to
            "bug" a user's computer, capturing any activity which passed in
            front of their camera. This document defines the RTC-Web threat
            model and defines an architecture which provides security within
            that threat model.</t>
          </abstract>

          <note title="Legal">
            <t>THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE
            PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE
            ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
            INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING
            TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
            BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
            THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
            MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
          </note>
        </front>
      </reference>
    </references>
  </back>
</rfc>