Method and system for using parallel Datagram Transport Layer Security (DTLS) connections over the Stream Control Transmission Protocol (SCTP)

Abstract

Embodiments include methods, electronic devices, storage media, and computer programs for implementing a parallel DTLS (Datagram Protocol Transport Layer Security) connection on an SCTP (Stream Control Transmission Protocol) association. In one embodiment, a method in a first network node for encoding a user message for secure transmission to a second network node includes initiating a DTLS connection on an SCTP (Stream Control Transmission Protocol) association through a DTLS handshake using an existing SCTP-AUTH (Authenticated Chunk for SCTP) key from an existing DTLS connection on the SCTP association to send the user message, deriving a new SCTP-AUTH key from the initiated DTLS connection, sending a further user message over the initiated DTLS connection using the new SCTP-AUTH key, and closing the existing DTLS connection on the SCTP association in response to confirmation that the SCTP packets encrypted with the existing DTLS connection and the SCTP packets authenticated by the existing SCTP-AUTH key have been delivered.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 270,064, filed on October 21, 2021, which is incorporated herein by reference.

[0002] Embodiments of the present invention relate to the field of networking, and more specifically, to using parallel Datagram Transport Layer Security (DTLS) connections over the Stream Control Transmission Protocol (SCTP).

Background Art

[0003] Signaling protocols in the 5th Generation (5G) network are used to transport sensible data that can be utilized to obtain information about mobile devices, their locations, and the like. For this purpose, in the 5G Radio Access Network (RAN), next - generation control plane interfaces such as the Next Generation Control (NG - C), Xn, E1, and F1 interfaces are used. Signaling data is encoded in Abstract Syntax Notation One (ASN.1) and transferred between nodes via the Stream Control Transmission Protocol (SCTP). The 3rd Generation Partnership Project (3GPP (registered trademark)) recommends protecting data with Internet Protocol Security (IPSec) for security and confidentiality. The size of the signal can be of any length, and there may be signals up to 144K bytes.

[0004] Since the connection between the IPSec gateway and the node is not protected, 3GPP also recommends adopting DTLS / SCTP for end-to-end protection. According to 3GPP, DTLS / SCTP protection is essential for node implementers and optional for operators to activate. However, SCTP associations can be very long-lived, sometimes having a lifetime measured in weeks or months, and peer nodes in end-to-end node connections need to have a solution for long-lived SCTP associations that support large SCTP messages.

Summary of the Invention

[0005] Embodiments include a method, a network node, a storage medium, and a computer program for implementing parallel Datagram Transport Layer Security (DTLS) connections on a Stream Control Transmission Protocol (SCTP) association. In one embodiment, a method in a first network node for encoding a user message for secure transmission to a second network node includes starting a DTLS connection on the SCTP association through a DTLS handshake using an existing SCTP-AUTH (Authenticated Chunk for SCTP) key from an existing DTLS connection on the SCTP association for transmitting the user message, deriving a new SCTP-AUTH key from the started DTLS connection, transmitting further user messages through the started DTLS connection using the new SCTP-AUTH key (210), and closing the existing DTLS connection on the SCTP association in response to confirmation that SCTP packets encrypted with the existing DTLS connection and SCTP packets authenticated with the existing SCTP-AUTH key have been delivered.

[0006] Embodiments include a network node for implementing parallel Datagram Transport Layer Security (DTLS) connections over a Stream Control Transmission Protocol (SCTP) association. In one embodiment, the network node comprises a processor and a non-transitory machine-readable storage medium providing instructions, which, when executed by the processor, cause the network node to start a DTLS connection over the SCTP association through a DTLS handshake using an existing SCTP-AUTH (Authenticated Chunk for SCTP) key from an existing DTLS connection on the SCTP association for sending user messages, derive a new SCTP-AUTH key from the started DTLS connection, use the new SCTP-AUTH key to send further user messages through the started DTLS connection, and close the existing DTLS connection on the SCTP association in response to confirmation that SCTP packets encrypted by the existing DTLS connection and SCTP packets authenticated by the existing SCTP-AUTH key have been delivered.

[0007] An embodiment includes a machine-readable storage medium for implementing parallel Datagram Transport Layer Security (DTLS) connections over a Stream Control Transmission Protocol (SCTP) association. In one embodiment, the machine-readable storage medium provides instructions that, when executed by a network node, cause the network node to start a DTLS connection over the SCTP association through a DTLS handshake using an existing SCTP-AUTH (Authenticated Chunk for SCTP) key from an existing DTLS connection on the SCTP association for sending user messages, derive a new SCTP-AUTH key from the started DTLS connection, use the new SCTP-AUTH key to send further user messages through the started DTLS connection, and close the existing DTLS connection on the SCTP association in response to confirmation that SCTP packets encrypted by the existing DTLS connection and SCTP packets authenticated by the existing SCTP-AUTH key have been delivered.

[0008] Embodiments of the present invention avoid the impact of an application pausing or at least delaying data transmission in a DTLS / SCTP session during key change data drain phases. Since DTLS protected records are self-describing and co-existable, the drain phase is avoided. Further, independent DTLS connection management enables explicit asynchronous close signaling when each side knows that all data using this key has been delivered first, resulting in closing down the connection and discarding the secret key material. )F

Brief Description of the Drawings

[0009] ​The present invention can be best understood by referring to the following description and the accompanying drawings used to illustrate embodiments of the present invention. In the drawings:

Figure 1

Figure 2

Figure 3

Figure 4

[0010] In general, all terms used in this specification should be interpreted according to their ordinary meanings in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which they are used. Any reference to an element, apparatus, component, means, step, etc. should be construed openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless otherwise specified. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless the step is explicitly described as after or before another step and / or it is implicit that the step must be after or before another step. Any feature of any embodiment disclosed herein may be applied to any other embodiment, where appropriate. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the embodiments included will become apparent from the following description.

[0011] 1. Introduction In the existing technology, it is difficult to implement a long - lived Stream Control Transmission Protocol (SCTP) association. For example, Datagram Transport Layer Security (DTLS) 1.3 does not support mutual authentication and does not enable rekeying (using Diffie - Hellman) of DTLS itself, and thus is not suitable for protecting long - lived (weeks and months) SCTP associations such as the basic form used in mobile networks. The procedure for DTLS (1.0 and 1.2) renegotiation according to IETF (Internet Engineering Task Force) RFC (Request for Comment) 6083, which handles key changes, requires draining, i.e., stopping transmission until all data is received, before the key change, which may affect the application. Note that the terms "association" and "SCTP association" are used interchangeably in this specification.

[0012] 1.1 Overview To overcome such problems, embodiments of the present invention establish a new DTLS connection in parallel with an existing DTLS connection on the same SCTP association, thereby enabling rekeying, mutual authentication, and updated certificates for a DTLS - protected SCTP association with minimal impact on the application for a long - lived SCTP association.

[0013] This can be done securely by mutual authentication in the DTLS handshake and the integrity and source authentication provided by SCTP-AUTH keyed by an existing DTLS connection. When a new handshake is performed and the security context and keys are established, both network node endpoints switch to using new keys for both DTLS records and the exported keys for SCTP-AUTH. DTLS records use the DTLS connection identifier (ID) function, and SCTP-AUTH uses its key-id mechanism to identify the correct context.

[0014] When each sender has ensured that all DTLS records and SCTP packets protected by the old SCTP-AUTH key have been successfully delivered, the old DTLS connection is closed unidirectionally. When both endpoints close the DTLS connection, all keys associated with this DTLS connection can be deleted. Thus, embodiments of the present invention enable the coexistence of two DTLS connections to have a minimal impact on the application and continue to maintain the assumed transport semantics for any SCTP message that should be reliably delivered.

[0015] In some embodiments, DTLS over SCTP is used with Authenticated Chunks for SCTP (SCTP-AUTH). DTLS can be implemented as specified in DTLS 1.2 [IETF RFC 6347] or DTLS 1.3 [IETF RFC 9147], while SCTP can be implemented as specified in [IETF RFC 4960] along with SCTP-AUTH [IETF RFC 4895]. Applications that use SCTP as the transport protocol may use these and other embodiments to provide mutual authentication of endpoints, confidentiality, integrity protection, and replay protection of user messages.

[0016] DTLS / SCTP uses SCTP and SCTP-AUTH for integrity protection and replay protection of user messages. Applications that use DTLS over SCTP can use almost all of the transport functions provided by SCTP and its extensions. DTLS / SCTP supports features including: 1) preservation of message boundaries, 2) multiple unidirectional and bidirectional streams, 3) ordered and unordered delivery of SCTP user messages, 4) partial reliability extensions as specified in [IETF RFC 3758], 5) dynamic address reconfiguration extensions as specified in [IETF RFC 5061], and 6) a user message size of up to 2^64-1. Unless otherwise noted, streams herein are unidirectional streams of an SCTP association and are uniquely identified by a stream identifier.

[0017] Some embodiments may require that the SCTP implementation support the optional feature of fragmentation of SCTP user messages as defined in [IETF RFC 4960]. The implementation is required to have an SCTP API (such as those described in [IETF RFC 6458]) that supports partial user message delivery, and it is recommended that I-DATA chunks as defined in [IETF RFC 8260] be used to efficiently implement and support larger user messages.

[0018] FIG. 1 shows a system diagram for providing extended DTLS / SCTP signaling and messaging according to some embodiments. FIG. 1 shows a node 100 that implements a traffic flow, and an application programming interface (API) 101 is an interface between an SCTP functional block (or module) 120 and an upper layer protocol to which messages are received or restored. A DTLS / SCTP functional block (or module) 110 is interposed between API 101 and SCTP functional block 120. In some embodiments, API 101 includes a DTLS API and an SCTP API.

[0019] The DTLS / SCTP functional block 110 uses DTLS and SCTP together to protect user messages and SCTP-AUTH keys. The DTLS / SCTP functional block 110 includes a parallel DTLS connection coordinator module 112 that implements embodiments of the present invention. In some embodiments, the DTLS / SCTP functional block 110 fragments messages from the upper layer protocol, provides the fragments to SCTP 120, defragments messages (SCTP packets) from SCTP 120, assembles them, and provides the assembled messages to the upper layer protocol.

[0020] The DTLS / SCTP functional block 110 includes a DTLS module 115, which implements the DTLS protocol and provides DTLS records with a size of up to 2^14 bytes. In some embodiments, the DTLS module 115 includes a TLS exporter 114, which exports a shared authentication key from the DTLS connection. The shared authentication key is paired with a key-id at reference number 116 and provides the key and the corresponding key-id to SCTP 120.

[0021] SCTP 120 is a functional block that implements the SCTP protocol, for example, in accordance with IETF RFC 4960 and various extensions or other IETF standard proposals. In some embodiments, the SCTP functional block 120 includes an SCTP-AUTH module 124 for receiving the shared authentication key and the corresponding key-id used for integrity protection, as detailed in section 4.7 below.

[0022] Restrictions are defined so that STARTTLS, as defined in [IETF RFC 3788], is no longer supported in some embodiments in order to simplify the implementation and reduce the risk of security holes.

[0023] 1.1.1. Comparison with TLS for SCTP When TLS is derived from DTLS, the TLS is designed to operate over a byte-stream-oriented transport protocol that provides reliable in-sequence delivery. TLS over SCTP, as described in [IETF RFC 3436], has several significant limitations: - It does not support unordered delivery of SCTP user messages; - It does not support partial reliability as defined in [IETF RFC 3758]; - It only supports the use of the same number of streams in both directions; and Use a TLS connection for each bi-directional stream, which requires a significant amount of resources and message exchange when a large number of streams are used.

[0024] 1.1.2. Changes from IETF RFC 6083 The DTLS over SCTP solution defined in IETF RFC 6083 had the following limitations: the maximum user message size was 2^14 (16384) bytes, which is the single DTLS record limit.

[0025] Embodiments of the present invention can replace IETF RFC 6083 and can include the following changes: - Remove the user message size limit by defining a secure fragmentation mechanism; - Mandate the need for a more recent DTLS version (DTLS 1.2 or 1.3); - Mandate the use of the latest hash-based message authentication code (HMAC: SHA-256) algorithm in the SCTP authentication extension [IETF RFC 4895]; - Recommend support for [IETF RFC 8260] to enable interleaving of large SCTP user messages to avoid scheduling issues; - Apply stricter requirements to always using DTLS for all user messages within an SCTP association; - Require that SCTP-AUTH be applied to all SCTP chunks for which authentication is possible; and - Require support for partial delivery of user messages.

[0026] 1.2. DTLS Version The DTLS / SCTP defined in this book can use either DTLS 1.2 [IETF RFC 6347] or DTLS 1.3 [IETF RFC 9147]. Generally, DTLS 1.3 is preferably a newer protocol that addresses known vulnerabilities and defines only strong algorithms that have no major weaknesses known at the time of publication.

[0027] Using DTLS 1.2 instead of DTLS 1.0 limits the lifetime of the DTLS connection and the amount of data that can be transferred over the DTLS connection. This is due to the following: - The number of renegotiations in DTLS 1.2 is limited to 65534 compared to the unlimited number in DTLS 1.0; and - The associated data authenticated encryption (AEAD) limits of DTLS 1.3 are not formally applicable to DTLS 1.2, but the mathematical limitations apply equally to DTLS 1.2.

[0028] DTLS 1.3 has the following numerous important changes: - Renegotiation is not supported and is instead partially replaced by KeyUpdates. The number of KeyUpdates is limited to 2^64. - In strict AEAD, the number of packets that can be sent before re-keying is severely limited.

[0029] Many applications that use DTLS / SCTP are of a semi-permanent nature, use SCTP associations with an expected lifetime of months or years, and it is quite costly to bring down the SCTP association to restart it. Such use of DTLS / SCTP requires: - Periodic re-authentication of both endpoints (not just the DTLS client); - Providing Perfect Forward Secrecy (PFS) by periodically re - executing Diffie - Hellman key exchange to reduce the impact of any key disclosure; and - Execute SCTP - AUTH re - keying.

[0030] At the time of publication, DTLS 1.3 does not support any of these, but the renegotiation function of DTLS 1.2 can provide this function in the context of DTLS / SCTP. To address these requirements from semi - persistent applications, embodiments of the present invention use several overlapping DTLS connections with either DTLS 1.2 or 1.3. By having a unified procedure, the impact during the upgrade from 1.2 to 1.3 is reduced, and the use of the renegotiation mechanism, which is disabled by default in many DTLS implementations, is avoided.

[0031] To address known vulnerabilities in DTLS 1.2, this specification describes and requires implementation constraints regarding cryptography, protocol options, and the use of the DTLS renegotiation mechanism.

[0032] In the remainder of this document, unless the DTLS version is specifically declared, this text applies to both versions of DTLS.

[0033] 2. Conventions In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" shall be interpreted as described in BCP 14 [IETF RFC 2119][IETF RFC 8174] only when written in all uppercase as shown below.

[0034] 3. DTLS Considerations 3.1. DTLS Version This document defines the use of DTLS 1.3 [I-D.ietf-tls-dtls13] or DTLS 1.2 [IETF RFC 6347]. Previous versions of DTLS MUST NOT be used (see [IETF RFC 8996]). The DTLS / SCTP described in this document is expected to operate with future versions of DTLS.

[0035] 3.2. Cipher Suites and Cipher Parameters For DTLS 1.2, cipher suites prohibited by [IETF RFC 7540] MUST NOT be used. For all versions of DTLS, cipher parameters that provide confidentiality and Perfect Forward Secrecy (PFS) MUST be used.

[0036] 3.3. Message Size DTLS / SCTP automatically fragments and reassembles user messages. This document defines how to split user messages into DTLS records, and each DTLS 1.3 record can use up to 2^14 protected bytes. Each DTLS record adds some overhead, so it is recommended to use the largest possible record size to minimize the overhead being sent.

[0037] Next, the sequence of DTLS records is fragmented into data or I-data chunks by SCTP to fit the path MTU. The largest possible user message using the mechanisms defined in this document is 2^64 - 1 bytes.

[0038] The security operation and reassembly process require that the protected user message, i.e., the message with DTLS record overhead, be buffered at the receiver. For this reason, this buffer space will impose a limit on the maximum size of the plaintext user message that can be transferred securely. However, by requiring the use of partial delivery of user messages from SCTP and assuming that two messages received on the same stream are not interleaved (as is the case when using the API defined in [IETF RFC 6458]), the buffering required before DTLS processing can be limited to a single DTLS record per incoming stream used.

[0039] As a result, the DTLS / SCTP implementation can provide the content of each DTLS record to the upper layer protocol (ULP) when it is decrypted and its integrity is verified, enabling partial delivery of user messages to the ULP. The implementation can trade off buffer memory requirements and transport overhead in the DTLS layer by using smaller DTLS records.

[0040] The DTLS / SCTP implementation is expected to behave very similarly to SCTP simply with respect to the processing of user messages, the processing of large user messages, and their reassembly and processing. Involve the ULP in handling resource contention related to large user messages.

[0041] 3.4. Replay Protection SCTP-AUTH [IETF RFC 4895] does not have explicit replay protection. However, the combination of the protection of SCTP-AUTH's DATA or I-DATA chunks and SCTP user message processing prevents attempts by third parties to inject or replay SCTP packets and affects the received protected user messages. In fact, the solutions in this document rely on SCTP-AUTH and SCTP to prevent the rearrangement, duplication, and deletion of DTLS records within each protected user message. This includes detecting changes in which DTLS records start and end SCTP user messages and deleting DTLS records before incrementing the epoch. Without SCTP-AUTH, all of these would require explicit processing.

[0042] DTLS optionally supports record replay detection. Such replay detection could result in the DTLS layer dropping valid messages received outside the DTLS replay window. Since DTLS / SCTP provides replay protection without DTLS replay protection, DTLS replay detection MUST NOT be used.

[0043] 3.5. Path MTU Discovery DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides path MTU discovery and fragmentation / reassembly for user messages, DTLS can send DTLS records of the maximum size according to Section 3.3.

[0044] 3.6. Message Resending SCTP provides a reliable in-sequence transport service for DTLS messages that require it. See Section 4.4. Therefore, DTLS procedures for resending MUST NOT be used.

[0045] 4. SCTP Considerations 4.1. Mapping of DTLS Records The SCTP implementation MUST support fragmentation of user messages using DATA [IETF RFC 4960] and optionally the I-DATA [IETF RFC 8260] chunk.

[0046] DTLS / SCTP functions as a shim layer between the user message API and SCTP. Fragmentation works in the same way as DTLS fragmentation of handshake messages. On the sending side, the user message is fragmented into fragments m0, m1, m2, each of which is 2^14 = 16384 bytes or less. m0 | m1 | m2 |... = user_message The resulting fragments are protected by DTLS and the records are concatenated user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 )... The new user_message', i.e., the protected user message, is the input to SCTP. On the receiving side, DTLS is used to decrypt the individual records. There are three failure cases that need to be detected by the implementation and then acted upon:

[0047] 1. Failure in the DTLS record decryption and integrity verification process. This should only occur in case of implementation errors or internal hardware failures, or if the required security context is prematurely discarded, due to SCTP-AUTH preventing the delivery of injected or corrupt fragments of the protected user message.

[0048] 2. When the SCTP layer receives MSG_EOR in a recvmsg() call when using the API described in, for example, [IETF RFC 6458], it indicates the end of a user message and the last buffered DTLS record length field does not match, i.e., the DTLS record is incomplete.

[0049] 3. Due to a shortage of resources such as memory, the decoding process cannot be executed and it is necessary to discard user message fragments. This specification is defined such that the resources required for DTLS / SCTP operation are limited for a given number of simultaneously transmitted SCTP streams or unordered user messages.

[0050] All of the above failure cases lead to the result that the receiver cannot reproduce a complete user message. This is a transport service failure that cannot be recovered in the DTLS / SCTP layer, and the sender may think that the complete message has been delivered. This error MUST NOT be ignored because SCTP lacks the function to declare a failure for a specific stream or user message, and the DTLS connection and SCTP association SHOULD be terminated. An effective exception to the termination of the SCTP association is when the receiver can notify the ULP about the delivery failure and the ULP can recover from this failure.

[0051] Note that when the SCTP extension for Partial Reliability (PR-SCTP: [IETF RFC 3758]) is used for user messages, the user messages can be delivered partially or discarded. These failures are not reasons to terminate the DTLS connection and SCTP association.

[0052] The DTLS connection ID MUST be negotiated (section 9 of [draft-ietf-tls-dtls-connection-id] or [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, a length field MUST be included and a 16-bit sequence number SHOULD be used.

[0053] Section 4 of [draft-ietf-tls-dtls-connection-id] states that "However, if an implementation chooses to accept CIDs of different lengths, the assigned CID value MUST be self-delineating since there is no other mechanism available to determine which connection (and hence which CID length) is being used." This solution requires multiple connection IDs, so using a CID of length zero is very problematic because a DTLS record with a zero-length CID could become a different DTLS connection context and fail decoding and integrity verification. In that case, the DTLS connection MUST be used to transfer to a zero-length CID so that decoding and verification are attempted. Resource utilization is improved. Therefore, it is RECOMMENDED not to use a zero-length CID value and instead use a single common length for CID values. Reusing old CIDs should be possible as long as the implementation ensures that they are not used in a time close to their previous use, so one byte should be sufficient.

[0054] 4.2 Handling of DTLS Connections DTLS connections MUST be established at the start of an SCTP association. When an SCTP association is terminated, all DTLS connections are terminated. DTLS connections MUST NOT span multiple SCTP associations.

[0055] Since establishing a DTLS connection is required at the start of an SCTP association, neither peer SHOULD send SCTP user messages that are not protected by DTLS. Therefore, it is a protocol violation for an endpoint to receive data that is neither a DTLS message on stream 0 nor a user message protected in the form of a sequence of DTLS records on any stream. The receiver MAY terminate the SCTP association due to this protocol violation.

[0056] Whenever mutual authentication, updated security parameters, re - execution of the Diffie - Hellman key exchange, or SCTP - AUTH re - keying is required, a new DTLS connection is set up in parallel with the old connection (i.e., there can be a maximum of two simultaneous DTLS connections within one association).

[0057] 4.3 Use of Payload Protocol Identifiers The SCTP payload protocol identifier is assigned by IANA. Application protocols that use DTLS over SCTP SHOULD register and use a distinct payload protocol identifier (PPID) and SHOULD NOT reuse the PPID registered for running directly over SCTP.

[0058] As long as the application can determine whether DTLS is being used or not, there is no harm in using the same PPID. However, it is much easier, for example, in the case of a protocol analyzer, when a distinct PPID is used.

[0059] This means, in particular, that there is no unique PPID for DTLS.

[0060] 4.4 Use of Streams All DTLS handshakes, alerts, or ChangeCipherSpec (DTLS 1.2 only) messages MUST be transferred on stream 0, which has the functionality of unlimited reliability and ordered delivery.

[0061] DTLS messages of the record protocol carrying protected user messages SHOULD use multiple streams other than stream 0 and MAY use stream 0. Since protected user messages and DTLS messages that do not record the protocol are mixed on stream 0, Additional ヘッドオブラインブロッキン g( head of line blocking) may occur.

[0062] 4.5 Handling of Chunks SCTP's DATA chunks MUST be sent in an authenticated way, as described in [IETF RFC 4895]. All other chunks that can be authenticated, i.e., all chunk types that can be listed in the Chunk List Parameter [IETF RFC 4895], MUST also be sent in an authenticated way. This makes it impossible for an attacker to change the stream on which a message is sent or to affect the ordered / unordered delivery of messages.

[0063] When the partially reliable SCTP (PR-SCTP: partial reliable SCTP) defined in [IETF RFC 3758] is used, the FORWARD-TSN chunks MUST also be sent in an authenticated way, as described in [IETF RFC 4895]. This ensures that it is impossible for an attacker to drop a message and hide this drop using forged FORWARD-TSN, SACK, and / or SHUTDOWN chunks.

[0064] The I-DATA chunk type defined in [IETF RFC 8260] is RECOMMENDED to be supported to avoid some of the downward aspects that a large user message has when blocking the transmission of a later-arriving high-priority user message. However, support is not mandatory and not negotiated independently of DTLS / SCTP. If I-DATA chunks are used, they MUST be sent in an authenticated way as described in [IETF RFC 4895].

[0065] 4.6 SCTP-AUTH Hash Functions When using DTLS / SCTP, the SHA-256 message digest algorithm MUST be supported in SCTP-AUTH [IETF RFC 4895] implementations. SHA-1 MUST NOT be used when using DTLS / SCTP. [IETF RFC 4895] requires support and inclusion of the HMAC-ALGO parameter, and therefore, to meet both requirements, the HMAC-ALGO parameter MUST include both SHA-256 and SHA-1 with SHA-256 listed before SHA-1 to indicate priority.

[0066] 4.7 Parallel DTLS Connections To enable re-keying of SCTP - AUTH, periodic authentication of both endpoints, and to force dynamic key extraction on the attacker, DTLS / SCTP according to this specification defines the use of parallel DTLS connections on the same SCTP association. This solution guarantees that there is no limit to the lifetime of the SCTP association by DTLS, and also avoids dependence on the properties of DTLS re - negotiation (DTLS 1.2 only) or key updates in DTLS 1.3 that do not permit mutual endpoint re - authentication. While existing DTLS is maintained as is, parallel DTLS connections enable opening a new DTLS connection that performs a full handshake and can use resumption. Upon completion of the handshake, switch to the security context of the new DTLS connection and ensure delivery of all SCTP chunks using the security context of the old DTLS connection. Once this is achieved, close the old DTLS connection and discard the associated security context.

[0067] As defined in Section 4.1, the use of the DTLS connection ID is required to ensure that the receiver can correctly identify the DTLS connection and its security context when performing its de - protection operation. Also, there is exactly one SCTP - AUTH key exported per DTLS connection, which guarantees a clear mapping between the DTLS connection and the SCTP - AUTH security context for each key - id, unless DTLS 1.2 re - negotiation is used when multiple keys can be exported.

[0068] Application writers should note that security parameters may change by establishing a new DTLS connection. See Section 8 for security considerations regarding re - keying.

[0069] A DTLS / SCTP endpoint MUST NOT open more than two DTLS connections simultaneously. Any endpoint MAY start a new DTLS connection by performing a complete DTLS handshake, and MAY use DTLS resumption if applicable. Since any endpoint can start a DTLS handshake on both sides simultaneously, any endpoint may receive a DTLS ClientHello when sending its own ClientHello. In this case, the ClientHello from the endpoint that has the role of the DTLS client in the establishment of the existing DTLS connection should continue to be processed, while the other is dropped.

[0070] When performing a DTLS handshake, an endpoint MUST verify that the peer identifies itself using the same identity as in the previous DTLS connection.

[0071] When the DTLS handshake is complete, a new SCTP-AUTH key (as shown in Figure 1) MUST be exported according to Section 4.9, and the new DTLS connection MUST be used for the DTLS protection operation of future protected SCTP messages. An endpoint is RECOMMENDED to use the security context of the new DTLS connection for the DTLS protection operations that occur after the handshake is complete. The new SCTP-AUTH key SHALL be used for any SCTP message that is sent after the DTLS handshake is complete. There is a possibility of using the new SCTP-AUTH key for any SCTP packet part of an SCTP message that was started but not yet fully sent before the completion of the new DTLS handshake, but the API defined in [IETF RFC 6458] does not support this unless the extensions in Section 6 are supported.

[0072] The SCTP endpoint notifies its peer when the previous DTLS connection and its context are no longer needed to receive any more data from this endpoint. This is done by causing DTLS to send a DTLS close_notify alert. The endpoint MUST NOT send close_notify until the following two conditions are met: - all SCTP packets containing any part of a DTLS record or message protected using the security context of this DTLS connection are acknowledged in a non-reproducible way; and - all SCTP packets using the SCTP-AUTH key associated with the security context of this DTLS connection are acknowledged in a non-reproducible way.

[0073] There is a very basic way to determine the above conditions for implementations that allow using the security context of a new DTLS connection for all future DTLS records to be protected, enabling the associated new SCTP-AUTH key simultaneously and not using the old context for future protection operations. Mark the time when the first SCTP chunk, which is part of the first (partial) SCTP message send call using the new security context, is sent. That SCTP chunk, and thus all previous chunks using the old security context, must be delivered to the peer before endpoint failure detection (see section 8.1 of [IETF RFC 4960]) triggers and terminates the SCTP association. Calculate the upper bound of this timeout period, which depends on two configurable parameters. The maximum endpoint failure timeout period is the product of the 'Association.Max.Retrans' and RTO.Max parameters. For the default values of 60 seconds for RTO.Max and a 10-minute time (i.e., 10 tries) [IETF RFC 4960].

[0074] In the case of an SCTP implementation that exposes an API such as [IETF RFC 6458], since it is impossible to change the SCTP - AUTH key of a partial SCTP message that was started before the security context was changed, it is necessary to track SCTP messages to determine the timing at which all messages using the old security context were sent. Without closer integration between the DTLS / SCTP layer and the SCTP implementation, it may not be possible to be fully reliable. This type of implementation also has an implicit limit on the size of the SCTP messages it can support. Each SCTP message needs to be able to complete delivery and close the previous DTLS connection before another DTLS connection needs to be created. For this reason, SCTP messages cannot be made larger than the time it takes for them to be sent within a time shorter than the duration during re - keying or re - authentication for this SCTP association.

[0075] If the DTLS / SCTP implementation is more tightly integrated with the SCTP stack or has a more complete API that allows it to know when an SCPT message was delivered, the old DTLS connection can be closed more timely and, thus, support more frequent re - keying, etc., as needed.

[0076] As a result of sending a DTLS close_notify alert on the old DTLS connection before the receiver receives the data, the failure case 1 described in Section 4.1 may occur, which may lead to the termination of the SCTP association.

[0077] 4.7b. Renegotiation and KeyUpdate Re - negotiation in DTLS 1.2 enables re - keying of DTLS (using ephemeral Diffie - Hellman) within a DTLS 1.2 connection, similar to mutual authentication. Re - negotiation has been removed from DTLS 1.3 and some of it has been replaced by post - handshake messages such as KeyUpdate. The parallel DTLS connection solution is defined because it lacks the functions required by DTLS 1.3, such as re - keying (using ephemeral Diffie - Hellman) in addition to mutual authentication, which are considered necessary for long - lived SCTP associations.

[0078] This specification recommends depending on parallel DTLS connections instead of using any of these mechanisms. There is no feature parity in the case of DTLS 1.3. Both DTLS implementations that follow standards such as IETF RFCs have the problem that they assume a window that is too limited for SCTP, where the security context of the previous epoch is maintained and thus a change to epoch handling (Section 4.8) is required. Therefore, there is a risk that the sender will lose data that is assumed to be reliably delivered, unless more applications defined below that affect draining are used.

[0079] 4.7b.1 Considerations for DTLS 1.2 After an endpoint starts establishing a new parallel DTLS connection in this SCTP association, it MUST NOT start DTLS re - negotiation in an existing / old DTLS connection. If a new DTLS connection handshake is received after an endpoint has started DTLS re - negotiation in an existing DTLS connection, both parties MUST complete the re - negotiation, the SCPT - AUTH key identifier should be n + 1, and the new DTLS connection should use n + 2. This can be achieved by first completing the re - negotiation and holding the new DTLS handshake process until the re - negotiation is complete.

[0080] Before sending a ClientHello message or a ServerHello message during re - negotiation, the DTLS endpoint MUST ensure that all DTLS messages using the previous epoch have been acknowledged by the SCTP peer in a non - cancellable way.

[0081] Before processing a received ClientHello message or ServerHello message, all other received SCTP user messages buffered in the SCTP layer and deliverable to the DTLS layer MUST be read and processed by DTLS.

[0082] 4.7b.2 Considerations for DTLS 1.3 Before sending a KeyUpdate message, the DTLS endpoint MUST ensure that all DTLS messages have been acknowledged by the SCTP peer in a non - cancellable way. After sending a KeyUpdate message, stop sending DTLS messages until the corresponding Ack message is processed.

[0083] Before processing a received KeyUpdate message, all other received SCTP user messages buffered in the SCTP layer and deliverable to the DTLS layer MUST be read and processed by DTLS.

[0084] 4.7c Operation Flow In some embodiments, establishing two parallel DTLS connections over an SCTP association involves the following operations:

[0085] 1. Start a new DTLS handshake protected by the existing SCTP - AUTH key. 2. Complete the DTLS handshake, establish a new security context, and export a new SCTP-AUTH key with a key identifier. 3. By starting to use the new DTLS connection and the established security context, protect the whole or fragments of messages from the upper layer protocol and stop using the previous DTLS connection to protect any new ULP messages. 4. Start using the new SCPT-AUTH key for any future SCTP packets or SCTP messages and do not use the old key for any new SCTP messages. 5. Each endpoint determines when all protected message fragments and SCTP packets have been delivered and closes the direction of the old DTLS connection. 6. When the DTLS connection is closed, delete the security context and the SCTP-AUTH key exported to this DTLS connection.

[0086] Figure 2 shows the operation of establishing parallel DTLS connections on an SCTP association, according to some embodiments. This operation can be performed by a network node implementing a parallel DTLS connection coordinator 112. The network node is, in some embodiments, a first network node that encodes user messages for secure transmission to a second network node.

[0087] In reference 202, the network node establishes a DTLS (Datagram Transport Layer Security) connection on an SCTP (Stream Control Transmission Protocol) association to send user messages for one or more applications. This DTLS connection is the first of two parallel DTLS connections on the same SCTP association and can also be referred to as an existing DTLS connection.

[0088] In Reference 204, the network node initiates a DTLS (Datagram Transport Layer Security) connection on an SCTP (Stream Control Transmission Protocol) association through a DTLS handshake using an existing SCTP-AUTH (Authenticated Chunks for SCTP) key from an existing DTLS connection on the SCTP association that sends user messages. The initiated DTLS connection is the second DTLS connection out of two parallel DTLS connections on the same SCTP association.

[0089] In Reference 206, the network node derives a new SCTP-AUTH key from the initiated DTLS connection. Optionally, in Reference 208, the network node sends ongoing SCTP packets that, in some embodiments, include further portions of user messages that are protected by the initiated DLTS connection but authenticated with the existing SCTP-AUTH key. Alternatively, the network node may send ongoing SCTP packets that include further portions of user messages that are to be protected by the existing DTLS connection and authenticated with the existing SCTP-AUTH key.

[0090] In Reference 210, the network node sends further user messages through the initiated DTLS connection using the new SCTP-AUTH key. In Reference 212, when the network node confirms that SCTP packets encrypted with the existing DTLS connection and SCTP packets authenticated with the existing SCTP-AUTH key have been delivered, the network node closes the existing DTLS connection on the SCTP association.

[0091] In some embodiments, closing an existing DTLS connection on an SCTP association includes sending a first DTLS connection close notification to a second network node. The first DTLS connection close notification may be the DTLS close_notify alert described above.

[0092] In some embodiments, closing an existing DTLS connection on an SCTP association further includes receiving a second DTLS connection close notification from the second network node.

[0093] In some embodiments, sending the first DTLS connection close notification includes verifying that, prior to sending the first DTLS connection close notification, transmitted data in the existing DTLS connection has been acknowledged in a non-renegable way by the second network node. For example, the verification includes verifying that 1) all SCTP packets, including any DTLS records or portions of messages protected using the security context of this DTLS connection, have been acknowledged in a non-renegable way, and / or 2) all SCTP packets using the SCTP-AUTH key associated with the security context of this DTLS connection have been acknowledged in a non-renegable way.

[0094] In some embodiments, existing and new SCTP-AUTH keys are identified by corresponding existing and new key identifiers (IDs), and the new KeyThe identifier is a value incremented by 1 from an existing key identifier. As shown in the above example, if the previous shared secret used the shared key identifier n, the new one uses the shared key identifier n+1. In some embodiments, modulo arithmetic may be performed. For example, the new shared key identifier is (n+1)mod 65535 in a 16-bit implementation (if the result = 0, it is set to 1; for example, if n = 65534, n+1 = 65535, and (n+1)mod(65535)=0, then the new key ID is 1). If the key ID is implemented with a different bit width, the divisor is also changed. For example, if the key ID is implemented with 8 bits, the divisor is 255.

[0095] In some embodiments, the DTLS connection is established before one or more certificates of an existing DTLS connection on the SCTP association become invalid. In some embodiments, initiating a DTLS connection on an SCTP association through a DTLS handshake includes maintaining one or more certificates of an existing DTLS connection that include timestamps within the one or more certificates.

[0096] In some embodiments, performing a handshake between a first network node and a second network node includes starting the handshake and, in response to receiving the initiation of the handshake, continuing the started handshake when the first network node functions as a DTLS client of the DTLS connection.

[0097] In some embodiments, an existing SCTP-AUTH key is deleted in response to the closure of an existing DTLS connection.

[0098] Embodiments of the present invention address data draining during key changes by existing solutions gfDuring the handshake, avoid the impact of the application that temporarily halts or at least delays data transmission in the DTLS / SCTP session. The DTLS protected record is self-describing (features of DTLS 1.3 and extensions of DTLS 1.2) and can coexist when the session ID is valid, so the dra ning phase is avoided. Further, independent DTLS connection management enables explicit asynchronous close signaling when each side knows that all data using this key has been delivered first, resulting in closing down the connection and discarding the secret key material. Therefore, parallel DTLS connections avoid some of the problems of using DTLS 1.2 in renegotiation. Also, it is guaranteed that important functions can be realized even when using DTLS 1.3.

[0099] 4.8 DTLS Epoch Generally, DTLS implementations SHOULD discard records from previous epochs. However, this is not appropriate in the context of reliable communication.

[0100] 4.8.1 Considerations for DTLS 1.2 MUST NOT follow the procedure in Section 4.1 of [IETF RFC 6347].

[0101] Instead, when currently using epoch n, for n > 1, MUST process DTLS packets from epochs n - 1 and n.

[0102] 4.8.2. Considerations for DTLS 1.3 The procedure in Section 4.2.1 of [I-D.ietf-tls-dtls13] is irrelevant. When receiving DTLS packets using epoch n, DTLS packets from previous epochs are not received.

[0103] 4.9. Handling of Endpoint Pair-Shared Secrets SCTP-AUTH [IETF RFC 4895] is keyed using an endpoint pair shared secret. In SCTP associations where DTLS is used, DTLS is used to establish these secrets. Endpoints MUST NOT use another mechanism to establish the SCTP-AUTH shared secret. The endpoint pair shared secret for shared key identifier 0 MUST be empty and MUST be used when establishing the first DTLS connection.

[0104] The initial DTLS connection MUST be used to establish a new shared secret as defined by the following DTLS version and MUST use shared key identifier 1. After sending the DTLS Finished message, the active SCTP-AUTH key MUST be switched to the new one. When the initial Finished message from the peer is processed by DTLS, the SCTP-AUTH key with shared key identifier 0 MUST be deleted.

[0105] When subsequent DTLS connections are set up, a new 64-byte shared secret is derived using TLS-Exporter. The shared secret identifiers form a sequence. If the previous shared secret used shared key identifier n, the new one MUST use shared key identifier n+1.

[0106] After sending the DTLS Finished message, the active SCTP-AUTH key MUST be switched to the new one. If an endpoint has sent and received closeNotify on an old DTLS connection, the endpoint MUST delete the (one or more) shared secrets associated with the old DTLS connection.

[0107] 4.9.1. Considerations for DTLS 1.2 Whenever the master secret changes, i.e., either due to DTLS renegotiation or the establishment of a new DTLS connection, a 64 - byte shared secret is derived from all master secrets and provided as a new endpoint - pair shared secret by using the TLS - Exporter described in [IETF RFC 5705].

[0108] The 64 - byte shared secret MUST be provided to the SCTP stack as soon as it is computable. The exporter MUST use the label given in Section 7 and MUST NOT use the context. The shared key identifier is selected according to the above such that it is n + 1 even for epoch changes due to renegotiation.

[0109] When a Finished message using DTLS epoch m where m>2 is processed by DTLS, the SCTP - AUTH key with the shared key identifier for this DTLS connection and epoch m - 2 MUST be deleted.

[0110] When a DTLS connection closes and it uses renegotiation, when a new DTLS connection creates n + 1, all undelleted shared keys MUST be deleted, which should be n and n - 1.

[0111] 4.9.2. Considerations for DTLS 1.3 When the exporter_secret is computable, a 64 - byte shared secret is derived from it and provided as a new endpoint - pair shared secret by using the TLS - Exporter described in [IETF RFC 8446]. The 64 - byte shared secret MUST be provided to the SCTP stack as soon as it is computable. The exporter MUST use the label given in Section 7 and MUST NOT use the context.

[0112] 4.10. Shutdown To prevent DTLS from discarding DTLS user messages during shutdown, the CloseNotify message MUST be sent only after all outstanding SCTP user messages have been acknowledged by the SCTP peer in a non-cancellable way.

[0113] Before processing a received CloseNotify, all other received SCTP user messages buffered in the SCTP layer MUST be read and processed by DTLS.

[0114] 5. DTLS over SCTP Service Adopting DTLS over SCTP according to the current description means adding options for transferring encrypted data to SCTP.

[0115] When DTLS over SCTP is used, all data transferred MUST be protected by chunk authentication and DTLS encryption. Chunks that need to be received in an authenticated way are defined by the CHUNK list parameter according to [IETF RFC 4895]. Error handling of authenticated chunks follows [IETF RFC 4895].

[0116] 5.1. Adaptation Layer Indication in INIT / INIT-ACK When initializing an association, the sender of an INIT or INIT ACK chunk that attempts to use DTLS / SCTP as defined in this specification MUST include an Adaptation Layer Indication Parameter with an IANA-assigned value of TBD (Section 7.2) to inform the peer that it can support DTLS over SCTP according to this specification.

[0117] 5.2. Initialization of DTLS over SCTP Figure 3 shows a signaling diagram 300 between a first node and a second node according to some embodiments of the present disclosure. Diagram 300 shows the initialization between a first node (Network Node 1) 310 and a second node (Network Node 2) 320. Network Node 1 and Network Node 2 can be any type of nodes that communicate with each other, such as nodes within a communication network.

[0118] The initialization of DTLS / SCTP requires all of the following options as part of the INIT / INIT-ACK handshake: -RANDOM: Defined in [IETF RFC 4895] -CHUNKS: A list of permitted chunks defined in [IETF RFC 4895] -HMAC-ALGO: Defined in [IETF RFC 4895] -ADAPTATION-LAYER-INDICATION: Defined in [IETF RFC 5061]

[0119] If all of the above options are present, the association starts with support for DTLS / SCTP. The set of options shown are DTLS / SCTP mandatory options. Data transfer is not permitted until the DTLS handshake is complete. Chunk bundling is permitted according to [[IETF RFC 4960]. The DTLS handshake enables authentication of both peers and further declares their supported message sizes.

[0120] It should be understood that other options or alternative technologies may be implemented. If the above options exist, the association begins with Node 320 starting the signaling. The DTLS support indication (or similar alternative) in INIT S301 notifies Node 310 that Node 320 supports extended DTLS / SCTP. In some embodiments, the DTLS support indication is an Adaptation-Layer-Indication having a value indicating the DTLS / SCTP function. Data transfer is not permitted until the DTLS handshake is completed. Data chunks received before the DTLS handshake may be silently discarded. Chunk bundling is permitted according to IETF RFC 4960. The DTLS handshake enables authentication of both peers and also has the supported message sizes of them.

[0121] When SCTP client node 320 starts association S301, the DTLS-Supported indication signals to node 310 that the client supports the extended DTLS / SCTP option, and DTLS-Supported may further indicate the size of the messages it can receive, or alternatively, the number of DTLS fragments it can receive. The size of the messages or the number of fragments that can be received may be limited by various factors. Accordingly, server node 310 sends an INIT-ACK S302 including the extended DTLS / SCTP option as well, indicating that node 310 is capable of extension and is not downgraded to legacy use with only a single DTLS segment. In some embodiments, DTLS-Supported may include only information related to the ability to implement extended DTLS / SCTP. In that case, information regarding the message / fragment size may be exchanged in a later handshake signal as described below. The DTLS-Supported signaling may similarly include other information for transfer between the two nodes.

[0122] Node 320 sends an INIT-ACK S302 that also includes extended DTLS / SCTP options, Receiving thereby indicating that Node 310 is capable of extension and is not downgraded to legacy use with only a single DTLS segment. The term "option" refers in some embodiments to instances where there are options to use legacy or extended techniques. In some embodiments, the extended technique may be a requirement. If Node 310 responds with an INIT-ACK that does not include the extended DTLS / SCTP option, Node 320 may decide to continue operating with legacy IETF RFC 6083 (e.g., single DTLS), continue operating with plain data only, or terminate the association.

[0123] If Node 310 (e.g., an SCTP server) supports extended DTLS / SCTP, upon receiving an INIT signaling S301 with DTLS / SCTP options, by responding with an INIT-ACK signaling S302 that also includes the extended DTLS / SCTP options, it may indicate that Node 310 can send extended DTLS / SCTP. Node 310 may follow the sequence and related traffic cases for DTLS initialization. After the transfer of the SCTP COOKIE-ECHO S303 and COOKIE-ACK S304 signaling, Node 320 starts the DTLS transfer by sending a DTLS handshake S305. In response, Node 310 sends messages with extended DTLS / SCTP in S306 based on the size limit indicated by Node 320.

[0124] As described above, in some embodiments, signaling of the message size or number of fragments that node 320 can receive may be included with the DTLS-Supported indication in S301. However, in some embodiments, this information may be sent during the initiation of the DTLS handshake S305 instead of DTLS-Supported. Further, other embodiments may provide this information in other signaling.

[0125] 5.3 Client Use Case When a client initiates an SCTP association with DTLS protection, i.e., an SCTP INIT including DTSL / SCTP mandatory options, the client can receive an INIT-ACK that also includes the DTLS / SCTP mandatory options, in which case the association proceeds as defined in the previous section 5.2. If the peer responds with an INIT-ACK that does not include all DTLS / SCTP mandatory options, the client SHOULD respond with an SCTP ABORT.

[0126] 5.4 Server Use Case When an SCTP server supports DTLS / SCTP, i.e., when it receives an INIT chunk with all DTLS / SCTP mandatory options as per this specification, it responds with an INIT-ACK that also includes all DTLS / SCTP mandatory options, following the sequence and related traffic cases of the DTLS initialization section 5.2. If an SCTP server that supports and is configured to use DTLS receives an INIT chunk without all DTLS / SCTP mandatory options, it SHOULD respond with an SCTP ABORT.

[0127] 5.5 IETF RFC 6083 Fallback In this section, it is described how endpoints supporting this specification fall back to the DTLS / SCTP behavior of IETF RFC 6083. It is recommended to define a setting indicating whether fallback is permitted or not. However, the possibility of using fallback is based on the fact that the ULP can operate using user messages of 16384 bytes or less, and security issues can be mitigated or considered acceptable. Fallback is NOT RECOMMENDED as it enables downgrading to weaker algorithms and versions of DTLS. Policy An SCTP endpoint (see Section 7.2) that receives an INIT chunk or INIT-ACK chunk without SCTP adaptation indication parameters having a DTLS / SCTP adaptation layer code point may potentially perform a fallback to the behavior of IETF RFC 6083 in certain cases. However, the fallback attempt needs to be performed only if the policy states that it is acceptable.

[0128] considered acceptable. Fallback is NOT RECOMMENDED as it enables downgrading to weaker algorithms and versions of DTLS.

[0129] An SCTP endpoint (see Section 7.2) that receives an INIT chunk or INIT-ACK chunk without SCTP adaptation indication parameters having a DTLS / SCTP adaptation layer code point may potentially perform a fallback to the behavior of IETF RFC 6083 in certain cases. However, the fallback attempt needs to be performed only if the policy states that it is acceptable.

[0130] If fallback is permitted, the client can send plaintext user messages before the DTLS handshake as permitted by IETF RFC 6083. Therefore, this needs to be part of the considerations for a policy that permits fallback.

[0131] 6. Socket API Considerations In this section, it is described how the socket API defined in [IETF RFC6458] is extended to provide a way for the application to observe the HMAC algorithm used for sending and receiving AUTH chunks.

[0132] This section is for informational purposes only.

[0133] Socket API implementations based on [IETF RFC 6458] are extended to provide event notifications whenever a new HMAC algorithm is used in a received AUTH chunk by the existing SCTP_AUTHENTICATION_EVENT event.

[0134] Furthermore, two new socket options for level IPPROTO_SCTP and names SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are defined as described below. The first socket option is used to query the HMAC algorithm used to send AUTH chunks. The second socket option enables monitoring of the HMAC algorithm used in AUTH chunks received via the SCTP_AUTHENTICATION_EVENT event.

[0135] Support for the SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also needs to be added to the function sctp_opt_info().

[0136] 6.1. Socket Option to Get the Sent HMAC Identifier (SCTP_SEND_HMAC_IDENT) During SCTP association establishment, the HMAC identifier used by the SCTP endpoint when sending AUTH chunks is selected.

[0137] The application can access the result of this selection by using this read-only socket option with level IPPROTO_SCTP and name SCTP_SEND_HMAC_IDENT.Devices.

[0138] The following structure is used to access the HMAC identifier used to send the AUTH chunk: struct sctp_assoc_value { sctp_assoc_t assoc_id; uint32_t assoc_value; };

[0139] assoc_id: This parameter is ignored for 1-to-1 style sockets.

[0140] For 1-to-many style sockets, the application inputs the association identifier. It is an error to use SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id.

[0141] assoc_value: This parameter contains the HMAC identifier used to send the AUTH chunk.

[0142] 6.2. Disclosure of Received HMAC Identifiers Section 6.1.8 of [IETF RFC 6458] defines the SCTP_AUTHENTICATION_EVENT event, which uses the following structure: struct sctp_authkey_event { uint16_t auth_type; uint16_t auth_flags; uint32_t auth_length; uint16_t auth_keynumber; uint32_t auth_indication; sctp_assoc_t auth_assoc_id; };

[0143] This specification struct sctp_authkey_event { uint16_t auth_type; uint16_t auth_flags; uint32_t auth_length; uint16_t auth_identifier; / * Previous auth_keynumber * / uint32_t auth_indication; sctp_assoc_t auth_assoc_id; }; For this, update this structure by renaming auth_keynumber to auth_identifier. When renaming auth_keynumber to auth_identifier, auth_identifier simply replaces auth_keynumber in the context of [IETF RFC 6458]. In addition, the SCTP_AUTHENTICATION_EVENT event is further extended to indicate when a new HMAC identifier is received, and such reporting is explicitly enabled as described in Section 6.3. In this case, auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is reported by auth_identifier.

[0144] 6.3. Socket Option to Expose the Use of HMAC Identifiers (SCTP_EXPOSE_HMAC_IDENT_CHANGES) Using this option enables or disables the receipt of SCTP_AUTHENTICATION_EVENT events when the application receives a new HMAC identifier in an AUTH chunk (see Section 6.2).

[0145] This read / write socket option uses the level IPPROTO_SCTP and the name SCTP_EXPOSE_HMAC_IDENT_CHANGES. Backward compatibility needs to be provided and by default these events are not reported.

[0146] The following structure is used to enable or disable the reporting of newly received HMAC identifiers in the AUTH chunk: struct sctp_assoc_value { sctp_assoc_t assoc_id; uint32_t assoc_value; };

[0147] assoc_id: This parameter is ignored for 1-to-1 style sockets.

[0148] For 1-to-many style sockets, the application may enter an association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC.

[0149] assoc_value: The newly received HMAC identifier is reported if and only if this parameter is non-zero.

[0150] 7. IANA Considerations 7.1. TLS Exporter Label IETF RFC 6083 defined a TLS Exporter Label registry as described in [IETF RFC 5705]. IANA is requested to update the reference to the label "EXPORTER_DTLS_OVER_SCTP" in this specification.

[0151] 7.2. SCTP Adaptation Layer Indication Code Point [IETF RFC 5061] defined an IANA registry for the adaptation code points used in the adaptation layer indication parameters.

[0152] 8. Security Considerations The security considerations given in [I-D.ietf-tls-dtls13], [IETF RFC 4895], and [IETF RFC 4960] also apply to this document.

[0153] 8.1. Encryption Considerations Over the years, there have been several serious attacks on previous versions of Transport Layer Security (TLS), including attacks on the most commonly used ciphers and modes of operation. [IETF RFC 7457] summarizes the attacks known at the time of publication, and BCP 195 [IETF RFC 7525][IETF RFC 8996] provides recommendations for improving the security of deployed services that use TLS.

[0154] When DTLS 1.2 [IETF RFC 6347] is used with DTLS / SCTP, DTLS 1.2 MUST be configured to disable options that are known to provide insufficient security.

[0155] HTTP / 2 [IETF RFC 7540] provides good minimum requirements based on attacks publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13] only defines strong algorithms that do not have major weaknesses at the time of publication. Many of the TLS registries have a "recommended" column.

[0156] Parameters not marked with "Y" are NOT RECOMMENDED to support. DTLS 1.3 is preferably a newer protocol that addresses known vulnerabilities and only defines strong algorithms that do not have major weaknesses at the time of publication.

[0157] DTLS 1.3 requires rekeying before reaching the algorithm-specific AEAD limit. The AEAD limit formula is equally valid for DTLS 1.2 and SHOULD be followed for DTLS / SCTP, but is not required by the DTLS 1.2 specification.

[0158] The HMAC-SHA-256 used in SCTP-AUTH has a very large tag length and very good integrity properties. The SCTP-AUTH key can be used longer than the current algorithms of the TLS record layer. The SCTP-AUTH key is rekeyed when a new connection is set up when a new SCTP-AUTH key is derived using a TLS exporter.

[0159] DTLS / SCTP is being introduced in many places instead of IPsec. Regarding IPsec, NIST (US), BSI (Germany), and ANSSI (France) recommend providing Perfect Forward Secrecy by frequently re-executing Diffie-Hellman and forcing attackers to perform dynamic key extraction. ANSSI states that "To limit the impact of key leakage, it is recommended to enforce regular key updates (e.g., every hour and every 100 GB of data)." [ANSSI-DAT-NT-003]

[0160] In many DTLS / SCTP deployments, DTLS connections are expected to have a very long duration of several months or years. For connections with such a long duration, both the client and the server need to be re-authenticated frequently. The duration of TLS certificates is generally less than one year, which is shorter than many expected DTLS / SCTP associations. Quite Shorter.

[0161] Re-keying of SCTP-AUTH, periodic authentication of both endpoints, and frequent re-execution of Diffie-Hellman to force dynamic key extraction from an attacker are achieved in DTLS / SCTP according to this document by setting up a new DTLS connection on the same SCTP association. Implementations SHOULD set up new connections frequently to force dynamic key extraction from an attacker. Implementations MUST set up a new connection before any of the certificates expire. When the certificate is new, it is RECOMMENDED that all negotiated and exchanged parameters be the same except for the timestamp in the certificate. Note that some parameters, typically random numbers and connection ids, are changed in a new handshake. Note that some parameters, typically serial numbers, are changed in a new certificate. The client and server MUST NOT accept a change of identity during the setup of a new connection, but MAY accept negotiation of stronger algorithms and security parameters, which may be motivated by new attacks.

[0162] When using DTLS 1.2 [IETF RFC 6347], AEAD limits, frequent re-authentication, and frequent re-execution of Diffie-Hellman can also be achieved through renegotiation (see TLS 1.2 [IETF RFC 5246]). When renegotiation is used, both the client and the server MUST use the renegotiation_info extension [IETF RFC 5746] and MUST follow the renegotiation guidelines of BCP 195 [IETF RFC 7525]. In particular, both the client and the server MUST NOT accept a change of identity during renegotiation. In many DTLS implementations, renegotiation is disabled by default. While renegotiation updates the exporter_secret, DTLS / SCTP as described herein only derives a new SCTP-AUTH key when a new connection is set up.

[0163] In DTLS 1.3, renegotiation has been removed from DTLS 1.3 and some has been replaced by Post-Handshake KeyUpdate. When using DTLS 1.3 [I-D.ietf-tls-dtls13], AEAD limits can also be achieved by sending frequent Post-Handshake KeyUpdate messages.

[0164] Symmetric re-keying provides significantly less protection against key leakage than re-running Diffie-Hellman. After the leakage of application_traffic_secret_N, a passive attacker can

[0165] passively eavesdrop on all future application data transmitted over the connection, including application data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc.

[0166] Note that KeyUpdate does not update the exporter_secret.

[0167] By allowing re - negotiations initiated by the client and new connections initiated by the client, a denial - of - service attack can be enabled. The server needs to limit the frequency of re - negotiations and new connections initiated by the client.

[0168] When DTLS / SCTP is used with DTLS 1.2 [IETF RFC 6347], the TLS session hash and the Extended Master Secret Extension [IETF RFC 7627] MUST be used to prevent an unknown key - sharing attack where an attacker establishes the same key across multiple connections. DTLS 1.3 always prevents these types of attacks. The use of SCTP - AUTH binds new connections cryptographically to old connections. This reduces the MITM attacks that plague re - negotiations [3SHAKE], along with the requirement of mandatory mutual authentication (on the DTLS layer) and not accepting new identities.

[0169] 8.2. Downgrade Attacks Peers that support DTLS / SCTP according to this specification, DTLS / SCTP according to [IETF RFC 6083], and / or SCTP without DTLS may be vulnerable to downgrade attacks where an on - path attacker interferes with the protocol setup to reduce or invalidate security. If possible, it is RECOMMENDED that the peer have a policy that permits only DTLS / SCTP according to this specification.

[0170] 8.3. Authentication and Policy Decision DTLS / SCTP MUST be mutually authenticated. It is RECOMMENDED that DTLS / SCTP be used with certificate-based authentication. All security decisions MUST be based on the peer's authenticated identity, rather than its transport layer identity.

[0171] It is possible to authenticate DTLS endpoints based on the IP addresses in the certificate. An SCTP association can use multiple IP addresses per SCTP endpoint. Thus, a DTLS record can be sent from a source IP address different from the one initially authenticated, or to a different destination IP address. This is not a problem as long as security decisions are not made based on the source or destination IP address.

[0172] 8.4. Privacy Considerations [IETF RFC 6973] proposes to document the privacy considerations for IETF protocols.

[0173] For each SCTP user message, the user also provides a stream identifier, a flag indicating whether the message is ordered or unordered, and a payload protocol identifier. DTLS / SCTP provides privacy for the actual user message, but the other three information fields are not confidentiality-protected. Since these are part of the SCTP DATA chunk header, they are sent in clear text.

[0174] DTLS / SCTP is RECOMMENDED to be used with certificate-based authentication in DTLS 1.3 [I-D.ietf-tls-dtls13] to provide identity protection. DTLS / SCTP MUST be used with a key exchange method that provides perfect forward secrecy. Perfect forward secrecy significantly limits the amount of data that can be leaked due to a key leak.

[0175] 8.5. Pervasive Monitoring As required by [IETF RFC 7258], work on IETF protocols needs to consider the impact of pervasive monitoring and, where possible, mitigate them.

[0176] Pervasive monitoring is the extensive monitoring of users. By encrypting more information, including user identities, DTLS 1.3 provides much better protection against extensive monitoring.

[0177] Large-scale pervasive monitoring attacks that rely on key exchange without forward secrecy have been reported. By making perfect forward secrecy mandatory, DTLS / SCTP effectively mitigates many forms of passive pervasive monitoring and limits the amount of data leaked due to key leakage.

[0178] An important mitigation of pervasive monitoring is to enforce the execution of dynamic key extraction instead of static key extraction. Dynamic key extraction increases the risk of discovery by attackers [IETF RFC 7624]. DTLS / SCTP as described in this document encourages implementations to frequently set up new DTLS connections on the same SCTP association to enforce dynamic key extraction on attackers. to the attacker

[0179] In addition to the privacy attacks described above, large-scale monitoring can enable the tracking of users over a wider geographical area and across different access networks. By using information from DTLS / SCTP together with information collected from other protocols, the risk of identifying individual users increases.

[0180] 9. Implementation of Embodiments of the Invention ​Figure 4 shows a network node that implements parallel DTLS connections over an SCTP association, according to some embodiments. Network node 402 may be implemented using a custom application specific integrated circuit (ASIC) as a processor and a dedicated operating system (OS), or a common off-the-shelf (COTS) processor and a standard OS.

[0181] Network node 402 includes hardware 440 comprising a set of one or more processors 442 (typically a COTS processor or a processor core or an ASIC) and a physical NI 446, and a non-transitory machine-readable storage medium 449 having software 450 stored therein. During operation, the one or more processors 442 may instantiate one or more sets of one or more of applications 464A - R by executing software 450. One embodiment does not implement virtualization, but alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment, virtualization layer 454 represents the kernel of an operating system (or a shim running on top of a basic operating system) that enables the creation of a plurality of instances 462A - R, referred to as software containers, each of which may be used to execute one (or more) of the sets of applications 464A - R. The plurality of software containers (also referred to as virtualization engines, virtual private servers, or jails) are Separate from each other, and in a user space (typically a virtual memory space) separate from the kernel space in which the operating system is executed. A given user SpaceThe set of applications being executed cannot access the memory of other processes unless explicitly permitted. In another such alternative embodiment, the virtualization layer 454 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor running on a host operating system, and each of the set of applications 464A - R is executed on top of a guest operating system within an instance referred to as a virtual machine 462A - R running on the hypervisor (which in some cases can be considered a strictly isolated form of a software container) - the guest operating system and applications may not know that they are being executed on a virtual machine as opposed to on a "bare metal" host electronic device, or, through para - virtualization, the operating system and / or applications may recognize the presence of virtualization for optimization purposes. In yet another alternative embodiment, one, some, or all of the applications are implemented as (one or more) unikernels, which can be generated by directly compiling the application using only a limited set of libraries that provide specific OS services required by the application (e.g., from a library operating system (LibOS) including drivers / libraries for OS services). Since the unikernel can be implemented to run directly on the hardware 440, directly on the hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or within a software container, embodiments can be fully implemented as a unikernel running directly on the hypervisor represented by the virtualization layer 454, a unikernel running within a software container represented by instances 462A - R, or a combination of unikernels and the above - described technologies (e.g., both a unikernel and a virtual machine running directly on the hypervisor, a unikernel, and a set of applications running within different software containers).

[0182] Software 450 includes a parallel DTLS connection coordinator 112 that executes the operations described above in this specification. The parallel DTLS connection coordinator 112 can be instantiated within applications 464A - R. The instantiation of one or more sets of one or more of applications 464A - R, and the virtualization when implemented, are collectively referred to as (one or more) software instances 452. Each set of applications 464A - R, the corresponding virtualization constructs (e.g., instances 462A - R) when implemented, and that portion of the hardware 440 that executes them (which is either the execution of the time - shared hardware and / or the hardware dedicated to time - slicing) form separate virtual electronic devices 460A - R.

[0183] The network interface (NI) can be physical or virtual. In the context of IP, the interface address is the IP address assigned to the NI, which can be a physical NI or a virtual NI. The virtual NI can be associated with a physical NI, associated with another virtual interface, or be on its own (e.g., a loop - back interface, a point - to - point protocol interface). The NI (physical or virtual) may or may not be numbered (NI with an IP address or NI without an IP address).

[0184] Term In general, all terms used in this specification should be interpreted according to their ordinary meanings in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which they are used. Any reference to an element, apparatus, component, means, step, etc. should be construed openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless otherwise specified. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless the step is explicitly described as being after or before another step and / or it is implicit that the step must be after or before another step. Any feature of any of the embodiments disclosed herein may, where appropriate, be applied to any other embodiment. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the embodiments included will become apparent from the following description.

[0185] As used herein, references to "one embodiment", "an embodiment", "exemplary embodiments", etc. indicate that the embodiments described may include a particular feature, structure, or characteristic, but not all embodiments necessarily include that particular feature, structure, or characteristic. Further, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it will be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0186] This specification and the claims may use the terms "coupled" and "connected" along with their derivatives. These terms are not intended to be synonymous with each other. "Coupled" is used to indicate that two or more elements cooperate or interact with each other, and these may or may not be in direct physical or electrical contact with each other. "Connected" is used to indicate the establishment of wireless or wired communication between two or more elements coupled to each other. As used herein, "set" refers to any positive integer number of items including one item.

[0187] An electronic device uses machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid-state drives, read-only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called carriers, e.g., electrical, optical, wireless, acoustic, or other forms of propagated signals such as carrier waves, infrared signals), to store and transmit code and / or data (internally and / or together with other electronic devices via a network). For this purpose, an electronic device (e.g., a computer) includes one or more sets of processors (e.g., one of which is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), other electronic circuits, or one or more combinations of the foregoing) coupled to one or more machine-readable storage media for storing code for execution on the set of processors and / or for storing data. For example, an electronic device includes non-volatile memory containing code, because the non-volatile memory can persist the code / data even when the electronic device is turned off (when the power is removed). When the electronic device is turned on, that portion of the code executed by the (one or more) processors of the electronic device is typically copied from the slower non-volatile memory to the volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of the electronic device. A typical electronic device further includes a set of one or more physical network interfaces (NIs) for establishing a network connection with other electronic devices (for transmitting and / or receiving code and / or data using propagated signals).For example, a set of physical NIs (or a set of physical NIs combined with a set of processors that execute code) can perform any formatting, coding, or conversion to enable an electronic device to send and receive data over wired and / or wireless connections. In some embodiments, the physical NI can include a wireless circuit capable of (1) receiving data from other electronic devices over a wireless connection and / or (2) transmitting data to other devices through a wireless connection. This wireless circuit can include one or more transmitters, one or more receivers, and / or one or more transceivers suitable for wireless frequency communication. The wireless circuit can convert digital data into a wireless signal with appropriate parameters (such as frequency, timing, channel, bandwidth, etc.). The wireless signal can then be transmitted through an antenna to an appropriate recipient(s). In some embodiments, the set of one or more physical NIs can include one or more network interface controllers (NICs), also known as network interface controller cards, network adapters, or local area network (LAN) adapters. The one or more NICs can facilitate connecting an electronic device to other electronic devices and enable the electronic device to communicate wired through insertion of a cable into a physical port connected to the NIC. One or more portions of embodiments of the present invention can be implemented using different combinations of software, firmware, and / or hardware.

[0188] A network node (also referred to as a network device or simply a node) is an electronic device that communicatively interconnects other electronic devices on a network (e.g., other network devices, end-user devices). Some network nodes are "multiple services network nodes" that provide support for multiple networking functions (e.g., routing, bridging, switching, layer 2 aggregation, session border control, quality of service, and / or subscriber management) and / or provide support for multiple application services (e.g., data, voice, and video).

[0189] The terms "module", "logic", and "unit" as used in this application can refer to a circuit for performing a defined function. In some embodiments, the defined function can be performed by a circuit in combination with software, such as by software executed by a general-purpose processor.

[0190] Any suitable step, method, feature, function, or effect disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may include several of these functional units. These functional units may be implemented using a processing circuit that may include one or more microprocessors or microcontrollers, and other digital hardware that may include a digital signal processor (DSP), dedicated digital logic, etc. The processing circuit may be configured to execute program code stored in a memory, which may include one or more types of memory such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more remote communication and / or data communication protocols, and instructions for executing one or more of the techniques described herein. In some implementations, the processing circuit may be used to cause individual functional units to perform corresponding functions according to one or more embodiments of the present disclosure.

[0191] The term unit may have its conventional meaning in the field of electronic equipment, electrical devices, and / or electronic devices, and may include, for example, an electrical circuit and / or an electronic circuit, a device, a module, a processor, a memory, a logic solid state and / or discrete device, a computer program or instructions for performing respective tasks, procedures, calculations, output, and / or display functions, etc., as described herein.

Claims

1. A method in a first network node for encoding a user message for secure transmission to a second network node, comprising: starting a DTLS connection on the SCTP association through a DTLS handshake using an existing SCTP - AUTH (Authenticated Chunk for SCTP) key from an existing DTLS connection on the SCTP association for transmitting the user message (204); deriving a new SCTP - AUTH key from the started DTLS connection (206); transmitting further user messages through the started DTLS connection using the new SCTP - AUTH key (210); closing the existing DTLS connection on the SCTP association in response to confirmation that an encrypted SCTP packet and an SCTP packet authenticated by the existing SCTP - AUTH key have been delivered (212). A method as described above.

2. The method according to claim 1, further comprising: transmitting an ongoing SCTP packet including a further portion of the user message protected by the started DLTS connection but authenticated by the existing SCTP - AUTH key (208).

3. The method according to claim 1, wherein: closing the existing DTLS connection on the SCTP association includes transmitting a first DTLS connection close notification to the second network node.

4. The method according to claim 1, wherein: closing the existing DTLS connection on the SCTP association further includes receiving a second DTLS connection close notification from the second network node.

5. The method according to claim 3, wherein: transmitting the first DTLS connection close notification includes verifying that transmitted data in the existing DTLS connection has been acknowledged by the second network node before transmitting the first DTLS connection close notification.

6. The method according to claim 1, wherein the existing SCTP - AUTH key and the new SCTP - AUTH key are identified by corresponding existing and new key identifiers (IDs), and the new key identifier is a value increased by 1 from the existing key identifier.

7. The method according to claim 1, wherein the DTLS connection is established before one or more certificates of the existing DTLS connection on the SCTP association become invalid.

8. The method according to claim 7, wherein initiating the DTLS connection on the SCTP association through the DTLS handshake includes maintaining the one or more certificates of the existing DTLS connection including timestamps within the one or more certificates.

9. The method according to claim 1, wherein performing the DTLS handshake between the first network node and the second network node includes starting the DTLS handshake and, in response to receiving the initiation of the DTLS handshake, continuing the started DTLS handshake when the first network node functions as a DTLS client of the DTLS connection.

10. The method according to claim 1, wherein the existing SCTP - AUTH key is deleted in response to the closure of the existing DTLS connection.

11. A network node (402) comprising a processor (442) and a non - transitory machine - readable storage medium (449) providing instructions, which, when executed by the processor (442), cause the processor (442) to initiate a DTLS connection on the SCTP (Stream Control Transmission Protocol) association through a DTLS handshake using an existing SCTP - AUTH (Authenticated Chunk for SCTP) key from an existing DTLS (Datagram Transport Layer Security) connection on the SCTP association for transmitting a user message (204); derive a new SCTP - AUTH key from the initiated DTLS connection (206); Using the new SCTP-AUTH key, transmitting further user messages through the initiated DTLS connection (210); In response to confirmation that the encrypted SCTP packets in the existing DTLS connection and the SCTP packets authenticated by the existing SCTP-AUTH key have been delivered, closing the existing DTLS connection on the SCTP association (212); A network node capable of performing the above. **Claim 12** The network node (402) according to claim 11, When the non-transitory machine-readable storage medium is executed by the processor (442), the processor (442) is caused to Transmit in-progress SCTP packets including further portions of user messages that are protected by the initiated DLTS connection but authenticated by the existing SCTP-AUTH key (208), A network node that further provides instructions that can be further executed. **Claim 13** The network node (402) according to claim 11, Closing the existing DTLS connection on the SCTP association includes transmitting a first DTLS connection close notification to a second network node. A network node. **Claim 14** The network node (402) according to claim 11, Closing the existing DTLS connection on the SCTP association further includes receiving a second DTLS connection close notification from a second network node. A network node. **Claim 15** The network node (402) according to claim 13, Transmitting the first DTLS connection close notification includes confirming that the transmitted data in the existing DTLS connection has been acknowledged by the second network node before transmitting the first DTLS connection close notification. A network node. **Claim 16** The network node (402) according to claim 11, The existing SCTP - AUTH key and the new SCTP - AUTH key are identified by corresponding existing and new key identifiers (IDs), and the new key identifier is a value increased by 1 from the existing key identifier, network node.

17. The network node (402) according to claim 11, wherein the DTLS connection is established before one or more certificates of the existing DTLS connection on the SCTP association become invalid, network node.

18. The network node (402) according to claim 17, wherein starting the DTLS connection on the SCTP association through the DTLS handshake includes maintaining the one or more certificates of the existing DTLS connection including timestamps in the one or more certificates, network node.

19. The network node (402) according to claim 11, wherein performing the DTLS handshake between the network node and a second network node includes starting the DTLS handshake and, in response to receiving the initiation of the DTLS handshake, continuing the started DTLS handshake when the network node functions as a DTLS client of the DTLS connection, network node.

20. The network node (402) according to claim 11, wherein the existing SCTP - AUTH key is deleted in response to the closure of the existing DTLS connection, network node.

21. A non - transitory machine - readable storage medium (449) that provides instructions which, when executed by a processor (442), cause the processor (442) to execute the method according to any one of claims 1 to 10, machine - readable storage medium.

22. A computer program that includes instructions which, when the computer program is executed by a network node (402), cause the network node to execute the method according to any one of claims 1 to 10, computer program.

Images