One document matched: draft-alvestrand-dispatch-rtcweb-datagram-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="exp" docName="draft-alvestrand-dispatch-rtcweb-datagram-01"
     ipr="trust200902">
  <front>
    <title abbrev="webm datagram">A Datagram Transport for the RTC-Web
    profile</title>

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

      <address>
        <postal>
          <street>Kungsbron 2</street>

          <city>Stockholm</city>

          <region></region>

          <code>11122</code>

          <country>Sweden</country>
        </postal>

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

    <date day="15" month="February" year="2011" />

    <abstract>
      <t>This document describes a combination and profiling of existing IETF
      protocols to provide a datagram service that is suitable as a generic
      transport substrate for the RTC-Web family of real-time audio/video
      applications.</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>When transporting audio / video and other realtime data between
      participants on the current Internet, there are a number of obstacles to
      be faced.</t>

      <t>Among them are NAT boxes, firewalls, connection interruptions, the
      availability of multiple paths between participants, and capacity
      issues.</t>

      <t>This memo describes a combination of existing protocols that can be
      used to achieve a seamless datagram transport service across this very
      heterogenous environment.</t>

      <t>An overview of the effort of which this is a part can be found in the
      overview document, <xref target="overview"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>This draft uses a couple of commonly used terms in quite specific
      ways. The reader is advised to study these definitions carefully.</t>

      <t>(TODO: Agree on terminology to use)</t>

      <t><list style="hanging">
          <t hangText="Session">An association with two endpoints, between
          which datagrams flow.</t>

          <t hangText="Datagram">A sequence of octets, of a given length. In
          this specification, a datagram does not carry addressing
          information.</t>

          <t hangText="Channel">One means of transporting a datagram over a
          session. A session may have multiple channels at any time.
          <Question: Should this word be replaced by "transport", for more
          consistency with ICE?></t>

          <t hangText="Endpoint">One end of a session. This document does not
          distinguish between an initiator and a responder endpoint.</t>

          <t hangText="Control channel">A means of communication between the
          endpoints of a session that does not require a transport to be
          active. Typically, authentication, authorization and negotiation is
          carried out over the control channel. The specification of the
          control channel is out of scope for this specification.</t>
        </list></t>
    </section>

    <section title="Service model">
      <t>The basic model presented is a datagram model. On top of this one can
      layer various services, such as pseudoTCP (REF), RTP<xref
      target="RFC3550"></xref> or any other higher layer protocol that is
      capable of running across a datagram service. (If a TCP connection can
      be established between the parties, this is usually the preferred option
      for reliable, sequenced transfer. The use of this datagram service for
      reliable transfer should be considered an option available for the case
      where only UDP connectivity is available.)</t>

      <t>The addressing model departs from the traditional Internet model in
      that end point addresses are not used for endpoint identification, only
      for channel establisment; instead, an initial packet exchange, using ICE
      <xref target="RFC5245"></xref>, is used to bind a channel to a
      prenegotiated session.</t>

      <t>The datagram service is not completely transparent; in particular, it
      is not possible to carry a datagram where the two highest bits of the
      first octet are zero and octet 5 to 8 contain the value 0x2112A442,
      since these datagrams are reserved for use of the STUN protocol (RFC
      5389 section 6).</t>
    </section>

    <section title="Channel types">
      <t></t>

      <section title="UDP channel">
        <t>An UDP channel is negotiated using ICE. Each datagram is simply
        carried as the content of an UDP packet.</t>
      </section>

      <section title="TCP channel">
        <t>A TCP channel consists of a TCP connection, over which are sent
        datagrams packaged according to RFC 4571 <xref
        target="RFC4571"></xref>. The binding of a TCP channel is done by
        executing an ICE negotiation over the first few packets passed across
        the TCP channel, as specified in ICE-TCP <xref
        target="I-D.ietf-mmusic-ice-tcp"></xref></t>
      </section>

      <section title="TLS channel">
        <t>A TLS channel consists of a standard TLS negotiation, followed by
        passing datagrams over the TLS record layer<xref
        target="RFC5246"></xref> section 6.2. There is no extra length field.
        A TLS channel is bound to its session by <insert process
        description>.</t>
      </section>

      <section title="DTLS channel">
        <t>A DTLS channel is created by executing a DTLS <xref
        target="RFC5238"></xref> connection negotiation, followed by datagram
        exchange, where the datagrams are protected by DTLS mechanisms. The
        DTLS channel is bound to its session by <insert process>.</t>
      </section>

      <section title="WebSockets channel">
        <t>A WebSockets channel uses the WebSockets protocol<xref
        target="I-D.ietf-hybi-thewebsocketprotocol"></xref> to pass datagrams
        as binary packets.</t>
      </section>

      <section title="Channels with relay">
        <t>If there is no possibility of setting up a direct connection, a
        relay must be used. When both parties are reachable using UDP
        candidates, the specification from TURN <xref
        target="RFC5766"></xref>is used. <NOTE - more text needed here - in
        particular because for TLS and WebSockets channels, TURN does not
        apply.></t>
      </section>
    </section>

    <section title="Channel setup, teardown and usage">
      <t>The service model envisioned here is that all datagrams arriving on a
      session are considered equally valid. The session gives no guarantees
      against duplication, loss or reordering; such concerns are left to the
      higher protocol layers.</t>

      <t>The expected normal usage is that two endpoints will exchange
      addressing information that can be used for a series of potential
      channels, that the endpoints will probe for working channels using ICE
      (RFC 5245), and use the "best" candidate, while using the STUN probing
      facilities to keep some number of "second best" candidates alive if the
      "best" candidate stops working.</t>

      <t>A data-sending endpoint may unilaterally decide to start or stop
      using an established channel at any time. No negotiation is
      necessary.</t>

      <t>A receiving endpoint will learn that a channel has been removed by
      not seeing any more STUN keepalive messages on that channel within
      <timeout>.</t>

      <t>A session is considered closed when all channels that have been
      successfully established have timed out.</t>
    </section>

    <section title="An URI scheme for datagram channels">
      <t>This URI scheme is mainly included in order to make it easy for APIs
      that normally use URIs as what they use to refer to objects. It reflects
      exactly the information found in the SDP attributes defined in RFC 5245
      section 15.</t>

      <t><NOTE IN DRAFT: This may be replaced with a JSON representation,
      an XML representation or the SDP representation in later drafts, if the
      WG so decides.></t>

      <t>The DGSESSION URI scheme specifies the information required for a
      session; it consists of two parts:</t>

      <t><list style="symbols">
          <t>An absolute reference, which includes the user name and password
          used to establish channels over this connection.</t>

          <t>A series of addressing hints, which include the data necessary to
          establish a channel.</t>
        </list><TODO: Fill out an URI registration template for the
      scheme></t>

      <t>Example:</t>

      <t>dgsession:username:password?ipv4:12.34.56:udp:12345&ipv6:2002::dead:beef:tcp:80&ipv4:12.34.56.78:tls:443</t>

      <t>The sequence of addressing hints is an indication of the preference
      of the URL constructor for the sequence in which to try these
      candidates; the most preferred address is the one to the left.</t>

      <t>Note that a DGSESSION URI is a capability; anyone with the URI will
      be able to connect to the entity. They should therefore be handled in
      the same way as (short-term) passwords, and never passed in the
      clear.</t>

      <section title="new section">
        <t></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t anchor="uridef">This document registers the URI scheme from section
      <xref target="uridef"></xref>.</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>As with all layered protocols, it is a matter for the application to
      decide which level security should be provided at. For instance, an RTP
      session protected using SRTP <ref> can be considered to not need
      any further safeguards against interception, modification or replay, so
      can be passed "in the clear" across any channel type here. For data
      without such protection, adequate measures need to be taken; in
      particular, it is trivially easy for someone with the ability to snoop
      and insert packets to insert fake packets into an established UDP
      channel.</t>

      <t>The main defense against denial-of-service attacks is the fact that
      the ICE mechanisms were designed for low cost refusal of unauthorized
      connections.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Markus Isomaki for reviewing version -00.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-mmusic-ice-tcp'?>

      <?rfc include='reference.I-D.ietf-hybi-thewebsocketprotocol'?>
    </references>

    <references title="Informative References">
      <reference anchor="overview">
        <front>
          <title>Overview: Real Time Protocols for Brower-based
          Applications</title>

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

          <date day="9" month="November" year="2010" />
        </front>
      </reference>

      <?rfc ?>
    </references>

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

      <t></t>

      <section title="Changes from alvestrand-00 to alvestrand-01">
        <t>Added the WebSockets channel option. Made some changes and
        clarifications, mainly based on Markus Isomaki's review. Pointed out
        that the DGSESSION URI scheme has to represent exactly the semantics
        of the SDP extensions for ICE.</t>

        <t></t>
      </section>
    </section>
  </back>
</rfc>