One document matched: draft-ietf-rtcweb-transports-01.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-01"
     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="3" month="September" year="2013" />

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

    <note 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>
    </note>
  </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>
    </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>For both protocols, 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.ietf-rtcweb-qos"></xref>. 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>If DSCP code points can only be set on a per-socket basis, not
        per-packet, one loses the ability to have the network discriminate
        reliably between classes of traffic sent over the same transport, but
        this does not prevent communication.</t>

        <t>This specification does not assume that the implementation will
        have access to ICMP or raw IP.</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>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.</t>

        <t>ICE TCP candidates <xref target="RFC6062"></xref> MAY be supported;
        this may allow applications to achieve peer-to-peer communication
        across UDP-blocking firewalls, but this also requires use of the
        SRTP/AVPF/TCP profile of RTP.</t>

        <t>The following specifications MUST be supported:</t>

        <t><list style="symbols">
            <t>ICE <xref target="RFC5245"></xref></t>

            <t>TURN, including TURN over TCP<xref
            target="RFC5766"></xref>.</t>
          </list></t>

        <t>TURN over TLS over TCP MAY be supported. (QUESTION: SHOULD?
        MUST?)</t>

        <t>For referring to STUN and TURN servers, this specification depends
        on the STUN URI, <xref
        target="I-D.nandakumar-rtcweb-stun-uri"></xref>.</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 data transport over the RTCWEB data channel <xref
        target="I-D.ietf-rtcweb-data-channel"></xref>, RTCWEB implementations
        support SCTP over DTLS over ICE. This is specified in <xref
        target="I-D.ietf-tsvwg-sctp-dtls-encaps"></xref>. Negotiation of this
        transport in SCTP 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>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>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. Further separation of
        the DTLS traffic into SCTP and "other" is described in <need
        reference>.</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>
    </section>
  </middle>

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

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

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

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

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

      <?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.ietf-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.nandakumar-rtcweb-stun-uri'?>
    </references>

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

      <?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>
  </back>
</rfc>