Stream Control Transmission Protocol (SCTP) DTLS Chunk
draft-ietf-tsvwg-sctp-dtls-chunk-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Magnus Westerlund , John Preuß Mattsson , Claudio Porfiri , Michael Tüxen | ||
| Last updated | 2025-10-20 (Latest revision 2025-08-27) | ||
| Replaces | draft-westerlund-tsvwg-sctp-dtls-chunk | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-tsvwg-sctp-dtls-chunk-01
TSVWG M. Westerlund
Internet-Draft J. Preuß Mattsson
Intended status: Standards Track C. Porfiri
Expires: 23 April 2026 Ericsson
M. Tüxen
Münster Univ. of Appl. Sciences
20 October 2025
Stream Control Transmission Protocol (SCTP) DTLS Chunk
draft-ietf-tsvwg-sctp-dtls-chunk-01
Abstract
This document describes a method for adding Cryptographic protection
to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS
chunk defined in this document is intended to enable communications
privacy for applications that use SCTP as their transport protocol
and allows applications to communicate in a way that is designed to
prevent eavesdropping and detect tampering or message forgery.
Applications using SCTP DTLS chunk can use all transport features
provided by SCTP and its extensions but with some limitations.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/.
Discussion of this document takes place on the Transport Area Working
Group (tsvwg) Working Group mailing list (mailto:tsvwg@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/tsvwg/.
Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.
Source for this draft and an issue tracker can be found at
https://github.com/gloinul/draft-westerlund-tsvwg-sctp-DTLS-chunk.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Westerlund, et al. Expires 23 April 2026 [Page 1]
Internet-Draft SCTP DTLS Chunk October 2025
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
3.2. DTLS Considerations . . . . . . . . . . . . . . . . . . . 6
3.3. Considerations about SCTP Protection Solutions . . . . . 8
3.4. SCTP DTLS Chunk Buffering and Flow Control . . . . . . . 8
3.5. PMTU Considerations . . . . . . . . . . . . . . . . . . . 8
3.6. Congestion Control Considerations . . . . . . . . . . . . 9
3.7. Dynamic Address Reconfiguration Considerations . . . . . 9
3.8. SCTP Restart Considerations . . . . . . . . . . . . . . . 10
3.8.1. Protected SCTP Restart . . . . . . . . . . . . . . . 10
3.8.2. Compatibility with Legacy SCTP Restart . . . . . . . 12
4. New Parameter Type . . . . . . . . . . . . . . . . . . . . . 13
4.1. DTLS 1.3 Chunk Protected Association . . . . . . . . . . 13
5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. DTLS Chunk (DTLS) . . . . . . . . . . . . . . . . . . . . 15
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. DTLS 1.3 Chunk Protected Association Parameter Missing . 16
6.2. Error in DTLS Chunk . . . . . . . . . . . . . . . . . . . 17
6.2.1. No Common Protection Solution . . . . . . . . . . . . 18
6.3. Critical Error from DTLS . . . . . . . . . . . . . . . . 18
6.4. Non-critical Error in the Protection . . . . . . . . . . 18
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Establishment of a Protected Association . . . . . . . . 18
Westerlund, et al. Expires 23 April 2026 [Page 2]
Internet-Draft SCTP DTLS Chunk October 2025
7.1.1. Offering Multiple Security Solutions . . . . . . . . 19
7.2. Termination of a Protected Association . . . . . . . . . 20
7.3. Considerations on Key Management . . . . . . . . . . . . 20
8. DTLS Chunk Handling . . . . . . . . . . . . . . . . . . . . . 20
8.1. Sending of DTLS Chunks . . . . . . . . . . . . . . . . . 21
8.2. Receiving of DTLS Chunks . . . . . . . . . . . . . . . . 22
9. Abstract API . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Cipher Suit Capabilities . . . . . . . . . . . . . . . . 22
9.2. Establish Client Write Keying Material . . . . . . . . . 23
9.3. Establish Server Write Keying Material . . . . . . . . . 23
9.4. Destroy Client Write Keying Material . . . . . . . . . . 24
9.5. Destroy Server Write Keying Material . . . . . . . . . . 25
9.6. Set Key to Use . . . . . . . . . . . . . . . . . . . . . 25
9.7. Require Protected SCTP Packets . . . . . . . . . . . . . 26
9.8. Get AEAD Encryption Invocations . . . . . . . . . . . . . 26
9.9. Get AEAD Decryption Invocations . . . . . . . . . . . . . 26
9.10. Get Failed AEAD Decryption Invocations . . . . . . . . . 27
9.11. Configure Replay Protection . . . . . . . . . . . . . . . 27
10. Socket API Considerations . . . . . . . . . . . . . . . . . . 28
10.1. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 28
10.2. A New Flag for recvmsg() (MSG_PROTECTED) . . . . . . . . 28
10.3. Functions . . . . . . . . . . . . . . . . . . . . . . . 28
10.3.1. sctp_dtls_nr_cipher_suits() . . . . . . . . . . . . 28
10.3.2. sctp_dtls_cipher_suits() . . . . . . . . . . . . . . 29
10.4. Socket Options . . . . . . . . . . . . . . . . . . . . . 29
10.4.1. Get or Set the Local Protection Method Identifiers
(SCTP_DTLS_LOCAL_PMIDS) . . . . . . . . . . . . . . . 31
10.4.2. Get the Remote Protection Method Identifiers
(SCTP_DTLS_REMOTE_PMIDS) . . . . . . . . . . . . . . 31
10.4.3. Set Send Keys (SCTP_DTLS_SET_SEND_KEYS) . . . . . . 32
10.4.4. Add Receive Keys (SCTP_DTLS_ADD_RECV_KEYS) . . . . . 33
10.4.5. Delete Receive Keys (SCTP_DTLS_DEL_RECV_KEYS) . . . 35
10.4.6. Set or Get Protection Enforcement
(SCTP_DTLS_ENFORCE_PROTECTION) . . . . . . . . . . . 36
10.4.7. Get Statistic Counters (SCTP_DTLS_STATS) . . . . . . 36
10.4.8. Get or Set the Replay Protection Window Size
(SCTP_DTLS_REPLAY_WINDOW) . . . . . . . . . . . . . . 37
11. Implementation Considerations . . . . . . . . . . . . . . . . 37
11.1. Privacy Padding of SCTP Packets . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. SCTP Protection Solution Identifiers . . . . . . . . . . 38
12.2. SCTP Chunk Type . . . . . . . . . . . . . . . . . . . . 39
12.3. SCTP Chunk Parameter Types . . . . . . . . . . . . . . . 40
12.4. SCTP Error Cause Codes . . . . . . . . . . . . . . . . . 40
12.5. SCTP Payload Protocol Identifier . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
13.1. Privacy Considerations . . . . . . . . . . . . . . . . . 41
13.2. AEAD Limit Considerations . . . . . . . . . . . . . . . 42
Westerlund, et al. Expires 23 April 2026 [Page 3]
Internet-Draft SCTP DTLS Chunk October 2025
13.3. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 42
13.4. Persistent Secure Storage of Restart Key Context . . . . 42
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. Normative References . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
This document defines a DTLS chunk for the Stream Control
Transmission Protocol (SCTP), as defined in [RFC9260].
This specification defines the actual DTLS chunk, how to enable its
usage, how it interacts with the SCTP association establishment to
enable endpoint authentication, key-establishment, and key updates.
The DTLS chunk is designed to enable mutual authentication of
endpoints, data confidentiality, data origin authentication, data
integrity protection, and data replay protection for SCTP packets
after the SCTP association has been established. It is dependent on
a key management function that is defined separately to achieve all
these capabilities. The key management function uses an API to
provision the SCTP association's DTLS chunk protection with key-
material to enable and rekey the protection operations.
Applications using SCTP DTLS chunk can use most transport features
provided by SCTP and its extensions. However, there can be some
limitations or additional requirements for them to function such as
those noted for SCTP restart and use of Dynamic Address
Reconfiguration, see Section 3.7 and Section 3.8. Due to its level
of integration as discussed in next section it will provide its
security functions on all content of the SCTP packet, and will thus
not impact the potential to utilize any SCTP functionalities or
extensions that are possible to use between two SCTP peers with full
security and SCTP association state.
DTLS is considered version 1.3 as specified in [RFC9147] whereas
other versions are explicitly not part of this document.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Westerlund, et al. Expires 23 April 2026 [Page 4]
Internet-Draft SCTP DTLS Chunk October 2025
3. Overview
3.1. Protocol Overview
The DTLS chunk can be used for secure and confidential transfer of
SCTP packets. This is implemented inside the SCTP protocol. Once an
SCTP packet has been received and the SCTP common header has been
used to identify the SCTP association, the DTLS chunk is processed by
the Chunk Protection Operator that will perform replay protection,
decrypt, verify authenticity, and if the DTLS chunk is successfully
processed provides the protected SCTP chunks for further processing.
Figure 1 is an example illustrating the DTLS chunk processing in
regard to SCTP and the Upper Layer Protocol (ULP) using DTLS 1.3 for
key management. Here the Key Management function contains
validation, i.e. using certificates, handshaking, updating policies
etc.
+---------------+ +-------------------------------+
| ULP | | DTLS 1.3 |
| | | +---------------------+ |
| | | +->+ Key Exporter +--+ |
| | | | +---------------------+ | |
| | | | | |
| | | | +---------------------+ | |
| | | +--+ Key Management + | |
| | | | +----------+----------+ | |
| | | | | | |
| | | | ContentType | | |
| | | | +----------+----------+ | |
| | | +->| Record | | |
| | | | Protection Operator | | |
+ | | +----------+----------+ | |
+-------+-------+ +-----------------------------+-+
^ ^ |
| | |
+--+-----------------------+ | keys
PPID | |
V V
+-----------------------------------------------+-+
| +---------------------+ | |
| SCTP | Chunk |<---+ |
| | Protection Operator | |
| +---------------------+ |
+-------------------------------------------------+
Figure 1: DTLS Chunk Layering in Regard to SCTP and ULP
Westerlund, et al. Expires 23 April 2026 [Page 5]
Internet-Draft SCTP DTLS Chunk October 2025
In the outgoing direction, once the SCTP stack has created the
unprotected SCTP packet containing control and/or DATA chunks, SCTP
chunks will be processed by the Chunk Protection Operator to be
protected. The result of this computation is a DTLS 1.3 record
encapsulated in a SCTP chunk which is named the DTLS chunk.
The Chunk Protection Operator performs protection operations on all
chunks of an SCTP packet. Information protection is kept during the
lifetime of the association and no information is sent unprotected
except the initial SCTP handshake, any initial key-management
traffic, the SCTP common header, the SCTP DTLS chunk header, and the
INIT and INIT-ACK chunks during an SCTP Restart procedure.
The support of the DTLS chunk and the key-management method to use is
negotiated by the peers at the setup of the SCTP association using a
new parameter. Key management and application traffic is multiplexed
using the PPID. The dedicated PPID 4242 is defined for use by key
management for DTLS chunk. The key management function uses an API
to key the Chunk protection operation function. Usage of the DTLS
1.3 handshake for initial mutual authentication and key establishment
as well as periodic re-authentication and rekeying with Diffe-Hellman
of the DTLS chunk protection is defined in separate documents, (see
Section 3.3). To prevent downgrade attacks of the key-management
negotiation the key-management should implement specific procedures
when deriving keys.
When the endpoint authentication and key establishment has been
completed, the association is considered to be secured and the ULP is
informed about that. From this time on it's possible for the ULPs to
exchange data securely with its peer.
A DTLS chunk will never be retransmitted, retransmission is
implemented by SCTP endpoint at chunk level as specified in
[RFC9260]. DTLS replay protection will be used to suppress
duplicated DTLS chunks.
3.2. DTLS Considerations
The DTLS Chunk architecture splits DTLS 1.3 as shown in Figure 1,
where the Key Management functionality is done at DTLS 1.3 block
level, acting as a parallel User Level Protocol and a Chunk
Protection Operator functionality inside the SCTP Protocol Stack.
Key Management is the set of data and procedures that take care of
key distribution, verification, and update, DTLS connection setup,
update and maintenance.
Westerlund, et al. Expires 23 April 2026 [Page 6]
Internet-Draft SCTP DTLS Chunk October 2025
Chunk Protection Operator functionality is the set of data and
procedures taking care of User Data encryption into DTLS Record and
DTLS record decryption into User Data.
DTLS 1.3 operations requires to directly handshake messages with the
remote peer for connection setup and other features, this kind of
handshake is part of the Key Management functionality. Key
Management function achieves these features behaving as a user of the
SCTP association. Key Management sends and receives its own data via
the SCTP User Level interface. Key Management's own data are
distinguished from any other data by means of a dedicated PPID using
the value 4242 (see Table 9).
Once Key Management has established a DTLS 1.3 connection, it can
derive primary and restart keys and set the Chunk Protection Operator
for SCTP Packet Payload encryption/decryption via an API to create
the necessary DTLS key contexts. Both a DTLS Key context for normal
use (primary) and a DTLS Key context for SCTP association restart
needs to be created.
In this document we use the terms DTLS Key context for indicating a
Key and IV, produced by the key-management, and all relevant data
that needs to be provided to the Chunk Protection Operator for DTLS
encryption and decryption. DTLS Key context includes Keys and IV for
sending and receiving, replay window, last used sequence number.
Each DTLS key context is associated with a four-value tuple
identifying the context, consisting of SCTP Association, the restart
indicator, the DTLS Connection ID (if used), and the DTLS epoch.
Support of DTLS Connection ID in the DTLS Record layer used in the
DTLS Chunk is OPTIONAL, and negotiated using the key-management
function.
The first established DTLS key context for any SCTP association and
DTLS connection ID (if used) SHALL use epoch=3. This ensures that
the epoch of the DTLS key context will normally match the epoch of a
DTLS key-management connection.
The Replay window for the DTLS Sequence Number will need to take into
account that heartbeat (HB) chunks are sent concurrently over all
paths in multihomed Associations, thus it needs to be large enough to
accommodate latency differences.
Westerlund, et al. Expires 23 April 2026 [Page 7]
Internet-Draft SCTP DTLS Chunk October 2025
3.3. Considerations about SCTP Protection Solutions
This document specifies the mechanisms for SCTP to be protected with
DTLS, it doesn't specify how the Key Management works, being limited
on what the Key Management SHALL provide for achieving the
protection. Even though DTLS1.3 is indicated as protocol for
providing Key Contexts, different implementations can achieve that
and different mechanisms may be used for features such as mutual
authentication, rekeying etc. The DTLS Chunk solution may use a
number of Key Management mechanisms depending on what is being
implemented and available and/or according to the local policies.
Key Management methods are called here Protection Solutions, they are
defined in their own specific documents, and needs to be registered
in the IANA Registry "SCTP Protection Solutions" to get their own
unique identifier. This document constitutes a requirement towards
any SCTP Protection Solution.
Currently there are two in-band DTLS key management solutions
defined, they have different properties. See
[I-D.ietf-tsvwg-dtls-chunk-key-management] and
[I-D.westerlund-tsvwg-sctp-DTLS-handshake].
3.4. SCTP DTLS Chunk Buffering and Flow Control
DTLS 1.3 operations and SCTP are asynchronous, meaning that the Chunk
Protection Operator may deliver the decrypted SCTP Payload to the
SCTP endpoint without respecting the reception order. It's up to
SCTP endpoint to reorder the chunks in the reception buffer and to
take care of the flow control according to what specified in
[RFC9260]. From SCTP perspective the DTLS chunk processing is part
of the transport network.
Even though the above allows the implementors to adopt a
multithreading design of the Chunk Protection Operators, the actual
implementation should consider that out-of-order handling of SCTP
chunks is not desired and may cause false congestion signals and
trigger retransmissions.
3.5. PMTU Considerations
The addition of the DTLS chunk to SCTP reduces the room for payload,
due to the size of the DTLS chunk header, padding, and the AEAD
authentication tag. Thus, the SCTP layer creating the plain text
payload needs to know about the overhead to adjust its target payload
size appropriately.
Westerlund, et al. Expires 23 April 2026 [Page 8]
Internet-Draft SCTP DTLS Chunk October 2025
A path MTU discovery function in SCTP will need to know the actual
sent and received size of packets for the SCTP packets. This to
correctly handle PMTUD probe packets.
From SCTP perspective, if there is a maximum size of plain text data
that can be protected by the Chunk Protection Operator that must be
communicated to SCTP. As such a limit will limit the PMTU for SCTP
to the maximum plain text plus DTLS chunk and algorithm overhead plus
the SCTP common header.
3.6. Congestion Control Considerations
The SCTP mechanism for handling congestion control does depend on
successful data transfer for enlarging or reducing the congestion
window CWND (see [RFC9260] Section 7.2).
It may happen that Chunk Protection Operator discards packets due to
replay protection, or integrity errors depending on network induced
bit errors or malicious modifications. As those packets do not
represent what the peer sent, it is acceptable to ignore them,
although in-situ modification on the path of a packet resulting in
discarding due to integrity failure will leave a gap, but has to be
accepted as part of the path behavior.
The Chunk Protection Operator will not interfere with the SCTP
congestion control mechanism, this basically means that from SCTP
perspective the congestion control is exactly the same as how
specified in [RFC9260].
3.7. Dynamic Address Reconfiguration Considerations
When using Dynamic Address Reconfiguration [RFC5061] in an SCTP
association using DTLS Chunk the ASCONF chunk is protected, thus it
needs to be unprotected first, furthermore it MAY come from an
unknown IP Address. In order to properly address the ASCONF chunk to
the relevant Association for being unprotected, Destination Address,
Source, Destination ports and VTag shall be used. If the combination
of those parameters is not unique the implementor MAY choose to send
the DTLS Chunk to all Associations that fit with the parameters in
order to find the right one. The association will attempt de-
protection operations on the DTLS chunk, and if that is successful
the ASCONF chunk can be processed. Note that trial decoding should
have a limit in number of tried contexts to prevent denial of service
attacks on the endpoint.
The section 4.1.1 of [RFC5061] specifies that ASCONF message are
required to be sent authenticated with SCTP-AUTH [RFC4895]. For SCTP
associations using DTLS Chunk this results in the use of redundant
Westerlund, et al. Expires 23 April 2026 [Page 9]
Internet-Draft SCTP DTLS Chunk October 2025
mechanism for Authentication with both SCTP-AUTH and the DTLS Chunk.
We recommend to amend [RFC5061] for including DTLS Chunks as
Authentication mechanism for ASCONF chunks.
3.8. SCTP Restart Considerations
This section deals with the handling of an unexpected INIT chunk
during an Association lifetime as described in Section 5.2 of
[RFC9260] with the purpose of achieving a Restart of the current
Association, thus implementing SCTP Restart.
This specification doesn't support SCTP Restart as described in
[RFC9260] because the COOCKIE-ECHO and COOKIE-ACK chunks are sent
encrypted (see Section 3.8.1);
When the upper layer protocols require support of SCTP Restart, as in
case of 3GPP NG-C protocol [ETSI-TS-38.413], the endpoint needs to
support also initiating protected SCTP Restart procedure described in
Section 3.8.1. Implementing initiating protected restart procedure
is RECOMMENDED, however not required as persistent secure storage of
the restart DTLS Key Context is needed.
The cases where one of the SCTP Endpoints only implements initiating
legacy SCTP Restart are described in Section 3.8.2.
3.8.1. Protected SCTP Restart
The protected SCTP Restart procedure keeps the security
characteristics of an SCTP Association using DTLS Chunk.
In protected SCTP Restart, INIT and INIT-ACK chunks are sent strictly
according to [RFC9260], but COOCKIE-ECHO and COOKIE-ACK chunks are
encrypted using DTLS Chunks and Restart DTLS Key contexts.
In order to support protected SCTP Restart, the SCTP Endpoints shall
allocate and maintain dedicated Restart DTLS Key contexts, SCTP
packets protected by these contexts will be identified in the DTLS
chunk with the R (Restart) bit set (see Section 5.1). Both SCTP
Endpoints needs to ensure that Restart DTLS key contexts is preserved
for supporting the protected SCTP Restart use case.
In order for the protected SCTP endpoint to be available for
protected SCTP Restart purposes, the DTLS chunk needs access to a
DTLS Key context for this SCTP association that needs to be kept in a
well-known state so that both SCTP Endpoints are aware of the DTLS
sequence numbers and replay window, i.e. initialized but never used.
An SCTP Endpoint SHALL NEVER use the SCTP Restart DTLS Key for any
other use case than SCTP association restart.
Westerlund, et al. Expires 23 April 2026 [Page 10]
Internet-Draft SCTP DTLS Chunk October 2025
An SCTP endpoint wanting to be able to initiate a protected SCTP
restart needs to store securely and persistently the restart Keys,
DTLS connection ID (if used) and related DTLS epoch, indexed so that
when performing a restart with the peer node it had a protected SCTP
association which can identify the right restart Key and DTLS epoch
and initialize the restart DTLS Key Context for when restarting the
SCTP association. The keys, DTLS connection ID, and epoch needs to
be stored secure and persistently so that they survive the events
that are causing protected SCTP Restart procedure to be used, for
instance a crash of the SCTP stack. The security considerations for
persistent secure storage of keying materials is further discussed in
Section 13.4.
The SCTP Restart handshakes INIT, INIT-ACK, COOCKIE-ECHO, COOKIE-ACK
exactly as in legacy SCTP Restart case; INIT, INIT-ACK SHALL be sent
plain as in the legacy, whereas COOCKIE-ECHO, COOKIE-ACK Chunks SHALL
be sent as DTLS chunk protected using the restart DTLS key context.
A DTLS Chunk using the restart DTLS key context is identified by
having the R bit (Restart Indicator) set in the DTLS Chunk (see
Figure 4). There's exactly one active Restart DTLS Context at a
time, the newest. However, a crash at the time having completed the
key-management exchange but failing to commit the DTLS Key Context to
persistent secure storage could result in loss of the latest DTLS Key
Context. Therefore, the endpoints SHOULD retain the old restart DTLS
key context until it the key-management confirms the new ones are
committed to secure storage. This can for example be ensure that at
key-changes signals to terminate the old DTLS Key Contexts (including
the restart) is never sent until the new restart DTLS Key Context has
been committed to storage.
Initiator Responder
| | -.
| | +-------
+--------------------(INIT)------------------>| | Plain
|<-----------------(INIT-ACK)-----------------+ +-------
| | -'
| | -.
| | +-------
+---------[DTLS CHUNK(COOKIE ECHO)]---------->| | Protected
|<--------[DTLS CHUNK(COOKIE ACK)]------------+ +-------
| | -'
| |
Figure 2: Handshake of SCTP Restart for DTLS in SCTP
The Figure 2 shows how the control chunks being used for SCTP
Association Restart are transported within DTLS in SCTP.
Westerlund, et al. Expires 23 April 2026 [Page 11]
Internet-Draft SCTP DTLS Chunk October 2025
The transport of COOCKIE-ECHO, COOCKIE-ACK by means of DTLS chunk
ensures that the peer requesting the restart has been previously
validated and the SCTP state machine after having reached ESTABLISHED
state moves automatically to PROTECTED state.
A restarted SCTP Association SHALL continue to use the Restart DTLS
Key Context, for User Traffic until a new primary DTLS Key Context
will be available. The implementors SHOULD initiate a rekeying as
soon as possible, and derive the primary and restart keys so that the
time when no Restart DTLS Key Context is available is kept to a
minimum. Note that another restart attempt prior to having created
new restart DTLS Key context for the new SCTP association will result
in the endpoints being unable to restart the SCTP association.
After restart the next primary DTLS key context SHALL use epoch=3,
i.e. the epoch value is reset. Note that if the restart epoch used
also was 3 when not using any DTLS connection ID, then the
installation of the new restart DTLS key context needs to be done
with some care to avoid dropping valid packets. After having derived
new primary DTLS Key Context the endpoint installs the primary DTLS
Key Context first, and start using it. The new restart DTLS Key
Context is only installed after any old in-flight restart packets
will have been received.
3.8.2. Compatibility with Legacy SCTP Restart
An SCTP Endpoint supporting only legacy SCTP Restart and involved in
an SCTP Association using DTLS Chunks SHOULD NOT attempt to restart
the Association. The effect will be that the restart initiator will
receive INIT-ACK but then all sent packets with COOCKE-ECHO will be
dropped until the peer nodes times out the SCTP Association from lack
of any response from the restarting node.
An SCTP Endpoint supporting only legacy SCTP Restart and involved in
an SCTP Association using DTLS Chunks, when receiving an COOCKIE-ECHO
chunk protected by DTLS chunk as described in Section 3.8.1, thus
having the R bit (Restart Indicator) set in the DTLS Chunk (see
Figure 4), will silently discard it.
Westerlund, et al. Expires 23 April 2026 [Page 12]
Internet-Draft SCTP DTLS Chunk October 2025
Since an SCTP Endpoint supporting only legacy SCTP Restart and
involved in an SCTP Association using DTLS Chunks cannot use SCTP
Restart legacy procedure, in case of need to restart the Association
it SHOULD keep on retrying initiating a new Association until the
remote SCTP Endpoint have closed the existing Association (i.e. due
to timeout) and will accept a new one. As alternative, depending on
the Use Case and the Upper Layer protocol, it MAY use a different
SCTP Source port number so that the peer SCTP Endpoint will accept
the initiation of the new Association while still supervising the old
one.
4. New Parameter Type
This section defines the new parameter type that will be used to
negotiate the use of the DTLS 1.3 chunk during association setup, its
keying method and indicate preference in relation to different keying
and other security solutions. Table 1 illustrates the new parameter
type.
+================+======================================+
| Parameter Type | Parameter Name |
+================+======================================+
| 0x80xx | DTLS 1.3 Chunk Protected Association |
+----------------+--------------------------------------+
Table 1: New INIT/INIT-ACK Parameter
Note that the parameter format requires the receiver to ignore the
parameter and continue processing if the parameter is not understood.
This is accomplished (as described in [RFC9260], Section 3.2.1.) by
the use of the upper bits of the parameter type.
4.1. DTLS 1.3 Chunk Protected Association
This parameter is used to the request and acknowledge of support of
DTLS 1.3 Chunk during INIT/INIT-ACK handshake and indicate preference
for keying and the preference order between multiple security
solutions (if supported).
Westerlund, et al. Expires 23 April 2026 [Page 13]
Internet-Draft SCTP DTLS Chunk October 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x80XX | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Solution #1 | Protection Solution #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Protection Solutions :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Solution #N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Protected Association Parameter
Parameter Type: 16 bits (unsigned integer)
This value MUST be set to 0x80XX.
Parameter Length: 16 bits (unsigned integer)
This value holds the length of the parameter, which will be the
number of Protection Solution fields (N) times two plus 4.
Protection Solution fields: one or more 16-bit SCTP Protection
Solution Identifiers:
Each Protection Solution Identifier (Section 12.1) is a 16-bit
unsigned integer value indicting a Protection Solution.
Protection solutions include both DTLS Chunk based, where a
solution combines the DTLS chunk with a key-management solution,
or non DTLS Chunk based security solution. The Protection
Solutions are listed in descending order of preference, i.e. the
first listed in the parameter is the most preferred and the last
the least preferred by the sender in the INIT chunk. In the INIT-
ACK chunk the endpoint includes all of the offered solutions which
it supports and lists the selected one first. Including its
decreasing preference on the additional Protection Solutions.
Padding: If the number of included Protection solutions is odd the
parameter MUST be padded with two zero (0) bytes of padding to make
the parameter 32-bit aligned.
RFC-Editor Note: Please replace 0x08XX with the actual parameter type
value assigned by IANA and then remove this note.
5. New Chunk Type
Westerlund, et al. Expires 23 April 2026 [Page 14]
Internet-Draft SCTP DTLS Chunk October 2025
5.1. DTLS Chunk (DTLS)
This section defines the new chunk type that will be used to
transport the DTLS 1.3 record containing protected SCTP payload.
Table 2 illustrates the new chunk type.
+============+===================+
| Chunk Type | Chunk Name |
+============+===================+
| 0x4X | DTLS Chunk (DTLS) |
+------------+-------------------+
Table 2: DTLS Chunk Type
RFC-Editor Note: Please replace 0x4x with the actual chunk type value
assigned by IANA and then remove this note.
It should be noted that the DTLS chunk format requires the receiver
stop processing this SCTP packet, discard the unrecognized chunk and
all further chunks, and report the unrecognized chunk in an ERROR
chunk using the 'Unrecognized Chunk Type' error cause. This is
accomplished (as described in [RFC9260] Section 3.2.) by the use of
the upper bits of the chunk type.
The DTLS chunk is used to hold the DTLS 1.3 record with the protected
payload of a plain text SCTP packet without the SCTP common header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4x | reserved |R| Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Payload |
| |
| +-------------------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DTLS Chunk Structure
reserved: 7 bits Reserved bits for future use. Sender MUST set
these bits to 0 and MUST be ignored on reception.
R: 1 bit (boolean) Restart indicator. If this bit is set this DTLS
chunk is protected with by a Restart DTLS Key context.
Chunk Length: 16 bits (unsigned integer) This value holds the length
Westerlund, et al. Expires 23 April 2026 [Page 15]
Internet-Draft SCTP DTLS Chunk October 2025
of the Payload in bytes plus 4.
Payload: variable length This holds the DTLSCiphertext as specified
in DTLS 1.3 [RFC9147].
Padding: 0, 8, 16, or 24 bits If the length of the Payload is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes to make the chunk 32-bit aligned. The Padding MUST NOT be
longer than 3 bytes and it MUST be ignored by the receiver.
6. Error Handling
This specification introduces a new set of error causes that are to
be used when SCTP endpoint detects a faulty condition. The special
case is when the error is detected by the DTLS 1.3 Protection that
may provide additional information.
6.1. DTLS 1.3 Chunk Protected Association Parameter Missing
When an initiator SCTP endpoint sends an INIT chunk that doesn't
contain the DTLS 1.3 Chunk Protected Association or other protection
solutions towards an SCTP endpoint that only accepts protected
associations, SCTP will send an ABORT chunk in response to the INIT
chunk (Section 5.1 of [RFC9260] including the error cause 'Policy Not
Met' (TBA10) (see Section 12.4 and the DTLS 1.3 chunk protected
association parameter identifier Section 4.1 in the missing param
Information field. It may also include additional parameters
representing other supported protection mechanisms that are
acceptable per endpoint security policy.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 2 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTLS 1.3 Chunk Protected Asc | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ERROR Missing Protected Association Parameter
Note: Cause Length in bytes is equal to following with the number of
missing parameters as N: 8 + N * 2 according to [RFC9260], section
3.3.10.2. Also the Protection Association ID may be present in any
of the N missing params, no order implied by the example in Figure 5.
Westerlund, et al. Expires 23 April 2026 [Page 16]
Internet-Draft SCTP DTLS Chunk October 2025
6.2. Error in DTLS Chunk
A new Error Type is defined for the DTLS Chunk, it's used for any
error related to the DTLS chunk's protection mechanism described in
this document and has a structure that allows detailed information to
be added as extra causes.
This specification describes some of the causes whilst the key
establishment specification MAY add further causes.
When detecting an error, SCTP will send an ABORT chunk containing the
relevant Error Type and Causes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = TBA9 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extra Cause #1 | Extra Cause #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extra Cause #N-1 | Extra Cause #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Error in DTLS Chunk Cause Format
Cause Code: 16 bits (unsigned integer)
The SCTP Error Chunk Cause Code indicating "Error in Protection"
is TBA9.
Cause Length: 16 bits (unsigned integer)
Is for N extra Causes equal to 4 + N * 2
Extra Cause: 16 bits (unsigned integer)
Each Extra Cause indicate an additional piece of information as
part of the error. There MAY be zero to as many as can fit in the
extra cause field in the ERROR Chunk (A maximum of 32764).
Editor's Note: Please replace TBA9 above with what is assigned by
IANA.
Below a number of defined Error Causes (Extra Cause above) are
defined, additional causes can be registered with IANA following the
rules in Section 12.4.
Westerlund, et al. Expires 23 April 2026 [Page 17]
Internet-Draft SCTP DTLS Chunk October 2025
6.2.1. No Common Protection Solution
If the responder to do not support any of the protection solutions
offered by the association initiator in the Protection Soluiton
Parameters Figure 3 SCTP will send an ABORT chunk in response to the
INIT chunk (Section 5.1 of [RFC9260], including the error cause "No
Common Protection" (TBA11) (see Section 12.4).
6.3. Critical Error from DTLS
The Chunk Protection Operator MAY inform local SCTP endpoint about
errors. When an Error in the DTLS 1.3 compromises the protection
mechanism, the Chunk Protection Operator may stop processing data
altogether, thus the local SCTP endpoint will not be able to send or
receive any chunk for the specified Association. This will cause the
SCTP Association to be closed by legacy timer-based mechanism. Since
the Association protection is compromised no further data will be
sent and the remote peer will also experience timeout on the
Association.
6.4. Non-critical Error in the Protection
A non-critical error in Chunk Protection Operator means that the
Chunk Protection Operator is capable of recovering without the need
of the whole SCTP Association to be re-established.
From SCTP perspective, a non-critical error will be perceived as a
temporary problem in the transport and will be handled with
retransmissions and SACKS according to [RFC9260].
When the Chunk Protection Operator will experience a non-critical
error, an ABORT chunk SHALL NOT be sent.
7. Procedures
7.1. Establishment of a Protected Association
An SCTP Endpoint acting as initiator willing to create a DTLS 1.3
chunk protected association shall send to the remote peer an INIT
chunk containing the DTLS 1.3 Chunk Protected Association parameter
(see Section 4.1) indicating supported and preferred key-management
solutions (see Figure 3).
An SCTP Endpoint acting as responder, when receiving an INIT chunk
with DTLS 1.3 Chunk Protected Association parameter, will reply with
INIT-ACK with its own DTLS 1.3 Chunk Protected Association parameter
containing the selected protection solution out of the set of
supported ones. In case there are no common set of supported
Westerlund, et al. Expires 23 April 2026 [Page 18]
Internet-Draft SCTP DTLS Chunk October 2025
solutions that are accepted by the responder, and the endpoints
policy require secured association it SHALL reply with an ABORT
chunk, include the error cause "No Common Protection" (TBA11) (see
Section 12.4). Otherwise, the responder MAY send an INIT-ACK without
the DTLS 1.3 Chunk Protected Association parameter to indicate it is
willing to create a session without security.
Additionally, an SCTP Endpoint acting as responder willing to support
only protected associations shall consider an INIT chunk not
containing the DTLS 1.3 Chunk Protected Association parameter or
another Protection Solution accepted by own security policy solution
as an error, thus it will reply with an ABORT chunk according to what
specified in Section 6.1 indicating that for this endpoint mandatory
DTLS 1.3 Chunk Protected Association parameter is missing.
When initiator and responder have agreed on a DTLS Chunk protected
association and the key-management method by means of handshaking
INIT/INIT-ACK the SCTP association establishment continues until it
has reached the ESTABLISHED state.
When the SCTP session has been established follow the process defined
by the selected key-management solution for establishing DTLS Key
Contexts and installing them.
7.1.1. Offering Multiple Security Solutions
An initiator of an SCTP association may want to offer multiple
different key-management solutions for DTLS Chunk or in combination
with other security solutions in addition to DTLS 1.3 chunks for the
SCTP association. This can be done but need to consider the
downgrade attack risks (see Section 13.3).
The initiator MAY include in its INIT additional security solutions
that are compatible to offer in parallel with DTLS 1.3 Chunks. This
may include SCTP-AUTH [I-D.ietf-tsvwg-rfc4895-bis]. This will result
in that a number of different SCTP parameters may be included that
are not possible to use simultaneously. Instead the responder needs
to parse these parameters to figure out which sets of solutions that
are offered that the implementation support, and apply its security
policies to select the most appropriate. For example an offer of
DTLS 1.3 Chunks and SCTP-AUTH, could be interpreted as three
different solutions with different properties, namely DTLS 1.3
Chunks, DTLS/SCTP [RFC6083], and SCTP-AUTH
[I-D.ietf-tsvwg-rfc4895-bis] only. However, here the DTLS 1.3 Chunk
Protected Association Parameter can indicate both preference and
which of the solutions that are preferred.
Westerlund, et al. Expires 23 April 2026 [Page 19]
Internet-Draft SCTP DTLS Chunk October 2025
The responder selects one or possibly more of compatible security
solutions that can be used simultaneously and include them in the
response (INIT-ACK). If DTLS 1.3 chunks was selected and the Key-
Management method follows the recommendation for down-grade
prevention the endpoints can know that down-grade did not happen.
7.2. Termination of a Protected Association
Besides the procedures for terminating an association explained in
[RFC9260], DTLS 1.3 chunk SHALL ask the SCTP endpoint for terminating
an association when having an internal error or by detecting a
security violation. Note that the closure of any key-management
connection doesn't compromise the capability of sending and receiving
protected SHUTDOWN-COMPLETE chunks as that capability only relies on
the Key Context and not on the key-management connection from where
it has been derived.
7.3. Considerations on Key Management
It is up to the upper layer to manage the keys for the DTLS chunk.
The meaning of key-management is described in Section 3.3.
The key-management SHOULD use a dedicated PPID to ensure that the
key-management related user messages are handled by the appropriate
layer.
When performing key-management, the keys for receiving SHOULD be
installed before the corresponding send keys at the peer. For
mitigating downgrade attacks the key derivation MUST include the
protection solution Identifiers that were sent and received.
The communication is only protected after both sides have configured
the keys for sending and both sides have enforced the protection.
8. DTLS Chunk Handling
The DTLS chunk MUST NOT be bundled with any other chunk. In
particular, it MUST be the first chunk.
Westerlund, et al. Expires 23 April 2026 [Page 20]
Internet-Draft SCTP DTLS Chunk October 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Unprotected SCTP Packet
The diagram shown in Figure 7 describes the structure of an
unprotected SCTP packet as described in [RFC9260].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTLS Chunk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Protected SCTP Packets
The diagram shown in Figure 8 describes the structure of a protected
SCTP packet being sent. Such packets are built with the SCTP common
header. Only one DTLS chunk can be sent in a SCTP packet.
8.1. Sending of DTLS Chunks
When the credentials for sending DTLS chunks have been configured by
the application, all SCTP packets are sent with a DTLS chunk.
When an SCTP packet needs to be sent, the sequence of chunks is used
as DTLSInnerPlaintext.content and DTLSInnerPlaintext.type is set to
application_data. Then the DTLSCiphertext is computed and used as
the payload of the DTLS chunk. Finally the SCTP common header is
prepended.
When the DTLS chunk is used, the DTLS chunk header and the overhead
of DTLS has to be considered to ensure that the final SCTP packet
does not exceed the PMTU.
Westerlund, et al. Expires 23 April 2026 [Page 21]
Internet-Draft SCTP DTLS Chunk October 2025
8.2. Receiving of DTLS Chunks
When an SCTP packet containing a DTLS chunk bundled with any other
chunk is received, the packet MUST be silently discarded.
After the application has restricted the SCTP packet handling to
protected SCTP packets only, a SCTP packet not containing a DTLS
chunk MUST be silently discarded.
When processing the payload of the DTLS chunk (i.e. the
DTLSCiphertext), the Restart flag in addition to the unified_hdr is
used to find the keys for processing the encrypted_record.
After the encrypted_record has been verified and decrypted, the
corresponding chunks (the DTLSInnerPlaintext.content) are processed
as defined in the corresponding specifications.
9. Abstract API
This section describes an abstract API that is needed between a key-
managment function and the DTLS 1.3 chunk. This is an example API
and there are alternative implementations.
This API enables the cryptographical protection operations by setting
client/server write keys, sequence number keys, and IVs for primary
and restart DTLS contexts. The write key is the used by the cipher
suite for DTLS record protection (Section 5.2 of [RFC8446]. The
initilization vector (IV) is random material used to XOR with the
sequence number to create the nonce per Section 5.3 of [RFC8446].
The sequence number key is used to encrypt the sequence number
(Section 4.2.3 of [RFC9147]).
9.1. Cipher Suit Capabilities
The key-management function needs to know which cipher suits defined
for usage with DTLS 1.3 that are supported by the DTLS chunk and its
protection operations block. All TLS cipher suit that are defined
are listed in the TLS cipher suit registry [TLS-CIPHER-SUITS] at IANA
and are identified by a 2-byte value. Thus this needs to return a
list of all supported cipher suits to the higher layer.
Request : Get Cipher Suits
Parameters : none
Reply : Cipher Suits
Parameters : list of cipher suits
Westerlund, et al. Expires 23 April 2026 [Page 22]
Internet-Draft SCTP DTLS Chunk October 2025
9.2. Establish Client Write Keying Material
The DTLS Chunk can use one of out of multiple sets of cipher suit and
corresponding key materials.
The following information needs to be provided when setting Client
Write (transmit) Keying material:
Request : Establish Client Write Key and IV
Parameters :
* SCTP Association: Reference to the relevant SCTP association to
set the keying material for.
* Restart indication: A bit indicating whether the Key is for
restart purposes
* DTLS Connection ID: : If DTLS connection ID (CID) has been
negotiated by the key-management its field length and value are
include. The field length can be set to zero (0) to indicate that
CID is not used.
* DTLS Epoch: The DTLS epoch these keys are valid for. Note that
Epoch lower than 3 are not expected as they are used during
DTLS handshake.
* Cipher Suit: 2 bytes cipher suit identification for the DTLS 1.3
Cipher suit used to identify the DTLS AEAD algorithm to perform
the DTLS record protection. The cipher suite is fixed for a
(SCTP Association, Key) pair.
* Write Key, Sequence Number Key and IV: The cipher suit specific
binary object containing all necessary information for
protection operations. The secret will used by the DTLS 1.3
client to encrypt the record. Binary arbitrary long object
depending on the cipher suit used.
Reply : Established or Failed
9.3. Establish Server Write Keying Material
The DTLS Chunk can use one of out of multiple sets of cipher suit and
corresponding key materials.
The following information needs to be provided when setting Server
Write (transmit) Keying material:
Westerlund, et al. Expires 23 April 2026 [Page 23]
Internet-Draft SCTP DTLS Chunk October 2025
Request : Establish Server Write Key and IV
Parameters :
* SCTP Association: Reference to the relevant SCTP association to
set the keying material for.
* Restart indication: A bit indicating whether the Key is for
restart purposes
* DTLS Connection ID: : If DTLS connection ID (CID) has been
negotiated by the key-management its field length and value are
include. The field length can be set to zero (0) to indicate that
CID is not used.
* DTLS Epoch: The DTLS epoch these keys are valid for. Note that
Epoch lower than 3 are note expected as they are used during
DTLS handshake.
* Cipher Suit: 2 bytes cipher suit identification for the DTLS 1.3
Cipher suit used to identify the DTLS AEAD algorithm to perform
the DTLS record protection. The cipher suite is fixed for a
(SCTP Association, Key) pair.
* Write Key, Sequence Number Key and IV: The cipher suit specific
binary object containing all necessary information for
protection operations. The secret will used by the DTLS 1.3
client to encrypt the record. Binary arbitrary long object
depending on the cipher suit used.
Reply : Established or Failed
9.4. Destroy Client Write Keying Material
A function to destroy the Client Write (transmit) keying material for
a given epoch for a given Key for a given SCTP Association.
Request : Destroy client write key and IV
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Westerlund, et al. Expires 23 April 2026 [Page 24]
Internet-Draft SCTP DTLS Chunk October 2025
Reply: Destroyed
Parameters : true or false
9.5. Destroy Server Write Keying Material
A function to destroy the Server Write (transmit) keying material for
a given epoch for a given Key for a given SCTP Association.
Request : Destroy server write key and IV
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Reply: Destroyed
Parameters : true or false
9.6. Set Key to Use
Set which key to use to protect the future SCTP packets sent by the
SCTP Association.
Request : Set Key used
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Reply: Key set
Parameters : true or false
Westerlund, et al. Expires 23 April 2026 [Page 25]
Internet-Draft SCTP DTLS Chunk October 2025
9.7. Require Protected SCTP Packets
A function to configure an SCTP association to require that normal
SCTP packets being received must be protected in a DTLS Chunk going
forward.
Parameters:
* SCTP Association
Reply: Acknowledgement
9.8. Get AEAD Encryption Invocations
Get the number of AEAD encryption invocations (protected messages)
for a given epoch.
Request : Get AEAD Encryption Invocations
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Reply: AEAD Encryption Invocations
Parameters : non-negative integer
9.9. Get AEAD Decryption Invocations
Get the number of AEAD decryption invocations for a given epoch.
Request : Get AEAD Decryption Invocations
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Westerlund, et al. Expires 23 April 2026 [Page 26]
Internet-Draft SCTP DTLS Chunk October 2025
Reply: AEAD Decryption Invocations
Parameters : non-negative integer
9.10. Get Failed AEAD Decryption Invocations
Get the number of failed AEAD decryption invocations for a given
epoch.
Request : Get Failed AEAD Decryption Invocations
Parameters :
* SCTP Association
* Restart indication
* DTLS CID
* DTLS Epoch
Reply: Failed AEAD Decryption Invocations
Parameters : non-negative integer
9.11. Configure Replay Protection
The DTLS replay protection in this usage is expected to be fairly
robust. Its depth of handling is related to maximum network path
reordering that the receiver expects to see during the SCTP
association. However as the actual reordering in number of packets
are a combination of how delayed one packet may be compared to
another times the actual packet rate this can grow for some
applications and may need to be tuned. Thus, having the potential
for setting this a more suitable value depending on the use case
should be considered.
Note this sets this configuration to be used across any DTLS key
context for a given SCTP Association and primary/restart usages.
Request : Configure Replay Protection
Parameters :
* SCTP Association
* Restart indication
Westerlund, et al. Expires 23 April 2026 [Page 27]
Internet-Draft SCTP DTLS Chunk October 2025
* Configuration parameters
Reply: Replay Protection Configured
Parameters : true or false
10. Socket API Considerations
This section describes how the socket API defined in [RFC6458] needs
to be extended to provide a way for the application to control the
usage of the DTLS chunk.
A 'Socket API Considerations' section is contained in all SCTP-
related specifications published after [RFC6458] describing an
extension for which implementations using the socket API as specified
in [RFC6458] would require some extension of the socket API. Please
note that this section is informational only.
Please also note, that the API described in this section can change
in a non-backwards compatible way during the evolution of this
document due to changed functionality or gained experience during the
implementation.
A socket API implementation based on [RFC6458] is extended by
supporting several new IPPROTO_SCTP-level socket options and a new
flag for recvmsg().
10.1. SCTP_ASSOC_CHANGE Notification
When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of
[RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or
SCTP_RESTART for an SCTP association where both peers support the
DTLS chunk, SCTP_ASSOC_SUPPORTS_DTLS should be listed in the sac_info
field.
10.2. A New Flag for recvmsg() (MSG_PROTECTED)
This flag is returned by recvmsg() in msg_flags for all user messages
for which all DATA chunks where received in protected SCTP packets.
This also means that if sctp_recvv() is used, MSG_PROTECTED is
returned in the *flags argument.
10.3. Functions
10.3.1. sctp_dtls_nr_cipher_suits()
sctp_dtls_nr_cipher_suits() returns the number of cypher suits
supported by the SCTP implementation.
Westerlund, et al. Expires 23 April 2026 [Page 28]
Internet-Draft SCTP DTLS Chunk October 2025
The function prototype is:
unsigned int
sctp_dtls_nr_cipher_suits(void);
This function can be used in combination with
sctp_dtls_cipher_suits().
10.3.2. sctp_dtls_cipher_suits()
sctp_dtls_cipher_suits() returns the cypher suits supported by the
SCTP implementation.
The function prototype is:
int
sctp_dtls_cipher_suits(uint8_t cipher_suits[][2], unsigned int n);
and the arguments are
cipher_suits: An array where the supported cypher suits are stored.
A cypher suit is represented by two uint8_t using the IANA
assigned values in the TLS cipher suit registry
[TLS-CIPHER-SUITS].
n: The number of cipher suits which can be stored in cipher_suits.
sctp_dtls_cipher_suits returns -1, if n is smaller than the number of
cipher suites supported by the stack. If n is equal to or larger
than the number of cipher suites supported the the SCTP
implementation, the cipher suits are stored in cipher_suits and the
number of supported cipher suits is returned.
10.4. Socket Options
The following table provides an overview of the IPPROTO_SCTP-level
socket options defined by this section.
Westerlund, et al. Expires 23 April 2026 [Page 29]
Internet-Draft SCTP DTLS Chunk October 2025
+==============================+========================+=====+=====+
| Option Name | Data Type | Set | Get |
+==============================+========================+=====+=====+
| SCTP_DTLS_LOCAL_PMIDS | struct | X | X |
| | sctp_dtls_pmids | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_REMOTE_PMIDS | struct | | X |
| | sctp_dtls_pmids | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_SET_SEND_KEYS | struct | X | |
| | sctp_dtls_keys | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_ADD_RECV_KEYS | struct | X | |
| | sctp_dtls_keys | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_DEL_RECV_KEYS | struct | X | |
| | sctp_dtls_keys_id | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_ENFORCE_PROTECTION | struct | X | X |
| | sctp_assoc_value | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_REPLAY_WINDOW | struct | X | X |
| | sctp_assoc_value | | |
+------------------------------+------------------------+-----+-----+
| SCTP_DTLS_STATS | struct | | X |
| | sctp_dtls_stats | | |
+------------------------------+------------------------+-----+-----+
Table 3: Socket Options
sctp_opt_info() needs to be extended to support:
* SCTP_DTLS_LOCAL_PMIDS,
* SCTP_DTLS_REMOTE_PMIDS,
* SCTP_DTLS_ENFORCE_PROTECTION,
* SCTP_DTLS_REPLAY_WINDOW, and
* SCTP_DTLS_STATS.
Westerlund, et al. Expires 23 April 2026 [Page 30]
Internet-Draft SCTP DTLS Chunk October 2025
10.4.1. Get or Set the Local Protection Method Identifiers
(SCTP_DTLS_LOCAL_PMIDS)
This socket option sets the protection method identifiers which will
be sent to the peer during the handshake. It can also be used to
retrieve the protection method identifiers which were sent during the
handshake.
The following structure is used as the option_value:
struct sctp_dtls_pmids {
sctp_assoc_t sds_assoc_id;
uint16_t sdp_nr_pmids;
uint16_t sdp_pmids[];
};
sds_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
For setsockopt(), only SCTP_FUTURE_ASSOC can be used. For
getsockopt(), it is an error to use SCTP_{CURRENT|ALL}_ASSOC.
sdp_nr_pmids: The number of entries in sdp_pmids.
sdp_pmids: The protection method identifiers which will be or have
been sent to the peer in the sequence they were contained in the
DTLS 1.3 Chunk Protected Association parameter and in host byte
order.
This socket option can be used with setsockopt() for SCTP endpoints
in the SCTP_CLOSED or SCTP_LISTEN state to configure the protection
method identifiers to be sent. When used with getsockopt() on an
SCTP endpoint in the SCTP_LISTEN state, the protection method
identifiers which will be sent can be retrieved. If the SCTP
endpoint is in a state other that SCTP_CLOSED or SCTP_LISTEN, the
protection method identifiers which have been sent can be retrieved.
10.4.2. Get the Remote Protection Method Identifiers
(SCTP_DTLS_REMOTE_PMIDS)
This socket option reports the protection method identifiers reported
by the peer during the handshake.
The following structure is used as the option_value:
Westerlund, et al. Expires 23 April 2026 [Page 31]
Internet-Draft SCTP DTLS Chunk October 2025
struct sctp_dtls_pmids {
sctp_assoc_t sds_assoc_id;
uint16_t sdp_nr_pmids;
uint16_t sdp_pmids[];
};
sds_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
sdp_nr_pmids: The number of entries in sdp_pmids.
sdp_pmids: The protection method identifiers reported by the peer in
the sequence they were contained in the DTLS 1.3 Chunk Protected
Association parameter and in host byte order.
This socket option will fail on any SCTP endpoint in state
SCTP_CLOSED, SCTP_COOKIE_WAIT and SCTP_COOKIE_ECHOED.
10.4.3. Set Send Keys (SCTP_DTLS_SET_SEND_KEYS)
Using this socket option allows to add a particular set of keys used
for sending DTLS chunks.
The following structure is used as the option_value:
struct sctp_dtls_keys {
sctp_assoc_t sdk_assoc_id;
uint8_t sdk_cipher_suit[2];
uint8_t sdk_restart;
uint8_t sdk_conn_id_len;
uint16_t sdk_key_len;
uint16_t sdk_iv_len;
uint16_t sdk_sn_key_len;
uint16_t sdk_unused;
uint64_t sdk_epoch;
uint8_t *sdk_conn_id;
uint8_t *sdk_key;
uint8_t *sdk_iv;
uint8_t *sdk_sn_key;
};
sdk_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
Westerlund, et al. Expires 23 April 2026 [Page 32]
Internet-Draft SCTP DTLS Chunk October 2025
sdk_cipher_suit: The cipher suit for which the keys are used.
sdk_restart: If the value is 0, the regular keys are added, if a
value different from 0 is used, the restart keys are added.
sdk_conn_id_len: The length of the DTLS connection identifier
specified in sdk_conn_id.
sdk_key_len: The length of the initialization vector specified in
sdk_key.
sdk_iv_len: The length of the initialization vector specified in
sdk_iv.
sdk_sn_key_len: The length of the sequence number key specified in
sdk_sn_key.
sdk_unused: This field is ignored.
sdk_epoch: The epoch for which the keys are added.
sdk_conn_id: A pointer to the connection identifier for which the
keys are added. Using NULL means that no connection identifier is
used.
sdk_key: A pointer to the key.
sdk_iv: A pointer to the initialization vector.
sdk_sn_key: A pointer to the sequence number key.
This socket option can only be used on SCTP endpoints in states other
then SCTP_LISTEN, SCTP_COOKIE_WAIT and SCTP_COOKIE_ECHOED. If the
socket options is successful, all affected DTLS chunks sent will use
the specified keys until the keys are changed again by another call
of this socket option.
10.4.4. Add Receive Keys (SCTP_DTLS_ADD_RECV_KEYS)
Using this socket option allows to add a particular set of keys used
for receiving DTLS chunks.
The following structure is used as the option_value:
Westerlund, et al. Expires 23 April 2026 [Page 33]
Internet-Draft SCTP DTLS Chunk October 2025
struct sctp_dtls_keys {
sctp_assoc_t sdk_assoc_id;
uint8_t sdk_cipher_suit[2];
uint8_t sdk_restart;
uint8_t sdk_conn_id_len;
uint16_t sdk_key_len;
uint16_t sdk_iv_len;
uint16_t sdk_sn_key_len;
uint16_t sdk_unused;
uint64_t sdk_epoch;
uint8_t *sdk_conn_id;
uint8_t *sdk_key;
uint8_t *sdk_iv;
uint8_t *sdk_sn_key;
};
sdk_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
sdk_cipher_suit: The cipher suit for which the keys are used.
sdk_restart: If the value is 0, the regular keys are added, if a
value different from 0 is used, the restart keys are added.
sdk_conn_id_len: The length of the DTLS connection identifier
specified in sdk_conn_id.
sdk_key_len: The length of the initialization vector specified in
sdk_key.
sdk_iv_len: The length of the initialization vector specified in
sdk_iv.
sdk_sn_key_len: The length of the sequence number key specified in
sdk_sn_key.
sdk_unused: This field is ignored.
sdk_epoch: The epoch for which the keys are added.
sdk_conn_id: A pointer to the connection identifier for which the
keys are added. Using NULL means that no connection identifier is
used.
sdk_key: A pointer to the key.
Westerlund, et al. Expires 23 April 2026 [Page 34]
Internet-Draft SCTP DTLS Chunk October 2025
sdk_iv: A pointer to the initialization vector.
sdk_sn_key: A pointer to the sequence number key.
This socket option can only be used on SCTP endpoints in states other
then SCTP_LISTEN, SCTP_COOKIE_WAIT and SCTP_COOKIE_ECHOED.
10.4.5. Delete Receive Keys (SCTP_DTLS_DEL_RECV_KEYS)
Using this socket option allows to remove a particular set of keys
used for receiving DTLS chunks.
The following structure is used as the option_value:
struct sctp_dtls_keys_id {
sctp_assoc_t sdki_assoc_id;
uint8_t sdki_restart;
uint8_t sdki_conn_id_len;
uint16_t sdki_unused;
uint64_t sdki_epoch;
uint8_t *sdki_conn_id;
}
sdki_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
sdki_restart: If the value is 0, the regular keys are removed, if a
value different from 0 is used, the restart keys are removed.
sdki_conn_id_len: The length of the DTLS connection identifier
specified in sdki_conn_id.
sdki_unused: This field is ignored.
sdki_epoch: The epoch for which the keys are removed.
sdki_conn_id: A pointer to the connection identifier for which the
keys are removed. Using NULL means that no connection identifier
is used.
This socket option can only be used on SCTP endpoints in states other
then SCTP_CLOSED, SCTP_LISTEN, SCTP_COOKIE_WAIT and
SCTP_COOKIE_ECHOED.
Westerlund, et al. Expires 23 April 2026 [Page 35]
Internet-Draft SCTP DTLS Chunk October 2025
10.4.6. Set or Get Protection Enforcement
(SCTP_DTLS_ENFORCE_PROTECTION)
Enabling this socket option on an SCTP endpoint enforces that
received SCTP packets are only processed, if they are protected. All
received packets with the first chunk not being an INIT chunk, INIT
ACK chunk, or DTLS chunk will be silently discarded.
The following structure is used as the option_value:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates upon which
SCTP association the caller is performing the action. It is an
error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
assoc_value: The value 0 represents that the option is off, any other
value represents that the option is on.
This socket option is off by default on any SCTP endpoint. Once
protection has been enforced by enabling this socket option on an
SCTP endpoint, it cannot be disabled again. Whether protection has
been enforced on an SCTP endpoint can be queried in any state other
than SCTP_CLOSED. Protection can be enforced in any state other than
SCTP_CLOSED, SCTP_COOKIE_WAIT and SCTP_COOKIE_ECHOED.
10.4.7. Get Statistic Counters (SCTP_DTLS_STATS)
This socket options allows to get various statistic counters for a
specific SCTP endpoint.
The following structure is used as the option_value:
struct sctp_dtls_stats {
sctp_assoc_t sds_assoc_id;
uint32_t sds_dropped_unprotected;
uint32_t sds_aead_failures;
uint32_t sds_recv_protected;
uint32_t sds_sent_protected;
/* There will be added more fields before the WGLC. */
/* There might be additional platform specific counters. */
};
sds_assoc_id: This parameter is ignored for one-to-one style
Westerlund, et al. Expires 23 April 2026 [Page 36]
Internet-Draft SCTP DTLS Chunk October 2025
sockets. For one-to-many style sockets, this parameter indicates
upon which SCTP association the caller is performing the action.
It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
sds_dropped_unprotected: The number of unprotected packets received
for this SCTP endpoint after protection was enforced.
sds_aead_failures: The number of AEAD failures when processing
received DTLS chunks.
sds_recv_protected: The number of DTLS chunks successfully
processed.
sds_sent_protected: The number of DTLS chunks sent.
10.4.8. Get or Set the Replay Protection Window Size
(SCTP_DTLS_REPLAY_WINDOW)
This socket option can be used to configure the replay protection for
SCTP endpoints.
The following structure is used as the option_value:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates upon which
SCTP association the caller is performing the action. It is an
error to use SCTP_{CURRENT|ALL}_ASSOC.
assoc_value: The maximum number of DTLS chunks in the replay
protection window.
11. Implementation Considerations
11.1. Privacy Padding of SCTP Packets
To reduce the potential information leakage from packet size
variations one may select to pad the SCTP Packets to uniform packet
sizes. This size may be either the maximum used, or in block sized
increments. However, the padding needs to be done inside of the
encryption envelope.
Westerlund, et al. Expires 23 April 2026 [Page 37]
Internet-Draft SCTP DTLS Chunk October 2025
Both SCTP and DTLS contains mechanisms to pad SCTP payloads, and DTLS
records respectively. If padding of SCTP packets are desired to hide
actual message sizes it RECOMMEDED to use the SCTP Padding Chunk
[RFC4820] to generate a consistent SCTP payload size. Support of
this chunk is only required on the sender side, any SCTP receiver
will safely ignore the PAD Chunk. However, if the PAD chunk is not
supported DTLS padding MAY be used.
It needs to be noted that independent if SCTP padding or DTLS padding
is used the padding is not taken into account by the SCTP congestion
control. Extensive use of padding has potential for worsen
congestion situations as the SCTP association will consume more
bandwidth than its derived share by the congestion control.
The use of SCTP PAD chunk is recommended as it at least can enable
future extension or SCTP implementation that account also for the
padding. Use of DTLS padding hides this packet expansion from SCTP.
12. IANA Considerations
This document defines two new registries in the Stream Control
Transmission Protocol (SCTP) Parameters group that IANA maintains.
Theses registries are for the extra cause codes for protection
related errors. It also adds registry entries into several other
registries in the Stream Control Transmission Protocol (SCTP)
Parameters group:
* One new SCTP Chunk Types
* One new SCTP Chunk Parameter Type
* Three new SCTP Error Cause Code
And finally the update of one registered SCTP Payload Protocol
Identifier.
12.1. SCTP Protection Solution Identifiers
IANA is requested to create a new registry called "SCTP Protection
Solutions". This registry is part of the of the Stream Control
Transmission Protocol (SCTP) Parameters grouping.
The purpose of this registry is to assign Protection Solution
Identifier for any security solution that is either the DTLS Chunk
combined with a key-management method, offered as an alternative to
DTLS chunk. Any security solution that is offered through a
parameter exchange during the SCTP handshake are potential to be
included here.
Westerlund, et al. Expires 23 April 2026 [Page 38]
Internet-Draft SCTP DTLS Chunk October 2025
Each entry will be assigned a 16-bit unsigned integer value from the
suitable range.
+============+================================+===========+=========+
| Identifier | Solution Name | Reference | Contact |
+============+================================+===========+=========+
| 0 | DTLS 1.3 Chunk with Pre- | RFC-TBD | Draft |
| | | | Authors |
+------------+--------------------------------+-----------+---------+
| 1-4095 | Available for Assignment | | |
| | using Specification | | |
| | Required policy | | |
+------------+--------------------------------+-----------+---------+
| 4096-65535 | Available for Assignment | | |
| | using First Come, First | | |
| | Served policy | | |
+------------+--------------------------------+-----------+---------+
Table 4: Protection Solution Identifiers
New entries in the range 0-4095 are registered following the
Specification Required policy as defined by [RFC8126]. New entries
in the range 4096-65535 are first come, first served.
12.2. SCTP Chunk Type
In the Stream Control Transmission Protocol (SCTP) Parameters group's
"Chunk Types" registry, IANA is requested to add the one new entry
depicted below in in Table 5 with a reference to this document. The
registry at time of writing was available at:
https://www.iana.org/assignments/sctp-parameters/sctp-
parameters.xhtml#sctp-parameters-1
+==========+===================+===========+
| ID Value | Chunk Type | Reference |
+==========+===================+===========+
| TBA6 | DTLS Chunk (DTLS) | RFC-To-Be |
+----------+-------------------+-----------+
Table 5: New Chunk Type Registered
The registration table for the chunk flags of this chunk type is
initially:
Westerlund, et al. Expires 23 April 2026 [Page 39]
Internet-Draft SCTP DTLS Chunk October 2025
+==================+=================+===========+
| Chunk Flag Value | Chunk Flag Name | Reference |
+==================+=================+===========+
| 0x01 | R bit | RFC-To-Be |
+------------------+-----------------+-----------+
| 0x02 | Unassigned | |
+------------------+-----------------+-----------+
| 0x04 | Unassigned | |
+------------------+-----------------+-----------+
| 0x08 | Unassigned | |
+------------------+-----------------+-----------+
| 0x10 | Unassigned | |
+------------------+-----------------+-----------+
| 0x20 | Unassigned | |
+------------------+-----------------+-----------+
| 0x40 | Unassigned | |
+------------------+-----------------+-----------+
| 0x80 | Unassigned | |
+------------------+-----------------+-----------+
Table 6: DTLS Chunk Flags
12.3. SCTP Chunk Parameter Types
In the Stream Control Transmission Protocol (SCTP) Parameters group's
"Chunk Parameter Types" registry, IANA is requested to add the new
entry depicted below in in Table 7 with a reference to this document.
The registry at time of writing was available at:
https://www.iana.org/assignments/sctp-parameters/sctp-
parameters.xhtml#sctp-parameters-2
+==========+======================================+===========+
| ID Value | Chunk Parameter Type | Reference |
+==========+======================================+===========+
| TBA8 | DTLS 1.3 Chunk Protected Association | RFC-To-Be |
+----------+--------------------------------------+-----------+
Table 7: New Chunk Type Parameters Registered
12.4. SCTP Error Cause Codes
In the Stream Control Transmission Protocol (SCTP) Parameters group's
"Error Cause Codes" registry, IANA is requested to add the new entry
depicted below in in Table 8 with a reference to this document. The
registry at time of writing was available at:
https://www.iana.org/assignments/sctp-parameters/sctp-
parameters.xhtml#sctp-parameters-24
Westerlund, et al. Expires 23 April 2026 [Page 40]
Internet-Draft SCTP DTLS Chunk October 2025
+==========+======================+===========+
| ID Value | Error Cause Codes | Reference |
+==========+======================+===========+
| TBA9 | DTLS Chunk Error | RFC-To-Be |
+----------+----------------------+-----------+
| TBA10 | Policy Not Met | RFC-To-Be |
+----------+----------------------+-----------+
| TBA11 | No Common Protection | RFC-To-Be |
+----------+----------------------+-----------+
Table 8: Error Cause Codes Parameters
Registered
12.5. SCTP Payload Protocol Identifier
In the Stream Control Transmission Protocol (SCTP) Parameters group's
"Payload Protocol Identifiers" registry, IANA is requested to update
the entry depicted below in in Table 9 with a reference to this
document. The registry at time of writing was available at:
https://www.iana.org/assignments/sctp-parameters/sctp-
parameters.xhtml#sctp-parameters-25
+==========+====================================+===========+
| ID Value | SCTP Payload Protocol Identifier | Reference |
+==========+====================================+===========+
| 4242 | DTLS Chunk Key-Management Messages | RFC-To-Be |
+----------+------------------------------------+-----------+
Table 9: Protection Operator Protocol Identifier Registered
13. Security Considerations
All the security and privacy considerations of the security protocol
used as the Chunk Protection Operator applies.
DTLS replay protection MUST NOT be turned off.
13.1. Privacy Considerations
Use of the SCTP DTLS chunk provides privacy to SCTP by protecting
user data and much of the SCTP control signaling. The SCTP
association is identifiable based on the 5-tuple where the
destination IP and port are fixed for each direction. Advanced
privacy features such as changing DTLS Connection ID and sequence
number encryption might therefore have limited effect.
Westerlund, et al. Expires 23 April 2026 [Page 41]
Internet-Draft SCTP DTLS Chunk October 2025
13.2. AEAD Limit Considerations
Section 4.5.3 of [RFC9147] defines limits on the number of records q
that can be protected using the same key as well as limits on the
number of received packets v that fail authentication with each key.
To adhere to these limits the key management function can
periodically poll the DTLS protection operation function to see when
a limit have been reached or is closed to being reached. Instead of
periodic polling, a callback can be used.
13.3. Downgrade Attacks
As long as the Key-management include the ordered list of protection
solutions indicators present in the parameter part of the INIT chunk
for the SCTP Association in its key-derivation the association will
be protected from down-grade.
In case any key-management do not include the parameter content in
its key-derivation down-grade might be possible if that key-
management method is selected. It is up to endpoint policies to
determine which protection it deems necessary against down-grade
attacks.
13.4. Persistent Secure Storage of Restart Key Context
The Restart DTLS Key Context needs to be stored securely and
persistent. Securely as access to this security context may enable
an attacker to perform a restart, resulting a denial of service on
the existing SCTP Association. It can also give the attacker access
to the ULP. Thus the storage needs to provide at least as strong
resistant against exfiltration as the main DTLS Key Context store.
When it comes to how to realize persistent storage that is highly
dependent on the ULP and how it can utilize restarted SCTP
Associations. One way can be to have an actual secure persistent
storage solution accessible to the endpoint. In other use cases the
persistence part might be accomplished be keeping the current restart
DTLS Key Context with the ULP State if that is sufficiently secure.
14. Acknowledgments
The authors thank Hannes Tschofenig and Tirumaleswar Reddy for their
participation in the design team and their contributions to this
document. We also like to thank Amanda Baber with IANA for feedback
on our IANA registry.
15. References
Westerlund, et al. Expires 23 April 2026 [Page 42]
Internet-Draft SCTP DTLS Chunk October 2025
15.1. Normative References
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol
(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
<https://www.rfc-editor.org/info/rfc4820>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011,
<https://www.rfc-editor.org/info/rfc6083>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[TLS-CIPHER-SUITS]
"TLS Cipher Suites", November 2023,
<https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#tls-parameters-4>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Westerlund, et al. Expires 23 April 2026 [Page 43]
Internet-Draft SCTP DTLS Chunk October 2025
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011,
<https://www.rfc-editor.org/info/rfc6458>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[I-D.ietf-tsvwg-rfc4895-bis]
Tüxen, M., Stewart, R. R., Lei, P., and H. Tschofenig,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", Work in Progress, Internet-Draft, draft-
ietf-tsvwg-rfc4895-bis-05, 21 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
rfc4895-bis-05>.
[I-D.ietf-tsvwg-dtls-chunk-key-management]
Tüxen, M., Tschofenig, H., and T. Reddy.K, "Using Datagram
Transport Layer Security (DTLS) for Key Management for the
Stream Control Transmission Protocol (SCTP) DTLS Chunk",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-dtls-
chunk-key-management-00, 4 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
dtls-chunk-key-management-00>.
[I-D.westerlund-tsvwg-sctp-DTLS-handshake]
Westerlund, M., Preuß Mattsson, J., and C. Porfiri,
"Datagram Transport Layer Security (DTLS) in the Stream
Control Transmission Protocol (SCTP) DTLS Chunk", July
2025, <https://datatracker.ietf.org/doc/draft-westerlund-
tsvwg-sctp-dtls-handshake/>.
[ETSI-TS-38.413]
"NG Application Protocol (NGAP) version 18.5.0 Release
18", n.d., <https://www.etsi.org/deliver/
etsi_ts/138400_138499/138413/18.05.00_60/
ts_138413v180500p.pdf>.
Authors' Addresses
Westerlund, et al. Expires 23 April 2026 [Page 44]
Internet-Draft SCTP DTLS Chunk October 2025
Magnus Westerlund
Ericsson
Email: magnus.westerlund@ericsson.com
John Preuß Mattsson
Ericsson
Email: john.mattsson@ericsson.com
Claudio Porfiri
Ericsson
Email: claudio.porfiri@ericsson.com
Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Westerlund, et al. Expires 23 April 2026 [Page 45]