Looking at Association Initialization with SCTP
Looking at Association Initialization with SCTP
A look at three SCTP procedures: association creation, user data transfer, and association teardown.
Join the DZone community and get the full member experience.Join For Free
In my previous post we've explored how SCTP packets are encoded and what protocol elements they contain. Next we will look at three SCTP procedures - association creation, user data transfer, and association tear down. Each procedure requires specific message flow, which will be reviewed in separate posts.
Section 4 from RFC 4960 has a state diagram for a SCTP association. There are two main states - CLOSED and ESTABLISHED. The transfer between them contains more intermediate states (COOKIE-WAIT, COOKIE-ECHOED, etc). Two endpoints can exchange user data only when the association is in an ESTABLISHED state. This is accomplished with association initialisation procedure. Once it is completed successfully the peers can exchange data by following user data transfer procedure. Finally the connection is closed with termination of association procedure. Now we will review association creation procedure.
Association initialisation procedure is described in Section 5. The peer which requests the connection is the client, the one accepting it - the server, just like in TCP. The flow is shown in fig. 1. The chunk names are in bold, below them are their most important parameters. Remember from the first post that a single SCTP packet can contain more than one chunk.
Figure 1: SCTP association initialization
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 the 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 and 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 multihoming feature. I plan a dedicated post for this, so I won't discuss it now.
Forward TSN supported parameter: This parameter is from SCTP Partial Reliability Extension. Check RFC 3758 section 3.2 for more information.
Figure 2: init.pcapng
INIT ACK Chunk
The server continues the association establishment process by sending message with INIT ACK chunk. In 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 the 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 the 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.
Figure 3: init_ack.pcapng
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 in fig. 4. It has only one parameter Cookie, which contains the state cookie received. COOKIE ECHO chunk is described in section 3.3.11.
Figure 4: cookie_echo.pcapng
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 in figure 5.
Figure 5: cookie_ack.pcapng
Association is Now Initialized
With this procedure the SCTP association is considered initialized and it is ready to transmit user data in both directions. The description here omits some details I consider irrelevant, as for example various timeouts, unexpected messages handling and so on. If you want to understand these details I do recommend to read the whole section 5 by yourself. Next time we will continue with user data transfer.
Opinions expressed by DZone contributors are their own.