Zusammenfassung

  • RFC 6525 erlaubte es, den Sequenzzustand ausgewählter SCTP-Streams auf null zu setzen, ohne die Assoziation oder nicht genannte Streams zu beenden.
  • Sender’s Last Assigned TSN markierte das Ende der alten Epoche. Solange der kumulative Bestätigungspunkt diese Grenze nicht erreicht hatte, antwortete der Empfänger mit „In progress“ und hielt neuere Daten zurück.
  • Die Reconfiguration besaß eigene Anforderungsnummern, wiederholbare Antworten und ein Ablehnungsrecht. Wer Datensequenzen vergessen wollte, musste die Geschichte des Vergessens zuverlässig bewahren.

Null ließ die Vergangenheit nicht aus dem Netz verschwinden

Eine SCTP-Assoziation führt mehrere unidirektionale Streams. Im RFC 4960 trägt jedes DATA-Fragment eine assoziationsweite Transmission Sequence Number; geordnete Nachrichten erhalten zusätzlich eine Stream Sequence Number innerhalb ihres Streams. RFC 9260 behält die Trennung zwischen Bestätigung und Duplikaterkennung per TSN und lokaler Reihenfolge per Stream bei.

Eine Anwendung kann die alte Aufgabe von Stream 3 beendet haben, während Fragmente noch erneut gesendet werden. Ein sofortiger SSN-Sprung auf null ließe ein verspätetes Fragment wie neue Daten aussehen. Das Schließen der ganzen Assoziation würde dagegen andere Streams und Pfadzustände zerstören.

RFC 6525 führte 2012 den RE-CONFIG-Chunk ein. Er löschte keine Pakete in Bewegung. Er koordinierte den Punkt, an dem beide Seiten eine Nummerierung beenden und die nächste beginnen konnten.

Die letzte vergebene TSN zog eine Grenze

Eine Outgoing SSN Reset Request enthält Reconfiguration Request Sequence Number, Response Sequence Number, Sender’s Last Assigned TSN und optional Streamnummern. Ohne Liste gilt sie für alle ausgehenden Streams; mit Liste bleiben die übrigen unverändert.

Die letzte vergebene TSN ist die nächste TSN minus eins. Vor der Anfrage vergibt der Sender keine neuen SSNs für die betroffenen Streams und stellt folgende Nachrichten an. Würde er bei unbekanntem Ergebnis weitersenden, könnte eine verlorene Anfrage zwei Epochen ununterscheidbar machen.

Der Empfänger vergleicht die Grenze mit seinem kumulativen Bestätigungspunkt. Liegt dieser davor, beginnt deferred reset processing. Daten der betroffenen Streams oberhalb der Grenze werden lokal gehalten; „In progress“ bestätigt das Verständnis der Anfrage, nicht ihren Abschluss.

Erst wenn die kumulative Bestätigung die Grenze erreicht, setzt der Empfänger die nächste erwartete SSN der genannten Streams auf null, gibt gehaltene TSNs frei und meldet Erfolg. Nicht genannte Streams laufen weiter. Die neue Epoche beginnt an einem gemeinsam beweisbaren Punkt.

Der Befehl zum Vergessen brauchte ein Gedächtnis

RE-CONFIG-Anfragen tragen monoton steigende Nummern, die von der anfänglichen TSN abgeleitet sind. Antworten kopieren die Nummer und melden unter anderem Erfolg, Ablehnung, falsche SSN, bereits laufende Anfrage, falsche Sequenz oder laufende Bearbeitung.

Kommt die letzte Anfrage als Wiederholung an, gibt der Empfänger dieselbe frühere Antwort und führt keinen zweiten Reset aus. Bei „In progress“ startet der Anforderer seinen Timer neu, ohne die Fehlerzähler der Assoziation zu erhöhen. Das Ergebnis ist weder Pfadausfall noch Stausignal.

Der Peer darf ablehnen. RFC 6525 nennt dies eine administrative Entscheidung, die auch nach Aufbau der Assoziation konfigurierbar bleibt. Unterstützung des Kontrollwortschatzes ist keine pauschale Zustimmung zu jeder Zustandsänderung.

Gleichzeitige Anfragen zeigen zudem den Unterschied zwischen vollständiger und teilweiser Überlappung. Ist eine eingehende Anfrage ganz von einem bereits wartenden ausgehenden Reset erfasst, kann „Nothing to do“ genügen. Eine nur teilweise Überschneidung wird normal verarbeitet, selbst wenn ein Stream bei null erneut auf null gesetzt wird. Zusätzlicher Kontrollverkehr ist sicherer als das unbelegte Zusammenlegen verschiedener Absichten.

Die Erweiterung kann auch zusätzliche ein- oder ausgehende Streams anfordern. Ein neuer ausgehender Stream darf vor einer positiven Peer-Antwort nicht benutzt werden. RE-CONFIG ist damit keine freie Schreibberechtigung für die Assoziation, sondern eine Familie bestätigungspflichtiger Zustandsänderungen.

Ein- und Ausgang hatten verschiedene Herren

Ein SCTP-Stream ist unidirektional. Dieselbe Nummer in Gegenrichtung erzeugt nicht automatisch einen bidirektionalen Kanal. Wer seine eingehende Sequenz zurücksetzen will, bittet den Peer um den Reset seiner ausgehenden Streams; nur der Nummerngeber kennt den alten Sendeschnitt.

SSN/TSN Reset ist eine getrennte, breitere Operation. Sie setzt alle SSNs zurück und wählt neue TSN-Anfänge. Der Sender stoppt dabei die TSN-Vergabe; Vorsorge über die maximale Segmentlebensdauer verhindert Mehrdeutigkeit beim Nummernumlauf. Das ist nicht bloß ein stärkerer selektiver Reset.

RFC 6458 macht Sequenzen und Benachrichtigungen für Anwendungen sichtbar. Deshalb müssen Reconfiguration und Ereignisse ausdrücklich aktiviert werden. Eine Anwendung mit Monotonieannahme muss den Epochenwechsel erfahren.

I-DATA änderte den Zähler, nicht die Grenze

RFC 8260 verwendet für Message Interleaving 32-Bit Message Identifiers in I-DATA. Beim Reset gehen zwei MID-Zähler, für geordnete und ungeordnete Nachrichten, auf null. Späte TSN-Vergabe vieler Scheduler erschwert die Umsetzung, beseitigt aber die alte Grenze nicht.

Das Verfahren ist auch keine Partial Reliability. RFC 7496 ergänzt Regeln zum Aufgeben von Nachrichten nach Priorität oder Wiederholungszahl. Aufgabe entscheidet, wie lange eine Nachricht verfolgt wird; Reset entscheidet, wann ein Nummernraum wiederverwendet werden darf.

Das IANA-Register der SCTP-Parameter weist RE-CONFIG den Typ 130 zu. Es erklärt Zahlen in einem Mitschnitt, beweist aber weder Implementierung noch Aushandlung oder Aktivierung durch die Anwendung.

RFC 6525 hält außerdem fest, dass SCTP-Verifikationstags weiterhin gegen blinde Angreifer wirken. Das ist eine enge Aussage: Sie authentifiziert keine Anwendungsabsicht, deckt keinen Angreifer auf dem Pfad ab und ersetzt keine administrative Autorisierung. Eine Betriebsbehauptung braucht daher ausgehandelte Fähigkeit, Socket-Konfiguration und den beobachteten Ausgang der Anfrage.

Quellen