TSVWG M. Westerlund Internet-Draft J. Preuß Mattsson Intended status: Standards Track C. Porfiri Expires: 20 August 2023 Ericsson 16 February 2023 Stream Control Transmission Protocol (SCTP) CRYPTO Chunk draft-westerlund-tsvwg-sctp-crypto-chunk-00 Abstract This document describes a method for adding cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP CRYPTO chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. The CRYPTO chunk defined here in is one half of a complete solution. Where a companion specification is required to define how the content of the CRYPTO chunk is protected, authenticated, and protected against replay, as well as how key management is accomplished. Applications using SCTP CRYPTO chunk can use all transport features provided by SCTP and its extensions. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto- chunk/. Discussion of this document takes place on the Transport Area Working Group (tsvwg) Working Group mailing list (mailto:tsvwg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tsvwg/. Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/. Source for this draft and an issue tracker can be found at https://github.com/gloinul/draft-westerlund-tsvwg-sctp-crypto-chunk. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Westerlund, et al. Expires 20 August 2023 [Page 1] Internet-Draft SCTP CRYPTO Chunk February 2023 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 August 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 2.2. Protection Engines Considerations . . . . . . . . . . . . 6 2.3. SCTP CRYPTO Chunk Buffering and Flow Control . . . . . . 7 2.4. PMTU Considerations . . . . . . . . . . . . . . . . . . . 7 2.5. Congestion Control Considerations . . . . . . . . . . . . 7 2.6. ICMP Considerations . . . . . . . . . . . . . . . . . . . 8 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. New Parameter Type . . . . . . . . . . . . . . . . . . . . . 8 4.1. Protected Association Parameter . . . . . . . . . . . . . 8 5. New Chunk Types . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Crypto Chunk (CRYPTO) . . . . . . . . . . . . . . . . . . 9 5.2. Protected Association Parameter Validation Chunk (PVALID) . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Mandatory Protected Association Parameter Missing . . . . 12 6.2. Error in Protection . . . . . . . . . . . . . . . . . . . 13 6.2.1. No Supported Protection Engine . . . . . . . . . . . 14 6.2.2. Error During Protection Handshake . . . . . . . . . . 14 Westerlund, et al. Expires 20 August 2023 [Page 2] Internet-Draft SCTP CRYPTO Chunk February 2023 6.2.3. Failure in Protection Engines Validation . . . . . . 14 6.2.4. Timeout During Protection Handshake or Validation . . 14 6.3. Critical Error from Protection Engine . . . . . . . . . . 14 6.4. Non-critical Error in the Protection Engine . . . . . . . 15 7. Protected SCTP State Diagram . . . . . . . . . . . . . . . . 15 7.1. New States . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. PROTECTION PENDING . . . . . . . . . . . . . . . . . 17 7.1.2. PROTECTED . . . . . . . . . . . . . . . . . . . . . . 17 7.1.3. Consideration on T-valid . . . . . . . . . . . . . . 18 8. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Establishment of a Protected Association . . . . . . . . 19 8.2. Termination of a Protected Association . . . . . . . . . 20 9. Protected Data Chunk Handling . . . . . . . . . . . . . . . . 20 9.1. Protected Data Chunk Transmission . . . . . . . . . . . . 22 9.2. Protected Data Chunk Reception . . . . . . . . . . . . . 22 9.2.1. SCTP Header Handler . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10.1. Protection Engine Identifier Registry . . . . . . . . . 23 10.2. Protection Error Cause Codes Registry . . . . . . . . . 24 10.3. SCTP Chunk Types . . . . . . . . . . . . . . . . . . . . 25 10.4. SCTP Chunk Parameter Types . . . . . . . . . . . . . . . 26 10.5. SCTP Error Cause Codes . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11.1. Privacy Considerations . . . . . . . . . . . . . . . . . 26 11.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 27 12. Requirements towards the protection engines . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document defines a CRYPTO chunk for the Stream Control Transmission Protocol (SCTP), as defined in [RFC9260]. This specification defines the actual CRYPTO chunk. How to enable it usage, how it interacts with the SCTP association establishment to enable endpoint authentication, key-establishment, and other features require a separate protection engine specification. Westerlund, et al. Expires 20 August 2023 [Page 3] Internet-Draft SCTP CRYPTO Chunk February 2023 This specification is intended to be capable of enabling mutual authentication of endpoints, data confidentiality, data origin authentication, data integrity protection, and data replay protection for SCTP packets after the SCTP association has been established. The exact properties will depend on the companion specification defining the protection engine used with the CRYPTO chunk. The protection engine specification might be based on an existing security protocol. Applications using SCTP CRYPTO chunk can use all transport features provided by SCTP and its extensions. Due to its level of integration as discussed in next section it will provide its security functions on all content of the SCTP packet, and will thus not impact the potential to utilize any SCTP functionalities or extensions. 2. Overview 2.1. Protocol Overview The CRYPTO chunk is defined as a method for secure and confidential transfer for SCTP packets. This is implemented inside the SCTP protocol, in a sublayer between the SCTP common header handling and the SCTP chunk handling. Once an SCTP packet has been received and the SCTP common header has been used to identify the SCTP association, the CRYPTO chunk is sent to the chosen protection engine that will return the SCTP payload containing the unprotected SCTP chunks, those chunks will then be handled according to current SCTP protocol specification. Figure 1 illustrates the CRYPTO chunk layering in regard to SCTP and the Upper Layer Protocol (ULP). +---------------------+ | | | ULP | | | +---------------------+ <-- User Level Messages | | | SCTP Chunks Handler | +-- SCTP Unprotected Payload | |/ +---------------------+ +--------------------+ | CRYPTO +--->| Protection Engine | | Chunk | +--------------------+ | Handler |<---+ Key Management | +---------------------+ +--------------------+ | |\ | SCTP Header Handler | +-- SCTP Protected Payload | | +---------------------+ Westerlund, et al. Expires 20 August 2023 [Page 4] Internet-Draft SCTP CRYPTO Chunk February 2023 Figure 1: CRYPTO Chunk Layering in Regard to SCTP and ULP Use of the CRYPTO chunk is defined per SCTP association and a SCTP association uses a single protection engine. Different associations within the same SCTP endpoint may use or not use the CRYPTO chunk, and different associations may use different protection engines. On the outgoing direction, once the SCTP stack has created the unprotected SCTP packet payload containing control and/or DATA chunks, that payload will be sent to the protection engine to be protected. The format of the protected payload depends on the protection engine but the unprotected payload will typically be encrypted and integrity tagged before being encapsulated in a CRYPTO chunk. The SCTP protection engine performs protection operations on the whole unprotected SCTP packet payload, i.e., all chunks after the SCTP common header. Information protection is kept during the lifetime of the association and no information is sent unprotected except than the initial SCTP handshake, the SCTP common Header, the SCTP CRYPTO chunk header and the SHUTDOWN-COMPLETE chunk. SCTP CRYPTO chunk capability is agreed by the peers at the initialization of the SCTP association, during that phase the peers exchange information about the protection engines available. Once the peers have agreed on what protection to use, the SCTP endpoints start sending SCTP CRYPTO chunks containing the initialization information related to the protection engine including key agreement and endpoint authentication. This is depending on the chosen protection engine thus is not being detailed in the current specification. When the endpoint authentication has been completed, the association is meant to be initialized and the ULP is informed about that, from this time on it's possible for the ULPs to exchange data. CRYPTO chunks will never be retransmitted, retransmission is implemented by SCTP endpoint at chunk level as in the legacy. Duplicated CRYPTO chunks, whenever they will be accepted by the protection engine, will result in duplicated SCTP chunks and will be handled as duplicated chunks by SCTP endpoint in the same way a duplicated SCTP packet with those SCTP chunks would have been. Westerlund, et al. Expires 20 August 2023 [Page 5] Internet-Draft SCTP CRYPTO Chunk February 2023 2.2. Protection Engines Considerations The protection engine, independently from the security characteristics, needs to be capable working on an unreliable transport mechanism same as UDP and have its own key management capability. SCTP CRYPTO chunk directly exploits the protection engine by requesting protection and unprotection of a buffer, in particular the protection buffer shall never exceed the SCTP payload size thus protection engine shall be aware of the PMTU (see Section 2.4). The key management part of the protection engine is the set of data and procedures that take care of key distribution, verification, and update. Key management of protection engine is RECOMMENDED to use the SCTP CRYPTO chunk for handshaking, in that case any packet being exchanged between protection engine peers shall be transported as payload of Crypto chunk (see Section 5.1). Key management MAY use other mechanism than what provided by SCTP CRYPTO chunks, in any case the mechanism for key management MUST be specified in the specification for that protection engine. Out-of-band communication between protection engines MAY exploit the Flags byte provided by the CRYPTO chunk header (see Figure 3). Details of the use of Flags, if different from what described in the current document, MUST be specified in the Protection Engine Specification document for that specific protection engine. The SCTP common header is assumed to be implicitly protected by the protection engine. This protection is based on the assumption that there will be a one-to-one mapping between SCTP association and individually established security contexts. If the protection engine does not meet that assumption further protection of the common header is likely required. An example of protection engine can be DTLS. Westerlund, et al. Expires 20 August 2023 [Page 6] Internet-Draft SCTP CRYPTO Chunk February 2023 2.3. SCTP CRYPTO Chunk Buffering and Flow Control Protection engine and SCTP are asynchronous, meaning that the protection engine may deliver the decrypted SCTP Payload to the SCTP endpoint without respecting the reception order. It's up to SCTP endpoint to reorder the chunks in the reception buffer and to take care of the flow control according to what specified in [RFC9260]. From SCTP perspective the CRYPTO chunk processing is part of the transport network. Even though the above allows the implementors to adopt a multithreading design of the protection engines, the actual implementation should consider that out-of-order handling of SCTP chunks is not desired and may cause false congestions and retransmissions. 2.4. PMTU Considerations The addition of the CRYPTO chunk to SCTP reduces the room for payload, due to the size of the CRYPTO chunk header and plain text expansion due to ciphering algorithm and any authentication tag. Thus, the SCTP layer creating the plain text payload needs to know about the overhead to adjust its target payload size appropriately. On the other hand, the protection engine needs to be informed about the PMTU by removing from the value the sum of the common SCTP header and the CRYPTO chunk header. This implies that SCTP can propagate the computed PMTU at run time specifically. The way protection engine provides the primitive for PMTU communication shall be part of the protection engine specification. From SCTP perspective, if there is a maximum size of plain text data that can be protected by the protection engine that must be communicated to SCTP. As such a limit will limit the PMTU for SCTP to the maximum plain text plus CRYPTO chunk and algorithm overhead plus the SCTP common header. 2.5. Congestion Control Considerations The SCTP mechanism for handling congestion control does depend on successful data transfer for enlarging or reducing the congestion window CWND (see [RFC9260] section 7.2). It may happen that protection engine discards packets due to internal checks or because it has detected a malicious attempt. Westerlund, et al. Expires 20 August 2023 [Page 7] Internet-Draft SCTP CRYPTO Chunk February 2023 The protection engine shall not interfere with the SCTP congestion control mechanism, this basically means that from SCTP perspective the congestion control is exactly the same as how specified in [RFC9260]. 2.6. ICMP Considerations SCTP implementation will be responsible for handling ICMP messages and their validation as specified in [RFC9260] Section 10. This includes for SCTP packets sent by the protection engines key management function. However, valid ICMP errors or information may indirectly be provided to the protection engine, such as an update to PMTU values based on packet to big ICMP messages. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. New Parameter Type This section defines the new parameter type that will be used to negotiate the use of the CRYPTO chunk and protection engines during association setup. Table 1 illustrates the new parameter type. +================+=======================+ | Parameter Type | Parameter Name | +================+=======================+ | 0x80xx | Protected Association | +----------------+-----------------------+ Table 1: New INIT/INIT-ACK Parameter Note that the parameter format requires the receiver to ignore the parameter and continue processing if the parameter is not understood. This is accomplished (as described in [RFC9260], Section 3.2.1.) by the use of the upper bits of the parameter type. 4.1. Protected Association Parameter This parameter is used to carry the list of proposed protection engines and the chosen protection engine during INIT/INIT-ACK handshake. Westerlund, et al. Expires 20 August 2023 [Page 8] Internet-Draft SCTP CRYPTO Chunk February 2023 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 0x80xx | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Protection Engines | | | | +-------------------------------+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Protected Association Parameter Parameter Type: 16 bits (unsigned integer) This value MUST be set to 0x80xx. Parameter Length: 16 bits (unsigned integer) This value holds the length of the Protection Engines field in bytes plus 4. Protection Engines: variable length In the INIT chunk this holds the list of protection engines in descending order of preference, i.e. the most preferred comes first, and the least preferred last in this field. In the INIT- ACK chunk this holds a single chosen protection engine. Each protection engine is specified by a 16-bit unsigned integer. Padding: 0 or 16 bits If the length of the Protection Engines field is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes to make the chunk 32-bit aligned. The Padding MUST NOT be longer than 2 bytes and it MUST be ignored by the receiver. RFC-Editor Note: Please replace 0x08xx with the actual parameter type value assigned by IANA and then remove this note. 5. New Chunk Types 5.1. Crypto Chunk (CRYPTO) This section defines the new chunk type that will be used to transport protected SCTP payload. Table 2 illustrates the new chunk type. Westerlund, et al. Expires 20 August 2023 [Page 9] Internet-Draft SCTP CRYPTO Chunk February 2023 +============+=======================+ | Chunk Type | Chunk Name | +============+=======================+ | 0x4X | Crypto Chunk (CRYPTO) | +------------+-----------------------+ Table 2: CRYPTO Chunk Type RFC-Editor Note: Please replace 0x4x with the actual chunk type value assigned by IANA and then remove this note. It should be noted that the CRYPTO chunk format requires the receiver stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an ERROR chunk using the 'Unrecognized Chunk Type' error cause. This is accomplished (as described in [RFC9260] Section 3.2.) by the use of the upper bits of the chunk type. The CRYPTO chunk is used to hold the protected payload of a plain SCTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x4X | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | | +-------------------------------+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: CRYPTO Chunk Structure Chunk Type: 8 bits (unsigned integer) This value MUST be set to 0x4X for all CRYPTO chunks. Chunk Flags: 8 bits This is used by the protection engine and ignored by SCTP. Chunk Length: 16 bits (unsigned integer) This value holds the length of the Payload in bytes plus 4. Payload: variable length This holds the encrypted data. Padding: 0, 8, 16, or 24 bits Westerlund, et al. Expires 20 August 2023 [Page 10] Internet-Draft SCTP CRYPTO Chunk February 2023 If the length of the Payload is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes to make the chunk 32-bit aligned. The Padding MUST NOT be longer than 3 bytes and it MUST be ignored by the receiver. 5.2. Protected Association Parameter Validation Chunk (PVALID) This section defines the new chunk types that will be used to validate the negotiation of the protection engine selected for CRYPTO chunk. This to prevent down grade attacks on the negotiation of protection engines. Table 3 illustrates the new chunk type. +============+=====================================================+ | Chunk Type | Chunk Name | +============+=====================================================+ | 0x4X | Protected Association Parameter Validation (PVALID) | +------------+-----------------------------------------------------+ Table 3: PVALID Chunk Type It should be noted that the PVALID chunk format requires the receiver stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an ERROR chunk using the 'Unrecognized Chunk Type' error cause. This is accomplished (as described in [RFC9260] Section 3.2.) by the use of the upper bits of the chunk type. The PVALID chunk is used to hold the protection engines list. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x4X | Flags = 0 | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Protection Engines | | | | +-------------------------------+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PVALID Chunk Structure Chunk Type: 8 bits (unsigned integer) This value MUST be set to 0x4X. Chunk Flags: 8 bits MUST be set to zero on transmit and MUST be ignored on receipt. Westerlund, et al. Expires 20 August 2023 [Page 11] Internet-Draft SCTP CRYPTO Chunk February 2023 Chunk Length: 16 bits (unsigned integer) This value holds the length of the Protection Engines field in bytes plus 4. Protection Engines: variable length This holds the list of protection engines where each protection engine is specified by a 16-bit unsigned integer. The field MUST be identical to the content of the Protected Association Parameter (Section 4.1) Protection Engines field that the endpoint sent in the INIT or INIT-ACK chunk. Padding: 0 or 16 bits If the length of the Protection Engines field is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes to make the chunk 32-bit aligned. The Padding MUST NOT be longer than 2 bytes and it MUST be ignored by the receiver. RFC-Editor Note: Please replace 0x4X with the actual chunk type value assigned by IANA and then remove this note. 6. Error Handling This specification introduces a new set of error causes that are to be used when SCTP endpoint detects a faulty condition. The special case is when the error is detected by the protection engine that may provide additional information. 6.1. Mandatory Protected Association Parameter Missing When an initiator SCTP endpoint sends an INIT chunk that doesn't contain the Protected Association parameter towards an SCTP endpoint that only accepts protected associations, the responder endpoint SHALL raise a Missing Mandatory Parameter error. The ERROR chunk will contain the cause code 'Missing Mandatory Parameter' (2) (see [RFC9260] section 3.3.10.7) and the protected association parameter identifier Section 4.1 in the missing param Information field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code = 2 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Association ID | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Westerlund, et al. Expires 20 August 2023 [Page 12] Internet-Draft SCTP CRYPTO Chunk February 2023 Figure 5: ERROR Missing Protected Association Paramater Cause Length is equal to the number of missing parameters 8 + N * 2 according to [RFC9260], section 3.3.10.2. 6.2. Error in Protection A new Error Type is defined for Crypto Chunk, it's used for any error related to the Protection mechanism described in this document and has a structure that allows detailed information to be added as extra causes. This specification describes some of the causes whilst the Protection Engine Specification MAY add further Causes related to the related Protection Engine. When detecting an error, SCTP will send an ABORT chunk followed by ERROR chunk containing the relevant Error Type and Causes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code = TBA9 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extra Cause #1 | Extra Cause #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extra Cause #N-1 | Extra Cause #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Error in Protection Cause Format Casuse Code: 16 bits (unsigned integer) The SCTP Error Chunk Cause Code indicating "Error in Protection" is TBA9. Cause Length: 16 bits (unsigned integer) Is for N extra Causes equal to 4 + N * 2 Extra Cause: 16 bits (unsigned integer) Each Extra Cause indicate an additional piece of information as part of the error. There MAY be 0 to as many as can fit in the extra cause field in the ERROR Chunk (A maximum of 32764). Editor's Note: Please replace TBA9 above with what is assigned by IANA. Below a number of defined Error Causes are defined, additional causes can be registered with IANA following the rules in Section 10.2. Westerlund, et al. Expires 20 August 2023 [Page 13] Internet-Draft SCTP CRYPTO Chunk February 2023 6.2.1. No Supported Protection Engine If list of protection engines contained in the INIT signal doesn't contain at least an entry that fits the list of protection engines at the responder, the responder will reply with an ERROR chunk with error in protection cause code (specified in Section 6.2) and the "No Supported Protection Engine" extra cause code identifier 0x00. 6.2.2. Error During Protection Handshake If the protection engine specifies a handshake for example for authentication, and key management is implemented inband, it may happen that the procedure has errors. In such case an ERROR chunk will be sent with error in protection cause code (specified in Section 6.2) and extra cause "Error During Protection Handshake" identifier 0x01. 6.2.3. Failure in Protection Engines Validation A Failure may occur during protection engine Validation (see Section 7.1.2). In such case an ERROR chunk will be sent with error in protection cause code (specified in Section 6.2) and extra cause "Failure in Protection Engines Validation" identifier 0x02 to indicate this failure. This error MUST be sent together with an SCTP abort to terminate the SCTP association. 6.2.4. Timeout During Protection Handshake or Validation Whenever a T-valid timeout occurs, the SCTP endpoint will send an ERROR chunk with "Error in Protection" cause (specified in Section 6.2) and extra cause "Timeout During Protection Handshake or Validation" identifier 0x03 to indicate this failure. To indicate in which phase the timeout occurred an additional extra cause code is added. If the protection engine specifies that key management is implemented inband and the T-valid timeout occurs during the handshake the Cause-Specific code to add is "Error During Protection Handshake" identifier 0x01. If the T-valid timeout occurs during the protection association parameter validation, the extra cause code to use is "Failure in Protection Engines Validation" identifier 0x02. 6.3. Critical Error from Protection Engine Protection engine MAY inform local SCTP endpoint about errors, in such case it's to be defined in the protection engine specification document. When an Error in the protection engine compromises the protection mechanism, the protection engine may stop processing data altogether, thus the local SCTP endpoint will not be able to send or receive any chunk for the specified Association. This will cause the Westerlund, et al. Expires 20 August 2023 [Page 14] Internet-Draft SCTP CRYPTO Chunk February 2023 Association to be closed by legacy timer-based mechanism. Since the Association protection is compromised no further data will be sent and the remote peer will also experience timeout on the Association. 6.4. Non-critical Error in the Protection Engine A non-critical error in the protection engine means that the protection engine is capable of recovering without the need of the whole Association to be restarted. From SCTP perspective, a non-critical error will be perceived as a temporary problem in the transport and will be handled with retransmissions and SACKS according to [RFC9260]. When the protection engine will experience a non-critical error, an ABORT chunk SHALL NOT be sent. This way non-critical errors are handled and how the protection engine will recover from these errors is being described in the Protection Engine Specifications. 7. Protected SCTP State Diagram The Figure 7 shows the changes of the SCTP association state machine as described in [RFC9260] section 4. .-------- (from any state) .-----. | receive INIT | | | receive ABORT [ABORT] --------------------- | v v -------------- or ---------- generate State Cookie | +---------+ delete TCB send ABORT send INIT ACK '---+ CLOSED | delete TCB +--+----+-+ / \ / \ [ASSOCIATE] | |----------------- | | create TCB | | send INIT receive valid | | start T1-init timer COOKIE ECHO | v (1) -----------------| +-----------+ create TCB | |COOKIE-WAIT| (2) send COOKIE ACK | +-----+-----+ | | | | receive INIT ACK | |------------------- | | send COOKIE ECHO | | stop T1-init timer | | start T1-cookie timer | v Westerlund, et al. Expires 20 August 2023 [Page 15] Internet-Draft SCTP CRYPTO Chunk February 2023 | +-------------+ | |COOKIE-ECHOED| (3) | +------+------+ | | | | receive COOKIE ACK | |------------------- | | stop T1-cookie timer +-----------------+-----+ | | +-----------------)----+-----+ | | | | | | v v | | +---------------------+ | | | PROTECTION PENDING | If INIT/INIT-ACK | | +----------+----------+ has Protected | | | Association | | | Parameter start | | | T-valid timer. | | | | | | [CRYPTO SETUP] | | |----------------- | | | send and receive | | | protection engine handshake | | | by means of CRYPTO chunks. | | | | | | | | v | | +----------------------+ | | | PROTECTED | | | +-----------+----------+ | | | | | | [ENDPOINT VALIDATION] | | |------------------------ | | | send and receive | | | PVALID by means of | | | CRYPTO chunk. | | | | | | | +-----------------+ | +-----------------+ | | | | | v v v +---------------+ | ESTABLISHED | +---------------+ Figure 7: SCTP State Diagram with Crypto Westerlund, et al. Expires 20 August 2023 [Page 16] Internet-Draft SCTP CRYPTO Chunk February 2023 7.1. New States This section describes details on the amendment to the SCTP association establishment state machine. 7.1.1. PROTECTION PENDING The presence of a Protected Association Parameter in the INIT or INIT-ACK chunk makes the State Machine entering PROTECTION PENDING state instead of ESTABLISHED. When entering PROTECTION PENDING state, a T-valid timer is started that will cover the whole validation time including the in-band key establishment. The value of T-valid is dependent on the protection engine and may also be further adjusted based if expected RTT values are outside of the ones commonly occurring on the general Internet, see Section 7.1.3. If key establishment is in-band, the protection engine will start the handshake with its peer and in case of failure or T-valid timeout, it will generate an ERROR chunk and an ABORT chunk. The ERROR handling follows what specified in Section 6.2.2. When Handshake has been successfully completed, the association state machine will enter PROTECTED state. The protection engine specification MUST specify when PROTECTED state can be entered for each endpoint. If key establishment is out-of- band, after starting T-valid timer the SCTP association will enter PROTECTED state per protection engine specification when the necessary security context is in place. 7.1.2. PROTECTED The association state machine can only reach PROTECTED state from PROTECTION PENDING state (see Section 7.1.1). When entering into PROTECTED state the T-valid timer is running and the protection engine has completed the key establishment so that protected data can be sent to the peer. From this time on, only CRYPTO chunks can be sent to the remote peer and any other type of plain text SCTP chunks coming from the remote peer will be silently discarded. Westerlund, et al. Expires 20 August 2023 [Page 17] Internet-Draft SCTP CRYPTO Chunk February 2023 In PROTECTED state the association initiating SCTP Endpoint (initiator) MUST validate the INIT sent protected association parameter, thus the initiator will send a PVALID chunk that will contain exactly the same list of Protection Engines as previously sent in protected association parameter of INIT chunk and in the same order. When the responder will receive PVALID, it will compare the list of protection engines with the list received in the INIT chunk, if they are identical it will reply to the initiator with a PVALID chunk containing the Protection Engine previously sent as protected association parameter in INIT-ACK chunk, it will clear the T-valid timer and will move into ESTABLISHED state. If the lists of Protection Engines don't match, it will generate an ERROR chunk and an ABORT chunk. ERROR CAUSE will indicate "Failure in Protection Engines Validation" and the SCTP association will be terminated. After sending PVALID, the initiator will wait for the responder to reply with the PVALID confirmation. The initiator will compare the Protection Engine received from the responder, if the value is the same it will clear the T-valid timer and move into ESTABLISHED state. If the chosen Protection Engines don't match, it will generate an ERROR chunk and an ABORT chunk. ERROR CAUSE will indicate "Failure in Protection Engines Validation" that is critical. If T-valid timer expires either at initiator or responder, it will generate an ERROR chunk and an ABORT chunk. The ERROR handling follows what specified in Section 6.2.4. 7.1.3. Consideration on T-valid The timer T-Valid supervises initializations that depend on how the handshake is specified for the Protection Engine and also on the characteristics of the transport network. This specification recommends a default value of 30 seconds for T-valid. This value is expected to be superseded by recommendations in the Protection Engine Specification for each Protection Engine. 8. Procedures Westerlund, et al. Expires 20 August 2023 [Page 18] Internet-Draft SCTP CRYPTO Chunk February 2023 8.1. Establishment of a Protected Association An SCTP Endpoint acting as initiator willing to create a Protected association shall send to the remote peer an INIT chunk containing the Protected Association parameter (see Section 4.1) where all the supported Protection Engines are listed, given in descending order of preference (see Figure 2). As alternative, an SCTP Endpoint acting as responder willing to support only protected associations shall consider INIT chunk not containing the Protected Association parameter as an error, thus it will reply with an ERROR chunk according to what specified in Section 6.1 indicating that for this endpoint mandatory protected association parameter is missing. An SCTP Endpoint acting as responder, when receiving an INIT chunk with protected association parameter, will search the list of protection engines for the most preferred commonly supported choice and will reply with INIT-ACK containing the protected association parameter with the chosen protection engine. When the responder cannot find a supported protection engine, it will reply with ABORT and Error in Protection with the extra cause code for "No Supported Protection Engine" (Section 6.2.1). When initiator and responder have agreed on a protected association by means of handshaking INIT/INIT-ACK with a common protection engine, only control chunks and CRYPTO chunks will be accepted. Any DATA chunk being sent on a Protected association will be silently discarded. After completion of initial handshake, that is after COOKIE-ECHO and COOKIE-ACK, the Protection Engine shall initialize itself by transferring its own data as Payload of the CRYPTO chunk (see Figure 3) if necessary. At completion of Protection Engine initialization, the setup of the Protected association is complete and from that time on only CRYPTO chunks will be exchanged. Any plain text chunks will be silently discarded. Westerlund, et al. Expires 20 August 2023 [Page 19] Internet-Draft SCTP CRYPTO Chunk February 2023 After completion of protected association initialization, the initiator MUST send to the responder a PVALID chunk (see Table 3) containing the list of Protection Engines previously sent in the protected association parameter of the INIT chunk. The responder receiving the PVALID chunk will compare the Protection Engines list with the one previously received in the INIT chunk, if they are exactly the same, with the same Protection engine in the same position, it will reply to the initiator with a PVALID chunk containing the chosen Protection Engine, otherwise it will reply with an ABORT chunk. If the association was not aborted the protected association is considered successfully established. When the initiator receive the PVALID chunk, it will compare with the previous chosen Protection Engine and in case of mismatch with the one received previously in the protected association parameter in the INIT-ACK chunk, it will reply with ABORT, otherwise the protected association is successfully established. 8.2. Termination of a Protected Association Besides the procedures for terminating an association explained in [RFC9260], the protection engine SHALL ask SCTP endpoint for terminating an association when having an internal error or by detecting a security violation, using the procedure described in Section 6.3. The internal design of Protection Engines and their capability is out of the scope of the current document. 9. Protected Data Chunk Handling With reference to the State Diagram as shown in Figure 7 and Figure 3 of [RFC9260], the handling of Control chunks, Data chunks and Crypto chunks follows the rules defined below: * When the association is in states CLOSED, COOKIE-WAIT, and COOKIE- ECHOED, any Control chunk is sent unprotected (i.e. plain text). No DATA chunks shall be sent in these states and DATA chunks received shall be silently discarded. * When the association is in state PROTECTION PENDING, any Control chunk is sent unprotected (i.e. plain text). No DATA chunks shall be sent in these states and DATA chunks received shall be silently discarded. CRYPTO Chunks can be sent by the Protection Engine to establish its security context. Westerlund, et al. Expires 20 August 2023 [Page 20] Internet-Draft SCTP CRYPTO Chunk February 2023 * When the association is in states PROTECTED, any SCTP chunk except for DATA and CRYPTO chunks, will be used to create an SCTP payload that will be encrypted by the Protection Engine and the result from that encryption will be the used as payload for a CRYPTO chunk that will be the only chunk in the SCTP packet to be sent. DATA chunks received shall be silently discarded. * When the association is in states ESTABLISHED and in the states for association shutdown, i.e. SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT as defined by [RFC9260], any SCTP chunk including DATA chunks, but excluding CRYPTO chunk, will be used to create an SCTP payload that will be encrypted by the Protection Engine and the result from that encryption will be the used as payload for a CRYPTO chunk that will be the only chunk in the SCTP packet to be sent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Plain Text SCTP Packet The diagram shown in Figure 8 describes the structure of any plain text SCTP packet being sent or received when the association has not reached the PROTECTED state yet. SCTP packet as depicted in Figure 9 may also be sent in PROTECTION PENDING state and in any later state of the association. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRYPTO Chunk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Protected SCTP Packets Westerlund, et al. Expires 20 August 2023 [Page 21] Internet-Draft SCTP CRYPTO Chunk February 2023 The diagram shown in Figure 9 describes the structure of an SCTP packet being sent after the PROTECTED state has been reached. Such packets are built with the SCTP common header. Only one CRYPTO chunk can be sent in a SCTP packet. 9.1. Protected Data Chunk Transmission When the association state machine (see Figure 7) has reached the PROTECTION PENDING state, it MAY perform protection engine key management inband depending on how the specification for the chosen Protection Engine has been defined. In such case, the CRYPTO chunk Handler will receive plain control chunks from the SCTP chunk handler and payload for CRYPTO chunks from the protection engine. Plain control chunks and CRYPTO chunks MUST NOT be bundled within the same SCTP packet. When the association state machine (see Figure 7) has reached the PROTECTED state, the CRYPTO chunk handler will receive control chunks and DATA chunks from the SCTP chunk handler as a complete SCTP payload with maximum size limited by PMTU reduced by the size of the SCTP common header and the CRYPTO chunk overhead. That plain payload will be sent to the protection engine in use for that specific association, the protection engine will return an encrypted payload. Depending on the specification for the chosen protection engine, when forming the CRYPTO chunk header the CRYPTO chunk handler MAY set the chunk header flags (see Figure 3). An SCTP packet containing an SCTP CRYPTO chunk SHALL be delivered without delay and SCTP bundling SHALL NOT be performed. 9.2. Protected Data Chunk Reception When the association state machine (see Figure 7) has reached the PROTECTION PENDING state, it MAY handle key management inband depending on how the specification for the chosen protection engine has been defined. In such case, the CRYPTO chunk handler will receive plain control chunks and CRYPTO chunks from the SCTP Header Handler. CRYPTO chunks will be forwarded to the protection engine whilst plain control chunks will be forwarded to SCTP chunk handler. During PROTECTION PENDING state, plain control chunks and CRYPTO chunks bundled within the same SCTP packet will be handled as protocol error. Westerlund, et al. Expires 20 August 2023 [Page 22] Internet-Draft SCTP CRYPTO Chunk February 2023 When the association state machine (see Figure 7) has reached the PROTECTED state, the CRYPTO chunk handler will receive CRYPTO chunks from the SCTP Header Handler. Payload from CRYPTO chunks will be forwarded to the protection engine in use for that specific association for decryption, the protection engine will return a plain SCTP Payload. The plain SCTP payload will be forwarded to SCTP Chunk Handler that will split it in separated chunks and will handle them according to [RFC9260]. Depending on the specification for the chosen protection engine, when receiving the CRYPTO chunk header the CRYPTO Chunk Handler MAY handle the Flags (see Figure 3) according to that specification. Meta data belonging to the SCTP packet received SHALL be tied to the relevant chunks and forwarded transparently to the SCTP endpoint. 9.2.1. SCTP Header Handler The SCTP Header Handler is responsible for correctness of the SCTP common header, it receives the SCTP packet from the lower transport layer, discriminates among associations and forwards the payload and relevant data to the SCTP protection engine for handling. In the opposite direction it creates the SCTP common header and fills it with the relevant information for the specific association and delivers it towards the lower transport layer. 10. IANA Considerations This document defines two new registries in the Stream Control Transmission Protocol (SCTP) Parameters group that IANA maintains. Theses registries are for the protection engine identifiers and extra cause codes for protection related errors. It also adds registry entries into several other registries in the Stream Control Transmission Protocol (SCTP) Parameters group: * Two new SCTP Chunk Types * One new SCTP Chunk Parameter Type * One new SCTP Error Cause Codes 10.1. Protection Engine Identifier Registry IANA is requested to create a new registry called "CRYPTO Chunk Protection Engine Identifiers". This registry is part of the Stream Control Transmission Protocol (SCTP) Parameters grouping. Westerlund, et al. Expires 20 August 2023 [Page 23] Internet-Draft SCTP CRYPTO Chunk February 2023 The purpose of this registry is to enable identification of different protection engines used by the CRYPTO chunk when performing the SCTP handshake and negotiating support. Entries in the registry requires a protection engine name, a reference to the specification for the protection engine, and a contact. Each entry will be assigned by IANA a unique 16-bit unsigned integer identifier for their protection engine. Values 0-65534 are available for assignment. Value 65535 is reserved for future extension. The proposed general form of the registry is depicted below in Table 4. +==========+==========================+===========+=========+ | ID Value | Name | Reference | Contact | +==========+==========================+===========+=========+ | 0-65534 | Available for Assignment | RFC-To-Be | | +----------+--------------------------+-----------+---------+ | 65535 | Reserved | RFC-To-Be | Authors | +----------+--------------------------+-----------+---------+ Table 4: Protection Engine Identifier Registry New entries are registered following the Specification Required policy as defined by [RFC8126]. 10.2. Protection Error Cause Codes Registry IANA is requested to create a new registry called "Protection Error Cause Codes". This registry is part of the Stream Control Transmission Protocol (SCTP) Parameters grouping. The purpose of this registry is to enable identification of different protection related errors when using CRYPTO chunk and a protection engine. Entries in the registry requires a Meaning, a reference to the specification defining the error, and a contact. Each entry will be assigned by IANA a unique 16-bit unsigned integer identifier for their protection engine. Values 0-65534 are available for assignment. Value 65535 is reserved for future extension. The proposed general form of the registry is depicted below in Table 5. Westerlund, et al. Expires 20 August 2023 [Page 24] Internet-Draft SCTP CRYPTO Chunk February 2023 +============+=========================+===========+=========+ | Cause Code | Meaning | Reference | Contact | +============+=========================+===========+=========+ | 0 | Error in the Protection | RFC-To-Be | Authors | | | Engine List | | | +------------+-------------------------+-----------+---------+ | 1 | Error During Protection | RFC-To-Be | Authors | | | Handshake | | | +------------+-------------------------+-----------+---------+ | 2 | Failure in Protection | RFC-To-Be | Authors | | | Engines Validation | | | +------------+-------------------------+-----------+---------+ | 3 | Timeout During KEY | RFC-To-Be | Authors | | | Handshake or Validation | | | +------------+-------------------------+-----------+---------+ | 4-65534 | Available for | RFC-To-Be | Authors | | | Assignment | | | +------------+-------------------------+-----------+---------+ | 65535 | Reserved | RFC-To-Be | Authors | +------------+-------------------------+-----------+---------+ Table 5: Protection Error Cause Code New entries are registered following the Specification Required policy as defined by [RFC8126]. 10.3. SCTP Chunk Types In the Stream Control Transmission Protocol (SCTP) Parameters group's "Chunk Types" registry, IANA is requested to add the two new entries depicted below in in Table 6 with a reference to this document. The registry at time of writing was available at: https://www.iana.org/assignments/sctp-parameters/sctp- parameters.xhtml#sctp-parameters-1 +==========+===============================+===========+ | ID Value | Chunk Type | Reference | +==========+===============================+===========+ | TBA6 | Crypto Chunk (CRYPTO) | RFC-To-Be | +----------+-------------------------------+-----------+ | TBA7 | Protected Association | RFC-To-Be | | | Parameter Validation (PVALID) | | +----------+-------------------------------+-----------+ Table 6: New Chunk Types Registered Westerlund, et al. Expires 20 August 2023 [Page 25] Internet-Draft SCTP CRYPTO Chunk February 2023 10.4. SCTP Chunk Parameter Types In the Stream Control Transmission Protocol (SCTP) Parameters group's "Chunk Parameter Types" registry, IANA is requested to add the new entry depicted below in in Table 7 with a reference to this document. The registry at time of writing was available at: https://www.iana.org/assignments/sctp-parameters/sctp- parameters.xhtml#sctp-parameters-2 +==========+=======================+===========+ | ID Value | Chunk Parameter Type | Reference | +==========+=======================+===========+ | TBA8 | Protected Association | RFC-To-Be | +----------+-----------------------+-----------+ Table 7: New Chunk Type Parameters Registered 10.5. SCTP Error Cause Codes In the Stream Control Transmission Protocol (SCTP) Parameters group's "Error Cause Codes" registry, IANA is requested to add the new entry depicted below in in Table 8 with a reference to this document. The registry at time of writing was available at: https://www.iana.org/assignments/sctp-parameters/sctp- parameters.xhtml#sctp-parameters-24 +==========+=========================+===========+ | ID Value | Error Cause Codes | Reference | +==========+=========================+===========+ | TBA9 | Protection Engine Error | RFC-To-Be | +----------+-------------------------+-----------+ Table 8: Error Cause Codes Parameters Registered 11. Security Considerations All the security and privacy considerations of the security protocol used as the protection engine applies. 11.1. Privacy Considerations Using a security protocol in the SCTP CRYPTO chunk might lower the privacy properties of the security protocol as the SCTP Verification Tag is an unique identifier for the association. Westerlund, et al. Expires 20 August 2023 [Page 26] Internet-Draft SCTP CRYPTO Chunk February 2023 11.2. Downgrade Attacks The CRYPTO chunk provides a mechanism for preventing downgrade attacks that detects downgrading attempts between protection engines and terminates the association. The chosen protection engine is the same as if the peers had been communicating in the absence of an attacker. The protection engine initial handshake is verified before the association is set as ESTABLISHED, thus no user data are sent before validation. The downgrade protection is only as strong as the weakest of the supported protection engines as an active attacker can trick the endpoints to negotiate the weakest protection engine and then modify the weakly protected CRYPTO chunks to deceive the endpoints that the negotiation of the protection engines is validated. This is similar to the downgrade protection in TLS 1.3 specified in Section 4.1.3. of [RFC8446] where downgrade protection is not provided when TLS 1.2 with static RSA is used. It is RECOMMENDED to only support a limited set of strongly profiled protection engines. 12. Requirements towards the protection engines This section specifies what is to be specified in the description of a protection engine. * Define how to protect the plain text set of chunks and encapsulate them in the CRYPTO Chunk payload. * Can define its usage of the 8-bit chunk Flags field in the CRYPTO chunk * Is required to register the defined protection engine(s) with IANA per Section 10.1. * Define how it and in such case how it transmits SCTP packets that are not created by the SCTP chunk handler, and instead by the Protection engine. This requires consideration of congestion control and path MTU. * Detail the state transition between PROTECTION PENDING and PROTECTED state (see Section 7). 13. References 13.1. Normative References Westerlund, et al. Expires 20 August 2023 [Page 27] Internet-Draft SCTP CRYPTO Chunk February 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022, . 13.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Magnus Westerlund Ericsson Email: magnus.westerlund@ericsson.com John Preuß Mattsson Ericsson Email: john.mattsson@ericsson.com Claudio Porfiri Ericsson Email: claudio.porfiri@ericsson.com Westerlund, et al. Expires 20 August 2023 [Page 28]