STREAM CONTROL TRANSMISSION PROTOCOL (SCTP)

SCTP service model connection oriented reliable data transfer - no loss - no duplicates - data integrity ordered / unordered delivery TCP provides only ordered service. If the application desires unordered service, it has the option of using UDP => unreliable SCTP separates data reliability from ordered delivery SCTP can provide unordered service with reliability SCTP can provide ordered service with reliability

SCTP preserves message boundaries TCP is byte-oriented. Applications must add their own record marking to delineate messages. concept of chunks security against SYN flooding attack multi-homing multi-streaming message fragmentation and bundling congestion control

Comparison between SCTP, TCP and UDP Feature SCTP TCP UDP State required at endpoints Yes No Reliable Data Transfer Multi-homed Host Support Multi-Stream Support Security against SYN attacks Unordered Data Delivery Failure detection (Heartbeat)

SCTP PDU format 1 common header + chunks (control or data)

Motivation Many applications need reliable message delivery – they do so by delineating a TCP stream TCP provides both strict-ordering and reliability – many applications may not need both

Motivation (contd) HTTP is one such application While transferring multiple embedded files we only want Reliable file transfer for each file Partial ordering for the packets of each file but not total ordering amongst all the packets TCP provides more than this (but overhead?) SCTP may help (how? – later)

HTTP Server Architecture Multiple File Transfer (Embedded files) - TCP Client Server Request file 0 Fork child Send file 0 Child process Request file 1..N Send file 1,2,…N

HTTP Server Architecture Multiple Files Transfer (Embedded Files) - SCTP Client Server Request file 0 Fork child Send file 0 – stream 0 Child process Request files 1..N Send file 1 – stream 1 Send file N – stream N

Receive buffer in kernel Reason Server Client 3 2 1 3 2 3 2 1 3 2 1 1 File 3 File 2 TCP Send buffer in kernel TCP Receive buffer in kernel

Reason Server Client 3 3 2 2 3 2 1 3 2 1 1 1 File 3 File 2 SCTP Receive buffer in kernel SCTP Receive buffer in kernel

Multi-homing

multi-homing single-homed SCTP endpoint multi-homed SCTP endpoint Host B Host A application application IP1=160.15.82.20 IP2=161.10.8.221 IP3=10.1.61.11 200 100 SCTP SCTP B1 B2 B3 A1 IP=128.33.6.12 endpoint=[128.33.6.12 : 100] endpoint=[160.15.82.20, 161.10.8.221, 10.1.61.11 : 200] SCTP association Host A Host B application application 100 IP1=160.15.82.20 IP2=161.10.8.221 IP3=10.1.61.11 200 SCTP SCTP A1 B1 B2 B3 IP=128.33.6.12 association={ [128.33.6.12 : 100] : [160.15.82.20, 161.10.8.221, 10.1.61.11 : 200] }

X Network Host A Host B 4 possible TCP connections: (A1,B1) or (A1,B2) or (A2,B1) or (A2,B2) 1 SCTP association: ({A1,A2},{B1,B2}) Primary destinations for A & B (e.g., A1 & B1) Network Host A Host B B1 B2 A1 A2 X What happens if a primary fails? TCP connection is broken whereas SCTP association can continue to transmit to an alternate destination address

failure detection Host A monitors reachability of the primary destination address of Host B Host A Host B application application 100 primary 200 alternates SCTP SCTP A1 B1 B2 B3 SACK DATA error_count is a variable associated with each destination address of a host. It is set to zero initially. Host A starts the retransmission timer If timer expires increment error_count If error_count > threshold state = inactive If Host A receives SACK before timer expires error_count = 0 & state = active

Host A monitors reachability of alternate destination addresses of Host B application application 100 primary 200 alternates SCTP SCTP A1 B1 B2 B3 HEARTBEAT HEARTBEAT-ACK HEARTBEAT is sent periodically to each alternate address When a HEARTBEAT is sent increment error_count If error_count > threshold state = inactive If Host A receives a HEARTBEAT-ACK error_count = 0 & state = active When the primary destination address is detected unreachable => SCTP sender chooses 1 of the REACHABLE, alternate destination addresses as primary

association setup How many way handshake ? V: verification tag I: initiation tag Host A Host B closed mandatory - type chunk flags chunk length initiation tag a_rwnd outbound streams maximum inbound streams initial TSN optional - addresses(IPv4,IPv6, hostname) supported address types ECN capable cookie preservative INIT (V=0) (I=TagA) cookie wait closed

SCTP INIT PDU

association setup V: verification tag I: initiation tag Host A Host B closed INIT (V=0) (I=TagA) cookie wait closed INIT-ACK (V=TagA) (I=TagB) mandatory – All fields present in mandatory INIT + state cookie optional - addresses(IPv4,IPv6, hostname) ECN Capable error reporting for unrecognized parameters NO TCB on server-side at this point

association setup V: verification tag I: initiation tag Host A Host B closed INIT (V=0) (I=TagA) type chunk flags chunk length state cookie DATA chunk can be sent along with COOKIE-ECHO cookie wait INIT-ACK (V=TagA) (I=TagB) closed COOKIE-ECHO (V=TagB) cookie echoed Note that now we can send data to mitigate the cost of the 4-way handshake

TCP SYN flooding attack why COOKIE ??? attackers victim Flooded!! 130.2.4.15 128.3.4.5 SYN SYN buffer holding half-open (pending) connections SYN 228.3.14.5 192.10.2.8 SYN SYN SYN 190.13.4.1 SYN 221.3.5.10 SYN TCP SYN flooding attack There is no ACK in response to the SYN-ACK, hence connection remains half-open Other genuine clients cannot open connections to the victim The victim is unable to provide service

how does COOKIE help ? Host B receives INIT Receiver of INIT does not make the Transmission Control Block (TCB) [i.e no pending connection information kept] Remains in CLOSED state In case of attack, COOKIE-ECHO won’t arrive but receiver is unaffected Send INIT_ACK with COOKIE Prepare COOKIE

how does COOKIE help ? Host B receives INIT Send INIT_ACK Prepare with COOKIE Prepare COOKIE Host B receives COOKIE-ECHO invalid Extract & Validate COOKIE Discard SCTP PDU valid yes COOKIE expired ? Send ERROR chunk Sender can request longer cookie life next time through the Cookie - preservative parameter in the INIT chunk no Unpack COOKIE and build association TCB Discard SCTP PDU

association setup V: verification tag I: initiation tag Host A Host B closed INIT (V=0) (I=TagA) type chunk flags chunk length DATA chunk can be sent along with COOKIE-ACK cookie wait INIT-ACK (V=TagA) (I=TagB) closed COOKIE-ECHO (V=TagB) cookie echoed COOKIE-ACK (V=TagA) Note that now we can send data to mitigate the cost of the 4-way handshake 4 – way handshake ! established established

association shutdown Host A Host B upper layer invokes SHUTDOWN established established DATA DATA shutdown_pending SACK SHUTDOWN shutdown_sent

stop accepting data SHUTDOWN DATA shutdown_sent shutdown_received SHUTDOWN+ SACK SHUTDOWN_ACK shutdown_ack_sent SHUTDOWN_COMPLETE delete TCB closed delete TCB closed

when should a SACK be sent ? Host A Host B DATA (TSN 1) Endpoint sends DATA to its peer, always bundle a SACK chunk to ack any new DATA chunks SACK 1 + DATA DATA (TSN 2) If no DATA to be sent to the peer, then SACK is DELAYED Delay – 200 to 500 ms 200 ms SACK 2 DATA (TSN 2) Duplicate data chunks => immediately send SACK without any delay SACK 2

when should a SACK be sent ? Host A Host B DATA (TSN 3) Must send a SACK for every other SCTP PDU received without any delay DATA (TSN 4) 200 ms SACK 4 DATA (TSN 5) X One or more TSNs missing => immediately send SACK with Gap Ack blocks without any delay DATA (TSN 6) SACK 4

summary SCTP PDU = 1 common header + 1 or more chunks ( control or data) Association setup = 4 way handshake (INIT, INIT-ACK, COOKIE-ECHO, COOKIE_ACK) COOKIE mechanism to prevent SYN flooding attack Graceful shutdown(SHUTDOWN, SHUTDOWN-ACK, SHUTDOWN-COMPLETE) no half-close as in TCP Separates reliability from ordered delivery Preserves message boundaries SACK chunks to ack cumulative TSN + gap ack blocks + duplicate TSNs Achieves link / path redundancy by supporting multi-homed hosts along with reachability check

References Randall R. Stewart, Qiaobing Xie. Stream Control Transmission Protocol (SCTP) A Reference Guide Stewart et. al. Stream Contol Transmission Protocol RFC-2960, October 2000. URL: http://www.ietf.org/rfc/rfc2960.txt SCTP for Beginners URL:http://tdrwww.exp-math.uni essen.de/inhalt/forschung/sctp_fb/index.html SCTP overview http://www.sctp.org/sctpoverview.html SCTP tutorial http://www.iec.org/online/tutorials/sctp/ SCTP applicability statement http://www.ietf.org/rfc/rfc3257.txt

P. Amer, P. Conrad, Sam Baskinger References Slides collected from various sources including Keyur Shah, Sourabh Ladha, P. Amer, P. Conrad, Sam Baskinger