ietf-corpus

rfc-4960

Stream Control Transmission Protocol

R. Stewart (Editor)
date2007-09 streamIETF areawit wgtsvwg statusPROPOSED STANDARD pages152 canonicalhttps://www.rfc-editor.org/rfc/rfc4960 doi10.17487/RFC4960 errataview
This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]

obsoleted by

obsoletes

updated by

Extracted elements (29)

design-rationale §1.1

SCTP uses multiple independent streams within a single association to eliminate head-of-line blocking inherent in TCP. A blocked stream waiting for the next in-sequence message does not prevent delivery on other streams, making SCTP suitable for multiplexed PSTN signaling and similar applications.

sctp

design-rationale §5.1.3

The cookie mechanism deliberately defers server-side state allocation (TCB creation) until the COOKIE ECHO is verified. This was chosen to resist denial-of-service attacks analogous to TCP SYN flooding without requiring stateless cookie generation on every packet.

sctp, security

interoperability-note §3.3.2.1

A sender MUST NOT use IPv4-mapped IPv6 addresses in the IPv6 Address parameter; a separate IPv4 Address parameter MUST be used instead. Omitting all IP Address parameters from INIT and INIT ACK is an alternative approach that improves NAT traversal compatibility.

sctp, ip, nat, v6ops

normative-requirement §1.6 SHOULD

All TSN arithmetic MUST be performed modulo 2^32 using Serial Number Arithmetic as per RFC 1982 (SERIAL_BITS=32). An endpoint SHOULD NOT transmit a DATA chunk with a TSN more than 2^31-1 above the beginning TSN of its current send window.

sctp

normative-requirement §8.2 MUST

An endpoint MUST use heartbeat chunks to monitor the reachability of peer transport addresses. A path is declared failed when the error count exceeds Path.Max.Retrans; the endpoint fails when all paths fail or the overall error count exceeds Association.Max.Retrans.

sctp

normative-requirement §7.2.4 MUST

Fast retransmit MUST be performed when an endpoint receives four SACKs indicating the same missing TSN (three gap reports). The missing DATA chunk SHOULD be retransmitted immediately, and the congestion window adjusted accordingly.

sctp, congestion

normative-requirement §3 MUST NOT

INIT, INIT ACK, and SHUTDOWN COMPLETE chunks MUST NOT be bundled with any other chunk in a packet. The INIT chunk MUST be the only chunk in its packet.

sctp

normative-requirement §3.1 MUST NOT

Port number 0 MUST NOT be used in either the Source Port Number or Destination Port Number fields of the SCTP common header.

sctp

normative-requirement §6.8 MUST

SCTP uses CRC32c (as described in Appendix B) for the packet checksum field. A receiver MUST silently discard any packet with an invalid CRC32c checksum.

sctp, security

normative-requirement §3.3.2 MUST NOT

The Initiate Tag in INIT and INIT ACK MUST NOT be zero. If a received INIT contains a zero Initiate Tag, the receiver MUST treat it as an error and close the association by sending an ABORT; if the INIT ACK contains a zero tag, the receiver MUST destroy the TCB.

sctp, security

normative-requirement §3.1 MUST

The Verification Tag in every outgoing SCTP packet MUST be set to the Initiate Tag received from the peer, except: INIT packets carry a zero tag, SHUTDOWN COMPLETE with T-bit copies the SHUTDOWN ACK tag, and ABORT may copy the tag from the packet that triggered it.

sctp, security

normative-requirement §1.3 MUST NOT

Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.

sctp

normative-requirement §3.2.2 MUST

When a COOKIE ECHO is sent in a packet it MUST be the first chunk. If an ERROR chunk must accompany the COOKIE ECHO (reporting unrecognized INIT ACK parameters), it SHOULD be bundled in the same packet.

sctp

normative-requirement §3.3.1 MUST

When a user message is fragmented across multiple DATA chunks, the TSNs for the fragments MUST be strictly sequential, and the same Stream Sequence Number MUST be carried in each fragment. Each fragment of an unordered message MUST have its U bit set.

sctp

protocol-element §3.2

Chunk Type and Parameter Type high-order 2 bits encode unrecognized-type handling: 00=stop and discard, 01=stop/discard/report unrecognized, 10=skip and continue, 11=skip/continue/report in ERROR. This enables forward-compatible protocol extension without association failure.

sctp

protocol-element §3.2.1

Optional and variable-length parameters in SCTP chunks use a TLV format: Parameter Type (16 bits), Parameter Length (16 bits, inclusive of type and length), and variable Parameter Value padded to a 4-byte multiple. Parameter types MUST be unique across all chunk types.

sctp

protocol-element §3.3.3.1

The INIT ACK (Type=2) State Cookie parameter (Type=7) is mandatory and variable-length; it MUST contain all state and parameters needed to recreate the association plus a MAC. The Unrecognized Parameter (Type=8) echoes unknown INIT parameters back to the initiator.

sctp, security, crypto

protocol-element §1.3

The Verification Tag is a randomly generated 32-bit value exchanged during association setup. It identifies packets as belonging to the current association, providing protection against stale packets from prior associations and blind masquerade attacks.

sctp, security

registry §14.4

This document establishes an IANA registry for SCTP Payload Protocol Identifiers (32-bit values in the DATA chunk Payload Protocol Identifier field). The value 0 indicates no application identifier; all other values require IANA assignment for use by upper-layer protocols.

sctp, registry

registry §14.2

This document establishes IANA registries for SCTP Chunk Parameter Types (0–65534; 65535 reserved) and Additional Error Causes used in ERROR and ABORT chunks. Thirteen error causes (1–13) are defined, including Invalid Stream Identifier, Stale Cookie Error, and Protocol Violation.

sctp, registry

security-consideration §11.2.3

SCTP does not provide confidentiality; users requiring it should use IPSEC or application-layer encryption. The CRC32c checksum provides protection against accidental data corruption in the network but is not a cryptographic integrity mechanism.

sctp, security, ipsec

security-consideration §11.2.4.1

SCTP employs a four-way handshake with a MAC-protected State Cookie to prevent flooding/SYN-style attacks. The responder allocates no state until a valid COOKIE ECHO is returned, and the cookie contains all information needed to reconstruct association state.

sctp, security, crypto

security-consideration §11.2.4.2

The Verification Tag protects against blind masquerade attacks and stale packets from previous associations. Packets without the expected Verification Tag are silently discarded; a randomly chosen tag makes it computationally infeasible for an off-path attacker to inject valid packets.

sctp, security

state-machine §4

The SCTP association state machine defines eight states: CLOSED, COOKIE-WAIT (INIT sent), COOKIE-ECHOED (COOKIE ECHO sent), ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, and SHUTDOWN-ACK-SENT. Transitions are triggered by chunk receipts (INIT, INIT ACK, COOKIE ECHO, COOKIE ACK, SHUTDOWN, SHUTDOWN ACK, SHUTDOWN COMPLETE) and timer expirations.

sctp

wire-format §3.2

Each SCTP chunk is encoded as Chunk Type (8 bits), Chunk Flags (8 bits), Chunk Length (16 bits, includes type/flags/length but not padding), and variable-length Chunk Value. Chunks are padded to a multiple of 4 bytes with at most 3 zero bytes not counted in the Length field.

sctp

wire-format §3.3.1

The DATA chunk (Type=0) carries: Reserved/U/B/E flags (8 bits), Length (16 bits), TSN (32 bits), Stream Identifier (16 bits), Stream Sequence Number (16 bits), Payload Protocol Identifier (32 bits, opaque to SCTP), and variable-length User Data. The U bit marks unordered delivery; B and E bits delimit fragment boundaries.

sctp

wire-format §3.3.2

The INIT chunk (Type=1) has fixed mandatory fields: Initiate Tag (32 bits), Advertised Receiver Window Credit a_rwnd (32 bits), Number of Outbound Streams (16 bits), Number of Inbound Streams (16 bits), and Initial TSN (32 bits), followed by optional TLV parameters for IPv4/IPv6 addresses and cookie lifetimes.

sctp

wire-format §3.3.4

The SACK chunk (Type=3) encodes: Cumulative TSN Ack (32 bits), a_rwnd (32 bits), Number of Gap Ack Blocks (16 bits), Number of Duplicate TSNs (16 bits), followed by Gap Ack Block pairs (Start offset 16 bits, End offset 16 bits each, relative to Cumulative TSN Ack) and duplicate TSN list (32 bits each).

sctp

wire-format §3.1

The SCTP common header contains four fields: Source Port Number (16 bits, unsigned), Destination Port Number (16 bits, unsigned), Verification Tag (32 bits, unsigned), and Checksum (32 bits, unsigned, CRC32c). All integer fields are transmitted in network byte order.

sctp, ip