Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
Extracted elements (29)
Only one ASCONF packet may be in flight at a time (per direction) to prevent a flood of address-change operations from causing network congestion. This is a deliberate congestion-control mechanism analogous to a window of one for address-reconfiguration signaling, independent of the normal SCTP data transfer congestion window.
The Adaptation Layer Indication parameter was included in this document (rather than a separate RFC) purely for convenience to minimize the number of SCTP extension documents. It carries a 32-bit opaque code point for upper-layer protocols such as adaptation layers that need to signal their presence during association setup.
The ASCONF Sequence Number is initialized to the same value as the Initial TSN so that the receiver can unambiguously determine the first valid ASCONF sequence at association start without additional negotiation. Every new ASCONF increments this counter by one using modulo-2**32 arithmetic.
If an endpoint receives an Operational Error indicating that the ASCONF chunk type is not understood, it MUST NOT send any further ASCONF chunks to that peer and MUST inform the upper-layer application that the peer does not support the dynamic address reconfiguration extension.
All addresses added via a received ASCONF chunk MUST be placed into the UNCONFIRMED state and MUST have path verification performed before they can be used as destinations, as defined in RFC 4960 Section 5.4 (rule F14).
All arithmetic on ASCONF Sequence Numbers MUST be performed modulo 2**32 using Serial Number Arithmetic as defined in RFC 1982 (SERIAL_BITS=32). The sequence number wraps from 2**32−1 back to 0.
An endpoint MUST NOT delete its last remaining IP address from an association (rule F5). If a request to delete the last remaining address is received, the receiver MUST send error cause 0x00A0 and MUST NOT perform the deletion.
ASCONF and ASCONF-ACK chunks MUST be sent in an authenticated manner using the mechanism defined in RFC 4895 (SCTP-AUTH). If either chunk is received unauthenticated, it MUST be silently discarded.
ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP state other than ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED, and SHUTDOWN-SENT. An ASCONF or ASCONF-ACK SHOULD NOT exceed the PMTU.
If an endpoint receives an ASCONF-ACK with a Sequence Number greater than or equal to the next Sequence Number to be used while no ASCONF is outstanding, the endpoint MUST ABORT the association (rule F0), including error cause 0x00A3.
If an endpoint supporting this extension receives an INIT indicating the peer supports ASCONF but NOT RFC 4895 (AUTH), the receiver MUST send an ABORT and MUST NOT proceed with association setup. Similarly, if INIT-ACK lacks AUTH support, the receiver MUST NOT send COOKIE-ECHO.
The sender MUST start a T-4 RTO timer when sending an ASCONF chunk and MUST stop it upon receiving the corresponding ASCONF-ACK. On T-4 expiry, the endpoint MUST increment error counters, backoff the RTO, and retransmit the same ASCONF (unchanged, including its Sequence Number) to an alternate destination if possible.
TLV parameters within an ASCONF chunk MUST be processed in order (first to last). If an error occurs for a TLV, once a receiver begins failing any ADD or DELETE request, it MUST fail all subsequent ADD or DELETE requests in that same ASCONF chunk (rule F11).
Until the ASCONF-ACK confirming an Add IP Address arrives, the sender MUST NOT use the new address as a source for any SCTP packet except one carrying an ASCONF chunk (rule F1). The receiver MUST perform path verification before sending to the new address, and MUST NOT send packets there except an ASCONF-ACK or HEARTBEAT.
When an endpoint receives a valid Delete IP Address request, it MUST consider the address no longer part of the association, MUST NOT send SCTP packets for the association to that address, and MUST treat subsequent packets from that address as Out Of The Blue (rule F13).
When creating a new ASCONF chunk, the sender MUST assign a Sequence Number initialized to the initial TSN value at association start and incremented by one for each subsequent ASCONF. Only one ASCONF packet MAY be outstanding (unacknowledged) at any time; additional ASCONFs MUST be queued until the previous one is acknowledged.
Five new SCTP error cause codes are defined: 0x00A0 (Request to Delete Last Remaining IP Address), 0x00A1 (Operation Refused Due to Resource Shortage), 0x00A2 (Request to Delete Source IP Address), 0x00A3 (Association Aborted Due to Illegal ASCONF-ACK), and 0x00A4 (Request Refused - No Authorization). Error causes copy the original ASCONF TLV into the variable-length cause body.
This document registers two new SCTP chunk types (ASCONF 0xC1, ASCONF-ACK 0x80), six new parameter types (0x8008 Supported Extensions; 0xC001–0xC006), five new error cause codes (0x00A0–0x00A4), and a new IANA registry for 32-bit Adaptation Layer Indication code points, assigned via IETF Consensus.
An on-path attacker can manipulate the Supported Extensions parameter in INIT/INIT-ACK (which are unprotected by AUTH) to prevent ASCONF use, cause spurious ABORTs, or trick one side into using ASCONF when the peer does not support it. This adds limited vulnerability since an on-path attacker already has the ability to drop or corrupt the entire INIT.
Dynamic address addition and deletion creates an association hijacking risk. RFC 4895 (SCTP-AUTH) is mandatory to mitigate this; if the threat model includes interception of the initial two handshake packets, a preconfigured shared endpoint-pair key MUST be used because AUTH without pre-shared keys is still vulnerable at setup time.
When ASCONF uses wildcard addresses (0.0.0.0 or ::0), the effective address is the IP header source, which is NOT protected by SCTP-AUTH. An on-path attacker can modify the source address to add an attacker-chosen address, delete all-but-one association address, or redirect the primary path. Endpoints facing on-path attacker threats SHOULD NOT use wildcard addresses in ASCONF Add/Delete/Set-Primary parameters.
Upon receiving an ASCONF chunk, the receiver uses a three-stage lookup (source address+port → Address Parameter TLV → OOTB) to find the association, then validates the AUTH chunk and Sequence Number. If sequence equals Peer-Sequence-Number+1, process and cache the ASCONF-ACK (E4); if lower, reply with cached ACK (E2); if higher, discard as stale or attack (E5).
The Adaptation Layer Indication parameter (type 0xC006, length 8) carries a 32-bit opaque Adaptation Code Point exchanged in INIT/INIT-ACK. It MUST NOT be sent in any chunk other than INIT or INIT-ACK, and SHOULD be passed opaquely to the upper-layer protocol without examination by the SCTP stack.
The Add IP Address parameter (type 0xC001) contains a 32-bit ASCONF-Request Correlation ID followed by a variable-length IPv4 or IPv6 Address Parameter TLV. If the address is 0.0.0.0 or ::0, the source address of the packet MUST be added.
The ASCONF-ACK chunk (type 0x80) carries a 32-bit Sequence Number copied from the acknowledged ASCONF and zero or more TLV ASCONF Parameter Responses. An ASCONF-ACK with only the Chunk Type, Flags, Length=8, and Sequence Number implicitly indicates complete success for all TLVs.
The ASCONF chunk (type 0xC1) carries a 32-bit Sequence Number, a mandatory Address Parameter (8 or 20 bytes depending on IPv4/IPv6), and one or more TLV ASCONF parameters. The upper two bits of the chunk type are set to 1, causing unknown receivers to skip and report an Unrecognized Chunk Type error rather than aborting.
The Delete IP Address parameter (type 0xC002) contains a 32-bit ASCONF-Request Correlation ID and a variable-length IPv4 or IPv6 Address Parameter TLV. If the address is 0.0.0.0 or ::0, all peer addresses except the packet source address MUST be deleted.
The Set Primary IP Address parameter (type 0xC004) contains a 32-bit ASCONF-Request Correlation ID and an IPv4 or IPv6 Address Parameter TLV; it may appear in ASCONF, INIT, or INIT-ACK chunks. If the address is 0.0.0.0 or ::0, the receiver MAY mark the packet source address as primary.
The Supported Extensions Parameter (type 0x8008) contains a variable-length list of 1-byte SCTP chunk type codes, padded to a 4-byte boundary. An implementation supporting this extension MUST list ASCONF (0xC1), ASCONF-ACK (0x80), and AUTH chunk types in its INIT and INIT-ACK.