Skip to main content

5. Association Initialization

5.1. Normal Establishment of an Association​

An SCTP endpoint A that wishes to establish an association with another SCTP endpoint Z MUST send an INIT chunk. If Z accepts the association, it MUST reply with a packet containing an INIT ACK chunk. The establishment of the association is further discussed below.

5.1.1. Handle Stream Parameters​

In the INIT or INIT ACK chunk, the sender MAY request the receiver to use specific address types by including a "Supported Address Types" parameter in the optional/variable-length parameter section. The sender SHOULD include this parameter if it does not support all address types or wants to limit its peer to use certain address types.

A receiver of an INIT or INIT ACK MUST send all subsequent communication using one of the address types specified in the list or the address type that the INIT or INIT ACK was sent to (if not listed).

If the receiver does not support or wishes to avoid any address type expected by the sender, it MAY abort the association and SHOULD send an "Unsupported Address Type" error.

Note: If an INIT or INIT ACK contains a "Supported Address Types" parameter, the receiver MUST use only one of the address types found in the parameter or the address type the INIT/INIT ACK was sent to, even if the receiver is capable of using other address types.

In an INIT or INIT ACK chunk, the sender indicates its stream capacity through the "Number of Outbound Streams (OS)" and "Number of Inbound Streams (MIS)" parameters it includes.

The receiver SHOULD use the value the sender indicates in the OS field of the INIT or INIT ACK as the maximum number of its own inbound streams (i.e., the receiver's MIS). The sender uses the MIS parameter to limit the number of streams on which the peer may send user messages.

In the INIT or INIT ACK, the sender's Number of Outbound Streams (OS) and Number of Inbound Streams (MIS) MUST NOT be 0.

If a receiver receives an INIT or INIT ACK where the OS or MIS value is 0, the receiver SHOULD abort the association, sending an ABORT chunk and MAY report the error "Invalid Mandatory Parameter".

The receiver MUST also limit its use of outbound streams to the actual number received in the MIS field of the INIT or INIT ACK. In other words, after the association is established, an endpoint will use the following:

Number of outbound streams to send user messages = 
    minimum(local OS, peer's MIS)

Number of inbound streams to receive user messages = 
    minimum(local MIS, peer's OS)

5.1.2. Handle Address Parameters​

During the initialization (prior to sending the INIT or INIT ACK), the sender SHOULD include all of its addresses in the INIT or INIT ACK using the optional IPv4 Address parameter and/or IPv6 Address parameter. Omission of this optional parameter indicates that the endpoint has only one address, the source address used to send the INIT or INIT ACK.

Before sending an INIT chunk, an endpoint SHOULD always enter the COOKIE-WAIT state.

Note: The absence of addresses in an INIT chunk does not mean that the sending endpoint does not accept other addresses. On the contrary, the absence of addresses indicates that the sender does not wish to be listened to, but it will accept messages sent from any of its peer's addresses.

If the receiver does not support any of the address types provided by the sender in the INIT or INIT ACK, it SHOULD abort the association and MAY send an "Unsupported Address Type" error cause.

A receiver of an INIT or INIT ACK MUST record all the address information provided (however obtained, including from the IP header, IPv4 Address parameter, and/or IPv6 Address parameter) and use that information to determine its transport address set.

If the sender includes a "Host Name Address" parameter, the receiver MUST immediately send an ABORT chunk and MAY include an "Unresolvable Address" error cause.

Note: Use of the "Host Name Address" parameter is deprecated. A receiver MUST ignore any "Host Name Address" parameter in an INIT or INIT ACK and SHOULD send an ABORT chunk in response.

An endpoint sending an INIT ACK should create a State Cookie and place it into the State Cookie parameter of the INIT ACK. See Section 5.1.3 for State Cookie usage.

The State Cookie should contain the following minimum required information:

  • Information obtained from the received INIT chunk (including the Initiate Tag and optional/variable-length parameters)
  • The time when the State Cookie was created
  • A Lifespan (the time the cookie is valid)
  • A method for authenticating the integrity and authenticity of the State Cookie (e.g., a Message Authentication Code (MAC))

Implementation Note: The State Cookie can be used to store additional information about the state of the association being established. This allows an endpoint to defer allocating resources (TCB) during association establishment. This optimization is called the "Cookie Approach" and can prevent simple Denial-of-Service attacks.

An implementation sending an INIT ACK SHOULD make the State Cookie sufficiently hard to protect against an attacker guessing valid State Cookies. A recommended technique is to include in the State Cookie:

  • A random nonce (unique per association instance)
  • A timestamp
  • The peer's source address
  • The peer's source port
  • The local destination address
  • The local destination port
  • A MAC covering all the above fields

The secret key needed to create this MAC SHOULD be created when the SCTP stack is initialized and should be refreshed periodically. This key MUST be kept secret to anyone outside of the communicating parties.

Including these values in the State Cookie parameter of the INIT ACK allows validation of the State Cookie returned in the COOKIE ECHO chunk. The validation process is described in Section 5.1.4.

Additionally, the sender MAY include any other data needed to generate the State Cookie used for validating the cookie returned in COOKIE ECHO and for establishing the association.

Note: The MAC computation MUST include the timestamp to ensure that a replayed cookie cannot be used as a Denial-of-Service attack tool.

When an endpoint receives a State Cookie in a COOKIE ECHO chunk, it MUST validate that cookie according to the following:

  1. Verify that the State Cookie's MAC is valid. If the MAC is invalid, silently discard the packet.

  2. Verify that the State Cookie is not stale. If the State Cookie is stale, the endpoint SHOULD send an ERROR chunk with the Cause Code set to "Stale Cookie Error" and silently discard the packet. The staleness of the State Cookie can be adjusted using the "Cookie Preservative" parameter. See Section 5.1.3.

  3. Check that the source address and port numbers match the values stored in the State Cookie. If they do not match, silently discard the packet.

If the State Cookie is valid, the endpoint SHOULD create an association to that peer and send a COOKIE ACK chunk to the sender. The endpoint should then move that association to the ESTABLISHED state.

An implementation MUST protect the integrity and authenticity of the State Cookie using a technique as described below or an equivalent technique.

The recommended technique is to include a Message Authentication Code (MAC) in the State Cookie. The MAC SHOULD be computed using a secret key known to the sender but unknown to any potential attacker.

The MAC algorithm SHOULD be at least as secure as HMAC-SHA-1 as defined in [RFC2104] and [RFC3174].

To create and verify the MAC, a secret key is needed. This secret key SHOULD be changed periodically (e.g., every few hours) to limit the ability of an attacker to infer the key by observing legitimate traffic.

During secret key changes, an implementation SHOULD retain the old key for a period of time (at least twice the cookie lifespan) to allow cookies created with the old key to be validated.

5.1.6. An Example of Normal Association Establishment​

In the simplest case, the normal association establishment of an endpoint A requesting to start an association to endpoint Z would look like this:

Endpoint A                                     Endpoint Z

INIT    ----[INIT ACK with State Cookie]----->
        <----------[COOKIE ECHO]-------------
        ----------[COOKIE ACK]--------------->

At this point, the association is ESTABLISHED at both ends.

Detailed Steps:

A) Endpoint A sends an INIT chunk to Endpoint Z, indicating its desire to establish an association. In the INIT chunk, Endpoint A MUST provide its Verification Tag (to be used in all packets from Z), the initial TSN it supports, the number of outbound streams (OS), the maximum number of inbound streams (MIS), and its other transport addresses (if any).

B) Upon receiving the INIT, Endpoint Z SHOULD respond with an INIT ACK chunk. In the INIT ACK, Z MUST provide its Verification Tag, its initial TSN, its OS, MIS, and its transport addresses (if applicable). Additionally, Z MUST create a State Cookie and include it in the INIT ACK.

C) Upon receiving the INIT ACK containing the State Cookie, Endpoint A SHOULD respond with a COOKIE ECHO chunk. The COOKIE ECHO chunk MUST contain the State Cookie received in the INIT ACK. Additionally, Endpoint A MAY send user data bundled with the COOKIE ECHO in the same packet.

D) Upon receiving the COOKIE ECHO, Endpoint Z will validate the State Cookie. If valid, Z will create the association and respond with a COOKIE ACK chunk. Additionally, Z MAY send user data bundled with the COOKIE ACK in the same packet.

E) Upon receiving the COOKIE ACK, Endpoint A will change its association state from COOKIE-ECHOED to ESTABLISHED. A can now send and receive user data on the established association.

At any time during the life of an association, an endpoint may receive unexpected or duplicate INIT, INIT ACK, COOKIE ECHO, or COOKIE ACK chunks. This section describes how to handle these chunks.

5.2.1. INIT Received in CLOSED State​

If an endpoint is in the CLOSED state and receives an INIT chunk, it SHOULD respond with an INIT ACK as described in Section 5.1.

If an endpoint is in the COOKIE-WAIT or COOKIE-ECHOED state and receives an INIT chunk whose Initiate Tag does not match its recorded peer Verification Tag, the endpoint SHOULD discard the old TCB (if any) and respond with an INIT ACK to the new INIT chunk.

If an endpoint is in the COOKIE-WAIT or COOKIE-ECHOED state and receives an INIT chunk whose Initiate Tag matches its recorded peer Verification Tag, the endpoint SHOULD respond with an INIT ACK but not change its state. This situation may occur when the peer did not receive or lost the INIT ACK.

If an endpoint is in the CLOSED state or COOKIE-WAIT state and receives an INIT ACK, the endpoint SHOULD send an ABORT chunk and MAY include an "Out of the Blue" error cause (see Section 3.3.10).

If an endpoint is in the COOKIE-WAIT state and receives an INIT ACK whose Initiate Tag field does not match its own Tag, the endpoint SHOULD enter the CLOSED state, destroy the TCB, and send an ABORT chunk.

This section describes the behavior when an endpoint receives a COOKIE ECHO chunk in states other than CLOSED and COOKIE-ECHOED.

Implementation Note: An endpoint may receive a COOKIE ECHO chunk at any time during the association lifetime, typically due to peer retransmission or network delay.

If an endpoint receives a COOKIE ECHO chunk and a TCB exists for the same association, the endpoint SHOULD handle it according to one of the following actions:

A) If the current state is ESTABLISHED, the endpoint SHOULD silently discard the COOKIE ECHO. Alternatively, if the peer includes an incorrect verification tag in the COOKIE ECHO, the endpoint MAY send an ABORT chunk.

B) If the current state is SHUTDOWN-ACK-SENT, the endpoint SHOULD silently discard the COOKIE ECHO.

In all other cases, the endpoint SHOULD treat the COOKIE ECHO as an attempt to establish a new association according to the rules in Section 5.2.4, but use any information in the existing TCB to optimize the association establishment process.

If an endpoint receives a COOKIE ACK chunk outside the COOKIE-ECHOED state, it SHOULD silently discard the chunk.

If an endpoint receives an ERROR chunk containing a "Stale Cookie" error cause after sending a COOKIE ECHO chunk and the endpoint is in the COOKIE-ECHOED state, the endpoint MAY attempt to re-establish the association using a new INIT chunk.

If the endpoint chooses to retry, it SHOULD include a "Cookie Preservative" parameter in the new INIT chunk with a value set to the Measure of Staleness field specified in the received "Stale Cookie" error.

If the endpoint chooses not to retry, it SHOULD enter the CLOSED state and report the problem to its upper layer.

5.3. Other Initialization Issues​

5.3.1. Selection of Default Port​

An SCTP endpoint SHOULD support receiving and sending SCTP packets to UDP port 9899 (the default port for SCTP over UDP encapsulation).

5.3.2. IPv4/IPv6 Coexistence​

An implementation SHOULD support the use of both IPv4 and IPv6 addresses as recommended in [RFC4213].

5.3.3. SCTP Association Identifier​

Each SCTP association is uniquely identified by a pair of Verification Tags:

  • The local Verification Tag (provided by the peer in its INIT or INIT ACK)
  • The peer's Verification Tag (sent in the local INIT or INIT ACK)

This pair of Tags is used to demultiplex received SCTP packets.

5.4. Path Verification​

During normal operation, an SCTP endpoint MUST use the heartbeat mechanism to verify the reachability of its peer's paths.

During initialization (after sending the INIT ACK), an endpoint SHOULD use the heartbeat mechanism to verify that all addresses received in the INIT or INIT ACK are reachable.

This verification SHOULD begin immediately after the association enters the ESTABLISHED state.

Implementation Note: If an endpoint receives an INIT or INIT ACK containing multiple IP addresses, it SHOULD attempt to verify all provided addresses by sending HEARTBEATs to each address.

Addresses that fail to respond to HEARTBEATs during the verification process SHOULD be marked as inactive and should not be used in normal data transmission unless they are later proven to be active (through HEARTBEATs or data transmission).

This chapter continues...

For more detailed content in Chapter 5 (including specific error handling, timeout mechanisms, and security-related considerations), please refer to the complete text of RFC 4960.

Last updated on