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

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

      <address>
        <postal>
          <street>345 Encinal Street</street>

          <city>Santa Cruz</city>

          <region>CA</region>

          <code>95060</code>

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

        <phone>+1 206 661-2398</phone>

        <email>cary.bran@plantronics.com</email>
      </address>
    </author>

    <author fullname="Matthew Kaufman" initials="M.K." surname="Kaufman">
      <organization>Skype</organization>

      <address>
        <postal>
          <street>3210 Porter Drive</street>

          <city>Palo Alto</city>

          <region>California</region>

          <country>US</country>

          <code>94304</code>
        </postal>

        <phone>+1 831 440 8771</phone>

        <email>matthew.kaufman@skype.net</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>

    <author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
      <organization>Skype</organization>

      <address>
        <postal>
          <street>3210 Porter Drive</street>

          <city>Palo Alto</city>

          <region>California</region>

          <country>US</country>

          <code>94304</code>
        </postal>

        <email>jdrosen@skype.net</email>
      </address>
    </author>

    <date day="29" month="October" year="2011" />

    <abstract>
      <t>This document outlines the network address translation (NAT)
      traversal requirements and for WebRTC client applications.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>An integral part of the of the Web Real Time Communications (WebRTC)
      will be the ability for client application implementations to have
      native, secure Network Address Translation (NAT) <xref
      target="RFC1631"></xref> traversal capabilities. This document provides
      requirements and implementation specifications WebRTC client NAT
      traversal.</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 anchor="ConnectionManagementReqs"
             title="Connection Management Requirements">
      <t>This section identifies the requirements for RTC-Web client
      applications to connection requirements.</t>

      <section title="NAT Traversal Requirements">
        <t>A majority of WebRTC clients will be web browsers and used behind a
        NAT and or firewall. WebRTC clients will use a UDP-based data
        transmission scheme for multimedia sessions [Open Issue: what draft
        should be cited for this requirement?]. UDP has well know NAT
        traversal problems and without native capabilities to traverse a NAT,
        WebRTC clients will be extremely limited in their functionality.
        Fortunately NAT traversal for UDP is a solved problem, but solutions
        require that clients transmitting media between each other need to use
        the same NAT traversal algorithms. Without a consistent, well
        specified NAT traversal mechanism WebRTC client implementations would
        likely be inoperable with each other. To address the identified
        problems WebRTC clients are REQUIRED to implement the NAT traversal
        mechanism as defined in <xref
        target="ConnectionManagment"></xref>.</t>
      </section>

      <section anchor="DataTransmissionReq"
               title="Data Transmission Requirements">
        <t>Whenever a calling WebRTC client attempts to establish a
        connection, the receiving WebRTC client MUST provide consent before
        the calling client can transmit data to the receiver. Providing
        consent on the receiving end before data transmission commence is
        needed to help to prevent malicious attacks by the calling client. All
        WebRTC clients are REQUIRED to implement connection management that
        provides a consent mechanism for media transmission. Furthermore it is
        REQUIRED that consent be given by the recipient before an WebRTC
        client can transmit media.</t>

        <t>As a note providing consent to open a media connection does not
        involve user-level consent, rather it is the responsibility of the
        WebRTC client application (e.g. web browser) to enforce this
        requirement.</t>
      </section>

      <section title="IPv4 to IPv6 Transition Requirements">
        <t>RTC-Web clients MUST support IPv4 to IPv6 transition.</t>
      </section>

      <section title="Legacy Phone System Interoperability Requirements">
        <t>There is no way to meet all the connection management requirements
        and maintain compatibility with all legacy phone systems. It is highly
        desirable that the WebRTC connection management mechanism be
        interoperable with legacy phone systems such as a VOIP endpoints, PSTN
        gateways and SIP trunks.</t>
      </section>
    </section>

    <section anchor="ConnectionManagment"
             title="Connection Management Mechanism">
      <t>This section specifies the connection management system that will
      address the identified requirements.</t>

      <section title="ICE">
        <t>To address the NAT traversal, data transmission, and
        interoperability requirements all WebRTC client applications are
        REQUIRED to implement ICE <xref target="RFC5245"></xref>. Implicit to
        ICE, and listed here for clarity, WebRTC client implementations will
        are also REQUIRED to implement STUN <xref target="RFC3489"></xref> and
        TURN <xref target="RFC5766"></xref>.</t>

        <t>Additional ICE requirements:</t>

        <t><list style="symbols">
            <t>Support of ICE's Aggressive Nomination is REQUIRED</t>

            <t>Support of ICE's Regular Nomination is OPTIONAL</t>

            <t>WebRTC media gateways MAY implement ICE-Lite instead of full
            ICE</t>
          </list></t>

        <section title="ICE as a Consent Mechanism">
          <t>Of the connection management requirements listed above, the least
          obvious is how ICE will satisfy being a consent mechanism for data
          transmission <xref target="DataTransmissionReq"></xref>. The reason
          ICE can satisfy this requirement is due to its reliance on STUN
          transactions to succeed in order to establish a connection. The
          success of a STUN transaction can be viewed as semantically the same
          thing as a recipient providing consent to transmit data. Conversely
          the failure of the STUN transaction would semantically map to the
          recipient rejecting the request to transmit data.</t>
        </section>
      </section>

      <section title="Web Browsers and ICE">
        <t>This section specifies the web browser implementation requirements
        for WebRTC client connection management.</t>

        <section title="Native ICE Support ">
          <t>To meet the WebRTC connectivity requirements, web browser vendors
          MUST natively support ICE <xref target="RFC5245"></xref>. Access to
          the web browser's ICE implementation will be defined in the W3C
          WebRTC-API specification<xref target="I.D.w3c-webrtc"> </xref>. </t>

          <t>Alternate proposals have been made that advocate for natively
          exposing STUN<xref target="RFC3489"> </xref> APIs in the web
          browser. The ICE implementation would be realized via a JavaScript
          library that uses the browser's native STUN API. After reviewing the
          alternate proposals the solution several issues were identified.
          </t>

          <t><list style="numbers">
              <t>JavaScript running within "real world" web applications
              cannot reliably handle the ICE timing and pacing requirements.
              An example of this is long running JavaScript code from embedded
              advertisers. A big JavaScript file can take a significant amount
              of time to execute and can prevent web application timers from
              firing in correctly. Given the pacing requirements for ICE are
              in the 20ms range, it is highly likely that ICE will break if it
              is implemented in a JavaScript library.</t>

              <t>Multiple implementations of a JavaScript ICE library is a
              logistical nightmare. Coordinating updates, bug fixes,
              enhancements and a testing matrix for interoperability at
              Internet scale will simply be impossible.</t>
            </list></t>
        </section>

        <section title="STUN Configuration">
          <t>Web browsers MUST provide a mechanism to configure access to a
          STUN server. </t>

          <t>Below are some proposed mechanisms by which the STUN server could
          be configured:<list style="symbols">
              <t>A preference page, similar to the what web browser's use for
              configuring web proxy settings</t>

              <t>Exposed as a JavaScript API and added to the W3C WebRTC-API
              specification </t>
            </list></t>

          <t>Regardless of the mechanism adopted by the web browser vendor,
          the following configuration data is REQUIRED to be exposed and
          settable through the web browsers configuration mechanism:</t>

          <t><list style="symbols">
              <t>STUN Server Address - the IPv4 or IPv6 address of the STUN
              server</t>

              <t>STUN Server Port</t>

              <t>Credentials to access the STUN server (these are not STUN
              generated credentials)</t>
            </list></t>
        </section>
      </section>
    </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>To guard against spoofing RTC-Web client applications are REQUIRED
      to:</t>

      <t><list style="symbols">
          <t>Internally encapsulate the generation of STUN transaction IDs</t>

          <t>Block read/write access to the generated STUN transaction IDs</t>
        </list></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 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'
include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.1631.xml'?>

      <reference anchor="I.D.w3c-webrtc">
        <front>
          <title abbrev="W3C WebRTC-API">WebRTC 1.0: Real-time Communication
          Between Browsers</title>

          <author fullname="Adam Bergkvist" initials="A." surname="Bergkvist">
            <organization>Ericsson</organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <email></email>
            </address>
          </author>

          <author fullname="Daniel C. Burnett" initials="D.C."
                  surname="Burnett">
            <organization>Voxeo</organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <email></email>
            </address>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <email></email>
            </address>
          </author>

          <author fullname="Anant Narayanan" initials="A." surname="Narayanan">
            <organization>Mozilla</organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <email></email>
            </address>
          </author>

          <date day="28" month="October" year="2011" />

          <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>
        </front>
      </reference>
    </references>
  </back>
</rfc>