draft-tuexen-tsvwg-sctp-dtls-req.xml

<?xml version='1.0' encoding='utf-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>

<rfc docName="draft-tuexen-tsvwg-sctp-dtls-req-latest"
     xmlns:xi="http://www.w3.org/2001/XInclude"
     xml:lang="en"
     ipr="trust200902"
     submissionType="IETF"
     consensus="true"
     category="info"
     version="3">

<front>
<title abbrev='SCTP-DTLS Requirements'>
Requirements for Securing SCTP Traffic using DTLS
</title>
<seriesInfo name="Internet-Draft"
            value="draft-tuexen-tsvwg-sctp-dtls-req-01-to-be"/>

<author initials="M." surname="Tüxen" fullname="Michael Tüxen" role="editor">
  <organization abbrev='Münster Univ. of Appl. Sciences'>
                Münster University of Applied Sciences</organization>
  <address>
    <postal>
        <street>Stegerwaldstrasse 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>tuexen@fh-muenster.de</email>
  </address>
</author>


<date />

<abstract>
<t>The current specification of DTLS over SCTP is outdated and does not
fulfill the requirements of 3GPP.
This Internet Draft documents the requirements of 3GPP for securing SCTP based
communications using DTLS.
It is a result of a design team in TSVWG and reflects the current of its work.
Therefore, this document is expected to change over time.</t>
</abstract>
</front>

<middle>

<section>
<name>Introduction</name>
<t>This document reflects the current status of a design team in TSVWG working
on the requirements of securing SCTP based traffic using DTLS.</t>
<t>The following people were participating the design team:
<contact fullname="Marcelo Ricardo Leitner"/>,
<contact fullname="Xin Long"/>,
<contact fullname="John Mattsson"/>,
<contact fullname="Claudio Porfiri"/>,
<contact fullname="Tirumaleswar Reddy.K"/>,
<contact fullname="Zahed Sarker"/>,
<contact fullname="Hannes Tschofenig"/>,
<contact fullname="Michael Tüxen"/>, and
<contact fullname="Magnus Westerlund"/>.</t>
</section>

<section>
<name>Functional Requirements for SCTP</name>
<ul>
<li><t>An SCTP implementation must support at least two streams used for
reliable and in-sequence delivery.</t></li>
<li><t>Message size of at least 1 GB must be supported.
It is known that currently user message size of 0.5 MB are in use.
Liaison statement from 3GPP RAN3 <xref target="LS-RAN3"/> stated
"RAN3 would like to confirm our previous LS: we do not expect to limit the
maximum message size of application protocols. For this reason, any solution
with a limit on message size will not meet RAN3 requirements."</t></li>
<li><t>Multihoming must be supported.
However, support or dynamic address reconfiguration as specified in
<xref target="RFC5061"/> is not required.</t></li>
<li><t>The restart procedure must be supported.</t></li>
<li><t>Protocol mechanisms should not limit the availability of the
communication (like the draining procedure in <xref target="RFC6083"/>).</t></li>
</ul>
</section>

<section>
<name>Implementation Considerations for SCTP</name>
<ul>
<li><t>User message sizes must not be limited by an protocol implementation
(for example the size of send or receive buffers).</t></li>
<li><t>For some it is preferred to be able to use open source kernel SCTP
implementations.</t></li>
</ul>
</section>

<section>
<name>Security Requirements</name>
<ul>
<li><t>Mutual authentication must be used with periodic re-authentication
allowing a certificate update.</t></li>
<li><t>It must the possible to run DH once per hour or every 100GB.</t></li>
<li><t>Privacy and integrity is required for user data.</t></li>
<li><t>An on-path attacker being able to drop packets might be able to drop
the association.</t></li>
<li><t>An on-path attacker being able to replay messages, insert messages,
or modify messages must not be able to affect the availability of the
association or change user data.</t></li>
<li><t>In particular, the SCTP restart procedure must not allow to take over
an SCTP association by an attacker.</t></li>
</ul>
</section>

<section>
<name>Implementation Considerations for DTLS</name>
<ul>
<li><t>Focus on DTLS 1.3 only.</t></li>
<li><t>For some it is preferred to use unmodified DTLS implementations.</t></li>
</ul>
</section>

<section>
<name>IANA Considerations</name>
<t>No actions from IANA required.</t>
</section>

<section>
<name>Security Considerations</name>
<t>TBD.</t>
</section>

</middle>

<back>
<references>
<name>References</name>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5061.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6083.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>
<reference anchor="LS-RAN3">
    <front>
      <title>Liaison statement: Reply LS on DTLS for SCTP next steps and request for input</title>
      <author fullname="3GPP RAN3"/>
      <date year="2023" month="Aug"/>
    </front>
    <refcontent>https://datatracker.ietf.org/liaison/1858/</refcontent>
  </reference>
</references>

</references>

</back>
</rfc>