Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
Extracted elements (31)
Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds (the IP MSL) to prevent TSN wrap-around. The Receiver's Next TSN is set to the smallest unacknowledged TSN plus 2^31 to place the new TSN sequence safely beyond any in-flight or delayed segments.
SCTP streams are uni-directional with no correspondence between outgoing and incoming streams. The protocol mandates that the incoming side always resets its SSN before the outgoing side; therefore, a reset request must always originate from the outgoing side, forcing a peer that wants its incoming streams reset to ask the peer to initiate an outgoing reset.
The Re-configuration Timer uses the same value as SCTP's RTO with exponential backoff, reusing SCTP's existing retransmission and threshold management machinery rather than defining a separate mechanism. This keeps association failure detection consistent.
Race condition handling for Incoming SSN Reset: if an Outgoing SSN Reset Request completely overlaps a simultaneously received Incoming SSN Reset Request, the endpoint MUST respond 'Nothing to do'. If partial overlap or already-reset streams, the Incoming request MUST still be processed normally.
This extension is negotiated using the Supported Extensions Parameter from RFC 5061. The RE-CONFIG chunk type (130) must appear in that parameter during INIT/INIT-ACK; without mutual advertisement, no RE-CONFIG chunks may be sent.
A new stream added via an Add Streams request MUST use SSN 0 for its first ordered message. The sender MUST await a positive Success acknowledgment before using any additional streams added by such a request.
After sending a RE-CONFIG chunk containing at least one request parameter, the sender MUST start the Re-configuration Timer set to the RTO value. The timer MUST use exponential backoff; on expiry, the sender MUST retransmit the RE-CONFIG chunk and increment error counters, applying SCTP threshold management.
An SCTP endpoint supporting this extension MUST include the RE-CONFIG chunk type (130) in the Supported Extensions Parameter (per RFC 5061) in the INIT or INIT-ACK. A sender MUST NOT send any RE-CONFIG chunk unless the peer has advertised support.
At any given time there MUST NOT be more than one re-configuration request in flight. If the Re-configuration Timer is running when a new request is to be sent, the RE-CONFIG chunk containing that request MUST be buffered until the timer stops.
For an SSN/TSN reset response, the Receiver's Next TSN SHOULD be the smallest TSN not acknowledged by the receiver of the request plus 2^31, and the Sender's Next TSN SHOULD be the highest TSN sent by the receiver plus 1.
On receipt of an Outgoing SSN Reset Request, if the Sender's Last Assigned TSN is greater than the cumulative acknowledgment point, the receiver MUST enter 'deferred reset processing', queue arriving data with TSNs beyond that value, and respond with 'In progress' until the cumulative ACK catches up.
The default behavior for an SCTP endpoint is to deny all incoming re-configuration requests. Applications MUST explicitly enable processing via the SCTP_ENABLE_STREAM_RESET socket option before requests will be honored.
When an 'In progress' response is received (Result=6), the Re-configuration Timer MUST be restarted; however, if the timer expires in this state, the RE-CONFIG chunk MUST be retransmitted but the error counters MUST NOT be incremented.
When sending an Outgoing SSN Reset Request, the sender MUST stop assigning new SSNs to user data on the affected streams and queue that data (step A1), because a lost request could cause out-of-sequence errors on the receiver before it is prepared to accept them.
When sending an SSN/TSN Reset Request, the sender MUST queue all user data and suspend new transmissions and TSN assignments (step C2). Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds (one IP maximum segment lifetime).
The RE-CONFIG chunk (Type 130) is a new SCTP chunk used to carry stream reconfiguration requests and responses. It contains one or two Re-configuration Parameters and uses chunk type upper-bits '10' so unrecognized receivers ignore it and continue processing.
The Re-configuration Request Sequence Number is a monotonically increasing 32-bit counter initialized to the same value as the initial TSN and incremented by 1 for each new Re-configuration Request Parameter sent.
The Re-configuration Response Result field (4 bytes) encodes: 0=Success-Nothing to do, 1=Success-Performed, 2=Denied, 3=Error-Wrong SSN, 4=Error-Request already in progress, 5=Error-Bad Sequence Number, 6=In progress.
IANA assigned RE-CONFIG chunk type 130 (upper two bits '10', meaning 'ignore if not understood') in the SCTP Chunk Types registry, with RFC 6525 as the reference. The chunk flags registration table is empty.
IANA assigned six new SCTP Chunk Parameter Types (upper two bits '00'): 13=Outgoing SSN Reset Request, 14=Incoming SSN Reset Request, 15=SSN/TSN Reset Request, 16=Re-configuration Response, 17=Add Outgoing Streams Request, 18=Add Incoming Streams Request.
SCTP associations are protected against blind attackers by verification tags, and this protection remains fully intact when using the re-configuration extension. The extension does not add any new attack surface with respect to blind attackers.
The sockets API exposes SCTP SSNs to applications, which may assume monotonically increasing values. Stream reconfiguration breaks that assumption, so applications MUST explicitly opt in via socket options and event subscriptions before the extension is activated.
When both SSN and TSN are reset, the maximum segment lifetime (30 seconds) is used as the minimum interval between successive SSN/TSN resets, preventing TSN wrap-around from causing data from an old epoch to be accepted as valid in the new epoch.
Outgoing SSN Reset flow: sender enters 'queuing' state (stops SSN assignment) on sending request; receiver may enter 'deferred reset processing' state while waiting for cumulative ACK to reach Sender's Last Assigned TSN; on success response, sender returns to normal operation and releases queued data.
SSN/TSN Reset flow: sender suspends all new data and TSN assignment on sending request (step C2); on success response (H5), sender resumes from Receiver's Next TSN with SSN 0 on all outgoing streams; all incoming streams are reset to expected SSN 0.
Add Outgoing/Incoming Streams Request Parameters (Types 17 and 18): fixed 12-byte format with Parameter Type (2 bytes), Parameter Length (2 bytes, MUST be 12), Re-configuration Request Sequence Number (4 bytes), Number of New Streams (2 bytes), and Reserved (2 bytes).
Incoming SSN Reset Request Parameter (Type 14): Parameter Type (2 bytes), Parameter Length (2 bytes, MUST be 8+2*N), Re-configuration Request Sequence Number (4 bytes), and N optional Stream Numbers (2 bytes each). Absence of stream numbers means reset all streams.
Outgoing SSN Reset Request Parameter (Type 13): Parameter Type (2 bytes), Parameter Length (2 bytes, MUST be 16+2*N), Re-configuration Request Sequence Number (4 bytes), Re-configuration Response Sequence Number (4 bytes), Sender's Last Assigned TSN (4 bytes), and N optional Stream Numbers (2 bytes each).
RE-CONFIG chunk: Type (1 byte, value 130), Chunk Flags (1 byte, set to 0), Chunk Length (2 bytes), followed by one mandatory and one optional Re-configuration Parameter. Only ten specific parameter combinations are permitted.
Re-configuration Response Parameter (Type 16): Type (2 bytes), Length (2 bytes, MUST be 12 without optional fields or 20 with them), Re-configuration Response Sequence Number (4 bytes), Result (4 bytes, values 0–6), and optional Sender's Next TSN and Receiver's Next TSN (4 bytes each, used only for SSN/TSN resets).
SSN/TSN Reset Request Parameter (Type 15): fixed 8-byte parameter containing Parameter Type (2 bytes), Parameter Length (2 bytes, MUST be 8), and Re-configuration Request Sequence Number (4 bytes). Resets both TSN and all SSNs.