Zusammenfassung

  • RFC 3358 definierte einen optionalen TLV mit 16-Bit-Fletcher-Prüfsumme für IS-IS-CSNPs, -PSNPs und -IIHs, weil die Sicherung der Linkschicht nicht zwingend die vom Routingprozess gelesenen Bytes schützte.
  • Fehlender TLV und Nullwert blieben kompatibel; eine falsche, doppelte oder unzulässig platzierte Prüfsumme führte zum Verwerfen. Zufällige Beschädigung wurde erkannt, ein Absender aber nicht authentisiert.

Der Frame konnte am Eingang vollkommen unauffällig sein. Er kam an, bestand die dortige Prüfung und wurde nach oben gereicht. Erst als IS-IS ein verändertes Längenfeld interpretierte, zeigte sich, dass der grüne Status der unteren Schicht eine andere Frage beantwortet hatte als der Routingprozess.

RFC 3358 erschien im August 2002 als Informational RFC von T. Przygienda aus der ISIS Working Group. Das Dokument wollte IS-IS nicht neu entwerfen. LSPs besaßen bereits eine eigene Prüfsumme. Complete Sequence Number PDUs, Partial Sequence Number PDUs und IS-IS Hello PDUs verließen sich dagegen auf Integrität unterhalb des Routingprotokolls.

Diese Annahme konnte durch eine fehlerhafte Implementierung der unteren Schicht oder eine Linktechnologie ohne die erwartete Prüfung brechen. Dann erreichte eine beschädigte PDU den Prozess, der ihre Struktur verstand. Traf die Änderung ein PDU- oder TLV-Längenfeld, verschob sich nicht nur ein Wert, sondern die Grenze, nach der alle folgenden Bytes gelesen wurden.

So konnte ein kleiner physischer Fehler semantisch anwachsen. Eine Zusammenfassung schien plötzlich viele leere oder gar nicht vorhandene LSP-Einträge zu enthalten. Die Linkprüfung hatte einen wahren Beleg geliefert, doch dieser Beleg galt nicht für die Datenstruktur, aus der die Link-State-Datenbank Schlüsse ziehen sollte.

Die Reparatur blieb klein: TLV-Typ 12, Länge zwei, mit einer 16-Bit-Fletcher-Prüfsumme über die vollständige PDU nach den Regeln des Dokuments. RFC 3359 nahm Typ 12 in das Register der IS-IS-TLV-Codepunkte auf. Entscheidend war weniger der Algorithmus als sein Platz an der Grenze, die das Kontrollobjekt konsumierte.

Ein unterstützender Empfänger prüft einen einzelnen zulässigen TLV mit einem Wert ungleich null. Stimmt die Summe nicht, verwirft er die PDU. Mehrere Prüfsummen-TLVs sind ebenfalls ein Fehler, ebenso ein TLV in einem nicht erlaubten PDU-Typ. Die mehrdeutige Struktur gelangt so nicht in die Datenbanklogik.

Ein fehlender TLV bleibt hingegen gültig. Ältere Geräte sendeten Typ 12 nicht, und eine optionale Erweiterung musste schrittweise einführbar sein. Ein alter Empfänger konnte den unbekannten TLV nach seinen normalen Regeln behandeln, ohne RFC-3358-Prüfung. Veröffentlichung, Senderfähigkeit und tatsächlich beobachtete Verifikation sind daher drei verschiedene Tatsachen.

Auch der Nullwert besitzt eine eigene Bedeutung. Der RFC behandelt ihn als korrekt, doch null belegt keine Berechnung und keinen Vergleich einer nichtnulligen Fletcher-Summe. Im Betrieb müssen fehlend, null, nichtnullig verifiziert, falsch, doppelt und falsch platziert getrennt bleiben. Eine einzige Anzeige „Prüfsumme in Ordnung“ würde den Beweisumfang verwischen.

Die Wechselwirkung mit Authentisierung schärft die Grenze. Wenn kryptografische Berechnung und Prüfsumme Felder abdecken, die voneinander abhängen, entsteht ein Reihenfolge- oder Zirkelproblem. Bei Authentisierung wie HMAC-MD5 verlangt RFC 3358 deshalb, die optionale Prüfsumme wegzulassen oder null zu senden. RFC 5304 und RFC 5310 behandeln kryptografische IS-IS-Authentisierung und liefern eine andere Art Beleg.

Fletcher erkennt zufällige Veränderungen. Die Summe beweist nicht, wer eine PDU erzeugt hat, ob der Absender berechtigt war, ob eine alte PDU wiederholt wurde oder ob ein Angreifer den Wert neu berechnet hat. Byteintegrität, Identität und Autorisierung dürfen nicht unter dem Wort Sicherheit zusammenfallen.

Auch die Dokumentgeschichte braucht Grenzen. RFC 1195 beschreibt integriertes IS-IS in TCP/IP-Umgebungen. RFC 1142 veröffentlichte Material im Umfeld von ISO 10589 erneut; RFC 7142 stufte ihn später als Historic ein und erklärte, dass er nicht als IETF-Standard gedacht war. Diese Linie sagt nichts über die tatsächliche Verbreitung von Typ 12.

Spätere RFCs zeigen die operative Bedeutung der PDU-Familien, aber keinen benannten RFC-3358-Ausfall. RFC 5303 ergänzt den Dreiwege-Handshake in Punkt-zu-Punkt-IIHs. RFC 5306 nutzt Restart-Signalisierung. RFC 6232 identifiziert den Urheber einer LSP-Löschung. Daraus folgt nicht, dass ihre Probleme von der 2002 beschriebenen Beschädigung verursacht wurden.

Im Primärtext fehlen ein benannter Vorfall, eine Herstellerliste, eine Einführungsquote und ein Vorher-nachher-Messwert. Er definiert Verhalten für Zustände, nicht die Häufigkeit dieser Zustände im Produktionsnetz.

Ein Betreiber braucht deshalb eine Matrix pro Nachbarschaft: Sendet der Peer den TLV, versteht der Empfänger ihn, erklärt Authentisierung den Nullwert oder das Fehlen, und trennen Zähler falsche Summe, Duplikat und unzulässigen PDU-Typ? Änderungen müssen zeitlich mit Captures, Interfacefehlern, Softwareständen und Topologie abgeglichen werden. Die Prüfsumme zeigt, wo Beschädigung sichtbar wurde, nicht wer sie verursachte.

Die Einführung beginnt mit Inventar und Beobachtung. Unterstützung lässt sich aktivieren, ohne Fehlen sofort als Störung zu werten. Für nichtnullige Prüfungen und Verwerfungsgründe werden Basiswerte gebildet. Erst wenn mehrere Belege zusammenpassen, ist eine Ursachenbehauptung gerechtfertigt.

Daraus folgt eine allgemeine Regel: Jedes Integritätsergebnis hat einen Geltungsbereich. Frameprüfung, PDU-Prüfsumme, Authentisierung, Datenbankkonsistenz, korrekte Route und Nutzererreichbarkeit beantworten verschiedene Fragen. Der Erfolg einer Schicht wird nicht automatisch zur Wahrheit der nächsten.

Zwei Texte von Lu Heng dienen als offengelegte redaktionelle Perspektive. „Minimum Initial Specification“ hilft, Typ 12 als kleine, freiwillige und lokal einführbare Reparatur zu lesen. „Reality Layers“ trennt materielle Bytes, das Symbol „Frame bestanden“, Protokollinterpretation und Vorfallserzählung. Beides schreibt dem RFC-Autor keine zusätzliche Absicht zu.

Der Frame hatte seine Prüfung bestanden. RFC 3358 machte sichtbar, dass der Routingprozess noch einen eigenen Beleg brauchte.

Quellen