SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
Extracted elements (26)
Forced switchback to the original primary path after recovery (RFC 4960 default) is suboptimal because the CWND on the primary path must be rebuilt from scratch. Primary Path Switchover eliminates this by permanently switching the primary to the currently working path when the old primary's error counter exceeds PSMR.
Frequent path changes (path-bouncing) caused by SCTP-PF are not harmful in practice because SCTP maintains per-destination path parameters (CWND, ssthresh, RTT, error count) independently. When migrating to a new path, SCTP starts with the minimal initial CWND, limiting packet reordering or duplication.
Reducing PMR also forces a reduction in Association.Max.Retrans (AMR) to avoid dormant state, which decreases overall association fault tolerance by increasing association termination during minor congestion. The PF state avoids this coupling by introducing an intermediate threshold that does not affect AMR.
Simply lowering PMR to zero is insufficient because RFC 4960 governs HEARTBEAT recovery using HB.Interval (typically 30 s), causing a long delay before SCTP can verify whether a spurious failover occurred and resume on the original path. SCTP-PF solves this by sending HEARTBEATs once per RTO on PF-state destinations, enabling rapid recovery detection.
For single-homed SCTP, SCTP-PF provides enhanced failure detection and faster idle-association endpoint failure detection via aggressive HEARTBEAT transmission in PF state, but failover and switchback aspects are not activated. Adequate dormant state operation is required to avoid harm.
The dormant state operation defined in Section 4 can also be applied by standard RFC 4960 implementations (not just SCTP-PF), providing enhanced disruption tolerance for cases where alternative paths approach inactive state before trouble is observed on the primary data-transfer path.
Acknowledgments for chunks transmitted to multiple destinations SHOULD NOT clear the error count for an inactive destination and SHOULD NOT move a PF-state destination to active, because the sender cannot determine whether the ACK was for the original or a retransmitted copy.
Acknowledgments for data chunks transmitted to a single destination address only MUST clear the error counter for that destination and MUST transition a PF-state destination back to active state.
An SCTP-PF sender SHOULD NOT send data to PF-state destinations when active-state alternatives exist. This applies to new transmissions, retransmissions, and user-requested sends to a PF address.
During dormant state (all destinations inactive), the sender MUST choose one destination and transmit data to it, and MUST NOT change its state or clear its error counter as a result. The sender SHOULD pick the inactive destination with the lowest error count.
For Primary Path Switchover, implementations MUST reject PSMR settings where PSMR < PFMR (SCTP-PF) or PSMR < PMR (standard SCTP). For SCTP-PF, spt_pathcpthld < spt_pathpfthld MUST be rejected with errno EINVAL.
The HB.Interval MUST be ignored for PF-state destinations; instead HEARTBEAT chunks are sent once per RTO. If the Path Heartbeat function is disabled for a destination, HEARTBEATs MUST NOT be sent to it even in PF state.
The SCTP stack SHOULD expose the PF state and its transitions to the ULP and SHOULD also provide the means to suppress PF state exposure, allowing ULPs to retain the simpler active/inactive model of RFC 4960.
The sender MUST NOT change the state or clear the error counter of a destination address solely as a result of choosing that address for data transmission, whether the address is active or PF.
When a destination address's error counter exceeds PFMR, the endpoint MUST mark that destination address as PF.
When a HEARTBEAT ACK is received from a PF-state destination, the sender SHOULD clear the error counter and transition that destination back to active state. Resuming data transmission after this transition MUST follow RFC 4960 Section 7.2 (congestion window handling).
When all destination addresses are in PF state (or some PF and some inactive), the sender MUST choose a PF-state destination and SHOULD pick the one with the lowest error count (fewest consecutive timeouts) for transmission.
When the path error counter on the set primary path exceeds PSMR, the SCTP implementation MUST autonomously select a new primary path — specifically the path that would currently be chosen for data transfer. It MUST be possible to disable Primary Path Switchover to retain RFC 4960 switchback behavior.
PotentiallyFailed.Max.Retrans (PFMR) is a new tunable sender-side parameter that defines the error counter threshold at which a destination address is classified as PF. The RECOMMENDED value is 0, meaning the PF state is entered on the first timeout. PFMR MUST be less than PMR for the PF state to be reachable before inactive.
Primary.Switchover.Max.Retrans (PSMR) is a new tunable parameter governing the Primary Path Switchover feature. For SCTP-PF implementations PSMR MUST be >= PFMR; for standard SCTP implementations PSMR MUST be >= PMR. Setting PSMR = PFMR (or PMR for standard SCTP) disables forced switchback to the original primary path.
The SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket option controls whether the PF state is exposed to the ULP via SCTP_PEER_ADDR_CHANGE events and SCTP_GET_PEER_ADDR_INFO queries. A new constant SCTP_ADDR_POTENTIALLY_FAILED is added to spc_state, and SCTP_POTENTIALLY_FAILED to spinfo_state.
The SCTP_PEER_ADDR_THLDS socket option (level IPPROTO_SCTP) exposes and controls PFMR and PSMR via the sctp_paddrthlds structure, which contains spt_pathmaxrxt (PMR), spt_pathpfthld (PFMR), and spt_pathcpthld (PSMR) fields per peer address.
SCTP-PF lowers the bar for attackers to force a path change, because they need to negatively influence connectivity for a shorter period than required by RFC 4960. However, this does not significantly change the effort needed to keep SCTP away from the primary path long-term, since standard switchback resumes on the primary at the next successful HEARTBEAT.
The additional PF state transition notifications give attackers an increased ability to generate local events on the endpoint. Implementations are expected to rate-limit event notifications to mitigate this threat.
The Primary Path Switchover mechanism changes the threat model materially: on-path attackers can force a permanent primary path change by blocking the primary long enough to trigger the switchover. The risk is highest when PSMR = PFMR = 0, where switchover occurs on the very first RTO timeout. Implementers and users of Primary Path Switchover should be aware of this.
SCTP-PF introduces a Potentially Failed (PF) state as an intermediate state between Active and Inactive in SCTP path management. A destination transitions Active→PF when its error counter exceeds PFMR, PF→Inactive after an additional PMR−PFMR consecutive timeouts, and PF→Active when a HEARTBEAT ACK or single-destination data ACK is received.