



TSVWG                                                      M. Westerlund
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                              C. Porfiri
Expires: 28 February 2026                                       Ericsson
                                                                M. Tüxen
                                         Münster Univ. of Appl. Sciences
                                                          27 August 2025


         Stream Control Transmission Protocol (SCTP) DTLS Chunk
                  draft-ietf-tsvwg-sctp-dtls-chunk-00

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 28 February 2026                [Page 1]

Internet-Draft               SCTP DTLS Chunk                 August 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 28 February 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  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   5
     3.2.  DTLS Considerations . . . . . . . . . . . . . . . . . . .   7
     3.3.  SCTP DTLS Chunk Buffering and Flow Control  . . . . . . .   8
     3.4.  PMTU Considerations . . . . . . . . . . . . . . . . . . .   9
     3.5.  Congestion Control Considerations . . . . . . . . . . . .   9
     3.6.  ICMP Considerations . . . . . . . . . . . . . . . . . . .   9
     3.7.  Path Selection Considerations . . . . . . . . . . . . . .  10
     3.8.  Dynamic Address Reconfiguration Considerations  . . . . .  10
     3.9.  SCTP Restart Considerations . . . . . . . . . . . . . . .  10
       3.9.1.  Protected SCTP Restart  . . . . . . . . . . . . . . .  11
       3.9.2.  Compatibility with Legacy SCTP Restart  . . . . . . .  13
   4.  New Parameter Type  . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  DTLS 1.3 Chunk Protected Association  . . . . . . . . . .  14
   5.  New Chunk Type  . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  DTLS Chunk (DTLS) . . . . . . . . . . . . . . . . . . . .  15
   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Mandatory Protected Association Parameter Missing . . . .  17
     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  . . . . . . . . . .  19
   7.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  19



Westerlund, et al.      Expires 28 February 2026                [Page 2]

Internet-Draft               SCTP DTLS Chunk                 August 2025


     7.1.  Establishment of a Protected Association  . . . . . . . .  19
       7.1.1.  Offering Multiple Security Solutions  . . . . . . . .  20
     7.2.  Termination of a Protected Association  . . . . . . . . .  20
     7.3.  Considerations on Key Management  . . . . . . . . . . . .  21
   8.  DTLS Chunk Handling . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Sending of DTLS Chunks  . . . . . . . . . . . . . . . . .  22
     8.2.  Receiving of DTLS Chunks  . . . . . . . . . . . . . . . .  22
   9.  Abstract API  . . . . . . . . . . . . . . . . . . . . . . . .  23
     9.1.  Cipher Suit Capabilities  . . . . . . . . . . . . . . . .  23
     9.2.  Establish Client Write Keying Material  . . . . . . . . .  23
     9.3.  Establish Server Write Keying Material  . . . . . . . . .  24
     9.4.  Destroy Client Write Keying Material  . . . . . . . . . .  25
     9.5.  Destroy Server Write Keying Material  . . . . . . . . . .  25
     9.6.  Set Key to Use  . . . . . . . . . . . . . . . . . . . . .  26
     9.7.  Require Protected SCTP Packets  . . . . . . . . . . . . .  26
     9.8.  Get q . . . . . . . . . . . . . . . . . . . . . . . . . .  26
     9.9.  Get v . . . . . . . . . . . . . . . . . . . . . . . . . .  27
     9.10. Configure Replay Protection . . . . . . . . . . . . . . .  27
   10. Socket API Considerations . . . . . . . . . . . . . . . . . .  28
     10.1.  A New Flag for recvmsg() (MSG_PROTECTED) . . . . . . . .  28
     10.2.  Get the Supported Cipher Suits
            (SCTP_DTLS_SUPPORTED_CIPHER_SUITS) . . . . . . . . . . .  29
     10.3.  Get or Set the Local Protection Method Identifiers
            (SCTP_DTLS_LOCAL_PMIDS)  . . . . . . . . . . . . . . . .  29
     10.4.  Get the Remote Protection Method Identifiers
            (SCTP_DTLS_REMOTE_PMIDS) . . . . . . . . . . . . . . . .  29
     10.5.  Set the Sender Keys (SCTP_DTLS_SET_SEND_KEYS)  . . . . .  29
     10.6.  Add Receive Keys (SCTP_DTLS_ADD_RECV_KEYS) . . . . . . .  29
     10.7.  Delete Receive Keys (SCTP_DTLS_DEL_RECV_KEYS)  . . . . .  29
     10.8.  Enforce Protection (SCTP_DTLS_ENFORCE_PROTECTION)  . . .  29
     10.9.  Get Statistic Counters (SCTP_DTLS_STATS) . . . . . . . .  29
   11. Implementation Considerations . . . . . . . . . . . . . . . .  29
     11.1.  Privacy Padding of SCTP Packets  . . . . . . . . . . . .  29
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     12.1.  Protection Error Cause Codes Registry  . . . . . . . . .  30
     12.2.  SCTP Protection Solution Identifiers . . . . . . . . . .  31
     12.3.  SCTP Chunk Type  . . . . . . . . . . . . . . . . . . . .  31
     12.4.  SCTP Chunk Parameter Types . . . . . . . . . . . . . . .  32
     12.5.  SCTP Error Cause Codes . . . . . . . . . . . . . . . . .  32
     12.6.  SCTP Payload Protocol Identifier . . . . . . . . . . . .  33
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  33
     13.1.  Privacy Considerations . . . . . . . . . . . . . . . . .  33
     13.2.  AEAD Limit Considerations  . . . . . . . . . . . . . . .  33
     13.3.  Downgrade Attacks  . . . . . . . . . . . . . . . . . . .  34
     13.4.  Persistent Secure Storage of Restart Key Context . . . .  34
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  34
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  34



Westerlund, et al.      Expires 28 February 2026                [Page 3]

Internet-Draft               SCTP DTLS Chunk                 August 2025


     15.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

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.8 and Section 3.9.  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.

3.  Overview







Westerlund, et al.      Expires 28 February 2026                [Page 4]

Internet-Draft               SCTP DTLS Chunk                 August 2025


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 illustrates the DTLS chunk processing in regard to SCTP and
   the Upper Layer Protocol (ULP) using DTLS 1.3 for key management.








































Westerlund, et al.      Expires 28 February 2026                [Page 5]

Internet-Draft               SCTP DTLS Chunk                 August 2025


          +---------------+ +-------------------------------+
          |      ULP      | |            DTLS 1.3           |
          |               | |    +---------------------+    |
          |               | | +->+    Key Exporter     +--+ |
          |               | | |  +---------------------+  | |
          |               | | |                           | |
          |               | | |  +---------------------+  | |
          |               | | +--+    Key Management   +  | |
          |               | | |  +---------------------+  | |
          |               | | |     +---+ +---+           | |
          |               | | |     | H | |   |           | |
          |               | | |     | a | |   |           | |
          |               | | | k   | n | | A |         k | |
          |               | | | e   | d | | l |         e | |
          |               | | | y   | s | | e |    ...  y | |
          |               | | | s   | h | | r |         s | |
          |               | | |     | a | | t |           | |
          |               | | |     | k | |   |           | |
          |               | | |     | e | |   |           | |
          |               | | |     +-+-+ +-+-+           | |
          |               | | |       |     |             | |
          |               | | |       +-----+---...       | |
          |               | | | ContentType |             | |
          |               | | |  +----------+----------+  | |
          |               | | +->|        Record       |  | |
          |               | |    | Protection Operator |  | |
          +               | |    +----------+----------+  | |
          +-------+-------+ +-----------------------------+-+
                  ^                          ^            |
                  |                          |            |
                  +--+-----------------------+            | keys
                PPID |                                    |
                     V                                    V
          +-----------------------------------------------+-+
          |                    +---------------------+    | |
          |        SCTP        |         Chunk       |<---+ |
          |                    | Protection Operator |      |
          |                    +---------------------+      |
          +-------------------------------------------------+

          Figure 1: DTLS Chunk Layering in Regard to SCTP and ULP

   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.




Westerlund, et al.      Expires 28 February 2026                [Page 6]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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
   SHUTDOWN-COMPLETE chunk.

   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, e.g.
   [I-D.westerlund-tsvwg-sctp-DTLS-handshake].  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.

   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



Westerlund, et al.      Expires 28 February 2026                [Page 7]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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 8).

   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.

3.3.  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.





Westerlund, et al.      Expires 28 February 2026                [Page 8]

Internet-Draft               SCTP DTLS Chunk                 August 2025


3.4.  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.

   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.5.  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.6.  ICMP Considerations

   The SCTP implementation will be responsible for handling ICMP
   messages and their validation as specified in [RFC9260] Section 10.
   This means that the ICMP validation needs to be done in relation to
   the actual sent SCTP packets with the DTLS chunk and not the
   unprotected payload.







Westerlund, et al.      Expires 28 February 2026                [Page 9]

Internet-Draft               SCTP DTLS Chunk                 August 2025


3.7.  Path Selection Considerations

   When an Association is multihomed there are multiple paths between
   Endpoints.  The selection of the specific path to be used at a
   certain time belongs to SCTP protocol that will decide according to
   [RFC9260].  The Chunk Protection Operator shall not influence the
   path selection algorithm, actually the Chunk Protection Operator will
   not even know what path is being used.

   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.

3.8.  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
   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.9.  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]; when unexpected INIT chunk is received unprotected, it
   SHALL be silently discarded to prevent denial of service attacks on
   the ongoing association.



Westerlund, et al.      Expires 28 February 2026               [Page 10]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   All implementations SHALL support receiving and processing unexpected
   INIT chunks protected by DTLS Chunk as described in Section 3.9.1.
   This as has minimal implementation burden as it only requires
   handling the restart DTLS Key Context and detect DTLS Chunks
   indicating the restart.

   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.9.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.9.2.

3.9.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 chunks are sent encrypted using DTLS
   Chunks.

   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.

   An SCTP endpoint wanting to be able to initiate a protected SCTP
   restart needs to store securely and persistent 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



Westerlund, et al.      Expires 28 February 2026               [Page 11]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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; these 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
          |                                             | -.
          +------------[DTLS CHUNK(INIT)]-------------->|   |
          |<---------[DTLS CHUNK(INIT-ACK)]-------------+   +-------
          |                                             |   | Using
          |                                             |   | SCTP
          +---------[DTLS CHUNK(COOKIE ECHO)]---------->|   | Chunks
          |<--------[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.

   The transport of INIT, INIT-ACK 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.











Westerlund, et al.      Expires 28 February 2026               [Page 12]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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 new DTLS
   keying 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.9.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 using unprotected INIT chunk.  The effect will be
   that the restart initiator will have its packet being 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 INIT chunk
   protected by DTLS chunk as described in Section 3.9.1, thus having
   the R bit (Restart Indicator) set in the DTLS Chunk (see Figure 4),
   will silently discard it.

   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.






Westerlund, et al.      Expires 28 February 2026               [Page 13]

Internet-Draft               SCTP DTLS Chunk                 August 2025


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).

      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)





Westerlund, et al.      Expires 28 February 2026               [Page 14]

Internet-Draft               SCTP DTLS Chunk                 August 2025


      This value holds the length of the parameter, which will be the
      number of Protection Solution fields (N) times two plus 4 and, if
      N is odd, plus 2 bytes of padding.

   Protection Solution fields: one or more 16-bit SCTP Protection
   Solution Identifiers:
      Each Protection Solution Identifier (Section 12.2) 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

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.








Westerlund, et al.      Expires 28 February 2026               [Page 15]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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
      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.




Westerlund, et al.      Expires 28 February 2026               [Page 16]

Internet-Draft               SCTP DTLS Chunk                 August 2025


6.1.  Mandatory 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, the responder endpoint SHALL raise a Missing Mandatory
   Parameter error.  The ERROR chunk will contain the cause code
   'Missing Mandatory Parameter' (2) (see [RFC9260] Section 3.3.10.7)
   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.

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.







Westerlund, et al.      Expires 28 February 2026               [Page 17]

Internet-Draft               SCTP DTLS Chunk                 August 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     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.1.

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
   "Error in DTLS Chunk" Section 6.2 and containing the Extra Cause "No
   Common Protection Solution".

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



Westerlund, et al.      Expires 28 February 2026               [Page 18]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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
   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 "Error in DTLS Chunk" Section 6.2 and
   containing the Extra Cause "No Common Protection Solution"
   Section 6.2.1.  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.




Westerlund, et al.      Expires 28 February 2026               [Page 19]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   When initiator and responder have agreed on a DTLS Chunk protected
   association 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 desired.

   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 SHALL ask SCTP endpoint for terminating an
   association when having an internal error or by detecting a security
   violation.  During the termination procedure all Control Chunks SHALL
   be protected except SHUTDOWN-COMPLETE.  The internal design of
   Protection Engines and their capability is out of the scope of the
   current document.




Westerlund, et al.      Expires 28 February 2026               [Page 20]

Internet-Draft               SCTP DTLS Chunk                 August 2025


7.3.  Considerations on Key Management

   It is up to the upper layer to manage the keys for the DTLS chunk.
   One example of such a in-band DTLS key management is
   [I-D.westerlund-tsvwg-sctp-DTLS-handshake].  The key management
   SHOULD use a dedicated PPID to ensure that the 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.

   To prevent downgrade attacks the key-management methods SHOULD
   include in its input to key derivation the offered list in priority
   order of protections solutions from the SCTP associations INIT
   chunk's DTLS 1.3 Chunk Protected Association parameter.  By both
   peers including the sent and received list, respectively, in the key
   derivation any downgrade will result in a key-missmatch between the
   SCTP assocation initiator and responder, resulting in the SCTP
   assocation failing after having installed key contexts, thus
   preventing any down-grade attempt to weaking the security.  Methods
   not including the list of offered protection solutions will enable a
   downgrade to such a key-management method.

8.  DTLS Chunk Handling

   The DTLS chunk MUST NOT be bundled with any other chunk.  In
   particular, it MUST be the first chunk.

      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





Westerlund, et al.      Expires 28 February 2026               [Page 21]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   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.

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
   DTLSCiphertest), 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.



Westerlund, et al.      Expires 28 February 2026               [Page 22]

Internet-Draft               SCTP DTLS Chunk                 August 2025


9.  Abstract API

   This section describes an abstract API that is needed between a key
   establishment part and the DTLS 1.3 protection chunk.  This is an
   example API and there are alternative implementations.

   This API enables the cryptographical protection operations by setting
   client/server write key and IV for primary and restart DTLS key
   context.  The key is the primary cryptograpical key used by the
   cipher suit for DTLS record protection (Section 5.2 of [RFC8446].
   The initilization vector (IV) is cryptographical random material used
   to XOR with the sequence number to create the nonce per Section 5.3
   of [RFC8446].

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

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



Westerlund, et al.      Expires 28 February 2026               [Page 23]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   *  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 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:

   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.



Westerlund, et al.      Expires 28 February 2026               [Page 24]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   *  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 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

   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



Westerlund, et al.      Expires 28 February 2026               [Page 25]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   *  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

9.7.  Require Protected SCTP Packets

   A function to configure an SCTP association to require that normal
   SCTP packets must be protected in a DTLS Chunk going forward.

   Parameters:

   *  SCTP Association

   Reply: Acknowledgement

9.8.  Get q

   Get q, the number of protected messages (AEAD encryption invocations)
   for a given epoch.

   Request : Get q

   Parameters :

   *  SCTP Association



Westerlund, et al.      Expires 28 February 2026               [Page 26]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   *  Restart indication

   *  DTLS CID

   *  DTLS Epoch

   Reply: q

   Parameters : non-negative integer

9.9.  Get v

   Get v, the number of attacker forgery attempts (failed AEAD
   decryption invocations) for a given epoch.

   Request : Get v

   Parameters :

   *  SCTP Association

   *  Restart indication

   *  DTLS CID

   *  DTLS Epoch

   Reply: v

   Parameters : non-negative integer

9.10.  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




Westerlund, et al.      Expires 28 February 2026               [Page 27]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   Parameters :

   *  SCTP Association

   *  Restart indication

   *  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.

   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.  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.

















Westerlund, et al.      Expires 28 February 2026               [Page 28]

Internet-Draft               SCTP DTLS Chunk                 August 2025


10.2.  Get the Supported Cipher Suits (SCTP_DTLS_SUPPORTED_CIPHER_SUITS)

10.3.  Get or Set the Local Protection Method Identifiers
       (SCTP_DTLS_LOCAL_PMIDS)

10.4.  Get the Remote Protection Method Identifiers
       (SCTP_DTLS_REMOTE_PMIDS)

10.5.  Set the Sender Keys (SCTP_DTLS_SET_SEND_KEYS)

10.6.  Add Receive Keys (SCTP_DTLS_ADD_RECV_KEYS)

10.7.  Delete Receive Keys (SCTP_DTLS_DEL_RECV_KEYS)

10.8.  Enforce Protection (SCTP_DTLS_ENFORCE_PROTECTION)

10.9.  Get Statistic Counters (SCTP_DTLS_STATS)

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.

   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.






Westerlund, et al.      Expires 28 February 2026               [Page 29]

Internet-Draft               SCTP DTLS Chunk                 August 2025


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 and the Protection Options identifiers for the PVALID
   chunk.  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

   *  One new SCTP Error Cause Code

   And finally the update of one registered SCTP Payload Protocol
   Identifier.

12.1.  Protection Error Cause Codes Registry

   IANA is requested to create a new registry called "Protection Error
   Cause Codes".  This registry is part of the Stream Control
   Transmission Protocol (SCTP) Parameters grouping.

   The purpose of this registry is to enable identification of different
   protection related errors when using DTLS chunk and a protection
   engine.  Entries in the registry requires a Meaning, a reference to
   the specification defining the error, and a contact.  Each entry will
   be assigned by IANA a unique 16-bit unsigned integer identifier.
   Values 0-65534 are available for assignment.  Value 65535 is reserved
   for future extension.  The proposed general form of the registry is
   depicted below in Table 3.

   +============+===============================+===========+=========+
   | Cause Code | Meaning                       | Reference | Contact |
   +============+===============================+===========+=========+
   |          0 | No Common Protection Solution | RFC-To-Be | Authors |
   +------------+-------------------------------+-----------+---------+
   |    1-65534 | Available for Assignment      | RFC-To-Be | Authors |
   +------------+-------------------------------+-----------+---------+
   |      65535 | Reserved                      | RFC-To-Be | Authors |
   +------------+-------------------------------+-----------+---------+

                   Table 3: Protection Error Cause Code

   New entries are registered following the Specification Required
   policy as defined by [RFC8126].




Westerlund, et al.      Expires 28 February 2026               [Page 30]

Internet-Draft               SCTP DTLS Chunk                 August 2025


12.2.  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 using the DTLS
   Chunk combined with a key-management method, offered as an
   alternative to DTLS chunk, or themselves want to use the PVALID
   message mechanism to detect downgrade attacks.  Any security solution
   that is offered through a parameter exchange during the SCTP
   handshake are potential to be included here.

   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: PVALID 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.3.  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





Westerlund, et al.      Expires 28 February 2026               [Page 31]

Internet-Draft               SCTP DTLS Chunk                 August 2025


               +==========+===================+===========+
               | ID Value | Chunk Type        | Reference |
               +==========+===================+===========+
               |     TBA6 | DTLS Chunk (DTLS) | RFC-To-Be |
               +----------+-------------------+-----------+

                    Table 5: New Chunk Type Registered

12.4.  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 6 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 6: New Chunk Type Parameters Registered

12.5.  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 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-24

               +==========+===================+===========+
               | ID Value | Error Cause Codes | Reference |
               +==========+===================+===========+
               |     TBA9 | DTLS Chunk Error  | RFC-To-Be |
               +----------+-------------------+-----------+

                  Table 7: Error Cause Codes Parameters
                                Registered









Westerlund, et al.      Expires 28 February 2026               [Page 32]

Internet-Draft               SCTP DTLS Chunk                 August 2025


12.6.  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 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-25

       +==========+====================================+===========+
       | ID Value | SCTP Payload Protocol Identifier   | Reference |
       +==========+====================================+===========+
       |     4242 | DTLS Chunk Key-Management Messages | RFC-To-Be |
       +----------+------------------------------------+-----------+

        Table 8: 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.

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.









Westerlund, et al.      Expires 28 February 2026               [Page 33]

Internet-Draft               SCTP DTLS Chunk                 August 2025


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

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>.







Westerlund, et al.      Expires 28 February 2026               [Page 34]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   [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>.

   [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





Westerlund, et al.      Expires 28 February 2026               [Page 35]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   [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.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

   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





Westerlund, et al.      Expires 28 February 2026               [Page 36]

Internet-Draft               SCTP DTLS Chunk                 August 2025


   Michael Tüxen
   Münster University of Applied Sciences
   Stegerwaldstrasse 39
   48565 Steinfurt
   Germany
   Email: tuexen@fh-muenster.de













































Westerlund, et al.      Expires 28 February 2026               [Page 37]
