Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk

1.3.1. Benefits Compared to DTLS/SCTP

DTLS/SCTP as defined by [I-D.ietf-tsvwg-dtls-over-sctp-bis] has several important differences most to the benefit of DTLS in SCTP. This section reviews these differences.¶

• Replay Protection in DTLS/SCTP has some limitations due to SCTP-AUTH [RFC4895] and its interaction with the SCTP implementation and dependencies on the actual SCTP-AUTH rekeying frequency. DTLS in SCTP relies on DTLS mechanism for replay protection that can prevent both duplicates from being delivered as well as preventing packets from outside the current window to be delivered. Thus, a stronger protection especially for non-DATA chunk is provided and protects the SCTP stack from replayed or duplicated packets.¶

• Encryption in DTLS/SCTP is only applied to ULP data. For DTLS in SCTP all chunk types after the association has reached established state and the initial DTLS handshake has compeleted will be encrypted. This, makes protocol attacks harder as a third-party attacker will have less insight into SCTP protocol state. Also, protocol header information likes PPIDs will also be encrypted, which makes targeted attacks harder but may also make management and debugging harder.¶

• DTLS/SCTP Rekeying is complicated and require advanced API or user message tracking to determine when a key is no longer needed so that it can be discarded. A DTLS/SCTP key that is prematurely discarded can result in loss of parts of a user message and failure of the assumptions on the transport where the sender believes it delivered and the receiver never gets it. This usually will result in the need to terminate the SCTP association to restart the ULP session to avoid any issues due to inconsistencies. DTLS in SCTP is robustly handling of any early discard of the DTLS key-material after having switched to a new established DTLS connection and its key-material. Any outstanding packet that has not been decoded yet will simply be treated as lost between the SCTP endpoints, and SCTP's retransmission will retransmit any user message data that requires it. Also, the algorithm for when to discard a DTLS connection can be much simpler.¶

• DTLS/SCTP rekeying can put restrictions on user message sizes unless the right APIs exist to the SCTP implementation to determine the state of user messages. No such restriction exists in DTLS in SCTP.¶

• By using the DTLS chunk that is acting on SCTP packet level instead of user messages the consideration for extensions are quite different. Only extensions that would affect the common header or how packets are formed would interact with this mechanism, any extension that just defines new chunks or parameters for existing chunks is expected to just work and be secured by the mechanism. DTLS/SCTP instead interact with extensions that affects how user messages are handled.¶

• A known limitation is that DTLS in SCTP does not support more than 2¹⁴ bytes of chunks per SCTP packet. If the DTLS implementation does not support the full DTLS record size the maximum supported packet size might be even lower. However, this value needs to be compared to the supported MTU of IP, and are thus in reality often not an actual limitation. Only for some special deployments or over loopback may this limitation be visible. Also if the proposed extension to (D)TLS record sizes [I-D.mattsson-tls-super-jumbo-record-limit] are published and implemented this extension could be used to achieve full IP MTU (64k).¶

There are several significant differences in regard to implementation between the two realizations.¶

• DTLS in SCTP do requires the DTLS chunk to be implemented in the SCTP stack implementation, and not as an adaptation layer above the SCTP stack which DTLS/SCTP instead requires. This has some extra challenges for operating system level implementations. However, as some updates anyway will be required to support the updated SCTP-AUTH specficiation the implementation burden is likely similar in this regard.¶

• DTLS in SCTP implemented in operating system kernels will require that the DTLS implementation is split. Where the protection operations performed to create DTLS records needs to be implemented in the kernel and have an appropriate API for setting keying materia and managed the functions of the protection operation. While the DTLS handshake is residing as an application on top of SCTP interface.¶

• DTLS in SCTP can use a DTLS implementation that does not rely on features from outside of the core protocol, where DTLS/SCTP required a number of features as listed below:¶

  • DTLS Connection Index to identify which DTLS connection that should process the DTLS record.¶

  • Support for DTLS records of the maximum size of 16 KB.¶

  • Optional to support negotiation of maximum DTLS record size unless not supporting 16 KB records when it is required. Even if implementing the negotiation, interoperability failure may occur. DTLS in SCTP will only require supporting DTLS record sizes that matches the largest IP packet size that endpoint support or the SCTP implementation.¶

  • Implementation is required to support turning off the DTLS replay protection.¶

  • Implementation is required to not use DTLS Key-update functionality. Where DTLS in SCTP is agnostic to its usage, and it provides a useful tool to ensure that the key lifetime is not an issue.¶

The conclusion of these implementation details is that DTLS in SCTP can use existing DTLS implementations, at least for user land SCTP implementation. It is not known if any DTLS 1.3 stack exist that fully support the requirements of DTLS/SCTP. It is expected that a DTLS/SCTP implementation will have to also extend some DTLS implementation.¶

4.1.1. PROTECTION INITILIZATION state

When entering PROTECTION INITILIZATION state, DTLS will start the handshake according to Section 6.1.¶

DTLS being initialized for a new SCTP association will set the Traffic DCI counter = 0, which implies a DCI field value of 0, for the initial DTLS connection. The DTLS handshake messages are transmitted from this endpoint to the peer using SCTP User message Section 3 with the PPID value set to DTLS-SCTP [I-D.westerlund-tsvwg-sctp-dtls-chunk]. Note that in case of SCTP association restart, the negotiation of the new Traffic DTLS connection SHALL still use a new Traffic DCI counter = 0 as the restarting SCTP endpoint may not know the old traffic DCI counter value for the last active DTLS connection.¶

When in PROTECTION INITILIZATION state, DTLS in SCTP MAY create a DTLS connection for Restart purposes. Such Restart connection is identified by a Restart DCI, that is based on a DCI counter independent from the traffic DCI. Whilst the first Restart DCI has value = 0, further Restart DCI will be increased using the same procedure than Traffic DCI and implementing the same parallel connection mechanism (see Section 4.2.1 and Section 4.2.2).¶

When a successful handshake for the traffic DCI = 0 has been completed and the keying material is established for DTLS connection and set for the DCI the DTLS chunk Handler will perform validation and then move SCTP State Machine into PROTECTED state.¶

4.1.2. PROTECTED state

In the PROTECTED state the currently active DTLS connection is used for protection operation of the payload of SCTP chunks in each packet per below specification. When necessary to meet requirements on periodic re-authentication of the peer and establishment of new forward secrecy keys, the existing DTLS 1.3 connection is being replaced with a new one by first opening a new parallel DTLS connection as further specified in Section 7 and then close the old DTLS connection.¶

When in PROTECTED state, DTLS in SCTP if it has not yet been done, SHALL create a DTLS connection for Restart purposes.¶

4.1.3. SHUTDOWN states

When the SCTP association leaves the ESTABLISHED state per [RFC9260] to be shutdown the DTLS connection is kept and continues to protect the SCTP packet payloads through the shutdown process.¶

When the association reaches the CLOSED state as part of the SCTP association closing process all DTLS connections existing (traffic and restart) for this association are terminated without further transmissions, i.e. DTLS close_notify is not transmitted.¶

4.2.1. Add a New DTLS Connection

Either peer can add a new DTLS connection to the SCTP association at any time, but no more than 2 DTLS connections can exist at the same time per DTLS connection type (Traffic or Restart). The new DCI value shall be the last active Traffic or Restart DCI increased by one. What is encoded in the DTLS chunk and DTLS user messages are the DCI value modulo 4. This makes the attempt to create a new DTLS connection to use the same, known, value of DCI from either peer. A new handshake will be initiated by DTLS using the new DCI. Details of the handshake are described in Section 6.1.¶

As either endpoint can initiate a DTLS handshake at the same time, either endpoint may receive a DTLS ClientHello message when it has sent its own ClientHello. In this case the ClientHello from the endpoint that had the DTLS Client role in the establishment of the previous DTLS connection shall be continued to be processed and the other dropped.¶

When the handshake has been completed successfully, the new DTLS connection will be possible to use, if the handshake is not completed successfully, the new DCI value will not be considered used and a next DTLS handshake attempt will reuse that DCI.¶

4.2.2. Remove an existing DTLS Connection

A DTLS connection is removed when a newer DTLS connection is in use. It is RECOMMENDED to not initiate removal until at least one SCTP packet protected by the new DTLS connection has been received, and any transmitted packets protected using the new DTLS connection has been acknowledge, alternatively one Maximum Segment Lifetime (120 seconds) has passed since the last SCTP packet protected by the old DTLS connection was transmitted.¶

Either peers can initialize the removal of a DTLS connection from the current SCTP association when needed when a new have been established. The closing of the DTLS connection when the SCTP association is in PROTECTED and ESTABLISHED state is done by having the DTLS connection send a DTLS close_notify. When DTLS closure for a DTLS connection is completed, the related DCI information in the DTLS chunk is released.¶

4.3.1. Initiator

The below assumes that the Intitiator (I) are currentnly using key epoch N.¶

1. The endpoint Initiates the key update and generates the new key for Epoch N+1. Epoch N+1 transmission key-materaial is set for the current DCI and epoch N+1 but not yet enabled for use. DTLS generates DTLS records containing the KeyUpdate DTLS message and update_requested, which is then sent using SCTP user message (Section 3) to the responder.¶

2. Initiator receives a DTLS user message containing the DTLS ACK message acknowledging the reception of the KeyUpdate message sent in step 1. The Initiator actives the new Epoch N+1 key in the DTLS chunk for protection of future transmissions of SCTP packets. The epoch N send direction key can be removed from the DTLS chunk key store.¶

3. Initiator receives a DTLS user message with the Responder's KeyUpdate message. The initator generates the recevie keys for epoch N+1 using the received message and installs them in the DTLS chunks key store. Then it generates a DTLS ACK for the KeyUpdate and sends it to the responder as a SCTP user message.¶

4. When the first SCTP packet protected by epoch N+1 has been received and succesfully decrypted by DTLS chunk the epoch N reception keys can be removed. Although to deal with network reordering, a delay is RECOMMENDED.¶

This completes the key-update procedure.¶

Note that even if both endpoints runs the Initiator process the KeyUpdate will complete. The main difference is that step 3 may occur before step 2 has happened.¶

4.3.2. Responder

The process for a responder to a peer initiating KeyUpdate.¶

1. The responder receives an SCTP DTLS user message containing a KeyUpdate message. The epoch N+1 keys reception keys are generated and installed into the DTLS chunk key store. A DTLS ACK message is generated and transmitted to the peer using a SCTP user message.¶

2. The responder initiates its own Key Update by generating keys and creating the KeyUpdate message. The send direction keys for epoch N+1 is installed but not enabled for use. The KeyUpdate message is transmitted to the peer using a SCTP user message.¶

3. The responder receives a DTLS user message containing the DTLS ACK message acknowledging the reception of the KeyUpdate message sent in step 2. The responder actives the new Epoch N+1 key in the DTLS chunk for protection of future transmissions of SCTP packets. The epoch N send direction key can be removed from the DTLS chunk key store.¶

4. When the first SCTP packet protected by epoch N+1 has been received and succesfully decrypted by DTLS chunk the epoch N reception keys can be removed. Although to deal with network reordering, a delay is RECOMMENDED.¶

5.2.1. General

The DTLS Connection ID SHOULD NOT be included in the DTLS records as it is not needed, the DTLS chunk indicates which DTLS connection the DTLS records are intended for using the DCI bits. Avoiding overhead and addition implementation requirements on DTLS implementation.¶

The DTLS record length field is normally not needed as the DTLS Chunk provides a length field unless multiple records are put in same DTLS chunk payload or user message. If multiple DTLS records are included in one DTLS chunk payload or user message the DTLS record length field MUST be present in all but the last.¶

DTLS record replay detection MUST be used.¶

Sequence number size can be adapted based on how quickly it wraps.¶

Many of the TLS registries have a "Recommended" column. Parameters not marked as "Y" are NOT RECOMMENDED to support in DTLS in SCTP. Non-AEAD cipher suites or cipher suites without confidentiality MUST NOT be supported. Cipher suites and parameters that do not provide ephemeral key-exchange MUST NOT be supported.¶

5.2.2. Authentication and Policy Decisions

DTLS in SCTP MUST be mutually authenticated. Authentication is the process of establishing the identity of a user or system and verifying that the identity is valid. DTLS only provides proof of possession of a key. DTLS in SCTP MUST perform identity authentication. It is RECOMMENDED that DTLS in SCTP is used with certificate-based authentication. When certificates are used the application using DTLS in SCTP is responsible for certificate policies, certificate chain validation, and identity authentication (HTTPS does for example match the hostname with a subjectAltName of type dNSName). The application using DTLS in SCTP defines what the identity is and how it is encoded and the client and server MUST use the same identity format. Guidance on server certificate validation can be found in [I-D.ietf-uta-rfc6125bis]. DTLS in SCTP enables periodic transfer of mutual revocation information (OSCP stapling) every time a new parallel connection is set up. All security decisions MUST be based on the peer's authenticated identity, not on its transport layer identity.¶

It is possible to authenticate DTLS endpoints based on IP addresses in certificates. SCTP associations can use multiple IP addresses per SCTP endpoint. Therefore, it is possible that DTLS records will be sent from a different source IP address or to a different destination IP address than that originally authenticated. This is not a problem provided that no security decisions are made based on the source or destination IP addresses.¶

5.2.3. New Connections

Implementations MUST set up new DTLS connections before any of the certificates expire. It is RECOMMENDED that all negotiated and exchanged parameters are the same except for the timestamps in the certificates. Clients and servers MUST NOT accept a change of identity during the setup of a new connections, but MAY accept negotiation of stronger algorithms and security parameters, which might be motivated by new attacks.¶

Allowing new connections can enable denial-of-service attacks. The endpoints MUST limit the number of simultaneous connections to two.¶

To force attackers to do dynamic key exfiltration and limit the amount of compromised data due to key compromise, implementations MUST have policies for how often to set up new connections with ephemeral key exchange such as ECDHE. Implementations SHOULD set up new connections frequently to force attackers to dynamic key extraction. E.g., at least every hour and every 100 GB of data which is a common policy for IPsec [ANSSI-DAT-NT-003]. See [I-D.ietf-tls-rfc8446bis] for a more detailed discussion on key compromise and key exfiltration in (D)TLS.¶

For many DTLS in SCTP deployments the SCTP association is expected to have a very long lifetime of months or even years. For associations with such long lifetimes there is a need to frequently re-authenticate both client and server by setting up new connections. TLS Certificate lifetimes significantly shorter than a year are common which is shorter than many expected SCTP associations protected by DTLS in SCTP.¶

5.2.4. Padding of DTLS Records

Both SCTP and DTLS contains mechanisms to padd 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 Chunck [RFC4820] to generate a consistent SCTP payload size. Support of this chunk is only required on the sender side. 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 recommened 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.¶

5.2.5. DTLS 1.3

DTLS 1.3 is used instead of DTLS 1.2 being a newer protocol that addresses known vulnerabilities and only defines strong algorithms without known major weaknesses at the time of publication.¶

DTLS 1.3 requires rekeying before algorithm specific AEAD limits have been reached. Implementations MAY setup a new DTLS connection instead of using key-update.¶

In DTLS 1.3 any number of tickets can be issued in a connection and the tickets can be used for resumption as long as they are valid, which is up to seven days. The nodes in a resumed connection have the same roles (client or server) as in the connection where the ticket was issued. Resumption can have significant latency benefits for quickly restarting a broken DTLS/SCTP association. If tickets and resumption are used it is enough to issue a single ticket per connection.¶

The PSK key exchange mode psk_ke MUST NOT be used as it does not provide ephemeral key exchange.¶

6.1.1. Handshake of initial DTLS connection

The handshake of the initial DTLS connection is part of the DTLS in SCTP Association initialization. The initialization is split in three distinct phases:¶

• SCTP Handshake¶

• DTLS Handshake¶

• Validation¶

Moving towards next phase is possible only when the previous phase handshake is completed.¶

SCTP Handshake is strictly compliant to [RFC9260].¶

As soon the SCTP Association has entered the SCTP state PROTECTION INITILIZATION as defined by [I-D.westerlund-tsvwg-sctp-dtls-chunk] the DTLS handshake procedure is initiated by the endpoint that has initiated the SCTP association. The initial DTLS handshake or as a result of a SCTP association restart SHALL use DCI = 0;¶

The DTLS endpoint will send the DTLS message in one or more SCTP user message depending if the DTLS endpoint fragments the message or not Section 3. The DTLS instance SHOULD NOT use DTLS retransmission to repair any packet losses of handshake message fragment. Note: If the DTLS implementation support configuring a MTU larger than the actual IP MTU it MAY be used as SCTP provides reliability and fragmentation.¶

If the DTLS handshake is successful in establishing a security context to protect further communication and the peer identity is accepted the keying material is installed for the DTLS chunk. This then triggers validated of the association establishment (see Section 1.2) by handshaking PVALID chunks inside DTLS CHUNK payload.¶

Once the Association has been validated, then the SCTP association is informed that it can move to the PROTECTED state.¶

If the DTLS handshake failed the SCTP association SHALL be aborted and an ERROR chunk with the Error in Protection error cause, with the appropriate extra error causes is generated, the right selection of "Error During Protection Handshake" or "Timeout During Protection Handshake or Validation".¶

The Figure 4 shows a successfull handshake and highlits the different parts of the setup. DTLS handshake messages are transported by means of DATA Chunks with SCTP-DTLS PPID.¶

6.1.2. Handshake of further DTLS connections

When the SCTP Association has entered the PROTECTED state, each of the endpoint can initiate a DTLS handshake for rekeying when necessary of the traffic or restart DTLS connections.¶

The DTLS endpoint will if necessary fragment the handshake into multiple records. Each DTLS handshake message fragment is sent as a SCTP user message Section 3. The DTLS instance SHOULD NOT use DTLS retransmission to repair any packet losses of handshake message fragment. Note: If the DTLS implementation support configuring a MTU larger than the actual IP MTU it could be used as SCTP provides reliability and fragmentation.¶

If the DTLS handshake failed the SCTP association SHALL generate an ERROR chunk with the Error in Protection error cause, with extra error causes "Error During Protection Handshake".¶

The DCI to be used for the handshake depends on the purpose of the DTLS connection. If this DTLS connection is being used for traffic purpose, DCI value is computed as the last active Traffic DCI increased by one modulo 4. If this DTLS connection is being used for Restart purpose DCI value is computed as the last active Restart DCI increased by one modulo 4 and setting R bit to 1.¶

The Figure 5 shows a successfull handshake of a further DTLS connection. Such connections can be initiated by any of the peers. Same as during the initial handshake, DTLS handshake messages are transported by means of DATA chunks with SCTP-DTLS PPID.¶

6.2.1. Handshake of initial DTLS Restart connection

As soon as the Association has reached the PROTECTED INITILIZATION state, a DTLS Restart connection MAY be instantiated. The instantiation of the initial DTLS Restart connection follows the rules given in Section 6.1.2 where the DCI = 0 (that is initial DCI = 0) and R bit = 1. Unless a SCTP association restart has happened and the restart DCI has been used. In this case a new restart DTLS connection SHALL be established using a restart DCI counter of the current + 1.¶

It MAY exist a time gap where the Association is in PROTECTED state but no DTLS Restart connection exists yet. If a SCTP Restart procedure will be initiated during that time, it will fail and the Association will also fail.¶

Once initiated, no traffic will be sent over the Restart DTLS connection so that both endpoints will have a known DTLS record state.¶

6.2.2. Handshake of further DTLS Restart connection

After the initial DTLS Restart connection has been established, at least an active DTLS Restart connection shall exist in a known state. It is recommended that updating of DTLS Restart connection follows the same times and rules as the traffic DTLS connections and is implemented by following the rules described in Section 7.¶

The next DTLS Restart DCI is computed as described in Section 4.2.1.¶

The handshake of further DTLS Restart Connection is sequenced as follows:¶

• Perform the DTLS Handshake as described in Section 6.1.2 on the next Restart DCI¶

• The Responder will store the new key before sending DTLS ACK¶

• The Initiator at reception of DTLS ACK will initiate closing the current Restart DCI¶

• The Responder will reply to the DTLS Close and remove the old key¶

• The Initiator receives the answer and remove the old key¶

6.2.3. SCTP Association Restart Procedure

The DTLS in SCTP Association Restart is meant to preserve the security characteristics.¶

In order the Association Restart to proceed both Initiator and Responder SHALL use the same Restart DCI for COOKIE-ECHO/COOKIE-ACK handshake, that implies that the Initiator must preserve the Key for that DCI and that the Responder SHALL NOT change the Key for the Restart DCI during the Restart procedure.¶

The Figure 6 shows a successfull SCTP Association Restart.¶

From procedure viewpoint the sequence is the following:¶

• Initiator sends plain INIT (VTag=0), Responder replies INIT-ACK¶

• Initiator sends COOKIE-ECHO using DTLS CHUNK encrypted with the Key tied to the Restart DCI¶

• Responder replies with COOKIE-ACK using DTLS CHUNK encrypted with the Key tied to the Restart DCI¶

• Initiator sends handshakes for new Traffic DTLS connnection as well as new Restart DTLS connection.¶

• When the handshake for the a new traffic DTLS connection has been completed, the DCI used to protect any SCTP chunks is switched from the restart DCI to the new traffic DCI enabling the Validation and transit to PROTECTED state.¶

User Data for any ULP traffic MAY be initiated immediately after COOKIE-ECHO/COOKIE-ACK handshake using the current Restart DCI, that is even before a new Traffic DCI or a Restart DCI have been handshaked. If a problem occurs before the new Restart DCI has been handshaked, the Association cannot be Restarted, thus it's RECOMMENDED the new Restart DCI to be handshaked as early as possible.¶