Stream Control Transmission Protocol (SCTP) är ett transportprotokoll som föreslogs som standard av arbetsgruppen Signaling Transport (SIGTRAN) inom IETF i oktober 2000. Protokollet finns beskrivet i RFC 4960.

SCTP är likt TCP men introducerar ny funktionalitet bland annat för att förbättra pålitligheten hos överföring av data och att ge bättre skydd mot SYN flooding attacker.

1998 bildades arbetsgruppen SIGTRAN med mål att skapa ett komplement till telefonnätets SS7 för att signalera över Internet. Under sitt arbete kom de fram till problem angående TCP:

• Head-of-line blockering - TCP ordnar all data i korrekt ordning innan den når applikation. Om ett paket förloras så kommer alla paket efter det förlorade paketet att bli försenade även om de har kommit fram till sin destination.
• Multihoming – Anslutningar i TCP har endast en anknytning mellan de två ändpunkterna. I SCTP, om en server har flera IP-adresser, så kan de två ändpunkterna ha flera anknytningar till varandra genom att använda olika IP-adresser. Detta gör att om en anknytning skulle brytas kan överföringen fortsätta på en alternativ väg.
• SYN-flood - Systemresurser kunde bli reserverade genom s.k. SYN-attack där angriparen byter ut sin egen IP i IP-paketen mot en godtycklig IP. TCP har inget inbyggt stöd för att hantera denna typ av attack utan mjukvara förväntas förhindra en sådan attack från att göra för stor skada. Dessa är väldigt ineffektiva då de inte kan skilja mellan den som går till attack och den som vill använda sig av tjänsten^[1].

Man övervägde inte att använda sig av User Datagram Protocol eftersom det inte var ett säkert dataöverföringsprotokoll, om en applikation vill göra om UDP till en säker dataöverföring så skulle det introducera mer komplexitet till applikationen, vilket kändes överdrivet ansåg R. Stewart och Q. Xie^[2]

Med dessa problem i åtanke började SIGTRAN att arbeta på ett nytt transportprotokoll för att hantera telefonsignalering över Internet. Samtidigt insåg cheferna på transportavdelningen hos IETF (Scott Bradner och Vern Paxson) värdet i att lösa dessa problem. De förstorade omfattningen hos SIGTRAN och gav dem i uppgift att skapa ett generellt transportprotokoll som andra applikationer också kunde dra nytta av. Detta nya transportprotokoll blev SCTP. ^[3]

I oktober 2000 blev SCTP en RFC (RFC 2960). Sedan dess har det implementerats i alla de stora operativsystemen: GNU/Linux, BSD och Solaris. Det finns också för Microsoft Windows som ett tredjepart kommersiellt paket. ^[4]

Ett SCTP paket innehåller följande:

1. IP Header - Antingen IPv6 eller IPv4 Nätverkslagret
2. SCTP Common Header
3. Chunks - Godtyckligt antal

Det finns 2 olika typer av så kallade "Chunks" i ett SCTP-paket, dessa är data och kontroll. Det finns inget krav i RFC2960 om att varje SCTP-paket behöver innehålla data eller kontroll-"chunks". Man kan alltså skicka SCTP-paket som enbart innehåller data-"chunks" eller kontroll-"chunks" men de kan även innehålla båda. Om man ska skicka ett paket innehållande både data- och kontroll-"chunks" så ska alltid kontroll-"chunks" komma först då dessa används för att underhålla associationen mellan ändpunkterna.

SCTP Common Header innehåller informationen som behövs för att paketet ska kunna nå målet, ändpunkten.

En SCTP Common Header innehåller följande:

1. Ursprungsadressen - Till exempel IP-adressen till sin egen enhet.
2. Måladressen - Till exempel IP-adressen till målenheten.
3. Verifikationsfält - Detta fält används för att kunna urskilja den aktuella associationen ifrån en gammal som inte längre är aktiv.
4. Adler-32 checksum - Används för att upptäcka fel i paketet och täcker SCTP Common Header och alla "chunks".^[5]

Likt TCP och UDP så har även SCTP ett eget set av portar utgivna av IANA, med hjälp av dessa och nodens IP-adress formar de tillsammans en SCTP-adress. Denna adress kan i sin tur kopplas till ett specifikt gränssnitt på målnoden och detta gör att man inte kan använda sig av multi- eller broadcast-adresser inom SCTP eftersom dessa inte går att koppla till specifika målgränssnitt.

En SCTP-adress mot till exempel en godtycklig nod hade därför haft följande utseende om de hade erbjudit en tjänst som accepterade SCTP-associationer på port 100.

173.194.71.94:100

Om man hade skapat en anslutning mot denna IP-adress så hade associationen för den anslutningen haft följande utseende

173.194.71.94:100 : [EGEN IP:PORT] där PORT är numret på den port som används ifrån enheten som vill skapa denna association använder sig av.^[6]

När en anslutning skapas så byts en lista ut mellan de två ändpunkterna. Dessa listor innehåller de IP-adresser som den respektive ändpunkten är associerad med. Detta betyder att varje ändpunkt är redo att ta emot data från flera olika IP-adresser. Om det börjar uppstå problem på den primära vägen kan en alternativ väg användas tills den primära vägen är fullt fungerande igen.^[7] Det går även att balansera nätverksanvändningen genom att använda sig av multihoming. Det går till exempel att använda 2 av 3 av IP adresserna för Tjänst A och den tredje för Tjänst B. Om man väljer att balansera nätverket på detta sätt får man 2 olika listor där varje listgrupp är bunden till en IP-port. Nedan visas 2 godtyckliga IP-listor.

Tjänst A: [160.15.82.20, 161.10.8.221:100]

Tjänst B: [10.1.61.11:150]

Det är även viktigt att veta att om man har definierat en IP-adress till en viss tjänst då man inte kan definiera den för flera tjänster. I exemplet ovan med Tjänst A och Tjänst B så hade därför till exempel IP-adressen 10.1.61.11 enbart kunnat använts för Tjänst B.^[8]

Inom en anslutning kan det skickas flera separata strömmar samtidigt. Dessa strömmar är oberoende av varandra och om ett paket förloras på en ström kommer de andra strömmarna inte bli påverkade. Detta fixar till stor del problemet Head-of-line-blockeringar och kan ge vissa meddelanden högre prioritet än andra (genom att skapa en separat ström bara för dem). ^[7]

SCTP använder ett s.k. 4-vägshandskakning för att skapa en anslutning. Detta används för att skydda en ändpunkt mot bland annat SYN flooding-attacker. Om nod A vill ansluta till nod B skickas först ett INIT-paket som berättar att nod A vill starta en anslutning. Nod B skickar då tillbaka ett INIT-ACK-paket innehållande en kaka. Denna kaka innehåller data för att kunna identifiera anslutningen. Nod A svarar med ett COOKIE-ECHO-paket, innehållande den kaka som skickades till nod A. Detta gör att nod B vet att IP-adressen för nod A existerar och allokerar resurser för anslutningen. Detta ger visserligen en utökad komplexitet i jämförelse med TCP, men innebär att säkerheten ökar. ^[4]

Eftersom SCTP initieras, behövs också en mekanism för att stänga anslutningen. I TCP, när man stänger en anslutning, finns det en fas som kallas för halvstängt, det innebär att när en nod vill stänga en anslutning kan motparten fortfarande ta emot data. Detta används mycket sällan av applikationer och därför har det tagits bort i SCTP. För att stänga en anslutning skickar nod A ett SHUTDOWN-paket. Då avallokerar nod B resurserna för anslutningen och svarar nod A med ett SHUTDOWN-ACK-paket. Nod B vet fortfarande om anslutningen ända tills den får ett svar på sin ack från nod A, ett SHUTDOWN-COMPLETE-paket. ^[4]

• Better Networking with SCTP
• http://www.sigtran.org
• https://web.archive.org/web/20050515080345/http://www.ietf.org/html.charters/sigtran-charter.html
• https://web.archive.org/web/20060206201712/http://www.openss7.org/
• http://www.sctp.de
• SCTP for QualNet network simulator from DEGAS networking group
• The Linux Kernel Stream Control Transmission Protocol (lksctp) project
• https://web.archive.org/web/20070203004241/http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/
• SCTP Sequence Diagram - Setup, IP Address Reconfiguration and Release (PDF)
• Tunneling of SCTP over Single UDP Port
• Open Source / GPL Seagull test tool - with SCTP support
• Parallel computing using the Message-passing Interface (MPI) over SCTP
• SCTPscan: SCTP port scanner and network scanner, GPL

• RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
• RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
• RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
• RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
• RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
• RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change
• RFC 3286 An Introduction to the Stream Control Transmission Protocol
• RFC 3257 Stream Control Transmission Protocol Applicability Statement
• RFC 2960 Stream Control Transmission Protocol