One document matched: draft-ietf-rtcweb-transports-03.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-03"
     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="31" month="March" 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 protocols 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.</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> (see <xref
        target="s-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>Platforms that do not give access to these interfaces will not be
        able to support a conforming RTCWEB implementation.</t>

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

      <section title="Ability to use IPv4 and IPv6">
        <t>Web applications running on top of the RTCWEB implementation MUST
        be able to utilize both IPv4 and IPv6 where available - that is, when
        two peers have only IPv4 connectivty to each other, or they have only
        IPv6 connectivity to each other, applications running on top of the
        RTCWEB implementation MUST be able to communicate.</t>

        <t>When TURN is used, and the TURN server has IPv4 or IPv6
        connectivity to the peer or its TURN server, candidates of the
        appropriate types MUST be supported. The "Happy Eyeballs"
        specification for ICE <xref
        target="I-D.reddy-mmusic-ice-happy-eyeballs"></xref> SHOULD be
        supported.</t>
      </section>

      <section title="Usage of temporary IPv6 addresses">
        <t>The IPv6 default address selection specification <xref
        target="RFC6724"></xref> specifies that temporary addresses <xref
        target="RFC4941"></xref> are to be preferred over permanent addresses.
        This is a change from the rules specified by <xref
        target="RFC3484"></xref>. For applications that select a single
        address, this is usually done by the IPV6_PREFER_SRC_TMP specified in
        <xref target="RFC5014"></xref>. However, this rule is not completely
        obvious in the ICE scope. This is therefore clarified as follows:</t>

        <t>When a client gathers all IPv6 addresses on a host, and both
        temporary addresses and permanent addresses of the same scope are
        present, the client SHOULD discard the permanent addresses before
        forming pairs. This is consistent with the default policy described in
        <xref target="RFC6724"></xref>.</t>
      </section>

      <section anchor="s-qos"
               title="Usage of Quality of Service - DSCP and Multiplexing">
        <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>

        <t>There exist a number of schemes for achieving quality of service
        that do not depend solely on DSCP code points. Some of these schemes
        depend on classifying the traffic into flows based on 5-tuple (source
        address, source port, protocol, destination address, destination port)
        or 6-tuple (same as above + DSCP code point). Under differing
        conditions, it may therefore make sense for a sending application to
        choose any of the configurations:</t>

        <t><list style="symbols">
            <t>Each media stream carried on its own 5-tuple</t>

            <t>Media streams grouped by media type into 5-tuples (such as
            carrying all audio on one 5-tuple)</t>

            <t>All media sent over a single 5-tuple, with or without
            differentiation into 6-tuples based on DSCP code points</t>
          </list>In each of the configurations mentioned, data channels may be
        carried in its own 5-tuple, or multiplexed together with one of the
        media flows.</t>

        <t>More complex configurations, such as sending a high priority video
        stream on one 5-tuple and sending all other video streams multiplexed
        together over another 5-tuple, can also be envisioned.</t>

        <t>A sending implementation MUST be able to multiplex all media and
        data on a single 5-tuple (fully bundled), MUST be able to send each
        media stream and data on their own 5-tuple (fully unbundled), and MAY
        choose to support other configurations.</t>

        <t>NOTE IN DRAFT: is there a need to place the "group by media type,
        with data multiplexed on the video" as a MUST or SHOULD
        configuration?</t>

        <t>A receiving implementation MUST be able to receive media and data
        in all these configurations.</t>
      </section>

      <section anchor="s-middlebox" 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>Configuration of STUN and TURN servers, both from browser
        configuration and from an applicaiton, 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 over TCP 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> MAY be
        supported.</t>

        <t>However, such candidates are not seen as providing any significant
        benefit. First, use of TURN TCP would only be relevant in cases which
        both peers are required to use TCP to establish a PeerConnection.
        Secondly, that use case is anyway supported by both sides establishing
        UDP relay candidates using TURN over TCP to connect to the relay
        server. Thirdly, using TCP only between the endpoint and its relay may
        result in less issues with TCP in regards to real-time constraints,
        e.g. due to head of line blocking.</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>If TCP connections are used, RTP framing according to <xref
        target="RFC4571"></xref> MUST be used, both for the RTP packets and
        for the DTLS packets used to carry data channels.</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>

        <t>NOTE IN DRAFT: This may be added.</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>. The SCTP extension for
        NDATA, <xref target="I-D.ietf-tsvwg-sctp-ndata"></xref>, MUST be
        supported.</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.4571'?>

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

      <?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.RFC.6724'?>

      <?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'?>

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

      <?rfc include='reference.I-D.reddy-mmusic-ice-happy-eyeballs'?>
    </references>

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

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

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

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

      <?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 title="Changes from -02 to -03">
        <t><list style="symbols">
            <t>Added required support for draft-ietf-tsvwg-sctp-ndata</t>

            <t>Removed discussion of multiplexing, since this is present in
            rtp-usage.</t>

            <t>Added RFC 4571 reference for framing RTP packets over TCP.</t>

            <t>Downgraded TURN TCP candidates from SHOULD to MAY, and added
            more language discussing TCP usage.</t>

            <t>Added language on IPv6 temporary addresses.</t>

            <t>Added language describing multiplexing choices.</t>

            <t>Added a separate section detailing what it means when we say
            that an RTCWEB implementation MUST support both IPv4 and IPv6.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>