One document matched: draft-ietf-rtcweb-transports-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-ietf-rtcweb-transports-02"
     ipr="trust200902">
  <front>
    <title abbrev="WebRTC Transports">Transports for RTCWEB</title>

    <author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand">
      <organization>Google</organization>

      <address>
        <email>harald@alvestrand.no</email>
      </address>
    </author>

    <date day="22" month="January" year="2014" />

    <abstract>
      <t>This document describes the data transport protocols used by RTCWEB,
      including the protocols used for interaction with intermediate boxes
      such as firewalls, relays and NAT boxes.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IETF RTCWEB effort, part of the WebRTC effort carried out in
      cooperation between the IETF and the W3C, is aimed at specifying a
      protocol suite that is useful for real time multimedia exchange between
      browsers.</t>

      <t>The overall effort is described in the RTCWEB overview document,
      <xref target="I-D.ietf-rtcweb-overview"></xref>. This document focuses
      on the data transport protocos that are used by conforming
      implementations.</t>

      <t>This protocol suite is designed for WebRTC, and intends to satisfy
      the security considerations described in the WebRTC security documents,
      <xref target="I-D.ietf-rtcweb-security"></xref> and <xref
      target="I-D.ietf-rtcweb-security-arch"></xref>.</t>

      <t></t>
    </section>

    <section title="Requirements language">
      <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="app-transport"
             title="Transport and Middlebox specification">
      <t></t>

      <section title="System-provided interfaces">
        <t>The protocol specifications used here assume that the following
        protocols are available to the implementations of the RTCWEB
        protocols:</t>

        <t><list style="symbols">
            <t>UDP. This is the protocol assumed by most protocol elements
            described.</t>

            <t>TCP. This is used for HTTP/WebSockets, as well as for TURN/SSL
            and ICE-TCP.</t>
          </list></t>

        <t>For both protocols, IPv4 and IPv6 support is assumed; applications
        MUST be able to utilize both IPv4 and IPv6 where available.</t>

        <t>For UDP, this specification assumes the ability to set the DSCP
        code point of the sockets opened on a per-packet basis, in order to
        achieve the prioritizations described in <xref
        target="I-D.dhesikan-tsvwg-rtcweb-qos"></xref> when multiple media
        types are multiplexed. It does not assume that the DSCP codepoints
        will be honored, and does assume that they may be zeroed or changed,
        since this is a local configuration issue.</t>

        <t>This specification does not assume that the implementation will
        have access to ICMP or raw IP.</t>
      </section>

      <section title="Usage of Quality of Service functions">
        <t>WebRTC implementations SHOULD attempt to set QoS on the packets
        sent, according to the guidelines in <xref
        target="I-D.dhesikan-tsvwg-rtcweb-qos"></xref>. It is appropriate to
        depart from this recommendation when running on platforms where QoS
        marking is not implemented.</t>
      </section>

      <section title="Support for multiplexing">
        <t>RTCWEB implementations MUST support the ability to send and receive
        multiple SSRCs on the same transport, and MUST support the ability to
        send and receive multiple SSRCs on multiple simultaneous transports,
        including the ability to send and receive audio and video on the same
        transport. The choice of configuration is done at higher layers (above
        transport), using mechanisms like BUNDLE <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>. Further
        information on RTP usage is found in <xref
        target="I-D.ietf-rtcweb-rtp-usage"></xref>.</t>

        <t>When different content types according to <xref
        target="I-D.dhesikan-tsvwg-rtcweb-qos"> </xref> are used on the same
        transport, appropriate per-packet DSCP marking SHOULD be used.</t>

        <t>DISCUSSION: Minimizing the number of transports has advantages in
        traversing NATs and firewalls, due to the reduced chance of
        negotiation failure. However, some network prioritization mechanisms
        (in particular active queue management techniques and flow-recognizing
        deep packet inspection boxes) will perform better when flows with
        different characteristics are separated on different 5-tuples. Since
        the optimum for this tradeoff is unknown, and may be variable, it is
        inappropriate to embed this choice in the protocol layer, and this is
        therefore left to the control of the application.</t>
      </section>

      <section title="Middle box related functions">
        <t>The primary mechanism to deal with middle boxes is ICE, which is an
        appropriate way to deal with NAT boxes and firewalls that accept
        traffic from the inside, but only from the outside if it's in response
        to inside traffic (simple stateful firewalls).</t>

        <t>ICE <xref target="RFC5245"></xref> MUST be supported. The
        implementation MUST be a full ICE implementation, not ICE-Lite.</t>

        <t>In order to deal with situations where both parties are behind NATs
        which perform endpoint-dependent mapping (as defined in <xref
        target="RFC5128"></xref> section 2.4), TURN <xref
        target="RFC5766"></xref> MUST be supported.</t>

        <t>In order to deal with firewalls that block all UDP traffic, TURN
        using TCP between the client and the server MUST be supported, and
        TURN using TLS between the client and the server MUST be supported.
        See <xref target="RFC5766"></xref> section 2.1 for details.</t>

        <t>In order to deal with situations where one party is on an IPv4
        network and the other party is on an IPv6 network, TURN extensions for
        IPv6 <xref target="RFC6156"></xref> MUST be supported.</t>

        <t>TURN TCP candidates <xref target="RFC6062"></xref> SHOULD be
        supported; this allows applications to achieve peer-to-peer
        communication when both parties are behind UDP-blocking firewalls
        using a single TURN server. (In this case, one can also achieve
        communication using two TURN servers that use TCP between the server
        and the client, and UDP between the TURN servers.)</t>

        <t>ICE-TCP candidates <xref target="RFC6544"></xref> MAY be supported;
        this may allow applications to communicate to peers with public IP
        addresses across UDP-blocking firewalls without using a TURN
        server.</t>

        <t>The ALTERNATE-SERVER mechanism specified in <xref
        target="RFC5389"></xref> (STUN) section 11 (300 Try Alternate) MUST be
        supported.</t>

        <t>Further discussion of the interaction of RTCWEB with firewalls is
        contained in <xref
        target="I-D.hutton-rtcweb-nat-firewall-considerations"></xref>. This
        document makes no requirements on interacting with HTTP proxies or
        HTTP proxy configuration methods.</t>
      </section>

      <section title="Transport protocols implemented">
        <t>For transport of media, secure RTP is used. The details of the
        profile of RTP used are described in "RTP Usage" <xref
        target="I-D.ietf-rtcweb-rtp-usage"></xref>.</t>

        <t>For data transport over the RTCWEB data channel <xref
        target="I-D.ietf-rtcweb-data-channel"></xref>, RTCWEB implementations
        MUST support SCTP over DTLS over ICE. This encapsulation is specified
        in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"></xref>. Negotiation
        of this transport in SDP is defined in <xref
        target="I-D.ietf-mmusic-sctp-sdp"></xref>.</t>

        <t>The setup protocol for RTCWEB data channels is described in <xref
        target="I-D.jesup-rtcweb-data-protocol"></xref>.</t>

        <t>RTCWEB implementations MUST support multiplexing of DTLS and RTP
        over the same port pair, as described in the DTLS_SRTP specification
        <xref target="RFC5764"></xref>, section 5.1.2. All application layer
        protocol payloads over this DTLS connection are SCTP packets.</t>
      </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>Security considerations are enumerated in <xref
      target="I-D.ietf-rtcweb-security"></xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document is based on earlier versions embedded in <xref
      target="I-D.ietf-rtcweb-overview"></xref>, which were the results of
      contributions from many RTCWEB WG members.</t>

      <t>Special thanks for reviews of earlier versions of this draft go to
      Magnus Westerlund, Markus Isomaki and Dan Wing; the contributions from
      Andrew Hutton also deserve special mention.</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.5764'?>

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-rtcweb-rtp-usage'?>

      <?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>

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

      <?rfc include='reference.I-D.dhesikan-tsvwg-rtcweb-qos'?>

      <?rfc include='reference.I-D.ietf-tsvwg-sctp-dtls-encaps'?>

      <?rfc include='reference.I-D.ietf-mmusic-sctp-sdp'?>
    </references>

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

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

      <?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>

      <?rfc include='reference.I-D.jesup-rtcweb-data-protocol'?>

      <?rfc include='reference.I-D.hutton-rtcweb-nat-firewall-considerations'?>
    </references>

    <section title="Change log">
      <t></t>

      <section title="Changes from -00 to -01">
        <t><list style="symbols">
            <t>Clarified DSCP requirements, with reference to -qos-</t>

            <t>Clarified "symmetric NAT" -> "NATs which perform
            endpoint-dependent mapping"</t>

            <t>Made support of TURN over TCP mandatory</t>

            <t>Made support of TURN over TLS a MAY, and added open
            question</t>

            <t>Added an informative reference to -firewalls-</t>

            <t>Called out that we don't make requirements on HTTP proxy
            interaction (yet</t>
          </list></t>
      </section>

      <section title="Changes from -01 to -02">
        <t><list style="symbols">
            <t>Required support for 300 Alternate Server from STUN.</t>

            <t>Separated the ICE-TCP candidate requirement from the TURN-TCP
            requirement.</t>

            <t>Added new sections on using QoS functions, and on multiplexing
            considerations.</t>

            <t>Removed all mention of RTP profiles. Those are the business of
            the RTP usage draft, not this one.</t>

            <t>Required support for TURN IPv6 extensions.</t>

            <t>Removed reference to the TURN URI scheme, as it was
            unnecessary.</t>

            <t>Made an explicit statement that multiplexing (or not) is an
            application matter.</t>
          </list>.</t>
      </section>
    </section>
  </back>
</rfc>