One document matched: draft-petithuguenin-p2psip-reload-sctp-00.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc rfcedstyle="no" ?>
<rfc ipr="noModificationTrust200902" docName="draft-petithuguenin-p2psip-reload-sctp-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="RELOAD SCTP">SCTP Overlay link for REsource LOcation And Discovery (RELOAD)</title>
    <author initials="M." surname="Petit-Huguenin" fullname="Marc Petit-Huguenin">
      <organization>Impedance Mismatch</organization>
      <address>
        <email>petithug@acm.org</email>
      </address>
    </author>
    <date day="17" month="February" year="2013"/>
    <abstract>
      <t>This document defines two new Overlay Link protocols to be used with REsource LOcation And Discovery (RELOAD), both using SCTP.  The Overlay Link protocol DTLS-SCTP-NO-ICE uses DTLS on top of native SCTP for overlays that do not require the use of ICE.  The Overlay Link protocol DTLS-SCTP-UDP uses DTLS on top of an UDP encapsulation of SCTP for overlays that require the use of ICE.  </t>
    </abstract>
  </front>
  <middle>
    <section anchor="section.introduction" title="Introduction" toc="default">
      <t><xref target="I-D.ietf-p2psip-base" pageno="false" format="default">RELOAD</xref> defines 3 Overlay Link protocols, DTLS-UDP-SR, TLS-TCP-FH-NO-ICE and DTLS-UDP-SR-NO-ICE but none of them prevents Head of Line (HoL) blocking.  <xref target="RFC6083" pageno="false" format="default">DTLS for SCTP</xref>, is a good candidate as Overlay Link protocol, but because most NATs cannot handle <xref target="RFC4960" pageno="false" format="default">SCTP</xref>, it can only been used with overlays that are known to not have nodes behind a NAT.  For overlays that may have nodes behind a NAT, a <xref target="I-D.ietf-tsvwg-sctp-udp-encaps" pageno="false" format="default">UDP encapsulation of SCTP</xref> is used in place of the native SCTP, so it can traverses NAT Additionnaly using a UDP encapsulation does not require to define how using SCTP in ICE.  </t>
    </section>
    <section anchor="section.terminology" title="Terminology" toc="default">
      <t>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default"/>.</t>
    </section>
    <section anchor="section.dtls-sctp-no-ice" title="DTLS-SCTP-NO-ICE Overlay Link Protocol" toc="default">
      <t>This overlay link protocol consists of DTLS over SCTP, as specified in <xref target="RFC6083" pageno="false" format="default"/>.  The RELOAD messages MUST be sent on a stream other than 0 (which is reserved for the DTLS ChangeCipherSpec, Alert and Handshake protocols), with unlimited reliability but without the ordered delivery feature.  </t>
      <t>The Framing Header or the Simple Reliability protocols described in RELOAD MUST NOT be used.</t>
    </section>
    <section anchor="section.dtls-sctp-udp" title="DTLS-SCTP-UDP Overlay Link Protocol" toc="default">
      <t>This overlay link protocol consists of DTLS over an UDP encapsulation of SCTP, as specified in <xref target="RFC6083" pageno="false" format="default"/> and <xref target="I-D.ietf-tsvwg-sctp-udp-encaps" pageno="false" format="default"/>.  The RELOAD messages MUST be sent on a stream other than 0 (which is reserved for the DTLS ChangeCipherSpec, Alert and Handshake protocols), with unlimited reliability but without the ordered delivery feature.  </t>
      <t>The Framing Header or the Simple Reliability protocols described in RELOAD MUST NOT be used.</t>
    </section>
    <section anchor="section.security" title="Security Considerations" toc="default">
      <t>TBD.</t>
    </section>
    <section anchor="section.iana" title="IANA Considerations" toc="default">
      <t>If this document is accepted as a standard track document this section will request that IANA assign codes for the DTLS-SCTP-NO-ICE and DTLS-SCTP-UDP overlay protocols.  Until this is done, implementions should use code 5 (reserved for experimentations as EXP-LINK).  Using the same code is not an issue in this case as ICE and NO-ICE Overlays Protocols cannot be be simultaneously used in the same overlay.  </t>
      <t>[[Do we need to also assign a PPID?]]</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <reference anchor="RFC2119"><front><title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="Scott Bradner"><organization>Harvard University</organization> <address><postal><street>1350 Mass. Ave.</street> <street>Cambridge</street> <street>MA 02138</street></postal> <phone>- +1 617 495 3864</phone> <email>sob@harvard.edu</email></address></author> <date year="1997" month="March"/> <area>General</area> <keyword>keyword</keyword> <abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list><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 RFC 2119.  </t></list></t> <t>Note that the force of these words is modified by the requirement level of the document in which they are used.  </t></abstract></front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/> <format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/> <format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/> </reference>
      <?rfc include="reference.RFC.4960" ?>
      <reference anchor="RFC4960"><front><title>Stream Control Transmission Protocol</title> <author initials="R." surname="Stewart" fullname="R. Stewart"><organization/></author> <date year="2007" month="September"/> <abstract><t>This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t><t> SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:</t><t> -- acknowledged error-free non-duplicated transfer of user data,</t><t> -- data fragmentation to conform to discovered path MTU size,</t><t> -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t><t> -- optional bundling of multiple user messages into a single SCTP packet, and</t><t> -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t><t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]</t></abstract></front> <seriesInfo name="RFC" value="4960"/> <format type="TXT" octets="346022" target="http://www.rfc-editor.org/rfc/rfc4960.txt"/> </reference>
      <?rfc include="reference.RFC.6083" ?>
      <reference anchor="RFC6083"><front><title>Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)</title> <author initials="M." surname="Tuexen" fullname="M. Tuexen"><organization/></author> <author initials="R." surname="Seggelmann" fullname="R. Seggelmann"><organization/></author> <author initials="E." surname="Rescorla" fullname="E. Rescorla"><organization/></author> <date year="2011" month="January"/> <abstract><t>This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).</t><t> DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.</t><t> Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]</t></abstract></front> <seriesInfo name="RFC" value="6083"/> <format type="TXT" octets="16674" target="http://www.rfc-editor.org/rfc/rfc6083.txt"/> </reference>
      <?rfc include="reference.I-D.ietf-p2psip-base" ?>
      <reference anchor="I-D.ietf-p2psip-base"><front><title>REsource LOcation And Discovery (RELOAD) Base Protocol</title> <author initials="C" surname="Jennings" fullname="Cullen Jennings"><organization/> </author> <author initials="B" surname="Lowekamp" fullname="Bruce Lowekamp"><organization/> </author> <author initials="E" surname="Rescorla" fullname="Eric Rescorla"><organization/> </author> <author initials="S" surname="Baset" fullname="Salman Baset"><organization/> </author> <author initials="H" surname="Schulzrinne" fullname="Henning Schulzrinne"><organization/> </author> <date month="January" day="19" year="2013"/> <abstract><t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network.  RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that needs to be stored for a particular application.  RELOAD defines a security model based on a certificate enrollment service that provides unique identities.  NAT traversal is a fundamental service of the protocol.  RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t></abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-24"/> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-24.txt"/> </reference>
      <?rfc include="reference.I-D.ietf-tsvwg-sctp-udp-encaps" ?>
      <reference anchor="I-D.ietf-tsvwg-sctp-udp-encaps"><front><title>UDP Encapsulation of SCTP Packets</title> <author initials="M" surname="Tuexen" fullname="Michael Tuexen"><organization/> </author> <author initials="R" surname="Stewart" fullname="Randall Stewart"><organization/> </author> <date month="January" day="22" year="2013"/> <abstract><t>This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations.  This allows the usage of SCTP in networks with legacy NAT not supporting SCTP.  It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges.</t></abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-sctp-udp-encaps-09"/> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-09.txt"/> </reference>
    </references>
  </back>
</rfc>