Skip to main content

Liaison statement
LS on DTLS for SCTP Progress Report

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2025-11-11
From Group tsvwg
From Contact Charles Eckel <eckelcu@cisco.com>
To Groups 3GPP-TSG-RAN-WG3, 3GPP-TSG-SA-WG3
To Contacts 3GPP Liaisons Coordinator <3GPPLiaison@etsi.org>
Peter Schmitt <Peter.Schmitt@huawei.com>
Cc Mike Bishop <mbishop@evequefou.be>
Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Charles Eckel <eckelcu@cisco.com>
Transport and Services Working Group Discussion List <tsvwg@ietf.org>
Martin Duke <martin.h.duke@gmail.com>
Response Contact Martin Duke <martin.h.duke@gmail.com>
Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Purpose For information
Attachments LS on DTLS for SCTP Progress Report
Liaisons referred by this one Reply LS on DTLS for SCTP
Reply LS on DTLS for SCTP next steps and request for input
Body
1. Description

IETF’s Transport Working Group (TSVWG) would like to inform 3GPP’s RAN3 and SA3
WGs about its progress on defining a DTLS based security solution for SCTP that
has occurred since the previous exchange of liaison statements [1,2,3].

TSVWG has now adopted two new WG items to provide a technical solution to
address the maximum message size issue with SCTP and DTLS as observed in [2].
The complete solution consists of two separate components.

The first component, which is the core of the complete solution, is called the
DTLS Chunk. This component specifies how an SCTP endpoint initiates the
negotiation using SCTP parameters and protects its packets using DTLS records
using key-contexts that have been provisioned using an API to the SCTP stack.
This protects the content of each SCTP packet in its own DTLS record. This
results in all application messages as well as SCTP control chunks being
encrypted and authenticated. It also ensures that there is no limit on
application message sizes as they are fragmented by the regular SCTP mechanism,
thereby supporting unlimited message size. This component is defined in the
TSVWG adopted internet draft “Stream Control Transmission Protocol (SCTP) DTLS
Chunk” [4]. The draft also defines certain requirements on key-management to
prevent down-grade attacks.

The second component of the complete solution is a key-management specification
that can provision the DTLS chunk (i.e., the first component) with keys. Such a
key-management is defined as functionality on top of the SCTP association,
using an API defined in the DTLS chunk [4] to provision keys to secure the
communication. TSVWG has adopted an Internet draft defining such a
key-management titled: “Using Datagram Transport Layer Security (DTLS) for Key
Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk” [5].
This key-management is dependent on new TLS 1.3 [6] functionality - the
extended key-update [7] being defined by the TLS WG. It will support long lived
sessions through ephemeral rekeying ensuring forward secrecy and also supports
SCTP Association restart.

Splitting the solution into two components (i.e., the DTLS chunk and the
key-management) allows for alternative key-management to be specified if
desired to achieve certain properties. There exists an individual internet
draft detailing an alternative key-management [8], which can be seen as a proof
that this divided concept works.

TSVWG aims to have the DTLS chunk, the first component, published as RFC before
the end of 2026. The WG key-management specification [5], the second component,
has dependency on the TLS extended key-update mechanism [7], hence work needs
to be done in both TSVWG and TLS working groups.

TSVWG would like to inform 3GPP RAN3, following their previous observations in
[2], that this technical solution does not limit the maximum size of
application protocol messages.

TSVWG plans to inform 3GPP RAN3 and SA3 when each of the components have been
requested to be published. TSVWG welcomes any feedback on its work items.

2. Upcoming Meeting

IETF 125 14-20 March 2026, Shenzhen, China
IETF 126 18-24 July 2026, Vienna, Austria

3. References

[1] TSVWG LS to RAN3 and SA3: DTLS for SCTP next steps and request for input,
https://datatracker.ietf.org/liaison/1851/

[2] R3-234497 - Reply LS on DTLS for SCTP next steps and request for input,
https://datatracker.ietf.org/liaison/1858/

[3] S3-234160 - Reply LS on DTLS for SCTP,
https://datatracker.ietf.org/liaison/1854/

[4] Stream Control Transmission Protocol (SCTP) DTLS Chunk,
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/

[5] Using Datagram Transport Layer Security (DTLS) for Key Management for the
Stream Control Transmission Protocol (SCTP) DTLS Chunk,
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-chunk-key-management/

[6] The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, Aug
2018, https://datatracker.ietf.org/doc/rfc8446/

[7] Extended Key Update for Transport Layer Security (TLS) 1.3,
https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/

[8] Datagram Transport Layer Security (DTLS) based key-management of the Stream
Control Transmission Protocol (SCTP) DTLS Chunk,
https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/