Requirements for Securing SCTP Traffic using DTLS Münster University of Applied Sciences
Stegerwaldstrasse 39 48565 Steinfurt Germany tuexen@fh-muenster.de
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.
Introduction This document reflects the current status of a design team in TSVWG working on the requirements of securing SCTP based traffic using DTLS. The following people were participating the design team: , , , , , , and .
Functional Requirements for SCTP
  • An SCTP implementation must support at least two streams used for reliable and in-sequence delivery.
  • 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 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."
  • Multihoming must be supported. However, support or dynamic address reconfiguration as specified in is not required.
  • The restart procedure must be supported.
  • Protocol mechanisms should not limit the availability of the communication (like the draining procedure in ).
Implementation Considerations for SCTP
  • User message sizes must not be limited by an protocol implementation (for example the size of send or receive buffers).
  • For some it is preferred to be able to use open source kernel SCTP implementations.
Security Requirements
  • Mutual authentication must be used with periodic re-authentication allowing a certificate update.
  • It must the possible to run DH once per hour or every 100GB.
  • Privacy and integrity is required for user data.
  • An on-path attacker being able to drop packets might be able to drop the association.
  • 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.
  • In particular, the SCTP restart procedure must not allow to take over an SCTP association by an attacker.
Implementation Considerations for DTLS
  • Focus on DTLS 1.3 only.
  • For some it is preferred to use unmodified DTLS implementations.
IANA Considerations No actions from IANA required.
Security Considerations TBD.
References Informative References Liaison statement: Reply LS on DTLS for SCTP next steps and request for input https://datatracker.ietf.org/liaison/1858/