Stream Control Transmission Protocol (SCTP) DTLS Chunk

3.1. Protocol Overview

The DTLS chunk is defined as a method for secure and confidential transfer for SCTP packets. This is implemented inside the SCTP protocol, in a sublayer between the SCTP common header handling and the SCTP chunk handling. Once an SCTP packet has been received and the SCTP common header has been used to identify the SCTP association, the DTLS chunk is sent to the DTLS Protection Operator that will perform replay protection, decrypt, verify authenticity, and if the DTLS chunk is successfully processed return the plain text SCTP payload containing the SCTP chunks, those chunks will then be handled according to their SCTP protocol specifications. Figure 1 illustrates the DTLS chunk layering in regard to SCTP and the Upper Layer Protocol (ULP).¶

Use of the DTLS chunk is defined per SCTP association.¶

In the outgoing direction, once the SCTP stack has created the unprotected SCTP packet payload containing control and/or DATA chunks, that payload will be sent to the DTLS Protection Operator to be protected. The format of the protected payload is a DTLS 1.3 record encapsulated in a SCTP chunk which is named the DTLS chunk.¶

The SCTP Protection Operator performs protection operations on the whole unprotected SCTP packet payload, i.e., all chunks after the SCTP common header. 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.¶

SCTP DTLS chunk capability is agreed by the peers at the initialization of the SCTP association. Until the DTLS protection has been keyed only plain text key-management traffic using a dedicated PPID (4242) may flow, no ULP traffic. The key management function uses an API to key the DTLS 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 defied in a seperate document [I-D.westerlund-tsvwg-sctp-DTLS-handshake].¶

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 supress duplicated DTLS chunks, however a failure to prevent replay will only result in duplicated SCTP chunks and will be handled as duplicated chunks by SCTP endpoint in the same way a duplicated SCTP packet with those SCTP chunks would have been.¶

3.2. DTLS Considerations

The DTLS Chunk architecture splits DTLS 1.3 as shown in Figure 1, where there's a Key Management functionality on top of SCTP Chunks Handler and a Protection Operator functionality interfacing DTLS Chunk Handler.¶

Key Management is the set of data and procedures that take care of key distribution, verification, and update, DTLS connection setup, update and maintenance.¶

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

A Key Management using DTLS when it has established a DTLS 1.3 connection, it can derive traffic and restart keys and set the Protection Operator for User Data encryption/decription via the API shown in Figure 1 to create the necessary DTLS key contexts. Both a DTLS Key context for traffic and a DTLS Key contect for restart should be created.¶

DTLS 1.3 handshake messages, that are transported as SCTP User Data with dedicated PPID = 4242, SHALL be sent and received as plain DATA chunks until the Association has reached the VALIDATION state (Section 8.3). From that time on, DTLS 1.3 handshake messages SHALL be transported as SCTP User Data with dedicated PPID = 4242 within DTLS chunks, same as any ULP data traffic.¶

In this document we use the terms DTLS Key context for indicating a Key, derived from a DTLS connection, and all relevant data that needs to be provided to the Protection Operator for DTLS encryption and decryption. DTLS Key context includes Keys for sending and receiving, replay window, last used sequence number. Each DTLS key context are associated with a four value tuple identifying the context, consisting of SCTP Association, the restart indicator, the DTLS Connection ID (if used), an 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 key context for any SCTP association and DTLS connection ID (if used) SHALL use epoch=3. This ensures that the epoch of the key context will normally match the epoch of the DTLS key-management connection.¶

3.3. SCTP DTLS Chunk Buffering and Flow Control

DTLS 1.3 operations and SCTP are asynchronous, meaning that the 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 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 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 Protection Operator discards packets due to replay protection, or integrity errors depending on network induced bit errors or malicous 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 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 Protection Operator shall not influence the path selection algorithm, actually the 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 accomodate latency differencies.¶

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

The SCTP Restart procedure is defined to maintain the security characteristics of an SCTP Association using DTLS Chunk, this requires that SCTP Restart procedure is modified in regards to how it is described in [RFC9260].¶

In order to support 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 shall ensure that Restart DTLS key contexts is preserved for supporting the SCTP Restart use case.¶

In order for the protected SCTP endpoint to be available for SCTP Restart purposes, the DTLS chunk needs acess 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 that want to enable itself initiating a SCTP restart needs to store the restart Keys, DTLS conenction ID (if used) and related DTLS epoch, indexed so that when performing a restart with the peer node it had an protected SCTP association with can identify the right restart Key and DTLS epoch and initialize the restart DTLS Key Context for when restarting the SCTP assocation. The keys, DTLS connection ID, and epoch needs to be stored safely so that they survive the events that are causing SCTP Restart procedure to be used, for instance a crash of the SCTP stack.¶

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 point having completed the key-management exchange but failing to commit the DTLS Key Context to secure storage could result in lost of the latest DTLS Key Context . Therefore, the endpoints SHOULD retain the old restart DTLS key context for at least 30 seconds after having the next installed. However, the old restart DTLS Key Context SHOULD NOT be maintained for more than 5 minutes.¶

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 statemachine after having reached ESTABLISHED state moves automatically to PROTECTED state.¶

A restarted SCTP Association SHALL continue to use the Restart DTLS Key Context, for User Traffic until a new traffic DTLS Key Context will be available. The implementors SHOULD initiate a new DTLS keying as soon as possible, and derive the traffic 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 assocation.¶

After restart the next traffic key SHALL use epoch=3, i.e. the epoch value is reseted. Note that if the restart epoch used also was 3 when not using any DTLS connection ID, then the installation of the new restart key context needs to be done with some care to avoid dropping valid packets. After having derived new traffic keys the endpoint installs the Traffic DTLS Key Context first, and start using it. The new restart DTLS Key Context is only installed after any old in-flight restart packets have had a chance to be received.¶

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: zero or more 16-bit SCTP Protection Solution Identifers:

Each Protection Solution Identifer (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 include all of the offered solutions which it supports and list 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 an 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 encrypted data as one DTLS 1.3 Record [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.¶

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

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

7.3. Critical Error from DTLS

DTLS Protection Operator MAY inform local SCTP endpoint about errors. When an Error in the DTLS 1.3 compromises the protection mechanism, the 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.¶

7.4. Non-critical Error in the Protection

A non-critical error in DTLS Protection Operator means that the Protection Operator is capable of recovering without the need of the whole SCTP Association to be restarted.¶

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 Protection Operator will experience a non-critical error, an ABORT chunk SHALL NOT be sent.¶

8.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 and any its set of supported key-management solutions, and the selected to be used among the common set listed first.¶

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 by security policy accepted security solution as an error, thus it will reply with an ABORT chunk according to what specified in Section 7.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. However, before the SCTP assocation is protected by the DTLS 1.3 Chunk some additional states needs to be passed. First the DTLS Chunk needs be initializied in the PROTECTION INTILIZATION state. This MAY be accomplished by the procedure defined in [I-D.westerlund-tsvwg-sctp-DTLS-handshake]. When that has been accomplished one enters the VALIDATION state where one validates the exchange of the DTLS 1.3 Chunk Protected Association Parameter and any alternative protection solutions. If that is successful one enters the PROTECTED state. This state sequence is depicted in Section 8.3.¶

Until the procedure has reached the PROTECTED state the only usage of DATA Chunks that is accepted is DATA Chunks with the SCTP-DTLS PPID value 4242 used to exchange in-band key establishment messages. Any other DATA chunk being received in a Protected association SHALL be silently discarded.¶

If in-band DTLS handshake [I-D.westerlund-tsvwg-sctp-DTLS-handshake] is used to establish the security parameters for the DTLS Chunks, DTLS 1.3 initializes itself by transferring its own handshake messages as payload of the DATA chunk. The DTLS Chunk initialization SHOULD be supervised by a T-valid timer that accomodates DTLS 1.3 handshake and may also be further adjusted based on whether expected RTT values are outside of the ones commonly occurring on the general Internet, see Section 8.5. The Association initiator and responder will independently enter VALIDATION state when the security parameters are locally installed for the DTLS chunk. During VALIDATION state both initiator and responder SHALL handle plain text chunks as well as DTLS chunks.¶

In case of T-valid timeout, the endpoint will generate an ABORT chunk. The ERROR handling follows what specified in Section 7.2.1.¶

When DTLS Key Context have been installed, the initiator key-management function MUST send to the responder a PVALID message (see Figure 5) containing indication of all offered protection solutions previously sent in the INIT chunk in the DTLS 1.3 Chunk Protected Association parameter. The transmission of the PVALID message is done using PPID=XX on stream=0 using a reliable SCTP user message. The responder receiving the PVALID message will compare the indicated solutions with the ones previously received in the parameter in the INIT chunk. The responder will ignore unknown parameters and security solutions. For the supported solutions if the parameters in the INIT matches what is listed in the PVALID and there are no additional by the endpoint supported solution in the PVALID, it will reply to the initiator with a PVALID message containing the content of parameter sent in the INIT-ACK, otherwise it will reply with an ABORT chunk. ERROR CAUSE will indicate "Failure in Validation" and the SCTP association will be terminated. If the association was not aborted the protected association is considered successfully established and the PROTECTED state is entered.¶

When the initiator receives the PVALID message, it will compare with the previous chosen option and in case of mismatch with the one received previously in the protected association parameter in the INIT-ACK chunk, it will reply with ABORT with the ERROR CAUSE "Failure in Validation", otherwise the protected association is successfully established and the initiator enters the PROTECTED state.¶

If T-valid timer expires either at initiator or responder, the endpoint will generate an ABORT chunk. The ERROR handling follows what specified in Section 7.2.3.¶

In the PROTECTED state any ULP SCTP messages for any PPID SHALL be exchanged in the protected SCTP association.¶

When entering the PROTECTED state, a Restart DTLS Key for the current epoch SHOULD be provided into the DTLS key context store for the SCTP association.¶

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

8.3. Protection Initialization State Machine

8.4. Considerations on Key Management

When the Association is in PROTECTION INITIALIZATION state, in-band DTLS key management, e.g. [I-D.westerlund-tsvwg-sctp-DTLS-handshake], SHALL use SCTP user messages with the SCTP-DTLS PPID value = 4242 (see Table 8) for message transfer that will be sent and received unencrypted.¶

When the Association is in DTLS chunk PROTECTED state and the SCTP assocation is in ESTABLISHED or any of the states that can be reached after ESTABLISHED state, in-band key management are RECOMMENDED to use SCTP Data chunk with dedicated PPID value = 4242, those chunks SHALL be sent and received using DTLS Chunks with the current DTLS Key context.¶

The use of plain DATA chunk with PPID value = 4242 before the association reaches the PROTECTED state cannot be avoided as no valid DTLS key context exist until that state. Further in-band key management SHALL NOT use plain DATA chunks as this would allow attackers to inject overlapping DATA chunks with protected and impact the content of the SACK block. Based on that, as soon as the initiator or responder independently enter PROTECTED state, they will silently discard any plain chunks. Plain chunks that were sent but not received yet will also be discarded as the SCTP protocol does guarantee the needed retransmissions.¶

8.5. Consideration on T-valid

The timer T-Valid supervises initializations that depend on how the handshake is specified for the key establishment used for the DTLS 1.3 chunk and also on the characteristics of the transport network.¶

This specification recommends a default value of 30 seconds for T-valid.¶

9.1. Protected Data Chunk Transmission

When DTLS Chunk has reached the VALIDATION and PROTECTED state, the DTLS chunk handler will receive control chunks and DATA chunks from the SCTP chunk handler as a complete SCTP payload with maximum size limited by PMTU reduced by the size of the SCTP common header and the DTLS chunk overhead.¶

That plain payload will be sent to the Protection Operator in use for that specific association, the Protection Operator will return an encrypted DTLS 1.3 record.¶

An SCTP packet containing an SCTP DTLS chunk SHALL be delivered without delay, and SCTP chunk bundling [RFC9260] SHALL NOT be performed.¶

9.2. Protected Data Chunk Reception

When the DTLS Chunk state machine has reached the VALIDATION or PROTECTED state, the DTLS chunk handler will receive DTLS chunks from the SCTP Header Handler. Payload from DTLS chunks will be forwarded to the Protection Operator which will return a plain SCTP Payload, assuming verified authenticty and no replay. The plain SCTP payload will be forwarded to SCTP Chunk Handler that will split it in separated chunks and will handle them according to [RFC9260].¶

If a SCTP packet with more than one DTLS chunk is received, thus bundling multiple chunks, the receiver SHALL handle the first DTLS chunk and ignore any subsequent chunk.¶

Metadata, such as ECN, reception time, IP packet size, source and destination address or path ID, belonging to the received SCTP packet SHALL be tied to the relevant set of chunks and forwarded transparently to the SCTP endpoint.¶

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

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

Paramters :¶

• SCTP Assocation:

  Reference to the relevant SCTP assocation to set the keying material for.¶

• Restart indication:

  A bit indicating wheter 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 Assocation, 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¶

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

Paramters :¶

• SCTP Assocation:

  Reference to the relevant SCTP assocation to set the keying material for.¶

• Restart indication:

  A bit indicating wheter 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 Assocation, 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¶

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

Paramters :¶

• SCTP Association¶

• Restart indication¶

• DTLS CID¶

• DTLS Epoch¶

Reply: Destroyed¶

Parameters : true or false¶

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

Paramters :¶

• SCTP Association¶

• Restart indication¶

• DTLS CID¶

• DTLS Epoch¶

Reply: Destroyed¶

Parameters : true or false¶

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

Paramters :¶

• SCTP Association¶

• Restart indication¶

• DTLS CID¶

• DTLS Epoch¶

Reply: Key set¶

Parameters : true or false¶

10.7. Get q

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

Request : Get q¶

Paramters :¶

• SCTP Association¶

• Restart indication¶

• DTLS CID¶

• DTLS Epoch¶

Reply: q¶

Parameters : non-negative integer¶

10.8. Get v

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

Request : Get v¶

Paramters :¶

• SCTP Association¶

• Restart indication¶

• DTLS CID¶

• DTLS Epoch¶

Reply: v¶

Parameters : non-negative integer¶

10.9. 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 traffic/restart usages.¶

Request : Configure Replay Protection¶

Paramters :¶

• SCTP Association¶

• Restart indication¶

• Configuration parameters¶

Reply: Replay Protection Configured¶

Parameters : true or false¶

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 Types

In the Stream Control Transmission Protocol (SCTP) Parameters group's "Chunk Types" registry, IANA is requested to add the two new entries 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¶

Secondly it is requested that a new Payload Protocol Identifier is assigned to be used to identify the PVALID message Section 6.¶

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

The pvalid chunk provides a mechanism for preventing downgrade attacks that detects downgrading attempts between protection solutions and terminates the association. The chosen protection solution is the same as if the peers had been communicating in the absence of an attacker.¶

The initial handshake is verified before the DTLS Chunk is considered protected, thus no user data are sent before validation.¶

The downgrade protection is only as strong as the weakest of the supported protection solutions as an active attacker can trick the endpoints to negotiate the weakest protection solution and then modify the weakly protected pvalid chunks to deceive the endpoints that the negotiation of the Protection Operators is validated. This is similar to the downgrade protection in TLS 1.3 specified in Section 4.1.3. of [RFC8446] where downgrade protection is not provided when TLS 1.2 with static RSA is used. It is RECOMMENDED to only support a limited set of strongly profiled protection solutions.¶

15.1. Normative References

[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

[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", March 2025, <https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/>.