SCTP - association initialisation

INIT chunk

First the client sends INIT chunk to the server. You can see a sample on fig. 2. It has the following parameters (described in Section 3.3.2):

• Initiate tag: This value should be saved by the receiver and set in Verification tag field in the SCTP common header for each message from the server to the client. Note that the Verification tag in the message, containing the INIT chunk, is 0 because it is the first one in the communication.

• Advertised Receiver Window Credit (a_rwnd): the buffer size of the sender. For more information check the description in Section 3.3.2.

• Number of outbound streams: The requested number of streams from the client to the server. Note that the server may not accept this number. The procedure for stream count is described later in this post. This value can't be zero.

• Number of inbound streams: The maximum number of inbound streams that the client supports. The server is obligated to respect this value, or error will occur. This value also can't be zero.

• Initial TSN: A random number between 0 4294967295. TSN stands for Transmission Sequence Number. Each DATA chunk (user data) has attached a unique TSN which is used for acknowledgement and duplicated chunk detection. This parameters states the first TSN that will be used by the sender (the client in this case). For each new DATA chunk, the TSN is incremented by one.

• Supported address types and IPv4 address parameters: they contain the IP addresses which can be used to reach the client. They can be more than one, because of the SCTP's multi-homing feature. I plan a dedicated post for this, so I won't discuss it now.

• ECN parameter: This parameter hasn't got any relation to association establishment so I will skip it. It is described in Appendix A from RFC 4960.

• Forward TSN supported parameter: This parameter is from SCTP Partial Reliability Extension. Check RFC 3758 section 3.2 for more information.

INIT ACK chunk

The server continues the association establishment process by sending message with INIT ACK chunk. On fig. 3 you can see the response for the INIT chunk from the previous section. The first thing you should notice is the Verification tag in the common header of the SCTP message. It is set to 0x08fe2132 - the Initiate tag from the INIT chunk. Remember that only the INIT message has Verification tag set to 0. Each subsequent message will have the Verification tag set to the Initiate tag of the receiver. Now let's continue with the parameters of the INIT ACK chunk. Some of them are the same as in INIT chunk, but with a bit different meaning:

• Initiate tag: the server announces its Verification tag.

• Advertised Receiver Window Credit (a_rwnd): check the description in INIT.

• Number of outbound streams: The number of streams from the server to the client. This value should be equal or less than 'Number of inbound streams' parameter in the INIT message. If the value is bigger the client can abort the association establishment procedures.

• Number of inbound streams: The maximum number of inbound streams, supported of the server. If the 'Number of outbound stream' parameters in the INIT chunk of the client is bigger than this parameter, the client must adjust its maximum output streams number.

• Initial TSN: the first TSN that will be used by the server. Check the description in INIT section for more details.

• ECN parameter and Forward TSN supported parameter: The same as for INIT.

You have noticed that at this point both the client and the server know the number of input and output streams supported by the other peer. This procedure is used to negotiate an acceptable number for both peers in each direction. Also note that the protocol negotiates the maximum, not the actual number of streams in each direction. This doesn't mean that the SCTP user is obligated to use all of them.

There are some more parameters in the INIT ACK chunk, which are not present in the INIT:

• State cookie: When INIT message is received, the server generates TCB (check Key terms), which stands for Transmission Control Block. It contains all the information of the association that is required by the server. The state cookie parameter contains the TCB with MAC (Message Authentication Code). It is used for integrity check and authentication of the TCB. For more information about MAC, check RFC 2104 or the Wikipedia article Hash-based message authentication code. After the state cookie is generated, the server deletes all the information about the association. The purpose is not to make the server vulnerable to DoS attacks, similar to SYN flood. In a nutshell - if a malicious user tries to flood the server with INIT messages the SCTP stack will only calculate state cookies and send INIT ACKs, without keeping any state information, which may exhaust its resources. If you are curious how TCBs are generated, check section 13. State cookie generation is covered in section 5.1.3.

For more information about INIT ACK chunk, check section 3.3.3.

COOKIE ECHO chunk

When the client receives INIT ACK chunk with state cookie, it should immediately respond with COOKIE ECHO. This chunk is very simple, you can see an example on fig. 4. It has only one parameter Cookie, which contains the state cookie received. COOKIE ECHO chunk is described in section 3.3.11.

COOKIE ACK chunk

The server receives the COOKIE ECHO chunk and extracts the state cookie. Then it reads the TCB and computes its MAC. If it matches with the one in the message, the TCB is considered valid and authenticated. Then the server extracts from it all the information about the association that is required to establish the association. On success the server returns COOKIE ACK chunk and the association is considered established. There aren't any parameters in this chunk, so nothing more to explain here. You can find more details about this procedure at section 5.1.5 and COOKIE ACK chunk is described in section 3.3.12. You can see a sample message with this chunk on figure 5.