Zum Hauptinhalt springen

5. Assoziationsinitialisierung (Association Initialization)

5.1. Normale Etablierung einer Assoziation (Normal Establishment of an Association)​

Ein SCTP-Endpunkt A, der eine Assoziation mit einem anderen SCTP-Endpunkt Z aufbauen möchte, MUSS einen INIT-Chunk senden. Wenn Z die Assoziation akzeptiert, MUSS er mit einem Paket antworten, das einen INIT ACK-Chunk enthält. Die Etablierung der Assoziation wird im Folgenden weiter diskutiert.

5.1.1. Behandlung von Stream-Parametern (Handle Stream Parameters)​

Im INIT- oder INIT ACK-Chunk KANN der Sender den Empfänger auffordern, bestimmte Adresstypen zu verwenden, indem er einen Parameter "Unterstützte Adresstypen (Supported Address Types)" im optionalen/variablen Längenparameter-Abschnitt einfügt. Der Sender SOLLTE diesen Parameter einfügen, wenn er nicht alle Adresstypen unterstützt oder seinen Peer auf die Verwendung bestimmter Adresstypen beschränken möchte.

Ein Empfänger eines INIT oder INIT ACK MUSS alle nachfolgenden Kommunikationen unter Verwendung eines der in der Liste angegebenen Adresstypen oder des Adresstyps senden, an den INIT oder INIT ACK gesendet wurde (falls nicht aufgelistet).

Wenn der Empfänger keinen vom Sender erwarteten Adresstyp unterstützt oder vermeiden möchte, KANN er die Assoziation abbrechen und SOLLTE einen Fehler "Nicht unterstützter Adresstyp (Unsupported Address Type)" senden.

Hinweis: Wenn ein INIT oder INIT ACK einen Parameter "Unterstützte Adresstypen (Supported Address Types)" enthält, MUSS der Empfänger nur einen der im Parameter gefundenen Adresstypen oder den Adresstyp verwenden, an den INIT/INIT ACK gesendet wurde, auch wenn der Empfänger in der Lage ist, andere Adresstypen zu verwenden.

In einem INIT- oder INIT ACK-Chunk gibt der Sender seine Stream-Kapazität durch die Parameter "Anzahl ausgehender Streams (Number of Outbound Streams, OS)" und "Anzahl eingehender Streams (Number of Inbound Streams, MIS)" an, die er einfügt.

Der Empfänger SOLLTE den Wert verwenden, den der Sender im OS-Feld des INIT oder INIT ACK angibt, als maximale Anzahl seiner eigenen eingehenden Streams (d.h. MIS des Empfängers). Der Sender verwendet den MIS-Parameter, um die Anzahl der Streams zu begrenzen, auf denen der Peer Benutzernachrichten senden kann.

Im INIT oder INIT ACK DARF die Anzahl ausgehender Streams (OS) und die Anzahl eingehender Streams (MIS) des Senders NICHT 0 sein.

Wenn ein Empfänger ein INIT oder INIT ACK empfängt, bei dem der OS- oder MIS-Wert 0 ist, SOLLTE der Empfänger die Assoziation abbrechen, einen ABORT-Chunk senden und KANN den Fehler "Ungültiger obligatorischer Parameter (Invalid Mandatory Parameter)" melden.

Der Empfänger MUSS auch seine Verwendung ausgehender Streams auf die tatsächliche Anzahl begrenzen, die im MIS-Feld des INIT oder INIT ACK empfangen wurde. Mit anderen Worten, nach der Etablierung der Assoziation wird ein Endpunkt Folgendes verwenden:

Anzahl ausgehender Streams zum Senden von Benutzernachrichten = 
    minimum(lokales OS, MIS des Peers)

Anzahl eingehender Streams zum Empfangen von Benutzernachrichten = 
    minimum(lokales MIS, OS des Peers)

5.1.2. Behandlung von Adressparametern (Handle Address Parameters)​

Während der Initialisierung (vor dem Senden des INIT oder INIT ACK) SOLLTE der Sender alle seine Adressen im INIT oder INIT ACK unter Verwendung des optionalen IPv4-Adressparameters und/oder IPv6-Adressparameters einfügen. Das Weglassen dieses optionalen Parameters zeigt an, dass der Endpunkt nur eine Adresse hat, die Quelladresse, die zum Senden des INIT oder INIT ACK verwendet wird.

Vor dem Senden eines INIT-Chunks SOLLTE ein Endpunkt immer in den COOKIE-WAIT-Zustand eintreten.

Hinweis: Das Fehlen von Adressen in einem INIT-Chunk bedeutet nicht, dass der sendende Endpunkt keine anderen Adressen akzeptiert. Im Gegenteil, das Fehlen von Adressen zeigt an, dass der Sender nicht abgehört werden möchte, aber er wird Nachrichten akzeptieren, die von einer der Adressen seines Peers gesendet werden.

Wenn der Empfänger keinen der vom Sender im INIT oder INIT ACK bereitgestellten Adresstypen unterstützt, SOLLTE er die Assoziation abbrechen und KANN eine Fehlerursache "Nicht unterstützter Adresstyp (Unsupported Address Type)" senden.

Ein Empfänger eines INIT oder INIT ACK MUSS alle bereitgestellten Adressinformationen (wie auch immer erhalten, einschließlich aus dem IP-Header, IPv4-Adressparameter und/oder IPv6-Adressparameter) aufzeichnen und diese Informationen verwenden, um seine Transportadressmenge zu bestimmen.

Wenn der Sender einen Parameter "Hostname-Adresse (Host Name Address)" einfügt, MUSS der Empfänger sofort einen ABORT-Chunk senden und KANN eine Fehlerursache "Nicht auflösbare Adresse (Unresolvable Address)" einfügen.

Hinweis: Die Verwendung des Parameters "Hostname-Adresse (Host Name Address)" ist veraltet. Ein Empfänger MUSS jeden Parameter "Hostname-Adresse (Host Name Address)" in einem INIT oder INIT ACK ignorieren und SOLLTE als Antwort einen ABORT-Chunk senden.

Ein Endpunkt, der einen INIT ACK sendet, sollte einen State Cookie erstellen und ihn in den State Cookie-Parameter des INIT ACK einfügen. Siehe Abschnitt 5.1.3 für die Verwendung des State Cookie.

Der State Cookie sollte die folgenden minimal erforderlichen Informationen enthalten:

  • Informationen aus dem empfangenen INIT-Chunk (einschließlich Initiate Tag und optionale/variable Längenparameter)
  • Die Zeit, zu der der State Cookie erstellt wurde
  • Eine Lebensdauer (die Zeit, in der der Cookie gültig ist)
  • Eine Methode zur Authentifizierung der Integrität und Authentizität des State Cookie (z.B. ein Message Authentication Code (MAC))

Implementierungshinweis: Der State Cookie kann verwendet werden, um zusätzliche Informationen über den Zustand der gerade aufzubauenden Assoziation zu speichern. Dies ermöglicht es einem Endpunkt, die Zuweisung von Ressourcen (TCB) während der Assoziationsetablierung aufzuschieben. Diese Optimierung wird als "Cookie-Ansatz (Cookie Approach)" bezeichnet und kann einfache Denial-of-Service-Angriffe verhindern.

Eine Implementierung, die einen INIT ACK sendet, SOLLTE den State Cookie ausreichend robust schützen, um zu verhindern, dass ein Angreifer gültige State Cookies errät. Eine empfohlene Technik besteht darin, im State Cookie Folgendes einzufügen:

  • Eine zufällige Nonce (eindeutig pro Assoziationsinstanz)
  • Einen Zeitstempel
  • Die Quelladresse des Peers
  • Den Quellport des Peers
  • Die lokale Zieladresse
  • Den lokalen Zielport
  • Einen MAC, der alle oben genannten Felder abdeckt

Der geheime Schlüssel, der zum Erstellen dieses MAC benötigt wird, SOLLTE bei der Initialisierung des SCTP-Stacks erstellt werden und sollte regelmäßig aktualisiert werden. Dieser Schlüssel MUSS für jeden außerhalb der kommunizierenden Parteien geheim gehalten werden.

Das Einfügen dieser Werte in den State Cookie-Parameter des INIT ACK ermöglicht die Validierung des im COOKIE ECHO-Chunk zurückgegebenen State Cookie. Der Validierungsprozess wird in Abschnitt 5.1.4 beschrieben.

Zusätzlich KANN der Sender alle anderen Daten einfügen, die zum Generieren des State Cookie benötigt werden, der zur Validierung des in COOKIE ECHO zurückgegebenen Cookies und zur Etablierung der Assoziation verwendet wird.

Hinweis: Die MAC-Berechnung MUSS den Zeitstempel einschließen, um sicherzustellen, dass ein wiederholter Cookie nicht als Denial-of-Service-Angriffswerkzeug verwendet werden kann.

Wenn ein Endpunkt einen State Cookie in einem COOKIE ECHO-Chunk empfängt, MUSS er diesen Cookie gemäß Folgendem validieren:

  1. Überprüfen, dass der MAC des State Cookie gültig ist. Wenn der MAC ungültig ist, das Paket stillschweigend verwerfen.

  2. Überprüfen, dass der State Cookie nicht veraltet ist. Wenn der State Cookie veraltet ist, SOLLTE der Endpunkt einen ERROR-Chunk mit dem Ursachencode "Stale Cookie Error" senden und das Paket stillschweigend verwerfen. Das Veraltetsein des State Cookie kann mit dem Parameter "Cookie Preservative" angepasst werden. Siehe Abschnitt 5.1.3.

  3. Überprüfen, dass die Quelladresse und Portnummern mit den im State Cookie gespeicherten Werten übereinstimmen. Wenn sie nicht übereinstimmen, das Paket stillschweigend verwerfen.

Wenn der State Cookie gültig ist, SOLLTE der Endpunkt eine Assoziation zu diesem Peer erstellen und einen COOKIE ACK-Chunk an den Sender senden. Der Endpunkt sollte dann diese Assoziation in den ESTABLISHED-Zustand verschieben.

Eine Implementierung MUSS die Integrität und Authentizität des State Cookie mit einer Technik wie unten beschrieben oder einer gleichwertigen Technik schützen.

Die empfohlene Technik besteht darin, einen Message Authentication Code (MAC) im State Cookie einzufügen. Der MAC SOLLTE unter Verwendung eines geheimen Schlüssels berechnet werden, der dem Sender bekannt ist, aber jedem potenziellen Angreifer unbekannt ist.

Der MAC-Algorithmus SOLLTE mindestens so sicher sein wie HMAC-SHA-1, wie in [RFC2104] und [RFC3174] definiert.

Um den MAC zu erstellen und zu verifizieren, wird ein geheimer Schlüssel benötigt. Dieser geheime Schlüssel SOLLTE regelmäßig geändert werden (z.B. alle paar Stunden), um die Fähigkeit eines Angreifers zu begrenzen, den Schlüssel durch Beobachtung legitimen Verkehrs abzuleiten.

Während der Änderungen des geheimen Schlüssels SOLLTE eine Implementierung den alten Schlüssel für eine gewisse Zeit (mindestens das Doppelte der Cookie-Lebensdauer) behalten, um die Validierung von Cookies zu ermöglichen, die mit dem alten Schlüssel erstellt wurden.

5.1.6. Ein Beispiel für normale Assoziationsetablierung (An Example of Normal Association Establishment)​

Im einfachsten Fall würde die normale Assoziationsetablierung eines Endpunkts A, der eine Assoziation zu Endpunkt Z aufbauen möchte, wie folgt aussehen:

Endpunkt A                                     Endpunkt Z

INIT    ----[INIT ACK mit State Cookie]----->
        <----------[COOKIE ECHO]-------------
        ----------[COOKIE ACK]--------------->

Zu diesem Zeitpunkt ist die Assoziation an beiden Enden ESTABLISHED.

Detaillierte Schritte:

A) Endpunkt A sendet einen INIT-Chunk an Endpunkt Z und zeigt seinen Wunsch an, eine Assoziation aufzubauen. Im INIT-Chunk MUSS Endpunkt A sein Verification Tag (das in allen Paketen von Z verwendet wird), das von ihm unterstützte anfängliche TSN, die Anzahl ausgehender Streams (OS), die maximale Anzahl eingehender Streams (MIS) und seine anderen Transportadressen (falls vorhanden) bereitstellen.

B) Nach Empfang des INIT SOLLTE Endpunkt Z mit einem INIT ACK-Chunk antworten. Im INIT ACK MUSS Z sein Verification Tag, sein anfängliches TSN, sein OS, MIS und seine Transportadressen (falls zutreffend) bereitstellen. Zusätzlich MUSS Z einen State Cookie erstellen und ihn im INIT ACK einfügen.

C) Nach Empfang des INIT ACK, das den State Cookie enthält, SOLLTE Endpunkt A mit einem COOKIE ECHO-Chunk antworten. Der COOKIE ECHO-Chunk MUSS den im INIT ACK empfangenen State Cookie enthalten. Zusätzlich KANN Endpunkt A Benutzerdaten gebündelt mit dem COOKIE ECHO im selben Paket senden.

D) Nach Empfang des COOKIE ECHO wird Endpunkt Z den State Cookie validieren. Wenn gültig, wird Z die Assoziation erstellen und mit einem COOKIE ACK-Chunk antworten. Zusätzlich KANN Z Benutzerdaten gebündelt mit dem COOKIE ACK im selben Paket senden.

E) Nach Empfang des COOKIE ACK wird Endpunkt A seinen Assoziationszustand von COOKIE-ECHOED zu ESTABLISHED ändern. A kann jetzt Benutzerdaten auf der etablierten Assoziation senden und empfangen.

Zu jedem Zeitpunkt während der Lebensdauer einer Assoziation kann ein Endpunkt unerwartete oder doppelte INIT-, INIT ACK-, COOKIE ECHO- oder COOKIE ACK-Chunks empfangen. Dieser Abschnitt beschreibt, wie diese Chunks behandelt werden.

5.2.1. INIT im CLOSED-Zustand empfangen (INIT Received in CLOSED State)​

Wenn sich ein Endpunkt im CLOSED-Zustand befindet und einen INIT-Chunk empfängt, SOLLTE er mit einem INIT ACK antworten, wie in Abschnitt 5.1 beschrieben.

5.2.2. Unerwartetes INIT im Cookie-Wait- oder Cookie-Echoed-Zustand (Unexpected INIT in Cookie-Wait or Cookie-Echoed State)​

Wenn sich ein Endpunkt im COOKIE-WAIT- oder COOKIE-ECHOED-Zustand befindet und einen INIT-Chunk empfängt, dessen Initiate Tag nicht mit seinem aufgezeichneten Peer Verification Tag übereinstimmt, SOLLTE der Endpunkt das alte TCB (falls vorhanden) verwerfen und mit einem INIT ACK auf den neuen INIT-Chunk antworten.

Wenn sich ein Endpunkt im COOKIE-WAIT- oder COOKIE-ECHOED-Zustand befindet und einen INIT-Chunk empfängt, dessen Initiate Tag mit seinem aufgezeichneten Peer Verification Tag übereinstimmt, SOLLTE der Endpunkt mit einem INIT ACK antworten, aber seinen Zustand nicht ändern. Diese Situation kann auftreten, wenn der Peer das INIT ACK nicht empfangen oder verloren hat.

5.2.3. Unerwartetes INIT ACK im CLOSED- oder COOKIE-WAIT-Zustand (Unexpected INIT ACK in CLOSED or COOKIE-WAIT State)​

Wenn sich ein Endpunkt im CLOSED-Zustand oder COOKIE-WAIT-Zustand befindet und ein INIT ACK empfängt, SOLLTE der Endpunkt einen ABORT-Chunk senden und KANN eine Fehlerursache "Out of the Blue" einfügen (siehe Abschnitt 3.3.10).

Wenn sich ein Endpunkt im COOKIE-WAIT-Zustand befindet und ein INIT ACK empfängt, dessen Initiate Tag-Feld nicht mit seinem eigenen Tag übereinstimmt, SOLLTE der Endpunkt in den CLOSED-Zustand eintreten, das TCB zerstören und einen ABORT-Chunk senden.

Dieser Abschnitt beschreibt das Verhalten, wenn ein Endpunkt einen COOKIE ECHO-Chunk in anderen Zuständen als CLOSED und COOKIE-ECHOED empfängt.

Implementierungshinweis: Ein Endpunkt kann zu jedem Zeitpunkt während der Assoziationslebensdauer einen COOKIE ECHO-Chunk empfangen, typischerweise aufgrund von Peer-Neuübertragung oder Netzwerkverzögerung.

Wenn ein Endpunkt einen COOKIE ECHO-Chunk empfängt und ein TCB für dieselbe Assoziation existiert, SOLLTE der Endpunkt ihn gemäß einer der folgenden Aktionen behandeln:

A) Wenn der aktuelle Zustand ESTABLISHED ist, SOLLTE der Endpunkt den COOKIE ECHO stillschweigend verwerfen. Alternativ, wenn der Peer ein falsches Verification Tag im COOKIE ECHO einfügt, KANN der Endpunkt einen ABORT-Chunk senden.

B) Wenn der aktuelle Zustand SHUTDOWN-ACK-SENT ist, SOLLTE der Endpunkt den COOKIE ECHO stillschweigend verwerfen.

In allen anderen Fällen SOLLTE der Endpunkt den COOKIE ECHO als Versuch behandeln, eine neue Assoziation gemäß den Regeln in Abschnitt 5.2.4 aufzubauen, aber alle Informationen im vorhandenen TCB verwenden, um den Assoziationsetablierungsprozess zu optimieren.

Wenn ein Endpunkt einen COOKIE ACK-Chunk außerhalb des COOKIE-ECHOED-Zustands empfängt, SOLLTE er den Chunk stillschweigend verwerfen.

Wenn ein Endpunkt nach dem Senden eines COOKIE ECHO-Chunks einen ERROR-Chunk mit einer Fehlerursache "Stale Cookie" empfängt und sich der Endpunkt im COOKIE-ECHOED-Zustand befindet, KANN der Endpunkt versuchen, die Assoziation mit einem neuen INIT-Chunk erneut aufzubauen.

Wenn der Endpunkt sich für einen erneuten Versuch entscheidet, SOLLTE er einen "Cookie Preservative"-Parameter im neuen INIT-Chunk einfügen, dessen Wert auf das im empfangenen "Stale Cookie"-Fehler angegebene Measure of Staleness-Feld gesetzt ist.

Wenn der Endpunkt sich gegen einen erneuten Versuch entscheidet, SOLLTE er in den CLOSED-Zustand eintreten und das Problem seiner oberen Schicht melden.

5.3. Weitere Initialisierungsprobleme (Other Initialization Issues)​

5.3.1. Auswahl des Standardports (Selection of Default Port)​

Ein SCTP-Endpunkt SOLLTE das Empfangen und Senden von SCTP-Paketen an UDP-Port 9899 (den Standardport für SCTP über UDP-Kapselung) unterstützen.

5.3.2. IPv4/IPv6-Koexistenz (IPv4/IPv6 Coexistence)​

Eine Implementierung SOLLTE die Verwendung sowohl von IPv4- als auch von IPv6-Adressen unterstützen, wie in [RFC4213] empfohlen.

5.3.3. SCTP-Assoziationsidentifikator (SCTP Association Identifier)​

Jede SCTP-Assoziation wird eindeutig durch ein Paar von Verification Tags identifiziert:

  • Das lokale Verification Tag (vom Peer in seinem INIT oder INIT ACK bereitgestellt)
  • Das Verification Tag des Peers (im lokalen INIT oder INIT ACK gesendet)

Dieses Paar von Tags wird verwendet, um empfangene SCTP-Pakete zu demultiplexen.

5.4. Pfadverifizierung (Path Verification)​

Während des normalen Betriebs MUSS ein SCTP-Endpunkt den Heartbeat-Mechanismus verwenden, um die Erreichbarkeit der Pfade seines Peers zu überprüfen.

Während der Initialisierung (nach dem Senden des INIT ACK) SOLLTE ein Endpunkt den Heartbeat-Mechanismus verwenden, um zu überprüfen, dass alle im INIT oder INIT ACK empfangenen Adressen erreichbar sind.

Diese Überprüfung SOLLTE unmittelbar nach dem Eintritt der Assoziation in den ESTABLISHED-Zustand beginnen.

Implementierungshinweis: Wenn ein Endpunkt ein INIT oder INIT ACK empfängt, das mehrere IP-Adressen enthält, SOLLTE er versuchen, alle bereitgestellten Adressen zu überprüfen, indem er HEARTBEATs an jede Adresse sendet.

Adressen, die während des Überprüfungsprozesses nicht auf HEARTBEATs antworten, SOLLTEN als inaktiv markiert werden und sollten nicht in der normalen Datenübertragung verwendet werden, es sei denn, sie werden später als aktiv nachgewiesen (durch HEARTBEAT oder Datenübertragung).

Dieses Kapitel wird fortgesetzt...

Für detailliertere Inhalte in Kapitel 5 (einschließlich spezifischer Fehlerbehandlung, Timeout-Mechanismen und sicherheitsrelevanter Überlegungen) konsultieren Sie bitte den vollständigen Text von RFC 4960.

Letztes Update am