Stream Control-Übertragungsprotokoll - Stream Control Transmission Protocol

Internetprotokoll-Suite
Anwendungsschicht
Transportschicht
Internetschicht
Verbindungsschicht

Das Stream Control Transmission Protocol ( SCTP ) ist ein Kommunikationsprotokoll für Computernetzwerke in der Transportschicht der Internet Protocol Suite . Ursprünglich für den Nachrichtentransport des Signalling 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, sequentiellen Transport von Nachrichten mit Überlastkontrolle wie dem Transmission Control Protocol ( TCP). Im Gegensatz zu UDP und TCP bietet das Protokoll Multi-Homing und redundante Pfade, um die Ausfallsicherheit und Zuverlässigkeit zu erhöhen. SCTP ist von der Internet Engineering Task Force (IETF) in RFC 4960 standardisiert . Die SCTP-Referenzimplementierung wurde als Teil von FreeBSD Version 7 veröffentlicht und wurde seitdem in großem Umfang auf andere Plattformen portiert.  

Formale Aufsicht

Die Arbeitsgruppe Signaling Transport ( SIGTRAN ) der IETF hat das Protokoll (Nummer 132) im Oktober 2000 definiert und die Arbeitsgruppe Transport Area (TSVWG) der IETF pflegt es. RFC  4960 definiert das Protokoll. RFC  3286 bietet eine Einführung.

Nachrichtenbasiertes Multistreaming

SCTP-Anwendungen übermitteln Daten zur Übertragung in Nachrichten (Bytegruppen) an die SCTP-Transportschicht. SCTP platziert Nachrichten und Steuerinformationen in separate Chunks (Daten-Chunks und Control-Chunks), die jeweils durch einen Chunk-Header identifiziert werden . Das Protokoll kann eine Nachricht in mehrere Datenblöcke fragmentieren, aber jeder Datenblock enthält Daten von nur einer Benutzernachricht. SCTP bündelt die Chunks in SCTP-Pakete. Das SCTP-Paket, das an das Internet Protocol übermittelt wird , besteht aus einem Paket-Header, SCTP-Kontrollblöcken (sofern erforderlich), gefolgt von SCTP-Datenblöcken (sofern verfügbar).

SCTP kann als nachrichtenorientiert charakterisiert werden, was bedeutet, dass es eine Folge von Nachrichten (jeweils eine Gruppe von Bytes) transportiert, anstatt einen ununterbrochenen Strom von Bytes wie bei TCP zu transportieren. Wie bei UDP sendet bei SCTP ein Sender eine Nachricht in einem Vorgang, und genau diese Nachricht wird in einem Vorgang an den empfangenden Anwendungsprozess übergeben. Im Gegensatz dazu ist TCP ein stromorientiertes Protokoll, das Byteströme zuverlässig und geordnet transportiert. TCP erlaubt dem Empfänger jedoch nicht zu wissen, wie oft die Senderanwendung den TCP-Transport aufgerufen hat, um ihm Gruppen von auszusendenden Bytes zu übergeben. Beim Sender hängt TCP einfach mehr Bytes an eine Warteschlange von Bytes an, die darauf warten, über das Netzwerk hinauszugehen, anstatt eine Warteschlange einzelner separater ausgehender Nachrichten führen zu müssen, die als solche erhalten bleiben müssen.

Der Begriff Multistreaming bezieht sich auf die Fähigkeit von SCTP, mehrere unabhängige Chunk-Streams parallel zu übertragen, beispielsweise die gleichzeitige Übertragung von Webseitenbildern mit dem Webseitentext. Im Wesentlichen beinhaltet es das Bündeln mehrerer Verbindungen zu einer einzigen SCTP-Assoziation, die mit Nachrichten (oder Chunks) statt mit Bytes arbeitet.

TCP behält die Bytereihenfolge im Stream bei, indem in jedes Segment eine Bytefolgenummer eingefügt wird . SCTP hingegen weist jeder in einem Stream gesendeten Nachricht eine Sequenznummer oder eine Nachrichten-ID zu . Dies ermöglicht eine unabhängige Anordnung von Nachrichten in verschiedenen Strömen. Die Nachrichtenreihenfolge ist in SCTP jedoch optional; eine empfangende Anwendung kann Nachrichten in der Reihenfolge des Eingangs statt in der Reihenfolge des Sendens verarbeiten.

Merkmale

Zu den Funktionen von SCTP gehören:

  • Zuverlässige Übertragung sowohl geordneter als auch ungeordneter Datenströme.
  • Multihoming- Unterstützung, bei der ein oder beide Endpunkte einer Verbindung aus mehr als einer IP-Adresse bestehen können, wodurch ein transparentes Failover zwischen redundanten Netzwerkpfaden ermöglicht wird.
  • Die Lieferung von Chunks innerhalb unabhängiger Streams eliminiert unnötige Head-of-Line-Blocking im Gegensatz zur TCP-Byte-Stream-Lieferung.
  • Explizite Teilzuverlässigkeit.
  • Pfadauswahl und Überwachung, um einen primären Datenübertragungspfad auszuwählen und die Konnektivität des Übertragungspfads zu testen.
  • Validierungs- und Bestätigungsmechanismen schützen vor Flooding-Angriffen und informieren über duplizierte oder fehlende Datenblöcke.
  • Verbesserte Fehlererkennung geeignet für Ethernet Jumbo Frames .

Die Designer von SCTP hatten es ursprünglich für den Transport von Telefonie ( Signalisierungssystem 7 ) über das Internetprotokoll vorgesehen, mit dem Ziel, einige der Zuverlässigkeitsattribute des SS7-Signalisierungsnetzwerks in IP zu duplizieren. Diese Bemühungen der IETF sind als SIGTRAN bekannt . Inzwischen wurden auch andere Anwendungen vorgeschlagen, beispielsweise das Diameter- Protokoll und das Reliable Server Pooling (RSerPool).

Motivation und Annahme

TCP ist das wichtigste Mittel, um Daten zuverlässig über das Internet zu übertragen. TCP hat jedoch mehreren Anwendungen Beschränkungen auferlegt. Aus RFC  4960 :

  • TCP bietet sowohl eine zuverlässige Datenübertragung als auch eine strikte Übermittlung der Daten in der Reihenfolge der Übertragung. Einige Anwendungen benötigen eine zuverlässige Übertragung ohne Sequenzwartung, während andere mit einer teilweisen Ordnung der Daten zufrieden sind. In beiden Fällen verursacht die Blockierungseigenschaft von TCP für den Zeilenkopf eine unnötige Verzögerung.
  • Für Anwendungen, die unterschiedliche Datensätze oder Nachrichten austauschen, erfordert die stromorientierte Natur von TCP das Hinzufügen von expliziten Markierungen oder einer anderen Codierung, um die einzelnen Datensätze abzugrenzen.
  • Um zu vermeiden, dass viele kleine IP-Pakete gesendet werden, bei denen ein einziges größeres Paket ausgereicht hätte, kann die TCP-Implementierung die Übertragung von Daten verzögern, während sie darauf wartet, dass möglicherweise weitere Daten von der Anwendung in die Warteschlange gestellt werden ( Nagle-Algorithmus ). Wenn eine so kleine Verzögerung unerwünscht ist, muss die Anwendung von Fall zu Fall explizit eine unverzögerte Übertragung unter Verwendung der Push-Funktion anfordern (dh durch Setzen des PSH-Flags im TCP-Paket-Header). SCTP hingegen ermöglicht die Konfiguration einer unverzögerten Übertragung als Standard für eine Assoziation, wodurch unerwünschte Verzögerungen vermieden werden, jedoch auf Kosten eines höheren Übertragungsaufwands.
  • Der begrenzte Umfang von TCP-Sockets erschwert die Aufgabe, eine hochverfügbare Datenübertragungskapazität unter Verwendung von mehrfach vernetzten Hosts bereitzustellen .
  • TCP ist relativ anfällig für Denial-of-Service-Angriffe wie SYN-Angriffe .

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

Multi-Homing

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

SCTP-Multihoming

Jeder SCTP-Endpunkt muss die Erreichbarkeit der primären und redundanten Adressen des entfernten Endpunkts mit einem Heartbeat überprüfen . Jeder SCTP-Endpunkt muss die vom Remote-Endpunkt empfangenen Heartbeats bestätigen.

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

Asymmetrisches Multihoming

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

Lokales Multi-Homing – Remote-Single-Homing

Wenn die Remote-Primäradresse beim lokalen Multi-Homing und Remote-Single-Homing nicht erreichbar ist, schlägt die SCTP-Zuordnung fehl, selbst wenn ein alternativer Pfad möglich ist.

Asymmetrisches Multi-Homing: Lokales Multi-Homing - Remote Single-Homing

Lokales Single-Homing – Remote-Multi-Homing

Asymmetrisches Multi-Homing: Lokales Single-Homing - Remote-Multi-Homing

Paketstruktur

Hauptartikel: SCTP-Paketstruktur
Bits 0–7 8-15 16–23 24-31
+0 Quellport Zielhafen
32 Bestätigungs-Tag
64 Prüfsumme
96 Block 1 Typ Chunk 1 Flaggen Abschnitt 1 Länge
128 Datenblock 1
… …
… Chunk-N-Typ Chunk-N-Flags Länge des Stücks N
… Chunk-N-Daten

Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten:

  1. Der gemeinsame Header , der die ersten 12 Byte belegt und blau hervorgehoben ist, und
  2. Die Datenblöcke , die den restlichen Teil des Pakets belegen. Der erste Chunk wird grün hervorgehoben und der letzte von N Chunks (Chunk N) wird rot hervorgehoben.

Jeder Chunk beginnt mit einer ein-Byte-Typ-ID, wobei 15 Chunk-Typen durch RFC  4960 definiert sind und mindestens 5 weitere durch zusätzliche RFCs definiert werden. Acht Flag-Bits, ein zwei Byte langes Feld und die Daten bilden den Rest des Chunks. Wenn der Chunk kein Vielfaches von 4 Bytes bildet (dh die Länge kein Vielfaches von 4 ist), wird er mit Nullen aufgefüllt, die nicht in der Chunk-Länge enthalten sind. Das 2-Byte-Längenfeld begrenzt jeden 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 - Designs war, wurde SCTP für eine verbesserte Sicherheit mit Funktionen , wie zB 4-Wege - Handshake ( im Vergleich zu TCP 3-Wege - Handshake ) zum Schutz gegen SYN - Flooding - Attacken und groß „Cookies“ für die Zuordnung Überprüfung und Authentizität.

Zuverlässigkeit war auch ein wichtiger Bestandteil des Sicherheitsdesigns von SCTP. Multihoming ermöglicht es, dass eine Assoziation auch dann geöffnet bleibt, wenn einige Routen und Schnittstellen ausgefallen sind. Dies ist für SIGTRAN von besonderer Bedeutung, da es SS7 über ein IP-Netzwerk unter Verwendung von SCTP überträgt und eine starke Widerstandsfähigkeit bei Verbindungsausfällen erfordert, um den Telekommunikationsdienst auch bei anhaltenden Netzwerkanomalien aufrechtzuerhalten.

SCTP ist manchmal ein guter Kandidat für Fingerabdrücke . Einige Betriebssysteme werden mit aktivierter SCTP-Unterstützung geliefert, und da sie nicht so bekannt ist wie TCP oder UDP, wird sie in Firewall- und Intrusion Detection-Konfigurationen manchmal übersehen, sodass häufig der Datenverkehr untersucht wird.

Implementierungen

Die SCTP-Referenzimplementierung läuft auf FreeBSD, Mac OS X, Microsoft Windows und Linux.

Die folgenden Betriebssysteme implementieren SCTP:

  • AIX Version 5 und höher
  • NetBSD seit 8.0
  • Cisco IOS 12
  • DragonFly BSD seit Version 1.4, jedoch wird die Unterstützung in Version 4.2 eingestellt
  • FreeBSD , Version 7 und höher, enthält die Referenz-SCTP-Implementierung
  • HP-UX , 11i v2 und höher
  • Linux- Kernel-basiert 2.4 und neuer
  • Tru64 mit dem Compaq SCTP-Add-on-Paket
  • QNX Neutrino Realtime OS, 6.3.0 bis 6.3.2, veraltet seit 6.4.0
  • Sun Solaris 10 und höher
  • VxWorks- Versionen 6.2.x bis 6.4.x und 6.7 und höher
  • leuchten

Treiber von Drittanbietern:

  • Microsoft-Windows :
    • Der SctpDrv-Kernel-Treiber ist eine Portierung des BSD-SCTP-Stacks auf Windows
  • MacOS :
    • SCTP-Netzwerk-Kernel-Erweiterung für Mac OS X

Userspace- Bibliothek:

Die folgenden Anwendungen implementieren SCTP:

Tunneln über UDP

Wenn Betriebssysteme keine native SCTP-Unterstützung bieten, ist es möglich, SCTP über UDP zu tunneln sowie TCP-API-Aufrufe SCTP-Aufrufen zuzuordnen, sodass vorhandene Anwendungen SCTP ohne Änderungen verwenden können.

RFC-Geschichte

  • RFC  7829 SCTP-PF: Ein schneller Failover-Algorithmus für das Stream Control Transmission Protocol
  • RFC  7765 TCP und Stream Control Transmission Protocol (SCTP) RTO-Neustart
  • RFC  7496 Zusätzliche Richtlinien für die teilweise zuverlässige Stream Control Transmission Protocol Extension
  • RFC  7053 SACK-IMMEDIATELY Erweiterung für das Stream Control Transmission Protocol (aktualisiert RFC 4960)
  • RFC  6951 UDP-Kapselung von Stream Control Transmission Protocol (SCTP)-Paketen für die End-Host-zu-End-Host-Kommunikation
  • RFC  6525 Stream Control Transmission Protocol (SCTP) Stream Rekonfiguration
  • RFC  6458 Sockets API-Erweiterungen für das Stream Control Transmission Protocol (SCTP)
  • RFC  6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registrierung (aktualisiert RFC 4960)
  • RFC  5062- Sicherheitsangriffe gegen das Stream Control Transmission Protocol (SCTP) und aktuelle Gegenmaßnahmen
  • RFC  5061 Stream Control Transmission Protocol (SCTP) Dynamische Adressrekonfiguration
  • RFC  5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaption
  • RFC  4960 Stream Control Transmission Protocol
  • RFC  4895 authentifizierte Chunks für das Stream Control Transmission Protocol (SCTP)
  • RFC  4820 Padding Chunk und Parameter für das Stream Control Transmission Protocol (SCTP)
  • RFC  4460 Stream Control Transmission Protocol (SCTP) Spezifikationsfehler und Probleme
  • RFC  3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
  • RFC  3758 Stream Control Transmission Protocol (SCTP) Teilzuverlässigkeitserweiterung
  • RFC  3554 zur Verwendung des Stream Control Transmission Protocol (SCTP) mit IPsec
  • RFC  3436 Transport Layer Security über Stream Control Transmission Protocol
  • RFC  3309 Stream Control Transmission Protocol (SCTP) Prüfsummenänderung (obsolet durch RFC 4960)
  • RFC  3286 Eine Einführung in das Stream Control Transmission Protocol
  •  Erklärung zur Anwendbarkeit des RFC 3257 Stream Control Transmission Protocol
  • RFC  2960 Stream Control Transmission Protocol (aktualisiert durch RFC 3309 und veraltet durch RFC 4960)

Siehe auch

Anmerkungen

Verweise

Externe Links