Zusammenfassung

  • Erst wenn der Peer in INIT oder INIT ACK eine unterstützte alternative Fehlererkennung für die konkrete Assoziation angekündigt hat, darf der Sender eine absichtlich falsche Null einsetzen.
  • Der Ersatz muss mindestens die Erkennungsqualität von CRC32c erreichen und einen Middlebox-bedingten Pfadausfall innerhalb von zwei RTO begrenzen; für Aufbau, Sonderfälle und Rückfall bleibt CRC32c Pflicht.

Nicht jede Null bedeutet dasselbe

Der normale SCTP-Pfad beginnt mit einer 32 Bit breiten CRC32c im Common Header. Gemäß RFC 9260 wird sie über den Header und sämtliche Chunks berechnet; Pakete mit ungültigem Ergebnis werden verworfen. Ein IPv4- oder IPv6-Pseudoheader gehört nicht zum Berechnungsbereich. Michael Tüxen ist Mitautor dieser aktuellen SCTP-Grundspezifikation.

Ausgerechnet die Null taugt jedoch nicht als eindeutiger Auslassungsmarker. Auch eine korrekt berechnete CRC32c kann null ergeben. Ein Empfänger kann dem Feld allein folglich nicht ansehen, ob gerechnet wurde oder ob ein Sender nach vorheriger Erlaubnis bewusst einen falschen Nullwert gesetzt hat. Wer in der Telemetrie nur den Wert behält, löscht den Unterschied zwischen Ergebnis und Absicht.

RFC 9653 verlagert die Bedeutung in den Aufbau der Assoziation. Ein Endpunkt darf in INIT oder INIT ACK höchstens einen Zero Checksum Acceptable Parameter senden. Darin nennt er eine konkrete alternative Methode. Erst nach Empfang dieser Erklärung, bei eigener Unterstützung und nach einer gegebenenfalls nötigen Freigabe durch die obere Schicht darf der Sender die absichtlich falsche Null verwenden.

Die Erlaubnis gilt weder dauerhaft für den Host noch pauschal für eine Anwendung. Sie hängt am Peer, an der Assoziation und an der Methode. Eine belastbare Analyse muss deshalb den Eröffnungsaustausch, die Methodenkennung, die tatsächlich aktive Kapselung und die Paketklasse zusammenführen.

Die Ersatzmethode braucht zwei Nachweise

Zunächst muss ihre Wahrscheinlichkeit, einen Fehler nicht zu erkennen, gleich oder geringer als bei CRC32c sein. Eine Methode kann außerdem Einschränkungen für einzelne Paketarten definieren. Der bloße Hinweis auf vorhandene Kryptografie reicht nicht: Sie muss genau die Pakete schützen, bei denen die korrekte Prüfsumme entfallen soll.

Der zweite Nachweis betrifft nicht die Endpunkte, sondern den Weg. Eine SCTP-verstehende Middlebox kann CRC32c prüfen und den absichtlich falschen Wert abweisen. RFC 9653 verlangt daher, dass ein solcher Pfadfehler nicht länger als zwei Retransmission-Timeout-Perioden anhält. Der Standard verspricht keine perfekte Durchlässigkeit; er begrenzt, wie lange eine falsche Annahme den Verkehr blockieren darf.

SCTP über DTLS nach RFC 8261 ist das ausdrücklich beschriebene vollständige Beispiel. DTLS bietet Vertraulichkeit, Quellauthentisierung und Integrität, wenn SCTP direkt über UDP oder über ICE/UDP läuft. Es übernimmt die Fehlererkennung. Zugleich bleibt das innere SCTP-Paket für Middleboxes unsichtbar, sodass sie dessen CRC nicht verwerfen können. RFC 9653 weist diesem Verfahren die Kennung 1 zu; sie ist eine Registernummer, kein Gütesiegel.

SCTP-AUTH aus RFC 4895 zeigt die Trennlinie. Steht AUTH als erster Chunk, kann die Authentisierung für geschützte Inhalte den ersten Nachweis erfüllen. Der Common Header bleibt aber sichtbar. Eine Middlebox kann weiterhin auf einer korrekten CRC bestehen. Ohne eine zusätzliche, deploymentspezifische Vorkehrung beweist AUTH allein daher nicht die Pfadverträglichkeit.

Wo die Grundregel weiter gilt

Auch nach erfolgreicher Aushandlung brauchen INIT, Antworten auf Out-of-the-blue-Pakete, COOKIE ECHO und ASCONF eine korrekte CRC32c. Dasselbe gilt für Pakete außerhalb der Bedingungen einer Methode. Ohne Ankündigung des Peers bleibt ohnehin jedes Paket unter der Ausgangsregel.

Auf Empfängerseite ist die Grenze spiegelbildlich: Eine falsche Null darf nur akzeptiert werden, wenn der Empfänger die betreffende Methode selbst angekündigt hat und deren Anforderungen erfüllt sind. Eine falsche Nichtnull wird dadurch nicht gültig. Eine korrekt errechnete Null bleibt ein normales Ergebnis. CRC32c muss deshalb für Aufbau, Ausnahmen, Rückfall und ältere Gegenstellen implementiert bleiben.

Die sichtbaren vier Bytes sind nur die Spitze des Steuerzustands. INIT-Parameter, Methodenunterstützung, Freigabe der oberen Schicht, äußerer Schutz, Paketklassifizierung, RTO-Timer und Middlebox-Verhalten entscheiden gemeinsam. Wer lediglich die Rechenoperation überspringt, ohne diesen Zustand abzubilden, implementiert nicht die Ausnahme, sondern bricht den Vertrag.

Tüxens Beitrag ist die prüfbare Grenze

Michael Tüxen leitet das Network Programming Laboratory der FH Münster. Der IETF Datatracker führt ihn als derzeitigen TCPM-Co-Vorsitzenden, TSVART-Reviewer und Beteiligten an zahlreichen RFCs. Seine Rolle sowohl bei der Basis als auch bei der Ausnahme erklärt die Kontinuität des Entwurfs.

RFC 3309 hatte Adler-32 gerade deshalb durch CRC32c ersetzt, weil SCTP eine bessere Fehlererkennung benötigte. RFC 9653 nimmt dieses Ziel nicht zurück. Die Arbeit darf auf eine qualifizierte Schicht wandern, doch Schutzwirkung und Pfadverhalten müssen belegbar bleiben.

Darin liegt die übertragbare Leistung: Redundanz wird nicht behauptet, sondern spezifiziert. Der Ersatz bekommt einen Namen, die Zustimmung einen Geltungsbereich, Ausnahmen eine Liste, ein Pfadproblem eine Frist und die Implementierung einen gemeinsamen Rückweg. Die Null spart möglicherweise Rechenarbeit; die Nachweiskette bleibt vollständig.

Quellen