Stream Control Transmission Protocol: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Markierung: Weiterleitung entfernt
Keine Bearbeitungszusammenfassung
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 3: Zeile 3:
== Beschreibung ==
== Beschreibung ==
[[File:sctpDoD.png|mini|300px]]
[[File:sctpDoD.png|mini|300px]]
Es gehört zur [[Transportschicht]] und setzt auf einem potenziell unzuverlässigen, verbindungslosen [[Paketvermittlung|Paketdienst]] der [[Netzwerkschicht]] auf.
Es gehört zur [[Transportschicht]] und setzt auf einem potenziell unzuverlässigen, verbindungslosen [[Paketvermittlung|Paketdienst]] der [[Netzwerkschicht]] auf


; Das Stream Control Transmission Protocol  
; Das Stream Control Transmission Protocol
* oder SCTP erweitert TCP, will aber gleichzeitig mit weniger Overhead auskommen
* oder SCTP erweitert TCP, will abeár gleichzeitig mit weniger Overhead auskommen
* Anfang der 1980er, in den frühen Jahren des Internets, hatten die Entwickler des Transmission Control Protocol (TCP) Anwendungen wie E-Mail und ftp im Hinterkopf, die zeitunkritisch sind und nur geringe Datenmengen erzeugen.
* Anfang der 1980er, in den frühen Jahren des Internets, hatten die Entwickler des Transmission Control Protocol (TCP) Anwendungen wie E-Mail und ftp im Hinterkopf, die zeitunkritisch sind und nur geringe Datenmengen erzeugen
* Es war für relativ unzuverlässige Leitungen ausgelegt und verfügt deshalb über umfangreiche Methoden zur Fehlersicherung und Flusssteuerung.
* Es war für relativ unzuverlässige Leitungen ausgelegt und verfügt deshalb über umfangreiche Methoden zur Fehlersicherung und Flusssteuerung
* Die strikte Reihenfolgesicherung schafft aber Abhängigkeiten zwischen einzelnen Datenpaketen.
* Die strikte Reihenfolgesicherung schafft aber Abhängigkeiten zwischen einzelnen Datenpaketen


; UDP (User Datagram Protocol)  
; UDP (User Datagram Protocol)
* als nachrichtenorientiertes Protokoll kommt ohne diesen Ballast aus
* als nachrichtenorientiertes Protokoll kommt ohne diesen Ballast aus
* bietet aber auch keine zuverlässige Sicherung gegen Übertragungsfehler.
* bietet aber auch keine zuverlässige Sicherung gegen Übertragungsfehler
* Das wiederholte Senden fehlerhafter Pakete, das Erkennen duplizierter Nachrichten und die Sicherung der Reihenfolge müssen hier höhere Softwareschichten übernehmen.
* Das wiederholte Senden fehlerhafter Pakete, das Erkennen duplizierter Nachrichten und die Sicherung der Reihenfolge müssen hier höhere Softwareschichten übernehmen
* Das verbindungslose UDP eignet sich beispielsweise gut für die Sprachübertragung, in der verbindungsorientierte Protokolle eher kontraproduktiv wären.
* Das verbindungslose UDP eignet sich beispielsweise gut für die Sprachübertragung, in der verbindungsorientierte Protokolle eher kontraproduktiv wären


; Im Jahr 2000 entwarf die IETF auf Betreiben der Telko-Provider ein drittes Layer-4-Protokoll für den TCP/IP-Stack
; Im Jahr 2000 entwarf die IETF auf Betreiben der Telko-Provider ein drittes Layer-4-Protokoll für den TCP/IP-Stack
* Das Stream Control Transmission Protocol (SCTP) nach RFC 4960 soll einerseits große Datenmengen zuverlässig durch komplexe Netze geleiten, andererseits das Senden von Signalisierungsdaten vereinfachen.
* Das Stream Control Transmission Protocol (SCTP) nach RFC 4960 soll einerseits große Datenmengen zuverlässig durch komplexe Netze geleiten, andererseits das Senden von Signalisierungsdaten vereinfachen
* Es arbeitet wie TCP verbindungsorientiert, ersetzt aber die TCP-Connections durch die weiter gefassten SCTP-Assoziationen.
* Es arbeitet wie TCP verbindungsorientiert, ersetzt aber die TCP-Connections durch die weiter gefassten SCTP-Assoziationen


Das '''Stream Control Transmission Protocol''' ('''SCTP''')  
Das '''Stream Control Transmission Protocol''' ('''SCTP''')
* ist ein [[Computernetzwerk]] [[Kommunikationsprotokoll]] in der [[Transportschicht]] der [[Internet-Protokollsuite]]. Ursprünglich für den Transport von Nachrichten des [[Signaling System 7]] (SS7) in der Telekommunikation gedacht, bietet das Protokoll die nachrichtenorientierte Funktion des [[User Datagram Protocol]] (UDP) und gewährleistet gleichzeitig einen zuverlässigen, sequenziellen Transport von Nachrichten mit [[TCP-Überlastkontrolle|Staukontrolle]] wie das [[Transmission Control Protocol]] (TCP). Im Gegensatz zu UDP und TCP unterstützt das Protokoll [[Multihoming]] und redundante Pfade, um die Ausfallsicherheit und Zuverlässigkeit zu erhöhen.
* ist ein [[Computernetzwerk]] [[Kommunikationsprotokoll]] in der [[Transportschicht]] der [[Internet-Protokollsuite]]
* Ursprünglich für den Transport von Nachrichten des [[Signaling System 7]] (SS7) in der Telekommunikation gedacht, bietet das Protokoll die nachrichtenorientierte Funktion des [[User Datagram Protocol]] (UDP) und gewährleistet gleichzeitig einen zuverlässigen, sequenziellen Transport von Nachrichten mit [[TCP-Überlastkontrolle|Staukontrolle]] wie das [[Transmission Control Protocol]] (TCP)
* Im Gegensatz zu UDP und TCP unterstützt das Protokoll [[Multihoming]] und redundante Pfade, um die Ausfallsicherheit und Zuverlässigkeit zu erhöhen


SCTP wurde von der [[Internet Engineering Task Force]] (IETF) in {{IETF RFC|9260}} standardisiert. Die SCTP-Referenzimplementierung wurde als Teil von [[FreeBSD]], Version 7, veröffentlicht und ist seitdem in großem Umfang auf andere Plattformen portiert worden.
SCTP wurde von der [[Internet Engineering Task Force]] (IETF) in {{IETF RFC|9260}} standardisiert
* Die SCTP-Referenzimplementierung wurde als Teil von [[FreeBSD]], Version 7, veröffentlicht und ist seitdem in großem Umfang auf andere Plattformen portiert worden


; Formale Aufsicht
; Formale Aufsicht
Die [[IETF]] Signaling Transport ([[SIGTRAN]]) Arbeitsgruppe definierte das Protokoll (Nummer 132) im Oktober 2000, und die IETF Arbeitsgruppe Transport Area (TSVWG) pflegt es. {{IETF RFC|9260}} definiert das Protokoll. {{IETF RFC|3286}} bietet eine Einführung.
Die [[IETF]] Signaling Transport ([[SIGTRAN]]) Arbeitsgruppe definierte das Protokoll (Nummer 132) im Oktober 2000, und die IETF Arbeitsgruppe Transport Area (TSVWG) pflegt es. {{IETF RFC|9260}} definiert das Protokoll. {{IETF RFC|3286}} bietet eine Einführung


== Eigenschaften und Funktionen ==
== Eigenschaften und Funktionen ==
SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument RFC 2960 veröffentlicht.
SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument RFC 2960 veröffentlicht
* Die Spezifikation wurde im September 2007 durch RFC 4960 und im Juni 2022 durch RFC 9260 ersetzt.
* Die Spezifikation wurde im September 2007 durch RFC 4960 und im Juni 2022 durch RFC 9260 ersetzt
* Eine Einführung findet sich in RFC 3286.
* Eine Einführung findet sich in RFC 3286


Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz SIGTRAN.
Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz SIGTRAN


Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol|TCP]] und [[User Datagram Protocol|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht|Schicht 4 des OSI-Modells]]).
Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol|TCP]] und [[User Datagram Protocol|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht|Schicht 4 des OSI-Modells]])


; SCTP realisiert das Konzept einer ''Association''
; SCTP realisiert das Konzept einer ''Association''
* Hier wird eine Verbindung aufgebaut, in der ''mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend'' (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden.
* Hier wird eine Verbindung aufgebaut, in der ''mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend'' (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden
* Zusätzlich können einzelne, zum Beispiel dringende, [[Datagramm]]e separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“.
* Zusätzlich können einzelne, zum Beispiel dringende, [[Datagramm]]e separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“


; SCTP kennt außerdem ''Multistreaming'' und ''[[Multihoming]]''
; SCTP kennt außerdem ''Multistreaming'' und ''[[Multihoming]]''
* (ein Host mit mehreren gültigen [[IP-Adresse]]n).
* (ein Host mit mehreren gültigen [[IP-Adresse]]n)
* Es werden ''[[Heartbeat (Informatik)|Heartbeats]]'' verwendet, um aktiv auf Verbindungsabriss zu testen.
* Es werden ''[[Heartbeat (Informatik)|Heartbeats]]'' verwendet, um aktiv auf Verbindungsabriss zu testen


; Anders als TCP zeigt sich SCTP resistent gegen [[SYN-Flood]]ing
; Anders als TCP zeigt sich SCTP resistent gegen [[SYN-Flood]]ing
* , eine [[Denial of Service|Denial-of-Service]]-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden.
* , eine [[Denial of Service|Denial-of-Service]]-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden
* Dazu verwendet es einen sogenannten [[Vier-Wege-Handshake]].
* Dazu verwendet es einen sogenannten [[Vier-Wege-Handshake]]
* Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines [[HTTP-Cookie|Cookie]]s (INIT-ACK-Paket) an den Client.
* Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines [[HTTP-Cookie|Cookie]]s (INIT-ACK-Paket) an den Client
* Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket).
* Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket)
* Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe [[SYN-Cookies]].
* Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe [[SYN-Cookies]]


Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten ([[Signalling System 7|SS7]]) aus Telefonnetzen auch über [[Internet Protocol|IP]]-Netzwerke übertragen zu können.
Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten ([[Signalling System 7|SS7]]) aus Telefonnetzen auch über [[Internet Protocol|IP]]-Netzwerke übertragen zu können
* Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund.
* Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund
* SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint.
* SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint
* Eine wichtige, auf SCTP aufbauende Anwendung ist [[Reliable Server Pooling]] (RSerPool).
* Eine wichtige, auf SCTP aufbauende Anwendung ist [[Reliable Server Pooling]] (RSerPool)


SCTP verwendet für ''[[Flusskontrolle|Fluss]]- und [[Überlastkontrolle]]'' ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral.
SCTP verwendet für ''[[Flusskontrolle|Fluss]]- und [[Überlastkontrolle]]'' ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral




; TCP, UDP und SCTP im Vergleich
; TCP, UDP und SCTP im Vergleich
{| class="wikitable sortable options"
{| class="wikitable big options"
|-
|-
! Funktion !! TCP !! UDP !! SCTP
! Funktion !! TCP !! UDP !! SCTP
Zeile 84: Zeile 87:


; Dabei lassen sich jedem Endpunkt mehrere IP-Adressen zuordnen, was man als Multihoming bezeichnet
; Dabei lassen sich jedem Endpunkt mehrere IP-Adressen zuordnen, was man als Multihoming bezeichnet
* Das entkoppelt die logische Verbindung, die Assoziation, noch weiter von den physischen Pfaden.
* Das entkoppelt die logische Verbindung, die Assoziation, noch weiter von den physischen Pfaden
* Durch die Nutzung mehrerer Übertragungswege und Provider lässt sich die Verfügbarkeit erhöhen.
* Durch die Nutzung mehrerer Übertragungswege und Provider lässt sich die Verfügbarkeit erhöhen
* Voraussetzung ist allerdings, dass Pfade nicht über dieselben Netzknoten führen.
* Voraussetzung ist allerdings, dass Pfade nicht über dieselben Netzknoten führen


;Nicht aktive Pfade werden laufend auf Verfügbarkeit überprüft
;Nicht aktive Pfade werden laufend auf Verfügbarkeit überprüft
* Ist der Backup-Pfad nicht erreichbar, wird er gestrichen.
* Ist der Backup-Pfad nicht erreichbar, wird er gestrichen
* Damit ist im Fehlerfall ein schnelles Umschalten ohne Routing möglich.
* Damit ist im Fehlerfall ein schnelles Umschalten ohne Routing möglich
* Ein Load Sharing über mehrere Pfade wie beim Multipath TCP (MPTCP) war ursprünglich nicht vorgesehen.
* Ein Load Sharing über mehrere Pfade wie beim Multipath TCP (MPTCP) war ursprünglich nicht vorgesehen
* Das liefert der Entwurf von IEEE und IETF zum Concurrent Multipath Transfer (CMT-SCTP) nach.
* Das liefert der Entwurf von IEEE und IETF zum Concurrent Multipath Transfer (CMT-SCTP) nach


; SCTP nutzt wie TCP Sequenznummern für jede Nachricht, deren Empfang die Gegenstelle bestätigt (Selective Acknowledgement)
; SCTP nutzt wie TCP Sequenznummern für jede Nachricht, deren Empfang die Gegenstelle bestätigt (Selective Acknowledgement)
* Statt eines Byte-Stroms überträgt SCTP Nachrichtenblöcke, sogenannte Messages, die mehr Spielraum bieten: Einerseits lassen sich große Nachrichten über mehrere Pakete verteilen, wenn sie die maximale Paketgröße (Path MTU) überschreiten.
* Statt eines Byte-Stroms überträgt SCTP Nachrichtenblöcke, sogenannte Messages, die mehr Spielraum bieten: Einerseits lassen sich große Nachrichten über mehrere Pakete verteilen, wenn sie die maximale Paketgröße (Path MTU) überschreiten
* Andererseits kann SCTP mehrere kleine Nachrichten in einem Paket zusammenfassen (Multiplexing).
* Andererseits kann SCTP mehrere kleine Nachrichten in einem Paket zusammenfassen (Multiplexing)


; Damit eignet es sich gleichermaßen als Signalisierungsprotokoll und für die Übertragung von Datenströmen
; Damit eignet es sich gleichermaßen als Signalisierungsprotokoll und für die Übertragung von Datenströmen
* Hierzu fasst es Pakete zu Streams zusammen und erlaubt die parallele Übertragung in mehreren Streams.
* Hierzu fasst es Pakete zu Streams zusammen und erlaubt die parallele Übertragung in mehreren Streams
* Während TCP alle Daten in die gleiche Reihenfolge presst, in der sie gesendet wurden, lässt SCTP pro Stream die Festlegung zu, ob eine Sicherung der Reihenfolge vorgenommen wird oder nicht.
* Während TCP alle Daten in die gleiche Reihenfolge presst, in der sie gesendet wurden, lässt SCTP pro Stream die Festlegung zu, ob eine Sicherung der Reihenfolge vorgenommen wird oder nicht
* Das verhindert, dass verloren gegangene Daten eines Streams den Fluss der anderen Streams behindern, ein als Head-of-Line Blocking bezeichnetes Phänomen.
* Das verhindert, dass verloren gegangene Daten eines Streams den Fluss der anderen Streams behindern, ein als Head-of-Line Blocking bezeichnetes Phänomen
* Mit der Erweiterung SCTP-PR (Partial Reliability) ist es zudem möglich, ungesicherte Streams zu definieren, bei denen verlorene Pakete nicht erneut gesendet werden.
* Mit der Erweiterung SCTP-PR (Partial Reliability) ist es zudem möglich, ungesicherte Streams zu definieren, bei denen verlorene Pakete nicht erneut gesendet werden
* Anders als bei UDP greift aber hier die Überlaststeuerung.
* Anders als bei UDP greift aber hier die Überlaststeuerung


; Durch die Aufteilung der Daten in mehrere Streams mit unterschiedlichen Eigenschaften lassen sich gleichzeitig UDP- und TCP-ähnliche Verbindungen zwischen zwei Endpunkten aufrechterhalten
; Durch die Aufteilung der Daten in mehrere Streams mit unterschiedlichen Eigenschaften lassen sich gleichzeitig UDP- und TCP-ähnliche Verbindungen zwischen zwei Endpunkten aufrechterhalten
* Zwar ließen sich auch getrennte TCP- und UDP-Verbindungen aufbauen, was aber mit einem größeren Overhead verbunden ist.
* Zwar ließen sich auch getrennte TCP- und UDP-Verbindungen aufbauen, was aber mit einem größeren Overhead verbunden ist
* Die Stärke von SCTP liegt gerade in der Verwaltung mehrerer paralleler Streams. Überlaststeuerung, Bandbreitenreservierung und Multihoming gelten jeweils für die gesamte Assoziation, allerdings separat für jede IP-Adresse.
* Die Stärke von SCTP liegt gerade in der Verwaltung mehrerer paralleler Streams. Überlaststeuerung, Bandbreitenreservierung und Multihoming gelten jeweils für die gesamte Assoziation, allerdings separat für jede IP-Adresse
* Einen einzelnen Stream überträgt TCP schneller, weshalb es seine Bedeutung weiterhin behält.
* Einen einzelnen Stream überträgt TCP schneller, weshalb es seine Bedeutung weiterhin behält


; SCTP werkelt bereits unauffällig in vielen Netzwerkanwendungen
; SCTP werkelt bereits unauffällig in vielen Netzwerkanwendungen
* In den Blickpunkt rückt es gegenwärtig wieder durch die Ausbreitung von IP-Netzen in Bereiche, die zuvor InfiniBand oder Fibre Channel vorbehalten waren, etwa durch iWARP (Internet Wide Area RDMA Protocol), das Direktspeicherzugriffe über IP erlaubt.
* In den Blickpunkt rückt es gegenwärtig wieder durch die Ausbreitung von IP-Netzen in Bereiche, die zuvor InfiniBand oder Fibre Channel vorbehalten waren, etwa durch iWARP (Internet Wide Area RDMA Protocol), das Direktspeicherzugriffe über IP erlaubt


=== Merkmale ===
=== Merkmale ===
Zeile 117: Zeile 120:
* Zuverlässige Übertragung sowohl von geordneten als auch von ungeordneten Datenströmen
* Zuverlässige Übertragung sowohl von geordneten als auch von ungeordneten Datenströmen
* Multihoming-Unterstützung, bei der ein oder beide Endpunkte einer Verbindung aus mehr als einer IP-Adresse bestehen können, was ein transparentes Failover zwischen redundanten Netzwerkpfaden ermöglicht
* Multihoming-Unterstützung, bei der ein oder beide Endpunkte einer Verbindung aus mehr als einer IP-Adresse bestehen können, was ein transparentes Failover zwischen redundanten Netzwerkpfaden ermöglicht
* Zustellung von Datenpaketen innerhalb unabhängiger Ströme eliminiert unnötiges [[Head-of-Line-Blocking]], im Gegensatz zur TCP-Byte-Stream-Zustellung.
* Zustellung von Datenpaketen innerhalb unabhängiger Ströme eliminiert unnötiges [[Head-of-Line-Blocking]], im Gegensatz zur TCP-Byte-Stream-Zustellung
* Explizite partielle Zuverlässigkeit
* Explizite partielle Zuverlässigkeit
* Pfadauswahl und -überwachung zur Auswahl eines primären Datenübertragungspfads und zur Prüfung der Konnektivität des Übertragungspfads
* Pfadauswahl und -überwachung zur Auswahl eines primären Datenübertragungspfads und zur Prüfung der Konnektivität des Übertragungspfads
* Validierungs- und Bestätigungsmechanismen zum Schutz vor Flooding-Angriffen und zur Benachrichtigung über duplizierte oder fehlende Datenpakete.
* Validierungs- und Bestätigungsmechanismen zum Schutz vor Flooding-Angriffen und zur Benachrichtigung über duplizierte oder fehlende Datenpakete
* Verbesserte Fehlererkennung, geeignet für [[Jumbo Frames|Ethernet Jumbo Frames]]
* Verbesserte Fehlererkennung, geeignet für [[Jumbo Frames|Ethernet Jumbo Frames]]


Die Entwickler von SCTP hatten es ursprünglich für die Übertragung von Telefongesprächen (d. h. Signalsystem 7) über das Internetprotokoll vorgesehen, mit dem Ziel, einige der Zuverlässigkeitsmerkmale des SS7-Signalisierungsnetzes in IP zu duplizieren. Diese Bemühungen der IETF sind als [[SIGTRAN]] bekannt. In der Zwischenzeit wurden andere Anwendungen vorgeschlagen, zum Beispiel das [[Diameter (Protokoll)|Diameter]]-Protokoll und [[Reliable Server Pooling]] (RSerPool).
Die Entwickler von SCTP hatten es ursprünglich für die Übertragung von Telefongesprächen (d. h. Signalsystem 7) über das Internetprotokoll vorgesehen, mit dem Ziel, einige der Zuverlässigkeitsmerkmale des SS7-Signalisierungsnetzes in IP zu duplizieren
* Diese Bemühungen der IETF sind als [[SIGTRAN]] bekannt
* In der Zwischenzeit wurden andere Anwendungen vorgeschlagen, etwa das [[Diameter (Protokoll)|Diameter]]-Protokoll und [[Reliable Server Pooling]] (RSerPool)


==Message-based Multi-Streaming==
==Message-based Multi-Streaming==
SCTP-Anwendungen übermitteln Daten zur Übertragung in Nachrichten (Byte-Gruppen) an die SCTP-Transportschicht. SCTP unterteilt Nachrichten und Kontrollinformationen in separate ''Chunks'' (Daten- und Kontrollchunks), die jeweils durch einen ''Chunk-Header'' gekennzeichnet sind. Das Protokoll kann eine Nachricht in mehrere Datenchunks aufteilen, aber jeder Datenchunk enthält nur die Daten einer einzigen Benutzernachricht. SCTP bündelt die Chunks zu SCTP-Paketen. Das SCTP-Paket, das an das [[Internetprotokoll]] übergeben wird, besteht aus einem Paketkopf, SCTP-Kontrollbrocken (sofern erforderlich), gefolgt von SCTP-Datenbrocken (sofern verfügbar).
SCTP-Anwendungen übermitteln Daten zur Übertragung in Nachrichten (Byte-Gruppen) an die SCTP-Transportschicht
* SCTP unterteilt Nachrichten und Kontrollinformationen in separate ''Chunks'' (Daten- und Kontrollchunks), die jeweils durch einen ''Chunk-Header'' gekennzeichnet sind
* Das Protokoll kann eine Nachricht in mehrere Datenchunks aufteilen, aber jeder Datenchunk enthält nur die Daten einer einzigen Benutzernachricht
* SCTP bündelt die Chunks zu SCTP-Paketen
* Das SCTP-Paket, das an das [[Internetprotokoll]] übergeben wird, besteht aus einem Paketkopf, SCTP-Kontrollbrocken (sofern erforderlich), gefolgt von SCTP-Datenbrocken (sofern verfügbar)


SCTP kann als nachrichtenorientiert bezeichnet werden, d. h. es transportiert eine Folge von Nachrichten (jeweils eine Gruppe von Bytes) und nicht wie TCP einen ununterbrochenen Strom von Bytes. Wie bei UDP sendet ein Absender bei SCTP eine Nachricht in einem Vorgang, und genau diese Nachricht wird in einem Vorgang an den empfangenden Anwendungsprozess weitergeleitet. Im Gegensatz dazu ist TCP ein strömungsorientiertes Protokoll, das Ströme von Bytes zuverlässig und in der richtigen Reihenfolge transportiert. Bei TCP weiß der Empfänger jedoch nicht, wie oft die Senderanwendung den TCP-Transport aufgerufen hat, um ihm die zu sendenden Byte-Gruppen zu übergeben. Beim Absender fügt TCP einfach weitere Bytes an eine Warteschlange von Bytes an, die darauf warten, über das Netz versendet zu werden, anstatt eine Warteschlange von einzelnen separaten ausgehenden Nachrichten zu führen, die als solche erhalten werden müssen.
SCTP kann als nachrichtenorientiert bezeichnet werden, d. h. es transportiert eine Folge von Nachrichten (jeweils eine Gruppe von Bytes) und nicht wie TCP einen ununterbrochenen Strom von Bytes
* Wie bei UDP sendet ein Absender bei SCTP eine Nachricht in einem Vorgang, und genau diese Nachricht wird in einem Vorgang an den empfangenden Anwendungsprozess weitergeleitet
* Im Gegensatz dazu ist TCP ein strömungsorientiertes Protokoll, das Ströme von Bytes zuverlässig und in der richtigen Reihenfolge transportiert
* Bei TCP weiß der Empfänger jedoch nicht, wie oft die Senderanwendung den TCP-Transport aufgerufen hat, um ihm die zu sendenden Byte-Gruppen zu übergeben
* Beim Absender fügt TCP einfach weitere Bytes an eine Warteschlange von Bytes an, die darauf warten, über das Netz versendet zu werden, anstatt eine Warteschlange von einzelnen separaten ausgehenden Nachrichten zu führen, die als solche erhalten werden müssen


Der Begriff ''Multi-Streaming'' bezieht sich auf die Fähigkeit von SCTP, mehrere unabhängige Ströme von Datenpaketen parallel zu übertragen, z. B.  Bilder einer [[Webseite]] gleichzeitig mit dem Text der Webseite. Im Wesentlichen geht es darum, mehrere Verbindungen in einer einzigen SCTP-Verbindung zu bündeln und mit Nachrichten (oder Chunks) statt mit Bytes zu arbeiten.
Der Begriff ''Multi-Streaming'' bezieht sich auf die Fähigkeit von SCTP, mehrere unabhängige Ströme von Datenpaketen parallel zu übertragen, z. B.  Bilder einer [[Webseite]] gleichzeitig mit dem Text der Webseite
* Im Wesentlichen geht es darum, mehrere Verbindungen in einer einzigen SCTP-Verbindung zu bündeln und mit Nachrichten (oder Chunks) statt mit Bytes zu arbeiten


TCP bewahrt die Byte-Reihenfolge im Datenstrom, indem es jedem [[TCP-Segment|Segment]] eine Byte-Sequenznummer beifügt. SCTP hingegen weist jeder ''Nachricht'', die in einem Datenstrom gesendet wird, eine Sequenznummer oder eine Message-ID zu. Die [[SCTP-Paketstruktur#DATA chunk|DATA chunk]] verwendet eine Sequenznummer für geordnete Nachrichten, die [[SCTP-Paketstruktur#I-DATA chunk|I-DATA chunk]], die einige Probleme mit dem ursprünglichen DATA chunk löst, verwendet eine Message-ID für alle Nachrichten. Dies ermöglicht eine unabhängige Anordnung von Nachrichten in verschiedenen Streams. Die Reihenfolge der Nachrichten ist bei SCTP jedoch optional; eine empfangende Anwendung kann sich dafür entscheiden, die Nachrichten in der Reihenfolge des Empfangs und nicht in der Reihenfolge des Versands zu verarbeiten.
TCP bewahrt die Byte-Reihenfolge im Datenstrom, indem es jedem [[TCP-Segment|Segment]] eine Byte-Sequenznummer beifügt
* SCTP hingegen weist jeder ''Nachricht'', die in einem Datenstrom gesendet wird, eine Sequenznummer oder eine Message-ID zu
* Die [[SCTP-Paketstruktur#DATA chunk|DATA chunk]] verwendet eine Sequenznummer für geordnete Nachrichten, die [[SCTP-Paketstruktur#I-DATA chunk|I-DATA chunk]], die einige Probleme mit dem ursprünglichen DATA chunk löst, verwendet eine Message-ID für alle Nachrichten
* Dies ermöglicht eine unabhängige Anordnung von Nachrichten in verschiedenen Streams
* Die Reihenfolge der Nachrichten ist bei SCTP jedoch optional; eine empfangende Anwendung kann sich dafür entscheiden, die Nachrichten in der Reihenfolge des Empfangs und nicht in der Reihenfolge des Versands zu verarbeiten


==Motivation und Einführung==
==Motivation und Einführung==
TCP war das wichtigste Mittel zur zuverlässigen Datenübertragung im Internet. Allerdings hat TCP bei verschiedenen Anwendungen zu Einschränkungen geführt. Aus {{IETF RFC|4960}}:
TCP war das wichtigste Mittel zur zuverlässigen Datenübertragung im Internet
* TCP bietet sowohl eine zuverlässige Datenübertragung als auch eine strikte Reihenfolge der Datenübermittlung. Einige Anwendungen benötigen eine zuverlässige Übertragung ohne Einhaltung der Reihenfolge, während andere mit einer teilweisen Reihenfolge der Daten zufrieden wären. In beiden Fällen verursacht die Head-of-Line-Blocking-Eigenschaft von TCP unnötige Verzögerungen.
* Allerdings hat TCP bei verschiedenen Anwendungen zu Einschränkungen geführt
* Für Anwendungen, die verschiedene Datensätze oder Nachrichten austauschen, erfordert die stromorientierte Natur von TCP die Hinzufügung expliziter Markierungen oder anderer Kodierungen, um die einzelnen Datensätze abzugrenzen.
* Aus {{IETF RFC|4960}}:
* Um zu vermeiden, dass viele kleine IP-Pakete gesendet werden, wo ein einziges größeres Paket ausgereicht hätte, kann die TCP-Implementierung die Übertragung von Daten verzögern, während sie auf möglicherweise weitere Daten wartet, die sich in der Warteschlange der Anwendung befinden ([[Nagle-Algorithmus]]). Wenn eine solche kleine Verzögerung unerwünscht ist, muss die Anwendung von Fall zu Fall ausdrücklich eine unverzögerte Übertragung mit Hilfe der [http://seclists.org/webappsec/2005/q3/0351.html push facility] anfordern (d. h. durch Setzen des PSH-Flags im TCP-Paketkopf). Bei SCTP hingegen kann die unverzögerte Übertragung als Standard für eine Assoziation konfiguriert werden, wodurch unerwünschte Verzögerungen vermieden werden, allerdings auf Kosten eines höheren Übertragungs-Overheads.
* TCP bietet sowohl eine zuverlässige Datenübertragung als auch eine strikte Reihenfolge der Datenübermittlung
* Die begrenzte Reichweite{{vague|date=December 2017}} von TCP-Sockets erschwert die Aufgabe, hochverfügbare Datenübertragungen mit multihomed Hosts zu ermöglichen.
* Einige Anwendungen benötigen eine zuverlässige Übertragung ohne Einhaltung der Reihenfolge, während andere mit einer teilweisen Reihenfolge der Daten zufrieden wären
* TCP ist relativ anfällig für Denial-of-Service-Angriffe, wie z. B.  [[SYN-Angriff]]e.
* In beiden Fällen verursacht die Head-of-Line-Blocking-Eigenschaft von TCP unnötige Verzögerungen
* Für Anwendungen, die verschiedene Datensätze oder Nachrichten austauschen, erfordert die stromorientierte Natur von TCP die Hinzufügung expliziter Markierungen oder anderer Kodierungen, um die einzelnen Datensätze abzugrenzen
* Um zu vermeiden, dass viele kleine IP-Pakete gesendet werden, wo ein einziges größeres Paket ausgereicht hätte, kann die TCP-Implementierung die Übertragung von Daten verzögern, während sie auf möglicherweise weitere Daten wartet, die sich in der Warteschlange der Anwendung befinden ([[Nagle-Algorithmus]])
* Wenn eine solche kleine Verzögerung unerwünscht ist, muss die Anwendung von Fall zu Fall ausdrücklich eine unverzögerte Übertragung mit Hilfe der [http://seclists.org/webappsec/2005/q3/0351.html push facility] anfordern (d. h. durch Setzen des PSH-Flags im TCP-Paketkopf)
* Bei SCTP hingegen kann die unverzögerte Übertragung als Standard für eine Assoziation konfiguriert werden, wodurch unerwünschte Verzögerungen vermieden werden, allerdings auf Kosten eines höheren Übertragungs-Overheads
* Die begrenzte Reichweite von TCP-Sockets erschwert die Aufgabe, hochverfügbare Datenübertragungen mit multihomed Hosts zu ermöglichen
* TCP ist relativ anfällig für Denial-of-Service-Angriffe, wie z. B. [[SYN-Angriff]]e


Die Akzeptanz wurde durch mangelndes Bewusstsein, fehlende Implementierungen (insbesondere in Microsoft Windows), fehlende Anwendungsunterstützung und fehlende Netzwerkunterstützung gebremst.
Die Akzeptanz wurde durch mangelndes Bewusstsein, fehlende Implementierungen (insbesondere in Microsoft Windows), fehlende Anwendungsunterstützung und fehlende Netzwerkunterstützung gebremst


== Multihoming ==
== Multihoming ==
Zeile 156: Zeile 180:
}}
}}


SCTP bietet redundante Pfade, um die Zuverlässigkeit zu erhöhen.
SCTP bietet redundante Pfade, um die Zuverlässigkeit zu erhöhen


Jeder SCTP-Endpunkt muss die Erreichbarkeit der primären und redundanten Adressen des entfernten Endpunkts mit Hilfe eines [[Heartbeat (computing)|heartbeat]] überprüfen. Jeder SCTP-Endpunkt muss die Heartbeats, die er vom entfernten Endpunkt empfängt, quittieren.
Jeder SCTP-Endpunkt muss die Erreichbarkeit der primären und redundanten Adressen des entfernten Endpunkts mit Hilfe eines [[Heartbeat (computing)|heartbeat]] überprüfen
* Jeder SCTP-Endpunkt muss die Heartbeats, die er vom entfernten Endpunkt empfängt, quittieren


Wenn SCTP eine Nachricht an eine entfernte Adresse sendet, wird die Quellschnittstelle nur durch die Routing-Tabelle des Hosts (und nicht durch SCTP) bestimmt.
Wenn SCTP eine Nachricht an eine entfernte Adresse sendet, wird die Quellschnittstelle nur durch die Routing-Tabelle des Hosts (und nicht durch SCTP) bestimmt


Beim asymmetrischen Multihoming unterstützt einer der beiden Endpunkte kein Multihoming.
Beim asymmetrischen Multihoming unterstützt einer der beiden Endpunkte kein Multihoming


Bei lokalem Multihoming und entferntem Single-Homing schlägt die SCTP-Zuordnung fehl, wenn die entfernte primäre Adresse nicht erreichbar ist, selbst wenn ein alternativer Pfad möglich ist.
Bei lokalem Multihoming und entferntem Single-Homing schlägt die SCTP-Zuordnung fehl, wenn die entfernte primäre Adresse nicht erreichbar ist, selbst wenn ein alternativer Pfad möglich ist


== Paketstruktur ==
== Paketstruktur ==
{{Main|SCTP packet structure}}
{{Main|SCTP packet structure}}
; Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten:
; Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten:
# Dem ''common header'', der die ersten 12 Bytes einnimmt und blau hervorgehoben ist.
# Dem ''common header'', der die ersten 12 Bytes einnimmt und blau hervorgehoben ist
# Die ''data chunks'', die den restlichen Teil des Pakets einnehmen. Der erste Chunk ist grün hervorgehoben, und der letzte von ''N'' Chunks (Chunk N) ist rot hervorgehoben.
# Die ''data chunks'', die den restlichen Teil des Pakets einnehmen
* Der erste Chunk ist grün hervorgehoben, und der letzte von ''N'' Chunks (Chunk N) ist rot hervorgehoben


{| class="wikitable" style="text-align:center; white-space:nowrap; white-space:nowrap;"
{| class="wikitable" style="text-align:center; white-space:nowrap; white-space:nowrap;"
Zeile 210: Zeile 236:
|}
|}


Jeder Chunk beginnt mit einem Ein-Byte-Typ-Identifikator, wobei 15 Chunk-Typen durch {{IETF RFC|9260}} und mindestens 5 weitere durch zusätzliche RFCs definiert sind. Siehe [[SCTP-Paketstruktur]] für weitere Einzelheiten. Acht Flaggenbits, ein Zwei-Byte-Längenfeld und die Daten bilden den Rest des Chunks. Wenn der Chunk kein Vielfaches von 4 Bytes ist (d.h. die Länge ist kein Vielfaches von 4), wird er mit Nullen aufgefüllt, die nicht in die Chunk-Länge eingerechnet werden. Das Zwei-Byte-Längenfeld begrenzt jedes Chunk auf eine Länge von 65.535 Byte (einschließlich der Felder Typ, Flags und Länge).
Jeder Chunk beginnt mit einem Ein-Byte-Typ-Identifikator, wobei 15 Chunk-Typen durch {{IETF RFC|9260}} und mindestens 5 weitere durch zusätzliche RFCs definiert sind
* Siehe [[SCTP-Paketstruktur]] für weitere Einzelheiten
* Acht Flaggenbits, ein Zwei-Byte-Längenfeld und die Daten bilden den Rest des Chunks
* Wenn der Chunk kein Vielfaches von 4 Bytes ist (d.h
* die Länge ist kein Vielfaches von 4), wird er mit Nullen aufgefüllt, die nicht in die Chunk-Länge eingerechnet werden
* Das Zwei-Byte-Längenfeld begrenzt jedes Chunk auf eine Länge von 65.535 Byte (einschließlich der Felder Typ, Flags und Länge)


==Sicherheit==
==Sicherheit==
Obwohl die Verschlüsselung nicht Teil des ursprünglichen SCTP-Entwurfs war, wurde SCTP mit Merkmalen zur Verbesserung der Sicherheit entwickelt, z. B.  4-Wege-[[Handshake (Computing)|Handshake]] (im Vergleich zu [[Drei-Wege-Handshake#Verbindungsaufbau|TCP 3-Wege-Handshake]]) zum Schutz vor [[SYN-Flood]]ing-Angriffen und große "Cookies" zur Überprüfung der Verbindung und Authentizität.
Obwohl die Verschlüsselung nicht Teil des ursprünglichen SCTP-Entwurfs war, wurde SCTP mit Merkmalen zur Verbesserung der Sicherheit entwickelt, z. B.  4-Wege-[[Handshake (Computing)|Handshake]] (im Vergleich zu [[Drei-Wege-Handshake#Verbindungsaufbau|TCP 3-Wege-Handshake]]) zum Schutz vor [[SYN-Flood]]ing-Angriffen und große "Cookies" zur Überprüfung der Verbindung und Authentizität


Auch die Zuverlässigkeit war ein wichtiger Bestandteil des Sicherheitsdesigns von SCTP. Multihoming ermöglicht es, eine Verbindung auch dann aufrechtzuerhalten, wenn einige Routen und Schnittstellen ausgefallen sind. Dies ist für [[SIGTRAN]] von besonderer Bedeutung, da es [[Signaling System 7|SS7]] über ein IP-Netz unter Verwendung von SCTP überträgt und eine hohe Ausfallsicherheit bei Verbindungsausfällen erfordert, um den Telekommunikationsdienst auch bei Netzanomalien aufrechtzuerhalten.
Auch die Zuverlässigkeit war ein wichtiger Bestandteil des Sicherheitsdesigns von SCTP
* Multihoming ermöglicht es, eine Verbindung auch dann aufrechtzuerhalten, wenn einige Routen und Schnittstellen ausgefallen sind
* Dies ist für [[SIGTRAN]] von besonderer Bedeutung, da es [[Signaling System 7|SS7]] über ein IP-Netz unter Verwendung von SCTP überträgt und eine hohe Ausfallsicherheit bei Verbindungsausfällen erfordert, um den Telekommunikationsdienst auch bei Netzanomalien aufrechtzuerhalten


SCTP ist manchmal ein guter Kandidat für [[TCP/IP Stack Fingerprinting|Fingerprinting]]. Einige Betriebssysteme werden mit aktivierter SCTP-Unterstützung ausgeliefert, und da SCTP nicht so bekannt ist wie TCP oder UDP, wird es manchmal in Firewall- und Intrusion-Detection-Konfigurationen übersehen, so dass es oft einen Sondierungsverkehr zulässt.
SCTP ist manchmal ein guter Kandidat für [[TCP/IP Stack Fingerprinting|Fingerprinting]]
* Einige Betriebssysteme werden mit aktivierter SCTP-Unterstützung ausgeliefert, und da SCTP nicht so bekannt ist wie TCP oder UDP, wird es manchmal in Firewall- und Intrusion-Detection-Konfigurationen übersehen, so dass es oft einen Sondierungsverkehr zulässt


==Implementations==
==Implementations==
The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux.
The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux


The following [[operating system]]s implement SCTP:
The following [[operating system]]s implement SCTP:
Zeile 253: Zeile 287:


== Tunneling über UDP ==
== Tunneling über UDP ==
In Ermangelung einer nativen SCTP-Unterstützung in Betriebssystemen ist es möglich, [[Tunneling-Protokoll|Tunnel]] SCTP über UDP, sowie TCP-API-Aufrufe auf SCTP-Aufrufe abzubilden, damit bestehende Anwendungen SCTP ohne Änderungen nutzen können.
In Ermangelung einer nativen SCTP-Unterstützung in Betriebssystemen ist es möglich, [[Tunneling-Protokoll|Tunnel]] SCTP über UDP, sowie TCP-API-Aufrufe auf SCTP-Aufrufe abzubilden, damit bestehende Anwendungen SCTP ohne Änderungen nutzen können


== Alternativen ==
== Alternativen ==
[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht.
[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht
* Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie|kryptographischen]] Absicherung der Kommunikation integriert wurde.
* Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie|kryptographischen]] Absicherung der Kommunikation integriert wurde
* QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet.
* QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet
* QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.
* QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt


<noinclude>
<noinclude>
Zeile 268: Zeile 302:
{{Special:PrefixIndex/SCTP}}
{{Special:PrefixIndex/SCTP}}


* {{section link|Transport layer|Comparison of transport layer protocols}}
* Transport layer|Comparison of transport layer protocols
* [[Session Initiation Protocol]] (SIP) – which may initiate multiple streams over SCTP, TCP, or UDP
* [[Session Initiation Protocol]] (SIP) – which may initiate multiple streams over SCTP, TCP, or UDP
* [[Multipath TCP]] – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
* [[Multipath TCP]] – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
* [[Happy Eyeballs]] – originally designed for efficient selection of IPv4 or IPv6 for a connection; could also be adapted to select from different transport protocols such as TCP and SCTP
* [[Happy Eyeballs]] – originally designed for efficient selection of IPv4 or IPv6 for a connection; could also be adapted to select from different transport protocols such as TCP and SCTP


==== Sicherheit ====
==== Dokumentation ====
==== Dokumentation ====
===== RFC =====
===== RFC =====
{| class="wikitable sortable options"
{| class="wikitable sortable options big"
|-
|-
! RFC !! Titel !! Datum
! RFC !! Titel
|-
|-
| 2960 || Stream Control Transmission Protocol || 2000
| [https://www.rfc-editor.org/info/rfc2960 2960] || Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960)
|-
|-
| 4960 || Stream Control Transmission Protocol || 2007
| [https://www.rfc-editor.org/info/rfc3257 3257] || Stream Control Transmission Protocol Applicability Statement
|-
|-
| 6951 || UDP Encapsulation of Stream Control Transmission Protocol || 2013
| [https://www.rfc-editor.org/info/rfc3286 3286] || An Introduction to the Stream Control Transmission Protocol
|-
|-
| 9260 || Stream Control Transmission Protocol || 2022
| [https://www.rfc-editor.org/info/rfc3309 3309] || Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960)
|-
|-
|9260 || Stream Control Transmission Protocol ||
| [https://www.rfc-editor.org/info/rfc3436 3436] || Transport Layer Security over Stream Control Transmission Protocol
|-
|-
|8540 || Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260) ||
| [https://www.rfc-editor.org/info/rfc3554 3554] || On the Use of Stream Control Transmission Protocol (SCTP) with [[IPsec]]
|-
|-
|7829 || SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol ||
| [https://www.rfc-editor.org/info/rfc3758 3758] || Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
|-
|-
|7765 || TCP and Stream Control Transmission Protocol (SCTP) RTO Restart ||
| [https://www.rfc-editor.org/info/rfc3873 3873] || Stream Control Transmission Protocol (SCTP) [[Management Information Base]] (MIB)
|-
|-
|7496 || Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension ||
| [https://www.rfc-editor.org/info/rfc4460 4460] || Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260)
|-
|-
|7053 || SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260) ||
| [https://www.rfc-editor.org/info/rfc4820 4820] || Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
|-
|-
|6951 || UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication ||
| [https://www.rfc-editor.org/info/rfc4895 4895] || Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
|-
|-
|6525 || Stream Control Transmission Protocol (SCTP) Stream Reconfiguration ||
| [https://www.rfc-editor.org/info/rfc4960 4960] || Stream Control Transmission Protocol
|-
|-
|6458 || Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) ||
| [https://www.rfc-editor.org/info/rfc4960 4960] || Stream Control Transmission Protocol (obsoleted by RFC 9260)
|-
|-
|6096 || Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260) ||
| [https://www.rfc-editor.org/info/rfc5043 5043] || Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
|-
|-
|5062 || Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures ||
| [https://www.rfc-editor.org/info/rfc5061 5061] || Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
|-
|-
|5061 || Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration ||
| [https://www.rfc-editor.org/info/rfc5062 5062] || Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
|-
|-
|5043 || Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation ||
| [https://www.rfc-editor.org/info/rfc6096 6096] || Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260)
|-
|-
|4960 || Stream Control Transmission Protocol (obsoleted by RFC 9260) ||
| [https://www.rfc-editor.org/info/rfc6458 6458] || Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
|-
|-
|4895 || Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) ||
| [https://www.rfc-editor.org/info/rfc6525 6525] || Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
|-
|-
|4820 || Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) ||
| [https://www.rfc-editor.org/info/rfc6951 6951] || UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
|-
|-
|4460 || Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260) ||
| [https://www.rfc-editor.org/info/rfc7053 7053] || SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260)
|-
|-
|3873 || Stream Control Transmission Protocol (SCTP) [[Management Information Base]] (MIB) ||
| [https://www.rfc-editor.org/info/rfc7496 7496] || Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
|-
|-
|3758 || Stream Control Transmission Protocol (SCTP) Partial Reliability Extension ||
| [https://www.rfc-editor.org/info/rfc7765 7765] || TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
|-
|-
|3554 || On the Use of Stream Control Transmission Protocol (SCTP) with [[IPsec]] ||
| [https://www.rfc-editor.org/info/rfc7829 7829] || SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
|-
|-
|3436 || Transport Layer Security over Stream Control Transmission Protocol ||
| [https://www.rfc-editor.org/info/rfc8540 8540] || Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260)
|-
|-
|3309 || Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960) ||
| [https://www.rfc-editor.org/info/rfc9260 9260] || Stream Control Transmission Protocol
|-
|3286 || An Introduction to the Stream Control Transmission Protocol ||
|-
|3257 || Stream Control Transmission Protocol Applicability Statement ||
|-
|2960 || Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960) ||
|}
|}
===== Man-Pages =====
===== Info-Pages =====


==== Links ====
==== Links ====
===== Projekt =====
===== Weblinks =====
===== Weblinks =====
# https://www.heise.de/hintergrund/Missing-Link-IETF-Standards-ueber-die-Zukunft-von-einem-Zoo-an-Protokollen-7549017.html
# https://de.wikipedia.org/wiki/Stream_Control_Transmission_Protocoloject Page]
# https://www.heise.de/select/ix/2018/7/1531019106497832
# [https://www.sctp.de/ sctp.de] – Michael Tüxen's SCTP Page
# [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]
# [http://www.openss7.org/ OpenSS7]
# [https://www.ietf.org/wg/concluded/sigtran.html Concluded Workgroup ''Signaling Transport (sigtran)''.] ietf.org
# [https://www.ibm.com/developerworks/linux/library/l-sctp/ Better networking with SCTP.] ibm.co
# https://de.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
# [https://web.archive.org/web/20131025214054/http://www.sigtran.ss7box.com/ sigtran (archived)]
# [https://web.archive.org/web/20050515080345/http://www.ietf.org/html.charters/sigtran-charter.html Ietf.org]
# [https://web.archive.org/web/20090201161053/http://www.ietf.org/html.charters/tsvwg-charter.html Ietf.org]
# [https://web.archive.org/web/20060206201712/http://www.openss7.org/ Openss7.org]
# [http://www.lksctp.org SCTP workgroup for Linux]
# [http://www.sctp.de/ Michael Tüxen's SCTP Page]
# [http://www.sctp.be/ Lode Coene's SCTP Page]
# [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]


[[Kategorie:Stream Control Transmission Protocol]]
[[Kategorie:SCTP]]
</noinclude>
</noinclude>

Aktuelle Version vom 15. Februar 2024, 12:25 Uhr

Stream Control Transmission Protocol (SCTP) - zuverlässiges, verbindungsorientiertes Netzwerkprotokoll der Transportschicht

Beschreibung

Es gehört zur Transportschicht und setzt auf einem potenziell unzuverlässigen, verbindungslosen Paketdienst der Netzwerkschicht auf

Das Stream Control Transmission Protocol
  • oder SCTP erweitert TCP, will abeár gleichzeitig mit weniger Overhead auskommen
  • Anfang der 1980er, in den frühen Jahren des Internets, hatten die Entwickler des Transmission Control Protocol (TCP) Anwendungen wie E-Mail und ftp im Hinterkopf, die zeitunkritisch sind und nur geringe Datenmengen erzeugen
  • Es war für relativ unzuverlässige Leitungen ausgelegt und verfügt deshalb über umfangreiche Methoden zur Fehlersicherung und Flusssteuerung
  • Die strikte Reihenfolgesicherung schafft aber Abhängigkeiten zwischen einzelnen Datenpaketen
UDP (User Datagram Protocol)
  • als nachrichtenorientiertes Protokoll kommt ohne diesen Ballast aus
  • bietet aber auch keine zuverlässige Sicherung gegen Übertragungsfehler
  • Das wiederholte Senden fehlerhafter Pakete, das Erkennen duplizierter Nachrichten und die Sicherung der Reihenfolge müssen hier höhere Softwareschichten übernehmen
  • Das verbindungslose UDP eignet sich beispielsweise gut für die Sprachübertragung, in der verbindungsorientierte Protokolle eher kontraproduktiv wären
Im Jahr 2000 entwarf die IETF auf Betreiben der Telko-Provider ein drittes Layer-4-Protokoll für den TCP/IP-Stack
  • Das Stream Control Transmission Protocol (SCTP) nach RFC 4960 soll einerseits große Datenmengen zuverlässig durch komplexe Netze geleiten, andererseits das Senden von Signalisierungsdaten vereinfachen
  • Es arbeitet wie TCP verbindungsorientiert, ersetzt aber die TCP-Connections durch die weiter gefassten SCTP-Assoziationen

Das Stream Control Transmission Protocol (SCTP)

SCTP wurde von der Internet Engineering Task Force (IETF) in Vorlage:IETF RFC standardisiert

  • Die SCTP-Referenzimplementierung wurde als Teil von FreeBSD, Version 7, veröffentlicht und ist seitdem in großem Umfang auf andere Plattformen portiert worden
Formale Aufsicht

Die IETF Signaling Transport (SIGTRAN) Arbeitsgruppe definierte das Protokoll (Nummer 132) im Oktober 2000, und die IETF Arbeitsgruppe Transport Area (TSVWG) pflegt es. Vorlage:IETF RFC definiert das Protokoll. Vorlage:IETF RFC bietet eine Einführung

Eigenschaften und Funktionen

SCTP wurde von der Internet Engineering Task Force (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument RFC 2960 veröffentlicht

  • Die Spezifikation wurde im September 2007 durch RFC 4960 und im Juni 2022 durch RFC 9260 ersetzt
  • Eine Einführung findet sich in RFC 3286

Das zuständige Gremium bei der IETF ist die Arbeitsgruppe Signaling Transport, kurz SIGTRAN

Als Transportprotokoll steht SCTP auf derselben Stufe des TCP/IP-Referenzmodells wie TCP und UDP (Schicht 4 des OSI-Modells)

SCTP realisiert das Konzept einer Association
  • Hier wird eine Verbindung aufgebaut, in der mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden
  • Zusätzlich können einzelne, zum Beispiel dringende, Datagramme separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“
SCTP kennt außerdem Multistreaming und Multihoming
  • (ein Host mit mehreren gültigen IP-Adressen)
  • Es werden Heartbeats verwendet, um aktiv auf Verbindungsabriss zu testen
Anders als TCP zeigt sich SCTP resistent gegen SYN-Flooding
  • , eine Denial-of-Service-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden
  • Dazu verwendet es einen sogenannten Vier-Wege-Handshake
  • Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines Cookies (INIT-ACK-Paket) an den Client
  • Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket)
  • Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe SYN-Cookies

Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten (SS7) aus Telefonnetzen auch über IP-Netzwerke übertragen zu können

  • Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund
  • SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint
  • Eine wichtige, auf SCTP aufbauende Anwendung ist Reliable Server Pooling (RSerPool)

SCTP verwendet für Fluss- und Überlastkontrolle ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral


TCP, UDP und SCTP im Vergleich
Funktion TCP UDP SCTP
verbindungsorientierte Übertragung ✓ – ✓
gesicherte Übertragung ✓ – ✓
ungesicherte Übertragung – ✓ ✓
Flusskontrolle ✓ – ✓
Überlaststeuerung ✓ – ✓
Steuerung der maximalen Paketgröße (Path MTU Discovery) ✓ – ✓
Multihoming – – ✓
Multistreaming – – ✓
Dabei lassen sich jedem Endpunkt mehrere IP-Adressen zuordnen, was man als Multihoming bezeichnet
  • Das entkoppelt die logische Verbindung, die Assoziation, noch weiter von den physischen Pfaden
  • Durch die Nutzung mehrerer Übertragungswege und Provider lässt sich die Verfügbarkeit erhöhen
  • Voraussetzung ist allerdings, dass Pfade nicht über dieselben Netzknoten führen
Nicht aktive Pfade werden laufend auf Verfügbarkeit überprüft
  • Ist der Backup-Pfad nicht erreichbar, wird er gestrichen
  • Damit ist im Fehlerfall ein schnelles Umschalten ohne Routing möglich
  • Ein Load Sharing über mehrere Pfade wie beim Multipath TCP (MPTCP) war ursprünglich nicht vorgesehen
  • Das liefert der Entwurf von IEEE und IETF zum Concurrent Multipath Transfer (CMT-SCTP) nach
SCTP nutzt wie TCP Sequenznummern für jede Nachricht, deren Empfang die Gegenstelle bestätigt (Selective Acknowledgement)
  • Statt eines Byte-Stroms überträgt SCTP Nachrichtenblöcke, sogenannte Messages, die mehr Spielraum bieten: Einerseits lassen sich große Nachrichten über mehrere Pakete verteilen, wenn sie die maximale Paketgröße (Path MTU) überschreiten
  • Andererseits kann SCTP mehrere kleine Nachrichten in einem Paket zusammenfassen (Multiplexing)
Damit eignet es sich gleichermaßen als Signalisierungsprotokoll und für die Übertragung von Datenströmen
  • Hierzu fasst es Pakete zu Streams zusammen und erlaubt die parallele Übertragung in mehreren Streams
  • Während TCP alle Daten in die gleiche Reihenfolge presst, in der sie gesendet wurden, lässt SCTP pro Stream die Festlegung zu, ob eine Sicherung der Reihenfolge vorgenommen wird oder nicht
  • Das verhindert, dass verloren gegangene Daten eines Streams den Fluss der anderen Streams behindern, ein als Head-of-Line Blocking bezeichnetes Phänomen
  • Mit der Erweiterung SCTP-PR (Partial Reliability) ist es zudem möglich, ungesicherte Streams zu definieren, bei denen verlorene Pakete nicht erneut gesendet werden
  • Anders als bei UDP greift aber hier die Überlaststeuerung
Durch die Aufteilung der Daten in mehrere Streams mit unterschiedlichen Eigenschaften lassen sich gleichzeitig UDP- und TCP-ähnliche Verbindungen zwischen zwei Endpunkten aufrechterhalten
  • Zwar ließen sich auch getrennte TCP- und UDP-Verbindungen aufbauen, was aber mit einem größeren Overhead verbunden ist
  • Die Stärke von SCTP liegt gerade in der Verwaltung mehrerer paralleler Streams. Überlaststeuerung, Bandbreitenreservierung und Multihoming gelten jeweils für die gesamte Assoziation, allerdings separat für jede IP-Adresse
  • Einen einzelnen Stream überträgt TCP schneller, weshalb es seine Bedeutung weiterhin behält
SCTP werkelt bereits unauffällig in vielen Netzwerkanwendungen
  • In den Blickpunkt rückt es gegenwärtig wieder durch die Ausbreitung von IP-Netzen in Bereiche, die zuvor InfiniBand oder Fibre Channel vorbehalten waren, etwa durch iWARP (Internet Wide Area RDMA Protocol), das Direktspeicherzugriffe über IP erlaubt

Merkmale

Zu den Merkmalen von SCTP gehören
  • Zuverlässige Übertragung sowohl von geordneten als auch von ungeordneten Datenströmen
  • Multihoming-Unterstützung, bei der ein oder beide Endpunkte einer Verbindung aus mehr als einer IP-Adresse bestehen können, was ein transparentes Failover zwischen redundanten Netzwerkpfaden ermöglicht
  • Zustellung von Datenpaketen innerhalb unabhängiger Ströme eliminiert unnötiges Head-of-Line-Blocking, im Gegensatz zur TCP-Byte-Stream-Zustellung
  • Explizite partielle Zuverlässigkeit
  • Pfadauswahl und -überwachung zur Auswahl eines primären Datenübertragungspfads und zur Prüfung der Konnektivität des Übertragungspfads
  • Validierungs- und Bestätigungsmechanismen zum Schutz vor Flooding-Angriffen und zur Benachrichtigung über duplizierte oder fehlende Datenpakete
  • Verbesserte Fehlererkennung, geeignet für Ethernet Jumbo Frames

Die Entwickler von SCTP hatten es ursprünglich für die Übertragung von Telefongesprächen (d. h. Signalsystem 7) über das Internetprotokoll vorgesehen, mit dem Ziel, einige der Zuverlässigkeitsmerkmale des SS7-Signalisierungsnetzes in IP zu duplizieren

Message-based Multi-Streaming

SCTP-Anwendungen übermitteln Daten zur Übertragung in Nachrichten (Byte-Gruppen) an die SCTP-Transportschicht

  • SCTP unterteilt Nachrichten und Kontrollinformationen in separate Chunks (Daten- und Kontrollchunks), die jeweils durch einen Chunk-Header gekennzeichnet sind
  • Das Protokoll kann eine Nachricht in mehrere Datenchunks aufteilen, aber jeder Datenchunk enthält nur die Daten einer einzigen Benutzernachricht
  • SCTP bündelt die Chunks zu SCTP-Paketen
  • Das SCTP-Paket, das an das Internetprotokoll übergeben wird, besteht aus einem Paketkopf, SCTP-Kontrollbrocken (sofern erforderlich), gefolgt von SCTP-Datenbrocken (sofern verfügbar)

SCTP kann als nachrichtenorientiert bezeichnet werden, d. h. es transportiert eine Folge von Nachrichten (jeweils eine Gruppe von Bytes) und nicht wie TCP einen ununterbrochenen Strom von Bytes

  • Wie bei UDP sendet ein Absender bei SCTP eine Nachricht in einem Vorgang, und genau diese Nachricht wird in einem Vorgang an den empfangenden Anwendungsprozess weitergeleitet
  • Im Gegensatz dazu ist TCP ein strömungsorientiertes Protokoll, das Ströme von Bytes zuverlässig und in der richtigen Reihenfolge transportiert
  • Bei TCP weiß der Empfänger jedoch nicht, wie oft die Senderanwendung den TCP-Transport aufgerufen hat, um ihm die zu sendenden Byte-Gruppen zu übergeben
  • Beim Absender fügt TCP einfach weitere Bytes an eine Warteschlange von Bytes an, die darauf warten, über das Netz versendet zu werden, anstatt eine Warteschlange von einzelnen separaten ausgehenden Nachrichten zu führen, die als solche erhalten werden müssen

Der Begriff Multi-Streaming bezieht sich auf die Fähigkeit von SCTP, mehrere unabhängige Ströme von Datenpaketen parallel zu übertragen, z. B.  Bilder einer Webseite gleichzeitig mit dem Text der Webseite

  • Im Wesentlichen geht es darum, mehrere Verbindungen in einer einzigen SCTP-Verbindung zu bündeln und mit Nachrichten (oder Chunks) statt mit Bytes zu arbeiten

TCP bewahrt die Byte-Reihenfolge im Datenstrom, indem es jedem Segment eine Byte-Sequenznummer beifügt

  • SCTP hingegen weist jeder Nachricht, die in einem Datenstrom gesendet wird, eine Sequenznummer oder eine Message-ID zu
  • Die DATA chunk verwendet eine Sequenznummer für geordnete Nachrichten, die I-DATA chunk, die einige Probleme mit dem ursprünglichen DATA chunk löst, verwendet eine Message-ID für alle Nachrichten
  • Dies ermöglicht eine unabhängige Anordnung von Nachrichten in verschiedenen Streams
  • Die Reihenfolge der Nachrichten ist bei SCTP jedoch optional; eine empfangende Anwendung kann sich dafür entscheiden, die Nachrichten in der Reihenfolge des Empfangs und nicht in der Reihenfolge des Versands zu verarbeiten

Motivation und Einführung

TCP war das wichtigste Mittel zur zuverlässigen Datenübertragung im Internet

  • Allerdings hat TCP bei verschiedenen Anwendungen zu Einschränkungen geführt
  • Aus Vorlage:IETF RFC:
  • TCP bietet sowohl eine zuverlässige Datenübertragung als auch eine strikte Reihenfolge der Datenübermittlung
  • Einige Anwendungen benötigen eine zuverlässige Übertragung ohne Einhaltung der Reihenfolge, während andere mit einer teilweisen Reihenfolge der Daten zufrieden wären
  • In beiden Fällen verursacht die Head-of-Line-Blocking-Eigenschaft von TCP unnötige Verzögerungen
  • Für Anwendungen, die verschiedene Datensätze oder Nachrichten austauschen, erfordert die stromorientierte Natur von TCP die Hinzufügung expliziter Markierungen oder anderer Kodierungen, um die einzelnen Datensätze abzugrenzen
  • Um zu vermeiden, dass viele kleine IP-Pakete gesendet werden, wo ein einziges größeres Paket ausgereicht hätte, kann die TCP-Implementierung die Übertragung von Daten verzögern, während sie auf möglicherweise weitere Daten wartet, die sich in der Warteschlange der Anwendung befinden (Nagle-Algorithmus)
  • Wenn eine solche kleine Verzögerung unerwünscht ist, muss die Anwendung von Fall zu Fall ausdrücklich eine unverzögerte Übertragung mit Hilfe der push facility anfordern (d. h. durch Setzen des PSH-Flags im TCP-Paketkopf)
  • Bei SCTP hingegen kann die unverzögerte Übertragung als Standard für eine Assoziation konfiguriert werden, wodurch unerwünschte Verzögerungen vermieden werden, allerdings auf Kosten eines höheren Übertragungs-Overheads
  • Die begrenzte Reichweite von TCP-Sockets erschwert die Aufgabe, hochverfügbare Datenübertragungen mit multihomed Hosts zu ermöglichen
  • TCP ist relativ anfällig für Denial-of-Service-Angriffe, wie z. B. SYN-Angriffe

Die Akzeptanz wurde durch mangelndes Bewusstsein, fehlende Implementierungen (insbesondere in Microsoft Windows), fehlende Anwendungsunterstützung und fehlende Netzwerkunterstützung gebremst

Multihoming

Vorlage:Multiple image

SCTP bietet redundante Pfade, um die Zuverlässigkeit zu erhöhen

Jeder SCTP-Endpunkt muss die Erreichbarkeit der primären und redundanten Adressen des entfernten Endpunkts mit Hilfe eines heartbeat überprüfen

  • Jeder SCTP-Endpunkt muss die Heartbeats, die er vom entfernten Endpunkt empfängt, quittieren

Wenn SCTP eine Nachricht an eine entfernte Adresse sendet, wird die Quellschnittstelle nur durch die Routing-Tabelle des Hosts (und nicht durch SCTP) bestimmt

Beim asymmetrischen Multihoming unterstützt einer der beiden Endpunkte kein Multihoming

Bei lokalem Multihoming und entferntem Single-Homing schlägt die SCTP-Zuordnung fehl, wenn die entfernte primäre Adresse nicht erreichbar ist, selbst wenn ein alternativer Pfad möglich ist

Paketstruktur

Vorlage:Main

Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten
  1. Dem common header, der die ersten 12 Bytes einnimmt und blau hervorgehoben ist
  2. Die data chunks, die den restlichen Teil des Pakets einnehmen
  • Der erste Chunk ist grün hervorgehoben, und der letzte von N Chunks (Chunk N) ist rot hervorgehoben
Bits 0–7 8–15 16–23 24–31
+0 Source port Destination port
32 Verification tag
64 Checksum
96 Chunk 1 type Chunk 1 flags Chunk 1 length
128 Chunk 1 data
… …
… Chunk N type Chunk N flags Chunk N length
… Chunk N data

Jeder Chunk beginnt mit einem Ein-Byte-Typ-Identifikator, wobei 15 Chunk-Typen durch Vorlage:IETF RFC und mindestens 5 weitere durch zusätzliche RFCs definiert sind

  • Siehe SCTP-Paketstruktur für weitere Einzelheiten
  • Acht Flaggenbits, ein Zwei-Byte-Längenfeld und die Daten bilden den Rest des Chunks
  • Wenn der Chunk kein Vielfaches von 4 Bytes ist (d.h
  • die Länge ist kein Vielfaches von 4), wird er mit Nullen aufgefüllt, die nicht in die Chunk-Länge eingerechnet werden
  • Das Zwei-Byte-Längenfeld begrenzt jedes Chunk auf eine Länge von 65.535 Byte (einschließlich der Felder Typ, Flags und Länge)

Sicherheit

Obwohl die Verschlüsselung nicht Teil des ursprünglichen SCTP-Entwurfs war, wurde SCTP mit Merkmalen zur Verbesserung der Sicherheit entwickelt, z. B.  4-Wege-Handshake (im Vergleich zu TCP 3-Wege-Handshake) zum Schutz vor SYN-Flooding-Angriffen und große "Cookies" zur Überprüfung der Verbindung und Authentizität

Auch die Zuverlässigkeit war ein wichtiger Bestandteil des Sicherheitsdesigns von SCTP

  • Multihoming ermöglicht es, eine Verbindung auch dann aufrechtzuerhalten, wenn einige Routen und Schnittstellen ausgefallen sind
  • Dies ist für SIGTRAN von besonderer Bedeutung, da es SS7 über ein IP-Netz unter Verwendung von SCTP überträgt und eine hohe Ausfallsicherheit bei Verbindungsausfällen erfordert, um den Telekommunikationsdienst auch bei Netzanomalien aufrechtzuerhalten

SCTP ist manchmal ein guter Kandidat für Fingerprinting

  • Einige Betriebssysteme werden mit aktivierter SCTP-Unterstützung ausgeliefert, und da SCTP nicht so bekannt ist wie TCP oder UDP, wird es manchmal in Firewall- und Intrusion-Detection-Konfigurationen übersehen, so dass es oft einen Sondierungsverkehr zulässt

Implementations

The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux

The following operating systems implement SCTP:

  • AIX Version 5 and newer
  • NetBSD
  • FreeBSD, version 7 and above, contains the reference SCTP implementation
  • HP-UX, 11i v2 and above
  • illumos
  • Linux kernel 2.4 and above
  • QNX Neutrino Realtime OS,
  • Tru64 with the Compaq SCTP add-on package
  • Sun Solaris 10 and above
  • VxWorks versions 6.2.x to 6.4.x, and 6.7 and newer

Third-party drivers:

  • Microsoft Windows:
    • The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows (Abandoned after 2012)
  • MacOS:
    • SCTP Network Kernel Extension for Mac OS X

Userspace library:

The following applications implement SCTP:

Tunneling über UDP

In Ermangelung einer nativen SCTP-Unterstützung in Betriebssystemen ist es möglich, Tunnel SCTP über UDP, sowie TCP-API-Aufrufe auf SCTP-Aufrufe abzubilden, damit bestehende Anwendungen SCTP ohne Änderungen nutzen können

Alternativen

QUIC ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht


Anhang

Siehe auch

  • Transport layer|Comparison of transport layer protocols
  • Session Initiation Protocol (SIP) – which may initiate multiple streams over SCTP, TCP, or UDP
  • Multipath TCP – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
  • Happy Eyeballs – originally designed for efficient selection of IPv4 or IPv6 for a connection; could also be adapted to select from different transport protocols such as TCP and SCTP

Dokumentation

RFC
RFC Titel
2960 Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960)
3257 Stream Control Transmission Protocol Applicability Statement
3286 An Introduction to the Stream Control Transmission Protocol
3309 Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960)
3436 Transport Layer Security over Stream Control Transmission Protocol
3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260)
4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
4960 Stream Control Transmission Protocol
4960 Stream Control Transmission Protocol (obsoleted by RFC 9260)
5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260)
6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260)
7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260)
9260 Stream Control Transmission Protocol

Links

Weblinks
  1. https://de.wikipedia.org/wiki/Stream_Control_Transmission_Protocoloject Page]
Abgerufen von „https://wiki.foxtom.de/index.php?title=Stream_Control_Transmission_Protocol&oldid=94318“