SCTP Explained: Multi-Homing, Telecom Signalling and Security

SCTP, the Stream Control Transmission Protocol, is a reliable, message oriented transport protocol that runs directly over IP (protocol number 132), carries many independent streams inside one association and can use several IP addresses at each end. It was built to carry telephone network signalling over IP, and today it sits under 4G and 5G control planes and inside every WebRTC data channel.

The current specification is RFC 9260, published in June 2022. Most engineers never touch SCTP directly, which is exactly why it deserves a careful look: it is loaded on more Linux hosts than people expect, it is rarely in anyone's firewall rules, and the networks that depend on it most, mobile cores, assume that their signalling peers are trusted. This post explains how the protocol works on the wire, what changed across three generations of the standard, which weakness classes the RFCs themselves describe, and how to check and restrict SCTP on systems you run. For the TCP side of the same questions, see TCP explained: the RFC 9293 handshake, state machine and hardening.

Key takeaways

• SCTP is defined by RFC 9260 (Proposed Standard, June 2022). It obsoletes RFC 4960 (September 2007), which had obsoleted the original RFC 2960 (October 2000). RFC 9260 also absorbs RFC 6096 and RFC 7053 and the two errata documents RFC 4460 and RFC 8540.
• An SCTP association opens with a four-way handshake (INIT, INIT ACK, COOKIE ECHO, COOKIE ACK). The responder keeps no state until the cookie comes back, because all the state it needs is packed into a MAC protected State Cookie. That is SCTP's built in answer to SYN style flooding.
• Every packet after setup carries a 32 bit Verification Tag that a blind attacker has to guess. The CRC32c checksum is error detection, not security.
• RFC 9260 states SCTP's security objectives as availability and integrity of user data. It provides no confidentiality and no cryptographic authentication on its own. For that you add SCTP-AUTH (RFC 4895), DTLS over SCTP (RFC 6083) or IPsec.
• Dynamic address reconfiguration (RFC 5061) lets a peer add and remove addresses mid association. Because that is also a hijacking tool, RFC 5061 requires SCTP-AUTH alongside it. On Linux, addip_enable and auth_enable both default to 0.
• 5G uses SCTP for NG-C signalling between the radio network and the AMF (3GPP TS 38.412), with IANA port 38412. WebRTC carries SCTP inside DTLS over UDP (RFC 8261, RFC 8831), so it never appears as IP protocol 132 on the wire.
• On a Linux host that does not need SCTP, the practical hardening is short: confirm whether the module is loaded, list SCTP listeners, prevent the module from loading if nothing uses it, and make sure your firewall has an explicit policy for protocol 132.

What SCTP is for, where it sits and which standard defines it

SCTP is a transport layer protocol, a peer of TCP and UDP. It sits directly on IPv4 or IPv6, where the IANA protocol numbers registry lists it as protocol 132, and offers applications reliable delivery of discrete messages rather than a byte stream.

RFC 9260's motivation section names four limits of TCP that pushed the IETF to design it:

1. Head of line blocking. TCP delivers every byte strictly in order, so one lost segment stalls everything behind it, even data that is logically unrelated.
2. Stream orientation. TCP has no message boundaries, so applications add their own record markers.
3. Single homed connections. A TCP connection is bound to one address pair, which makes failover across multiple network interfaces awkward.
4. SYN flood exposure. RFC 9260 notes that TCP is "relatively vulnerable to denial-of-service attacks, such as SYN attacks."

Transport of public switched telephone network (PSTN) signalling over IP hits all four at once, and that was the original use case. The IETF SIGTRAN working group designed SCTP for it, and the Linux kernel's own SCTP documentation still records that history. RFC 9260 then adds that other applications fit too, and names WebRTC data channels as the example.

What RFC 9260 consolidated

RFC 9260, by Randall Stewart, Michael Tüxen and Karen Nielsen, came out of the IETF Transport and Services Working Group (TSVWG) in June 2022 as a Proposed Standard of 133 pages. According to the RFC Editor's metadata it obsoletes five documents:

Nothing has updated or obsoleted RFC 9260 itself as of 23 October 2026, according to its RFC Editor record. Note that RFC 9260 remains a Proposed Standard, not an Internet Standard like TCP's RFC 9293. That is a statement about the IETF process, not about deployment: SCTP has carried mobile signalling at scale for well over a decade.

How SCTP works on the wire

Packets are a common header plus chunks

An SCTP packet is a 12 byte common header followed by one or more chunks. A chunk carries either control information or user data. RFC 9260 section 3 sets two firm rules: INIT, INIT ACK and SHUTDOWN COMPLETE chunks must never be bundled with anything else, and all integer fields go in network byte order.

The common header has four fields:

Every chunk then has its own small header:

The base chunk types in RFC 9260, plus the extension chunks the IANA SCTP parameters registry lists, look like this:

The two highest bits of the chunk type tell a receiver what to do with a type it does not recognise: stop processing the packet silently, stop and report it, skip it silently, or skip it and report it. The same trick applies to parameter types. That is how SCTP extensions stay backwards compatible, and it is why some extension chunk numbers look oddly large: ASCONF (193) and FORWARD TSN (192) have both top bits set, so an older receiver skips them, reports them and carries on.

The four-way handshake and the State Cookie

SCTP calls a connection an association. Setup takes four chunks instead of TCP's three segments:

 Endpoint A (initiator)                          Endpoint Z (responder)
 state: CLOSED                                   state: CLOSED

 INIT  ---------------------------------------->
   Verification Tag = 0
   Initiate Tag = Tag_A, a_rwnd, OS, MIS, initial TSN,
   optional address list
 state: COOKIE-WAIT
                                                 Z builds a State Cookie
                                                 (MAC, timestamp, lifespan,
                                                 ports, both tags) and keeps
                                                 NO association state
       <----------------------------------------  INIT ACK
                                                   Verification Tag = Tag_A
                                                   Initiate Tag = Tag_Z
                                                   State Cookie parameter
 COOKIE ECHO  --------------------------------->
   Verification Tag = Tag_Z
   echoes the State Cookie, may carry DATA
 state: COOKIE-ECHOED
                                                 Z verifies MAC, ports, tag
                                                 and cookie age, then
                                                 creates the association
       <----------------------------------------  COOKIE ACK
 state: ESTABLISHED                              state: ESTABLISHED

The key design choice is that the responder does not allocate a Transmission Control Block (TCB) when an INIT arrives. RFC 9260 section 5.1.3 says the responder packs everything it would need into a State Cookie and requires a MAC over it: "The use of a MAC is mandatory to prevent denial-of-service attacks." The cookie should carry a creation timestamp and lifespan, the port numbers and the Verification Tags. The secret key should be random and changed "reasonably frequently (e.g., hourly)".

When the COOKIE ECHO comes back, section 5.1.5 has the responder recompute the MAC, compare the ports and Verification Tag in the cookie against the packet's common header, and check the cookie's age against its lifespan. A bad MAC means silent discard. An expired cookie earns a "Stale Cookie" ERROR chunk. Only a valid cookie creates the association.

Because the INIT ACK goes back to the address the INIT came from, an attacker spoofing someone else's address never sees the cookie and cannot complete the handshake. TCP got a similar property later through SYN cookies as an optional host behaviour. In SCTP it is part of the base protocol.

Verification Tags and "out of the blue" packets

Each side picks a random, non zero 32 bit Initiate Tag in INIT or INIT ACK. From then on, every packet the peer sends must carry that value in its Verification Tag field, and a receiver discards packets whose tag does not match. RFC 4895's introduction describes it plainly: SCTP uses 32 bit verification tags "to protect itself against blind attackers," and those values do not change for the life of the association.

Compare that with TCP, where a blind attacker has to land a sequence number inside the receive window. In SCTP the attacker needs the exact 32 bit tag. That raises the bar for blind injection considerably, but it is still a shared value sent in clear text in every packet. Anyone who can see one packet of the association knows it.

Packets that arrive for no known association are "out of the blue" (OOTB). RFC 9260 section 8.4 lists exactly how to treat them, mostly by discarding them or by sending an ABORT with carefully chosen tag rules so that an OOTB reply cannot be turned into a weapon.

The association state machine

RFC 9260 section 4 defines these states:

Two differences from TCP stand out. First, there is no half closed state. When either side starts a graceful shutdown, both stop accepting new data from their users and the association drains and closes. Second, there is no TIME-WAIT state in the diagram. Each association gets fresh Verification Tags, and packets carrying the wrong tag are discarded, which is how SCTP keeps stray packets from an old association out of a new one.

ABORT ends an association from any state immediately, with no drain. That makes the rules for accepting an ABORT, essentially "the Verification Tag must match", one of the most important pieces of the protocol from a defender's point of view.

Streams: many ordered queues in one association

During setup each side announces how many outbound streams it wants (OS) and how many inbound streams it will accept (MIS). The association uses the minimum of what was requested and what was offered. Each DATA chunk carries:

• a Transmission Sequence Number (TSN), used for reliability across the whole association
• a Stream Identifier, which stream the message belongs to
• a Stream Sequence Number (SSN), used for ordering within that stream
• a Payload Protocol Identifier (PPID), a 32 bit value that tells the receiving application what kind of payload this is

Reliability is association wide, ordering is per stream. A lost message on stream 3 holds up later messages on stream 3 only; stream 7 keeps delivering. A sender can also mark a message unordered with the U flag, and the receiver hands it up as soon as it arrives. This is the head of line blocking fix that motivated SCTP.

Acknowledgments come in SACK chunks, which carry a cumulative TSN acknowledgment plus gap reports for data received beyond a hole. RFC 9260 suggests a SACK delay of 200 milliseconds. Selective acknowledgment is part of base SCTP, where in TCP it is a negotiated option.

PPIDs matter in telecom. 3GPP TS 38.412 says the PPID for NGAP, and for NGAP over DTLS over SCTP, is assigned by IANA, and that the PPID is sent big endian. RFC 6083 says applications that run over DTLS should register and use a different PPID from the one they use over plain SCTP.

Multi-homing and path management

At setup, each endpoint can list several IP addresses. RFC 9260 defines an association as spanning "all of the possible source/destination combinations" from those lists. One destination is the primary path, and by default all new data goes there. Retransmissions after a timeout should go to a different active address. Reply chunks such as INIT ACK, COOKIE ACK and HEARTBEAT ACK go back to the address the triggering chunk came from.

Each endpoint tracks reachability with HEARTBEAT chunks on idle paths (every 30 seconds by default per RFC 9260 section 16) and with error counters:

• Path failure. When a path's error counter passes Path.Max.Retrans (recommended 5), that address is marked inactive and the upper layer is told.
• Endpoint failure. When the association wide counter passes Association.Max.Retrans (recommended 10), the peer is considered unreachable and the association closes.

Addresses learned from a peer are not trusted blindly. RFC 9260 section 5.4 marks every address other than the ones the application supplied, or the one the INIT ACK went to, as UNCONFIRMED. The endpoint must not send data to an unconfirmed address. It confirms it by sending a HEARTBEAT that carries a 64 bit random nonce and checking that the HEARTBEAT ACK echoes the same nonce. This path verification rule exists because a misbehaving peer could otherwise list addresses it does not own and turn the association into a traffic cannon aimed at a third party.

Multi-homing in SCTP is about redundancy, not load sharing: the base protocol sends new data on one primary path and fails over when that path dies. Linux adds a "potentially failed" state (pf_enable, pf_retrans) so traffic moves to an alternate path sooner without lowering path_max_retrans.

Ports, IANA and the services you will meet

SCTP has its own port space. RFC 9260 section 15.6 says SCTP ports are allocated by IANA under expert review, following RFC 6335, and they live in the same Service Name and Transport Protocol Port Number registry as TCP and UDP. Some registrations you are likely to see in practice, as listed in that registry on 23 October 2026:

SCTP inside UDP and inside DTLS

SCTP does not have to ride directly on IP. RFC 9260 points to two encapsulations:

• UDP encapsulation (RFC 6951, May 2013) wraps SCTP packets in UDP so they cross NATs and middleboxes that only know TCP and UDP. IANA registers UDP port 9899 as sctp-tunneling. On Linux, the kernel's UDP tunnelling socket is controlled by net.sctp.udp_port, which defaults to 0, meaning closed.
• DTLS encapsulation (RFC 8261, November 2017) runs SCTP on top of DTLS. Here SCTP has no idea which IP addresses lie below it, so associations "can only be single-homed," and INIT and INIT ACK must not carry address parameters.

Where SCTP runs today: telecom cores and WebRTC

Telecom signalling

The SIGTRAN family carries classic SS7 signalling over IP using SCTP and a set of adaptation layers: M2UA, M2PA, M3UA and SUA, with the IANA ports above. Diameter is registered for SCTP on port 3868. In LTE, the S1 and X2 control planes use SCTP. In 5G, 3GPP TS 38.412 (version 19.0.0, September 2025, Release 19) says plainly that "SCTP (IETF RFC 4960 [2]) shall be supported as the transport layer of NG-C signalling bearer," the interface between the radio network and the AMF.

TS 38.412 also shows how operators use SCTP's features:

• A gNB and an AMF must support a single SCTP association per node pair, and should support multiple associations.
• One pair of stream identifiers is reserved for non UE associated NGAP procedures, and at least one more pair for UE associated signalling.
• A given UE's signalling stays on one association and one stream until that association fails or is rebound.
• "Transport network redundancy can be achieved by SCTP multi-homing."

Notice that TS 38.412 still cites RFC 4960, not RFC 9260. That is normal for telecom specifications, which update references on their own cycle, and it does not change the wire protocol in any material way.

WebRTC data channels

Browser data channels, the API that lets two peers swap arbitrary messages, are SCTP. RFC 8831 (January 2021) specifies the stack: SCTP over DTLS (RFC 8261) over ICE and UDP. The DTLS layer gives confidentiality, source authentication and integrity. RFC 8831 requires the stream reconfiguration extension (RFC 6525) to close channels, the partial reliability extension (RFC 3758) plus the limited retransmission policy (RFC 7496) for unreliable channels, and recommends message interleaving (RFC 8260). It also requires that the stack can be implemented in user space, which lets WebRTC implementations ship their own SCTP library instead of relying on the operating system's.

RFC 8831 assigns WebRTC PPIDs, which the IANA registry lists as 50 (DCEP, the channel establishment protocol), 51 (String), 53 (Binary), with 52 and 54 deprecated. RFC 8841 (January 2021) defines how the SCTP port is negotiated in SDP; its examples use a=sctp-port:5000. Because all of this sits inside DTLS inside UDP, a network firewall never sees IP protocol 132 for WebRTC. Our WebRTC explainer covers ICE, STUN, TURN and DTLS-SRTP around it.

Versions and history

RFC 9260 section 1.7 lists the changes from RFC 4960. Among them: the ASSOCIATE primitive can take multiple remote addresses, path MTU discovery now points to PLPMTUD (RFC 8899), ICMP handling moved from an appendix into the main text, the ECN appendix was removed, packet size handling was made precise with the new terms PMTU, PMDCS and AMDCS, the handling of INIT and INIT ACK with invalid mandatory parameters was tightened, and the State Cookie description was improved. None of these change the wire format in a way that breaks RFC 4960 peers.

Work in progress worth knowing about, without treating it as standard:

• A revision of DTLS over SCTP (draft-ietf-tsvwg-dtls-over-sctp-bis) aimed to remove RFC 6083's 16 KB message limit and update DTLS versions. Its datatracker page shows it expired, with the last revision dated 3 May 2024 and the working group state "Revised I-D Needed".
• The IANA SCTP parameters registry, last updated 20 October 2026, shows chunk type 65 temporarily registered for a "DTLS" chunk on 20 February 2026, expiring 20 February 2027, for draft-ietf-tsvwg-sctp-dtls-chunk-01. That is an early allocation for a draft, not a published standard.

What is deployed: RFC 4960 behaviour is what most telecom equipment was built and certified against, with RFC 9260 cleanups arriving through stack updates. The Linux kernel ships an implementation. Note that its own documentation page is badly out of date: it still calls the code "the current BETA release" and points at RFC 2960. The ip-sysctl documentation is the better reference for what the Linux stack actually supports today.

Security properties: what SCTP guarantees and what it does not

RFC 9260 section 12.1 is unusually direct. SCTP's security objectives are:

• availability of reliable and timely data transport services
• integrity of the user to user information carried by SCTP

That is it. Confidentiality is explicitly left to other layers.

RFC 9260 section 12.2.3 notes that the confidentiality requirement usually applies to the payload, so encrypting user data only, for example with DTLS per RFC 6083, may be enough. For mobile users who also need addresses and ports hidden, it says ESP should be used, with an integrity protecting transform, and that IKEv2 should manage the keys. Our post on IKEv2 and IPsec covers that layer.

SCTP-AUTH in brief

RFC 4895 (August 2007) adds the AUTH chunk (type 15) and three parameters exchanged in INIT and INIT ACK: RANDOM (0x8002), CHUNKS (0x8003, which chunk types must be authenticated) and HMAC-ALGO (0x8004). HMAC identifiers are 1 for SHA-1, which every implementation must support, and 3 for SHA-256. Each side derives an association shared key from an optional endpoint pair shared key plus the random values exchanged at setup, and puts an HMAC in an AUTH chunk ahead of the chunks it covers.

Its own Security Considerations section sets out the limits clearly:

• Without an endpoint pair shared key, AUTH only protects against attackers who did not capture the initial handshake. An observer who saw the RANDOM values can compute the key.
• With an endpoint pair shared key, even a full man in the middle cannot inject chunks that must be authenticated.
• How you establish that shared key is out of scope; TLS or manual configuration are suggested.
• If one endpoint still accepts a NULL key while both are meant to use real keys, an attacker who captured the handshake can still inject.
• If COOKIE ECHO must be authenticated, the restart procedure stops working for anyone who does not know the association key, legitimate restarted peers included.

DTLS over SCTP in brief

RFC 6083 (January 2011) runs DTLS on top of SCTP so user messages are encrypted and authenticated, while SCTP keeps doing reliability, streams and multi-homing. Every SCTP user message carries exactly one DTLS record, a DTLS connection must not span associations, DATA chunks must be sent with SCTP-AUTH, and the DTLS layer manages the SCTP-AUTH keys. Two caveats: the maximum user message is 2^14 bytes, the DTLS record limit, and SCTP headers themselves stay in the clear. RFC 8996 later updated RFC 6083 by deprecating TLS 1.0 and 1.1, which in DTLS terms means DTLS 1.0 should not be used.

Weakness classes, described as concepts

These come first from RFC 9260 section 12, RFC 5061 section 6 and the informational RFC 5062, which catalogues attacks against SCTP and the countermeasures that went into RFC 4960. Each is described here at the level of what goes wrong and why the design allows it, not how to carry it out.

Setup flooding and cookie processing cost

Any listener can be flooded with INITs. SCTP's defence is that answering an INIT costs the responder only a MAC computation and one packet, never a stored TCB. RFC 9260 says choosing "a high-performance MAC algorithm increases the resistance against cookie flooding attacks." The residual risk is CPU spent computing MACs and bandwidth spent on INIT ACKs, plus whatever the application does once an association is real. A responder that skips the MAC, or uses a weak or never rotated key, hands back the very state exhaustion problem the cookie was meant to remove. On Linux, cookie_hmac_alg accepts sha256 or none, and the default is sha256.

Reflection and byte amplification

An INIT ACK carries a State Cookie and an address list, so it is usually bigger than the INIT that triggered it. If an attacker spoofs a victim's address in INIT, the victim receives the larger INIT ACK. RFC 9260 section 12.4 tells implementations to keep the INIT ACK as small as possible "to reduce the possibility of byte amplification attacks," lets them drop optional "Unrecognized Parameter" reports from it, and limits responses to one packet of control chunks per received packet. RFC 5062 lists four separate "bombing" amplification cases tied to address lists and how path verification addresses them. The general lesson is the same as for UDP services: an internet reachable SCTP listener that nobody needs is a potential reflector. Our UDP services audit covers the same reasoning for UDP.

Blind masquerade and injection

A blind attacker who cannot see traffic might try to insert a SHUTDOWN or ABORT into someone else's association. The four-way handshake and the 32 bit Verification Tag are the defences. RFC 9260 section 12.2.4.2 explains that because the INIT ACK goes back to the real source address, a spoofer never receives the cookie, and because the startup is memoryless, failed spoofing does not trigger lockouts that could be turned against the impersonated node. The weakness is that the Verification Tag is a clear text shared value, not a key. It stops blind guessing, not on path observers.

Address based attacks: camping, hijacking and redirection

Multi-homing means an association is identified by sets of addresses, which creates attack shapes TCP does not have. RFC 5062's section titles name them: address camping or stealing, two association hijacking cases, and association redirection. In each, the underlying issue is that a peer announces addresses it may not own, or an attacker races to claim an address another node will later use. RFC 9260's path verification rules (unconfirmed addresses, nonce carrying heartbeats) and the restart procedure rules are the countermeasures that came out of that analysis.

Dynamic address reconfiguration (ASCONF)

RFC 5061 lets an endpoint add an address, delete an address, or set the peer's primary path while the association is running, using ASCONF chunks. That is exactly what you want for mobile or renumbered hosts, and exactly what an attacker would want to hijack an association. RFC 5061 section 6 therefore requires SCTP-AUTH: ASCONF and ASCONF-ACK must be authenticated, and an implementation that supports ASCONF must refuse an INIT from a peer that offers ASCONF without AUTH.

Two residual risks remain, both spelled out in the RFC:

• If AUTH runs without a preconfigured endpoint pair key, an attacker who captured the first two setup packets can still hijack using ASCONF. If that threat is credible, a pre-shared key is a MUST.
• When an ASCONF uses a wildcard address, the actual address comes from the packet's IP source, which AUTH does not protect. An on path attacker can then add, delete or promote addresses. RFC 5061 says endpoints facing on path threats should not use wildcard addresses in those parameters.

Linux reflects this. addip_enable defaults to 0. addip_noauth_enable, which allows ASCONF without authentication for interoperability with old stacks, defaults to 0, and the kernel documentation says it "should only be set in a closed environment."

Improper monopolisation

Some abuse is not an attack on the protocol at all. RFC 9260 section 12.2.4.3 describes a legitimate peer that opens a very large number of associations or pushes huge volumes of junk inside a valid one. The RFC's answer is policy: limits on associations per adjacent node, and applications that notice and terminate floods of "no-op" messages. This matters more for SCTP than for TCP because one-to-many style sockets (RFC 6458) let a single listening socket hold many associations, so one noisy peer can crowd out others. The Linux rcvbuf_policy setting exists partly for this: the kernel documentation explains that one stalled association can otherwise consume a socket's whole receive buffer and block the others.

Exposure of signalling endpoints

The largest real world SCTP risk is not in the transport. Telecom signalling protocols carried over SCTP, SS7 via SIGTRAN, Diameter, S1AP and NGAP, were designed for closed networks between trusted operators and equipment. SCTP will happily deliver those messages to anyone who can complete a handshake. If a signalling endpoint is reachable from the internet, or from a roaming or interconnect partner without filtering at the application layer, the security of the whole exchange rests on the upper protocol, and those protocols historically assumed the peer was legitimate. That is the reason to filter signalling at the application layer as well as the network layer, and it is why 3GPP TS 38.412 provides a PPID for NGAP over DTLS over SCTP. For any team, the transport level lesson is simple: an SCTP listener on a signalling port should only accept associations from known peer addresses, and those peers should be authenticated cryptographically wherever the equipment supports it.

Middlebox and filtering blind spots

Many firewalls and cloud security groups were written with TCP and UDP in mind. A rule set that allows "all TCP to port X" and "all UDP to port Y" says nothing about protocol 132, so whether SCTP passes depends on a default that nobody chose deliberately. RFC 9260 section 12.3 helps filters a little: an INIT must never be bundled with other chunks and must carry a zero Verification Tag, so a filter can identify new association attempts from the first fragment. Encapsulated SCTP, in UDP on 9899 or inside DTLS, will not match a protocol 132 rule at all.

Kernel attack surface you did not mean to load

On Linux, SCTP is usually built as a kernel module. Depending on how the distribution is configured, that module may be loaded when a program asks for an SCTP socket, so a host that never deliberately runs an SCTP service can still end up with SCTP code in its kernel. Any code in the kernel is attack surface. If a host has no reason to speak SCTP, the cleanest control is to stop the module from loading at all, shown in the configuration section below.

Secure configuration, with defender-side check commands

The commands below come from the Linux kernel's ip-sysctl documentation, the ss(8), lsmod(8) and modprobe.d(5) manual pages, and the nftables manual page, all linked in the Sources. Only run them against systems you own or are authorised to test. They read configuration and socket tables; none of them send SCTP packets to anyone.

Step 1: is SCTP loaded at all?

lsmod formats the contents of /proc/modules, the list of loaded kernel modules.

lsmod | grep -i sctp

No output means the sctp module is not loaded right now. It can still be loaded on demand later unless you prevent it (step 4). If the /proc/sys/net/sctp directory exists, the SCTP stack is present and initialised:

ls /proc/sys/net/sctp/ 2>/dev/null || echo "SCTP sysctls not present"

Step 2: list SCTP sockets and the processes that own them

The ss(8) manual page documents -S (or the long form) as "Display SCTP sockets".

# Listening SCTP sockets, numeric addresses, owning process
ss -S -l -n -p

# All SCTP sockets, including established associations
ss -S -a -n

On a host that is not meant to speak SCTP, both should be empty. On a telecom node, compare each listener against the interfaces you expect: S1AP on 36412, NGAP on 38412, M3UA on 2905 and so on. A listener bound to every address (the wildcard) on a multi-homed signalling host is worth questioning, because it will accept associations on interfaces that may face untrusted networks.

Step 3: check the SCTP extension and cookie settings

The kernel ip-sysctl documentation describes every SCTP variable under /proc/sys/net/sctp/. Read the security relevant ones together:

for v in auth_enable addip_enable addip_noauth_enable cookie_hmac_alg \
         valid_cookie_life udp_port encap_port reconf_enable \
         max_init_retransmits association_max_retrans path_max_retrans; do
  printf '%-24s %s\n' "$v" "$(cat /proc/sys/net/sctp/$v 2>/dev/null)"
done

What the documentation says about the defaults, and what to look for:

To make a setting persistent, write it to a file under /etc/sysctl.d/ as your distribution documents, and keep the change under configuration management so a rebuilt host comes back the same.

Step 4: stop the module loading on hosts that do not need SCTP

The modprobe.d(5) manual page documents two directives that matter here. blacklist modulename makes modprobe ignore that module's internal aliases. install modulename command tells modprobe to run your command instead of inserting the module. The second is the stronger control because it also covers attempts to load the module by name.

# /etc/modprobe.d/disable-sctp.conf
install sctp /bin/false
blacklist sctp

Then confirm what is configured:

grep -rn "sctp" /etc/modprobe.d/ /usr/lib/modprobe.d/ 2>/dev/null

A module that is already loaded stays loaded until reboot, and the kernel documentation warns that removing the SCTP module at runtime "is not yet a safe activity," so plan the change for a maintenance window and reboot rather than unloading it live. Do not do this on telecom nodes, on hosts running SIGTRAN or Diameter over SCTP, or on anything whose software opens kernel SCTP sockets. WebRTC data channels that use a user space SCTP stack over UDP do not depend on the kernel module.

Step 5: give protocol 132 an explicit firewall policy

The nftables manual page documents meta l4proto, which matches the transport protocol in IPv4 or IPv6 and skips IPv6 extension headers, and an SCTP header expression with sport, dport, vtag, checksum and chunk keys. A minimal policy for a signalling host might allow NGAP only from known peers and drop everything else that is SCTP:

# Review the ruleset you have today
nft list ruleset | grep -n -i sctp

# Example rules for an existing inet table "filter" with an "input" chain
nft add rule inet filter input ip saddr 192.0.2.10 sctp dport 38412 accept
nft add rule inet filter input meta l4proto sctp drop

The addresses above are documentation examples. On a host that should never speak SCTP, the single meta l4proto sctp drop line in the input chain is the explicit policy. Also check that UDP 9899 is closed unless you deliberately use UDP encapsulation, because a protocol 132 rule does not see SCTP inside UDP.

Step 6: encrypt and authenticate signalling

• For signalling that crosses any network you do not fully control, use IPsec ESP with an integrity protecting transform and IKEv2 for keys, as RFC 9260 recommends, or DTLS over SCTP where your equipment and 3GPP profile support it.
• If you use SCTP-AUTH, configure endpoint pair shared keys rather than relying on keys derived only from the handshake, and make sure no endpoint still accepts the NULL key.
• Authenticate ASCONF, avoid wildcard addresses in ASCONF parameters, and never enable addip_noauth_enable outside a lab.
• Base access decisions on authenticated identity, not on the source address of a packet, since multi-homed peers legitimately send from several addresses.

Step 7: set association limits and watch them

Configure your SCTP application with a maximum number of associations per peer and a per association rate limit, as RFC 9260 section 12.2.4.3 expects. Alert on sudden growth in ss -S -a -n output, on repeated association restarts, and on unexpected changes to a peer's address set. Keep the kernel and any user space SCTP library on supported versions; your distribution's kernel updates are how fixes to the Linux SCTP code reach you.

SCTP vs TCP vs QUIC vs UDP: when to use which

The rule of thumb: choose SCTP when you are implementing a standard that requires it, which in practice means telecom interfaces, or when you are building on WebRTC data channels and get it for free. For new general purpose services, QUIC covers most of what SCTP was designed for, streams without head of line blocking and resilience to address changes, with encryption built in and far better middlebox traversal. See QUIC and HTTP/3 explained for that design, and TCP vs UDP: what an eavesdropper can see and change for how much plain transports expose on the wire.

Common mistakes

• Assuming firewalls block SCTP because nobody allowed it. Rule sets written for TCP and UDP often leave protocol 132 to a default nobody reviewed. Write an explicit rule either way.
• Treating the Verification Tag as authentication. It defeats blind guessing. It is sent in clear text in every packet and does nothing against an on path observer.
• Treating CRC32c as integrity protection. It catches transmission errors. Anyone modifying a packet can recompute it.
• Enabling ASCONF without AUTH. Setting addip_enable=1 with addip_noauth_enable=1 to make an old peer interoperate turns dynamic addressing into a hijacking path. The kernel documentation limits that to closed environments.
• Running SCTP-AUTH without endpoint pair keys and calling it secure. Without a pre-shared key, anyone who captured the handshake can compute the association key.
• Setting cookie_hmac_alg to none for performance. That removes the MAC the cookie mechanism depends on.
• Exposing signalling listeners on wildcard addresses. A multi-homed node bound to all addresses will accept associations on interfaces facing networks you did not intend.
• Unloading the SCTP module live. The kernel documentation warns that module removal is not safe. Prevent loading through modprobe configuration and reboot.
• Blocking protocol 132 and assuming WebRTC data channels are affected. WebRTC carries SCTP inside DTLS over UDP. Blocking protocol 132 does not touch it, and allowing UDP does not mean allowing kernel SCTP.
• Trusting source addresses for access decisions. Multi-homed peers legitimately send from several addresses. Base decisions on authenticated identity, as RFC 6083 says.

FAQ

What port does SCTP use?

SCTP has its own port space, separate from TCP and UDP, allocated by IANA. There is no single SCTP port. Common registrations include 2905 for M3UA, 3868 for Diameter, 36412 for LTE S1 control, and 38412 for the 5G NG control plane. UDP port 9899 is registered for SCTP tunnelled in UDP under RFC 6951.

Is SCTP encrypted?

No. Base SCTP sends headers, chunks and payloads in clear text. RFC 9260 lists only availability and integrity as its security objectives. Encryption comes from DTLS over SCTP (RFC 6083), SCTP over DTLS (RFC 8261, as in WebRTC) or IPsec ESP underneath.

What is the SCTP four-way handshake?

INIT, INIT ACK, COOKIE ECHO, COOKIE ACK. The responder puts all the state it needs into a MAC protected State Cookie in the INIT ACK and keeps nothing until the initiator echoes the cookie back. That makes setup flooding much less effective than against a stateful listener.

What is SCTP multi-homing?

Each endpoint can give the other several IP addresses at setup. One is the primary path; if it fails, detected through heartbeats and retransmission counters, traffic moves to another address without ending the association. New addresses must be confirmed with a nonce carrying heartbeat before data is sent to them.

SCTP vs TCP: what is the difference?

TCP is a single ordered byte stream between two addresses. SCTP carries discrete messages over many independent streams, can deliver messages unordered, supports multiple addresses at each end, and uses a stateless cookie handshake. TCP has far better support in firewalls, load balancers and tools.

How do I check if SCTP is enabled on Linux?

Run lsmod | grep -i sctp to see whether the module is loaded and ss -S -l -n -p to list SCTP listeners. Read /proc/sys/net/sctp/ to see the stack's settings. Only check systems you own or are authorised to test.

Should I disable SCTP?

On servers and workstations that do not run telecom software or anything else that opens kernel SCTP sockets, preventing the module from loading removes kernel code you do not use. Use an install sctp /bin/false line in /etc/modprobe.d/ and reboot. Do not do it on telecom nodes.

What is SCTP-AUTH?

An extension (RFC 4895) that adds an AUTH chunk carrying an HMAC over selected chunks, using keys derived at setup and optionally a pre-shared endpoint pair key. It provides integrity and origin authentication for chunks, but not confidentiality. Dynamic address reconfiguration requires it.

Does WebRTC use SCTP?

Yes, for data channels. RFC 8831 runs SCTP over DTLS over ICE and UDP, so the SCTP traffic is encrypted and never appears on the network as IP protocol 132.

Where Safeguard fits

Safeguard does not inspect, capture or filter SCTP traffic, does not configure kernels, modprobe or firewalls, and is not a signalling firewall for telecom interconnects. Every hardening step above is something you do with your operating system and network tools.

The honest connection is the software around SCTP. WebRTC applications can embed user space SCTP and DTLS libraries, signalling products depend on SCTP, Diameter and ASN.1 libraries, and the DTLS layer that protects SCTP comes from open source TLS libraries. Safeguard's software composition analysis, generally available, builds a full transitive dependency inventory of those libraries in your repositories and container images, and its SBOM generation and analysis, also generally available, records them in SPDX or CycloneDX. Vulnerability management with EPSS and KEV enrichment, generally available, and reachability analysis, generally available, show which of those findings your code actually calls. Container visibility and scanning, generally available as part of ESSCM, shows what sits inside each image, though not the host kernel that holds the Linux SCTP module, which you patch through your distribution. Policies and gates, generally available, can stop a build that pulls in a known vulnerable DTLS or SCTP library. When the next advisory lands, our post on using SBOMs to find affected products fast shows the workflow.

Fix it without waiting for upstream

SCTP bugs rarely live in your own code. They live in the stacks and libraries you depend on: the user space SCTP and DTLS libraries inside a WebRTC application, the TLS library that provides DTLS, or the signalling stack inside a telecom product.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not network monitoring or kernel configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image of a WebRTC service or a signalling application you build, the same scan lists the SCTP, DTLS and TLS libraries inside it with their versions and known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a DTLS or data channel library in an application that opens SCTP associations.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects ship a particular version of a DTLS or SCTP library and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 9260: Stream Control Transmission Protocol, June 2022
• RFC 4960: Stream Control Transmission Protocol, September 2007
• RFC 2960: Stream Control Transmission Protocol, October 2000
• RFC 3309: SCTP Checksum Change, September 2002
• RFC 3286: An Introduction to SCTP, May 2002
• RFC 4895: Authenticated Chunks for SCTP, August 2007
• RFC 5061: SCTP Dynamic Address Reconfiguration, September 2007
• RFC 5062: Security Attacks Found Against SCTP and Current Countermeasures, September 2007
• RFC 4820: Padding Chunk and Parameter for SCTP, March 2007
• RFC 6083: DTLS for SCTP, January 2011
• RFC 6458: Sockets API Extensions for SCTP, December 2011
• RFC 6525: SCTP Stream Reconfiguration, March 2012
• RFC 6951: UDP Encapsulation of SCTP Packets, May 2013
• RFC 8260: Stream Schedulers and User Message Interleaving for SCTP, November 2017
• RFC 8261: DTLS Encapsulation of SCTP Packets, November 2017
• RFC 8831: WebRTC Data Channels, January 2021
• RFC 8841: SDP Offer/Answer Procedures for SCTP over DTLS, January 2021
• RFC 9653: Zero Checksum for SCTP, September 2024
• RFC Editor metadata for RFC 4460, 6096, 7053, 8540, 8899, 8996 and 4168 (obsoletes, updates and dates)
• IETF Datatracker: draft-ietf-tsvwg-dtls-over-sctp-bis
• IANA: Stream Control Transmission Protocol (SCTP) Parameters
• IANA: Service Name and Transport Protocol Port Number Registry
• IANA: Assigned Internet Protocol Numbers
• 3GPP TS 38.412: NG-RAN; NG signalling transport (V19.0.0, September 2025)
• Linux kernel documentation: IP Sysctl, /proc/sys/net/sctp variables
• Linux kernel documentation: Linux Kernel SCTP
• ss(8), Linux manual page
• lsmod(8), Linux manual page
• modprobe.d(5), Linux manual page
• nft(8), nftables manual page

Last reviewed: 23 October 2026. SCTP extensions and kernel defaults change between releases; check the documentation for the kernel and equipment you actually run.