Stream Control Transmission Protocol: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
Zum nächsten Versionsunterschied →
VisuellWikitext
Markierung: Neue Weiterleitung
 
Markierung: Weiterleitung entfernt
Zeile 1: Zeile 1:
#WEITERLEITUNG [[:Kategorie:Stream Control Transmission Protocol]]
'''Stream Control Transmission Protocol''' ('''SCTP''') - [[Zuverlässigkeit (Telekommunikation)|zuverlässiges]], [[Verbindungsorientierung|verbindungsorientiertes]] [[Netzwerkprotokoll]] der [[Transportschicht]]
 
== Beschreibung ==
[[File:sctpDoD.png|mini|300px]]
Es gehört zur [[Transportschicht]] und setzt auf einem potenziell unzuverlässigen, verbindungslosen [[Paketvermittlung|Paketdienst]] der [[Netzwerkschicht]] auf.
 
; Das Stream Control Transmission Protocol
* oder SCTP erweitert TCP, will aber 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''')
* 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.
 
; 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.
 
== 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-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''
* 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“.
 
; SCTP kennt außerdem ''Multistreaming'' und ''[[Multihoming]]''
* (ein Host mit mehreren gültigen [[IP-Adresse]]n).
* Es werden ''[[Heartbeat (Informatik)|Heartbeats]]'' verwendet, um aktiv auf Verbindungsabriss zu testen.
 
; 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.
* 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.
* 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 ([[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.
* 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 ''[[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
{| class="wikitable sortable options"
|-
! 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 [[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).
 
==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 [[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==
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 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 [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{{vague|date=December 2017}} 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.
 
== Multihoming ==
{{multiple image
|direction = vertical
|width = 500
|image1 = SCTP-Multihoming.png
|caption1 = SCTP multihoming
|image2 = SCTP-LocalMultihoming-RemoteSinglehoming.png
|caption2 = Asymmetric multihoming: local multihoming to remote single homing
|image3 = SCTP-LocalSinglehoming-RemoteMultihoming.png
|caption3 = Asymmetric multihoming: local single homing to remote multihoming
}}
 
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.
 
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 ==
{{Main|SCTP packet structure}}
; Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten:
# 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.
 
{| class="wikitable" style="text-align:center; white-space:nowrap; white-space:nowrap;"
|-
! Bits
! colspan="8" | 0–7
! colspan="8" | 8–15
! colspan="8" | 16–23
! colspan="8" | 24–31
|- style="background:#ddf;"
!+0
|colspan="16" style="text-align: center"|Source port
|colspan="16" style="text-align: center"|Destination port
|- style="background:#ddf;"
! 32
|colspan="32" style="text-align: center"|Verification tag
|- style="background:#ddf;"
! 64
|colspan="32" style="text-align: center"|Checksum
|- style="background:#dfd;"
! 96
|style="text-align: center" colspan="8"|Chunk 1 type
|style="text-align: center" colspan="8"|Chunk 1 flags
|colspan="16" style="text-align: center"|Chunk 1 length
|- style="background:#dfd;"
! 128
|colspan="32" style="text-align: center"|Chunk 1 data
|-
!…
|colspan="32" style="text-align: center"|…
|- style="background:#fdd;"
!…
|style="text-align: center" colspan="8"|Chunk ''N'' type
|style="text-align: center" colspan="8"|Chunk ''N'' flags
|colspan="16" style="text-align: center"|Chunk ''N'' length
|- style="background:#fdd;"
!…
|colspan="32" style="text-align: center"|Chunk ''N'' data
|}
 
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==
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.
 
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==
The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux.
 
The following [[operating system]]s implement SCTP:
 
* [[AIX operating system|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 (operating system)|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
 
[[User space|Userspace]] library:
* Portable SCTP userland stack
* The SCTP library
** [[Windows XP]] port
* [[Java version history#Java SE 7|Oracle Java SE 7]]
* [[Erlang (programming language)|Erlang/OTP]]
 
The following applications implement SCTP:
* [[WebRTC]]
* [[NetFlow]]
 
== 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.
 
== Alternativen ==
[[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.
* 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.
 
<noinclude>
 
== Anhang ==
 
=== Siehe auch ===
{{Special:PrefixIndex/SCTP}}
 
* {{section link|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
 
==== Sicherheit ====
==== Dokumentation ====
===== RFC =====
{| class="wikitable sortable options"
|-
! RFC !! Titel !! Datum
|-
| 2960 || Stream Control Transmission Protocol || 2000
|-
| 4960 || Stream Control Transmission Protocol || 2007
|-
| 6951 || UDP Encapsulation of Stream Control Transmission Protocol || 2013
|-
| 9260 || Stream Control Transmission Protocol || 2022
|-
|9260 || Stream Control Transmission Protocol ||
|-
|8540 || Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260) ||
|-
|7829 || SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol ||
|-
|7765 || TCP and Stream Control Transmission Protocol (SCTP) RTO Restart ||
|-
|7496 || Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension ||
|-
|7053 || SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260) ||
|-
|6951 || UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication ||
|-
|6525 || Stream Control Transmission Protocol (SCTP) Stream Reconfiguration ||
|-
|6458 || Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) ||
|-
|6096 || Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260) ||
|-
|5062 || Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures ||
|-
|5061 || Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration ||
|-
|5043 || Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation ||
|-
|4960 || Stream Control Transmission Protocol (obsoleted by RFC 9260) ||
|-
|4895 || Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) ||
|-
|4820 || Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) ||
|-
|4460 || Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260) ||
|-
|3873 || Stream Control Transmission Protocol (SCTP) [[Management Information Base]] (MIB) ||
|-
|3758 || Stream Control Transmission Protocol (SCTP) Partial Reliability Extension ||
|-
|3554 || On the Use of Stream Control Transmission Protocol (SCTP) with [[IPsec]] ||
|-
|3436 || Transport Layer Security over Stream Control Transmission Protocol ||
|-
|3309 || Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960) ||
|-
|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 ====
===== Projekt =====
===== Weblinks =====
# https://www.heise.de/hintergrund/Missing-Link-IETF-Standards-ueber-die-Zukunft-von-einem-Zoo-an-Protokollen-7549017.html
# 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]]
</noinclude>

Version vom 20. Mai 2023, 14:29 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 aber 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. Diese Bemühungen der IETF sind als SIGTRAN bekannt. In der Zwischenzeit wurden andere Anwendungen vorgeschlagen, zum Beispiel das Diameter-Protokoll und Reliable Server Pooling (RSerPool).

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 ReichweiteVorlage:Vague 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

  • Vorlage:Section link
  • 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

Sicherheit

Dokumentation

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

Projekt
Weblinks
  1. https://www.heise.de/hintergrund/Missing-Link-IETF-Standards-ueber-die-Zukunft-von-einem-Zoo-an-Protokollen-7549017.html
  2. https://www.heise.de/select/ix/2018/7/1531019106497832
  3. sctp.de – Michael Tüxen's SCTP Page
  4. Thomas Dreibholz's SCTP Project Page
  5. OpenSS7
  6. Concluded Workgroup Signaling Transport (sigtran). ietf.org
  7. Better networking with SCTP. ibm.co
  8. https://de.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
  9. sigtran (archived)
  10. Ietf.org
  11. Ietf.org
  12. Openss7.org
  13. SCTP workgroup for Linux
  14. Michael Tüxen's SCTP Page
  15. Lode Coene's SCTP Page
  16. Thomas Dreibholz's SCTP Project Page
Abgerufen von „https://wiki.foxtom.de/index.php?title=Stream_Control_Transmission_Protocol&oldid=70403“