Stream Control Transmission Protocol (SCTP) DTLS Chunk

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

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

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

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

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

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

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

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

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

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

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

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

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

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¶

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

• 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¶

• 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¶

• 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¶

Parameters :¶

• SCTP Association¶

• Restart indication¶

• Configuration parameters¶

Reply: Replay Protection Configured¶

Parameters : true or false¶

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

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

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

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

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

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¶

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¶

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¶

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¶

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

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

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

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