SCTP - association initialisation


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 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

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 on 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 initialisation

figure 1: 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.

figure 2: INIT chunk

figure 2: init.pcapng

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.

figure 3: INIT ACK chunk

figure 3: init_ack.pcapng

Association is now initialised

With this procedure the SCTP association is considered initialised 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.

The book

This post is part of my "SCTP in Theory and Practice:A quick introduction to the SCTP protocol and its socket interface in Linux" e-book. If you find the content in this post interesting - I think you will like it.

The book covers two topics - how SCTP works in theory and how to use it in Linux.

The best way to learn how SCTP works is to read and understand its specification - RFC 4960. However this document is not an easy read - the purpose of the document is to describe a full SCTP implementation and contains details which you usually don't need, unless you plan to write your own SCTP stack.

The role of the first five chapters of the book is to give you structured and easy to read explanation about how different parts of the protocol work. You will see how an SCTP association is established on network packet level, how data transfer works, how multi-homing is implemented and so on. Additionally each section contains references to specific sections from RFC 4960, which cover the topics in question. This approach will save you a lot of time reading the document.

The rest of the book focuses on SCTP from programmer point of view. You will learn how to write client-server applications in Linux. You will learn the difference between one-to-one and one-to-many style sockets and how to implement multi-homing. Each chapter contains working client and/or server implementation in C and line-by-line code review.

All source code and PCAP files used in the book are available as extra content.

Think you will like it? You can buy it on Leanpub. I really appreciate your support!


Comments powered by Disqus