Internet DRAFT - draft-westerlund-tsvwg-sctp-crypto-chunk
draft-westerlund-tsvwg-sctp-crypto-chunk
TSVWG M. Westerlund
Internet-Draft J. Preuß Mattsson
Intended status: Standards Track C. Porfiri
Expires: 11 March 2024 Ericsson
8 September 2023
Stream Control Transmission Protocol (SCTP) CRYPTO Chunk
draft-westerlund-tsvwg-sctp-crypto-chunk-02
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 but with some limitations.
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 11 March 2024 [Page 1]
Internet-Draft SCTP CRYPTO Chunk September 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 11 March 2024.
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 . . . . . . . . . . . . . . . . . . . 8
2.5. Congestion Control Considerations . . . . . . . . . . . . 8
2.6. ICMP Considerations . . . . . . . . . . . . . . . . . . . 8
2.7. Path Selection Considerations . . . . . . . . . . . . . . 9
2.8. Dynamic Address Reconfiguration Considerations . . . . . 9
2.9. SCTP Restart Considerations . . . . . . . . . . . . . . . 9
2.9.1. INIT chunk in CRYPTO chunk . . . . . . . . . . . . . 10
2.9.2. INIT chunk as plain text . . . . . . . . . . . . . . 10
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. New Parameter Type . . . . . . . . . . . . . . . . . . . . . 11
4.1. Protected Association Parameter . . . . . . . . . . . . . 12
5. New Chunk Types . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Crypto Chunk (CRYPTO) . . . . . . . . . . . . . . . . . . 13
5.2. Protected Association Parameter Validation Chunk
(PVALID) . . . . . . . . . . . . . . . . . . . . . . . . 14
Westerlund, et al. Expires 11 March 2024 [Page 2]
Internet-Draft SCTP CRYPTO Chunk September 2023
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Mandatory Protected Association Parameter Missing . . . . 15
6.2. Error in Protection . . . . . . . . . . . . . . . . . . . 16
6.2.1. No Supported Protection Engine . . . . . . . . . . . 17
6.2.2. Error During Protection Handshake . . . . . . . . . . 17
6.2.3. Failure in Protection Engines Validation . . . . . . 17
6.2.4. Timeout During Protection Handshake or Validation . . 17
6.3. Critical Error from Protection Engine . . . . . . . . . . 18
6.4. Non-critical Error in the Protection Engine . . . . . . . 18
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Establishment of a Protected Association . . . . . . . . 18
7.2. Termination of a Protected Association . . . . . . . . . 20
7.3. Protection Initialization State Machine . . . . . . . . . 21
7.4. Considerations on Key Management . . . . . . . . . . . . 21
7.5. Consideration on T-valid . . . . . . . . . . . . . . . . 22
8. Protected Data Chunk Handling . . . . . . . . . . . . . . . . 22
8.1. Protected Data Chunk Transmission . . . . . . . . . . . . 23
8.2. Protected Data Chunk Reception . . . . . . . . . . . . . 24
8.2.1. SCTP Header Handler . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Protection Engine Identifier Registry . . . . . . . . . . 25
9.2. Protection Error Cause Codes Registry . . . . . . . . . . 25
9.3. SCTP Chunk Types . . . . . . . . . . . . . . . . . . . . 26
9.4. SCTP Chunk Parameter Types . . . . . . . . . . . . . . . 27
9.5. SCTP Error Cause Codes . . . . . . . . . . . . . . . . . 27
9.6. SCTP Payload Protocol Identifier . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28
10.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 28
11. Requirements Towards the Protection Engines . . . . . . . . . 29
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 11 March 2024 [Page 3]
Internet-Draft SCTP CRYPTO Chunk September 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 most transport features
provided by SCTP and its extensions. However, there can be some
limitations or additional requirements for them to function such as
those noted for SCTP restart and use of Dynamic Address
Reconfiguration, see Section 2.8 and Section 2.9. 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 that are possible to use between two SCTP peers with full
security and SCTP association state.
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 their SCTP
protocol specifications. Figure 1 illustrates the CRYPTO chunk
layering in regard to SCTP and the Upper Layer Protocol (ULP).
Westerlund, et al. Expires 11 March 2024 [Page 4]
Internet-Draft SCTP CRYPTO Chunk September 2023
+---------------+ +--------------------+
| | | Protection Engine | Keys
| ULP | | +-------------.
| | | Key Management | |
+---------------+-+---+----------------+ |
| | \ User |
| | +-- Level |
| SCTP Chunks Handler | Messages |
| | |
| | +-- SCTP Unprotected Payload |
| |/ |
+---------------------+ +---------------------+ |
| CRYPTO | | Protection Engine | |
| Chunk |<-->| |<--'
| Handler | | Protection Operator |
+---------------------+ +---------------------+
| |\
| SCTP Header Handler | +-- SCTP Protected Payload
| |
+---------------------+
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 SCTP association is established and the peers have agreed on what
protection to use, the SCTP endpoints may start sending Protection
Westerlund, et al. Expires 11 March 2024 [Page 5]
Internet-Draft SCTP CRYPTO Chunk September 2023
Engine's payloads in SCTP DATA 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 and may be done out-of-band of the SCTP association.
When the endpoint authentication and key establishment has been
completed, the association is considered to be secured and the ULP is
informed about that. From this time on it's possible for the ULPs to
exchange data securely.
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.
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 in regards to the payloads of the
CRYPTO chunk, and have its own key management capability. SCTP is
capable of providing reliable transport of key-management messages.
SCTP CRYPTO chunk directly exploits the protection engine by
requesting protection and unprotection of a buffer, in particular the
protection buffer should never exceed the possible SCTP packet size
thus protection engine needs to 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. SCTP CRYPTO provides support for in-band key management, on
those cases the Protection Engines uses SCTP DATA chunks identified
with a dedicated Payload Protocol Identifier. The protection engine
can specify if the transmission of any key-managment messages are
non-reliable or reliable transmitted by SCTP.
During protection engine initialization, that is after the SCTP
association reaches the ESTABLISHED state (see [RFC9260] Section 4),
but before protection engine key-management has completed and the
Protected Assocation Parameter Validation is completed, the in-band
Key Management MAY use DATA chunks that SHALL use the Protection
Engine PPID (see Table 9). These DATA chunks SHALL be sent
unprotected by the protection engine as no keys have been established
yet. As soon as the protection engine has been intialized and the
Westerlund, et al. Expires 11 March 2024 [Page 6]
Internet-Draft SCTP CRYPTO Chunk September 2023
validation has occured, any protection engine that uses in-band key
management, i.e. sent using SCTP DATA chunks with the Protection
Engine PPID, will have their message protected inside SCTP CRYPTO
chunk protected with the currently established key. SCTP CRYPTO
chunk state evolution is described in Section 7.3.
Key management MAY use other mechanism than what provided by SCTP
CRYPTO chunks, in any case the mechanism for key management MUST be
detailed in the specification for that protection engine.
The protection engines MAY exploit the Flags byte provided by the
CRYPTO chunk header (see Figure 3) for its needs. 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 as specified in
[I-D.westerlund-tsvwg-sctp-crypto-dtls].
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.
Westerlund, et al. Expires 11 March 2024 [Page 7]
Internet-Draft SCTP CRYPTO Chunk September 2023
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. As those
packets do not represent what the peer sent, it is acceptable to
ignore them, although in-situ modification on the path of a packet
resulting in discarding due to integrity failure will leave a gap,
but has to be accepted as part of the path behavior.
The protection 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
The SCTP implementation will be responsible for handling ICMP
messages and their validation as specified in [RFC9260] Section 10.
This means that the ICMP validation needs to be done in relation to
the actual sent SCTP packets with the CRYPTO chunk and not the
unprotected payload. 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.
Westerlund, et al. Expires 11 March 2024 [Page 8]
Internet-Draft SCTP CRYPTO Chunk September 2023
2.7. Path Selection Considerations
When an Association is multihomed there are multiple paths between
Endpoints. The selection of the specific path to be used at a
certain time belongs to SCTP protocol that will decide according to
[RFC9260]. The Protection Engine shall not influence the path
selection algorithm, actually the Protection Engine will not even
know what path is being used.
2.8. Dynamic Address Reconfiguration Considerations
When using Dynamic Address Reconfiguration [RFC5061] in an SCTP
association using CRYPTO Chunk the ASCONF chunk is protected, thus it
needs to be unprotected first, furthermore it MAY come from an
unknown IP Address. In order to properly address the ASCONF chunk to
the relevant Association for being unprotected, Destination Address,
Source and Destination ports and VTag shall be exploited. If the
combination of those parameters is not unique the implementor MAY
choose to send the Crypto Chunk to all Associations that fit with the
parameters in order to find the right one. The association will
attempt de-protection operations on the crypto chunk, and if that is
successful the ASCONF chunk can be processed.
The recommendation [RFC5061] specifies (section 4.1.1 of [RFC5061])
that ASCONF message are required to be sent authenticated with SCTP-
AUTH [RFC4895]. For SCTP associations using Crypto Chunks, when the
Protection Engine provides strong Authentication such for instance in
case of DTLS, results in the use of redundant mechanism for
Authentication with both SCTP-AUTH and the Crypto Chunk. We
recommend to amend [RFC5061] for including Crypto Chunks as
Authentication mechanism for ASCONF chunks.
2.9. SCTP Restart Considerations
This section deals with the handling of an unexpected INIT chunk
during an Association lifetime as described in [RFC9260] section 5.2
The introduction of CRYPTO CHUNK opens for two alternatives depending
on if the protection engine preserves its state (crypto context) or
not.
When the encryption engine can preserve the crypto context, meaning
that encrypted data belonging to the current Association can be
encrypted and decrypted, the request for SCTP Restart SHOULD use INIT
chunk in CRYPTO chunk.
Westerlund, et al. Expires 11 March 2024 [Page 9]
Internet-Draft SCTP CRYPTO Chunk September 2023
When the crypto context is not preserved, the SCTP Restart can only
be accomplished by means of plain text INIT. This opens to a man-in-
the-middle attack where a malicious attacker may theoretically
generate an INIT chunk with proper parameters and hijack the SCTP
association.
2.9.1. INIT chunk in CRYPTO chunk
If the crypto context has been preserved the peer aiming for a SCTP
Restart can still send CRYPTO chunks that can be processed by the
remote peer. In such case the peer willing to restart the
Association SHOULD send the INIT chunk in a CRYPTO chunk and encrypt
it. At reception of the CRYPTO chunk containing INIT, the receiver
will follow the procedure described in [RFC9260] section 5.2.2 with
the exception that all the chunks will be sent in CRYPTO chunks.
An endpoint supporting SCTP Association Restart and implementing
Crypto Chunk MUST accept receiving SCTP packets with a verification
tag with value 0. The endpoint will attempt to map the packet to an
association based on source IP address, destination address and port.
If the combination of those parameters is not unique the implementor
MAY choose to send the Crypto Chunk to all Associations that fit with
the parameters in order to find the right one. Note that type of
trial decrypting of the SCTP packets will increase the resource
consumption per packet with the number of matching SCTP associations.
Note that the Association Restart will update the verification tags
for both endpoints. At the end of the unexpected INIT handshaking
the receiver of INIT chunk SHALL trigger the creation of a new DTLS
connection to be executed as soon as possible to verify the peer
identity.
2.9.2. INIT chunk as plain text
If the crypto context isn't preserved the peer aiming for a SCTP
Restart can only perform an INIT in plain text. Supporting this
option opens up the SCTP association to an availability attack, where
an capable attacker may be able to hijack the SCTP association.
Therefore an implementation should only support and enable this
option if restart is crucial.
To mount the attack the attacker needs to be able to process copies
of packets sent from the target endpoint towards its peer for the
targeted SCTP association. In addition the attacker needs to be able
to send IP packets with a source address of the target's peer. If
the attacker can send an SCTP INIT that appear to be from the peer,
if the target is allowing this option it will generate an INIT ACK
back, and assuming the attacker succesfully completes the restart
Westerlund, et al. Expires 11 March 2024 [Page 10]
Internet-Draft SCTP CRYPTO Chunk September 2023
handshake process the attack has managed to change the VTAG for the
association and the peer will no longer respond, leading to a SCTP
associatons failure.
As mitigation an SCTP endpoint supporting Association Restart by
means of plain text INIT SHOULD support is the following. The
endpoint receiving an INIT should send HEARTBEATs protected by CRYPTO
CHUNK to its peer to validate that the peer is unreachable. If the
endpoint receive an HEARTBEAT ACK within a reasonable time (at least
a couple of RTTs) the restart INIT SHOULD be discarded as the peer
obviously can respond, and thus have no need for a restart. A
capable attacker can still succeed in its attack supressing the
HEARTBEAT(s) through packet filtering, congestion overload or any
other method preventing the HEARTBEATS or there ACKs to reach their
destination. If it has been validated that the peer is unreachable,
the INIT chunk will trigger the procedure described in [RFC9260]
section 5.2.2
Note that the Association Restart will update the verification tags
for both endpoints. At the end of the unexpected INIT handshaking
the receiver of INIT chunk SHALL trigger the creation of a new DTLS
connection to be executed as soon as possible. Also note that
failure in handshaking of a new DTLS connection is considered a
protocol violation and will lead to Association Abort (see
Section 6.2.2).
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
Westerlund, et al. Expires 11 March 2024 [Page 11]
Internet-Draft SCTP CRYPTO Chunk September 2023
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.
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.
Westerlund, et al. Expires 11 March 2024 [Page 12]
Internet-Draft SCTP CRYPTO Chunk September 2023
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.
+============+=======================+
| 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.
Westerlund, et al. Expires 11 March 2024 [Page 13]
Internet-Draft SCTP CRYPTO Chunk September 2023
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Westerlund, et al. Expires 11 March 2024 [Page 14]
Internet-Draft SCTP CRYPTO Chunk September 2023
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.
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.
Westerlund, et al. Expires 11 March 2024 [Page 15]
Internet-Draft SCTP CRYPTO Chunk September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ERROR Missing Protected Association Paramater
Note: Cause Length is equal to the number of missing parameters 8 + N
* 2 according to [RFC9260], section 3.3.10.2. Also the Protection
Association ID may be present in any of the N missing params, no
order implied by the example in Figure 5.
6.2. Error in 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 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.
Westerlund, et al. Expires 11 March 2024 [Page 16]
Internet-Draft SCTP CRYPTO Chunk September 2023
Cause Length: 16 bits (unsigned integer)
Is for N extra Causes equal to 4 + N * 2
Extra Cause: 16 bits (unsigned integer)
Each Extra Cause indicate an additional piece of information as
part of the error. There MAY be zero to as many as can fit in the
extra cause field in the ERROR Chunk (A maximum of 32764).
Editor's Note: Please replace TBA9 above with what is assigned by
IANA.
Below a number of defined Error Causes are defined, additional causes
can be registered with IANA following the rules in Section 9.2.
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 ABORT 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 in-band, it may
happen that the procedure has errors. In such case an ABORT 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, i.e. when
the PVALID chunks Section 5.2 are exchanged to validate the
protection engine offered. In such case an ABORT 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.
6.2.4. Timeout During Protection Handshake or Validation
Whenever a T-valid timeout occurs, the SCTP endpoint will send an
ABORT 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
Westerlund, et al. Expires 11 March 2024 [Page 17]
Internet-Draft SCTP CRYPTO Chunk September 2023
implemented in-band 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
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. Procedures
7.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).
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
Westerlund, et al. Expires 11 March 2024 [Page 18]
Internet-Draft SCTP CRYPTO Chunk September 2023
cannot find a supported protection engine, it will reply with ABORT
containing Error in Protection with the extra cause code for "No
Supported Protection Engine" (Section 6.2.1).
Additionally, 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 ABORT chunk according to what specified in Section 6.1
indicating that for this endpoint mandatory protected association
parameter is missing.
When initiator and responder have agreed on a protected association
by means of handshaking INIT/INIT-ACK with a common protection engine
the SCTP association establishment continue until it has reached the
ESTABLISHED state. However, before the SCTP assocation is protected
by the Crypto Chunk and its protection engine some additional states
needs to be passed. First the protection engine needs be initilizied
in the PROTECTION INTILIZATION state. When that has been
accomplished one enters the VALIDATION state where one validates the
exchange of the Protected Association Parameter. If that is
successful one enters the PROTECTED state. This state sequence is
depicted in Section 7.3.
Until the procedure has reached the PROTECTED state the only usage of
DATA Chunks that is accepted is DATA Chunks with the Protection
Engine PPID. Any other DATA chunk being sent on a Protected
association SHALL be silently discarded.
The Protection Engine may initialize itself by transferring its own
messages as payload of the DATA chunk if necessary. The Crypto Chunk
initialization SHOULD be supervised by a T-valid timer that depends
on the protection engine and may also be further adjusted based on
whether expected RTT values are outside of the ones commonly
occurring on the general Internet, see Section 7.5. At completion of
Protection Engine initialization the setup of the Protected
association is complete and one enters the VALIDATION state, and from
that time on only CRYPTO chunks will be exchanged. Any plain text
chunk will be silently discarded.
If protection engine key establishment is in-band, the protection
engine will start the handshake with its peer and in case of failure
or T-valid timeout, the endpoint will generate an ABORT chunk. The
ERROR handling follows what specified in Section 6.2.2.
Westerlund, et al. Expires 11 March 2024 [Page 19]
Internet-Draft SCTP CRYPTO Chunk September 2023
The protection engine specification MUST specify when VALIDATION
state can be entered for each endpoint. If key establishment is out-
of-band, after starting T-valid timer the SCTP association will enter
the VALIDATION state per protection engine specification when the
necessary security context is in place.
When entering the VALIDATION state, 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 transmission of the PVALID chunk
MUST be done reliably. 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. ERROR CAUSE
will indicate "Failure in Protection Engines Validation" and the SCTP
association will be terminated. If the association was not aborted
the protected association is considered successfully established and
the PROTECTED state is entered.
When the initiator receives the PVALID 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 with the ERROR CAUSE
"Failure in Protection Engines Validation", otherwise the protected
association is successfully established and the initiator enters the
PROTECTED state.
If T-valid timer expires either at initiator or responder, it will
generate an ABORT chunk. The ERROR handling follows what specified
in Section 6.2.4.
In the PROTECTED state any ULP SCTP messages for any PPID MAY be
exchanged in the protected SCTP association.
7.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. During the termination procedure all Control Chunks
SHALL be protected except SHUTDOWN-COMPLETE. The internal design of
Protection Engines and their capability is out of the scope of the
current document.
Westerlund, et al. Expires 11 March 2024 [Page 20]
Internet-Draft SCTP CRYPTO Chunk September 2023
7.3. Protection Initialization State Machine
+---------------+
| ESTABLISHED |
+-------+-------+
|
| If INIT/INIT-ACK has Protected
| Association Parameter
v
+--------------------------+
| PROTECTION INITILIZATION |
+------------+-------------+
|
| start T-valid timer.
|
| [CRYPTO SETUP]
|-----------------
| send and receive
| protection engine handshake
v
+----------------------+
| VALIDATION |
+-----------+----------+
|
| [ENDPOINT VALIDATION]
|------------------------
| send and receive
| PVALID by means of
| CRYPTO chunk.
v
+---------------+
| PROTECTED |
+---------------+
Figure 7: Crypto Chunk State Diagram
7.4. Considerations on Key Management
When the Association is in PROTECTION INITILIZATION state, in-band
key management shall exploit SCTP DATA chunk with the Protection
Engine PPID (see Table 9) that will be sent unencrypted.
When the Association is in crypto chunk PROTECTED state and the SCTP
assocation is in ESTABLISHED or any of the states that can be reached
after ESTABLISHED state, in-band key management shall exploit SCTP
DATA chunk that will be protected by the Protection Engine and
encapsulated in CRYPTO chunks.
Westerlund, et al. Expires 11 March 2024 [Page 21]
Internet-Draft SCTP CRYPTO Chunk September 2023
In-band key management shall use a dedicated Payload Protocol
Identifier assigned by IANA and defined in the specific Protection
Engine Specification.
7.5. 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. Protected Data Chunk Handling
With reference to the Crypto Chunk states and the state Diagram as
shown in 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 Crypto Chunk is in state PROTECTED and the SCTP
association is in states ESTABLISHED or 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. DATA chunks are accepted and handled
according to section 4 of [RFC9260].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Westerlund, et al. Expires 11 March 2024 [Page 22]
Internet-Draft SCTP CRYPTO Chunk September 2023
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 Crypto Chunk is not
in VALIDATION or PROTECTED state.
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
The diagram shown in Figure 9 describes the structure of an SCTP
packet being sent after the Crypto Chunk VALIDATION or 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.
8.1. Protected Data Chunk Transmission
When the Crypto Chunk state machine hasn't reached the VALIDATION
state, the protection enigne MAY perform protection engine key
management in-band depending on how the specification for the chosen
Protection Engine has been defined. In such case, the CRYPTO chunk
Handler will receive plain control and DATA chunks from the SCTP
chunk handler.
When the Crypto Chunk has reached the VALIDATION and 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.
Westerlund, et al. Expires 11 March 2024 [Page 23]
Internet-Draft SCTP CRYPTO Chunk September 2023
8.2. Protected Data Chunk Reception
When the Crypto Chunk state machine hasn't reached the VALIDATION
state, it MAY handle key management in-band 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 DATA chunks with Protection Engine PPID from the SCTP Header
Handler. Those plain control chunks will be forwarded to SCTP chunk
handler.
When the Crypto Chunk state machine has reached the VALIDATION or
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.
8.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.
9. 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
Westerlund, et al. Expires 11 March 2024 [Page 24]
Internet-Draft SCTP CRYPTO Chunk September 2023
* One new SCTP Chunk Parameter Type
* One new SCTP Error Cause Codes
* One new SCTP Payload Protocol Identifier
9.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.
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].
9.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.
Westerlund, et al. Expires 11 March 2024 [Page 25]
Internet-Draft SCTP CRYPTO Chunk September 2023
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.
+============+=========================+===========+=========+
| 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].
9.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
Westerlund, et al. Expires 11 March 2024 [Page 26]
Internet-Draft SCTP CRYPTO Chunk September 2023
+==========+===============================+===========+
| 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
9.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
9.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
Westerlund, et al. Expires 11 March 2024 [Page 27]
Internet-Draft SCTP CRYPTO Chunk September 2023
9.6. SCTP Payload Protocol Identifier
In the Stream Control Transmission Protocol (SCTP) Parameters group's
"Payload Protocol Identifiers" registry, IANA is requested to add the
new entry depicted below in in Table 9 with a reference to this
document. The registry at time of writing was available at:
https://www.iana.org/assignments/sctp-parameters/sctp-
parameters.xhtml#sctp-parameters-25
+==========+=======================================+===========+
| ID Value | SCTP Payload Protocol Identifier | Reference |
+==========+=======================================+===========+
| TBA10 | Protection Engine Protocol Identifier | RFC-To-Be |
+----------+---------------------------------------+-----------+
Table 9: Protection Engine Protocol Identifier Registered
10. Security Considerations
All the security and privacy considerations of the security protocol
used as the protection engine applies.
10.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.
10.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 Crypto
Chunk is considered protected, thus no user data are sent before
validation.
Westerlund, et al. Expires 11 March 2024 [Page 28]
Internet-Draft SCTP CRYPTO Chunk September 2023
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.
11. 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 9.1.
* Detail the state transition between PROTECTION INITILIZATION and
VALIDATION.
12. Acknowledgments
The authors thank Michael Tüxen for his invaluable comments helping
to cope with Association Restart, ASCONF handling and restructuring
the Protection Engine architecture.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
2007, <https://www.rfc-editor.org/info/rfc4895>.
Westerlund, et al. Expires 11 March 2024 [Page 29]
Internet-Draft SCTP CRYPTO Chunk September 2023
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
13.2. Informative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[I-D.westerlund-tsvwg-sctp-crypto-dtls]
Westerlund, M., Preuß Mattsson, J., and C. Porfiri,
"Datagram Transport Layer Security (DTLS) in the Stream
Control Transmission Protocol (SCTP) CRYPTO Chunk", June
2023, <https://datatracker.ietf.org/doc/draft-westerlund-
tsvwg-sctp-crypto-dtls/>.
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 11 March 2024 [Page 30]
