Stream Control Transmission Protocol

Från Wikipedia
Protokollstack för IP-nätverk
Applikation
BitTorrent · DHCP · DNS · FTP · HTTP · IMAP · IRC · NNTP · POP3 · RTP · SIP · SMTP · SNMP · SSH · Telnet · TLS · SSL · TFTP  · BGP
Transport
DCCP · SCTP · TCP · UDP · IL · RUDP
Nätverk
ARP · ICMP · IGMP · IP (IPv4 · IPv6) · RIP · RARP
Länk
ATM · Ethernet · FDDI · ISDN · IS-IS · MPLS · Token Ring · PPP · SLIP · Wi-Fi
Fysiskt
IEEE 802 · ISDN · RS-232 · IrDA · Bluetooth · xDSL
v • r

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.

Historia

1998 bildades arbetsgruppen SIGTRAN med som mål att skapa ett komplement till telefonnätets SS7 för att signalera över Internet. Under deras 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 - System resurser kunde bli reserverade genom s.k. SYN-attack där attackeraren byter ut sin egna IP i IP packet 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 utav User Datagram Protocol eftersom att 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]

Paketstruktur

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 2. 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ål ändpunkten.

En SCTP Common Header innehåller följande:

  1. Ursprungs adressen - Till exempel IP adressen till sin egna enhet
  2. Mål adressen - Till exempel IP adressen till mål enheten.
  3. Verifikations fä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]

SCTP adress

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

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]

Multihoming

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 igen är fullt fungerande.[7] Det går även att balansera nätverks anvä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 3 för Tjänst B. Om man väljer att balansera nätverket på detta sett så får man 2 st olika listor där varje listgrupp är bunden till en IP port. Nedan visas 2 st 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 så kan man inte 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]

Multstreaming

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]

Uppkopplingsfas

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

Nedkopplingsfas

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]

Referenser

  1. ^ Stream Control Transmission Protocol(SCTP) A Reference Guide ISBN 0-201-72186-4 P 10
  2. ^ Steam Control Transmission Protocol(SCTP) A Reference Guide ISBN 0-201-72186-4 p 11
  3. ^ Why is SCTP needed given TCP and UDP are widely available?
  4. ^ [a b c] Better networking with SCTP
  5. ^ Stream Control Transmission Protocol (SCTP) A Reference Guide ISBN 0-201-72186-4 p 36
  6. ^ Stream Control Transmission Protocol (SCTP) A Reference Guide ISBN 0-201-72186-4 P 25
  7. ^ [a b] Stream Control Transmission Protocol, Sida 3: SCTP Advantages: Multi-Homing, Multi-Streaming, and Other Features
  8. ^ Stream Control Transmission Protocol(SCTP) A Reference Guide ISBN 0-201-72186-4 p 23

Externa länkar

RFCs

  • 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
Hämtad från ”https://sv.wikipedia.org/w/index.php?title=Stream_Control_Transmission_Protocol&oldid=25157503”