Zusammenfassung

  • draft-ietf-ippm-ioam-data-integrity-20 lässt einen vertrauenswürdigen Validator eine kumulative AES-GMAC-Kette nachrechnen und Änderungen an den einbezogenen unveränderlichen Feldern erkennen.
  • Ein gültiger ICV beweist nicht, dass alle erwarteten Option-Types ankamen, ein kompromittierter Knoten wahr berichtete, Exportdaten unverändert blieben, keine Verzögerung stattfand oder sämtlicher Verkehr erfasst wurde.
  • Automatisierung braucht einen Beleg mit Soll-/Ist-Menge, Replay-Entscheidung, Validator-Provenienz, Export-Verwahrung, Abdeckungsnenner und unabhängiger Dienstmessung.

Am Ende steht nur ein Vergleich. Der rekonstruierte ICV entspricht dem Wert im Paket. Daraus folgt eine saubere, aber schmale Aussage: Unter der aktuellen Schlüssel-, Identitäts- und Replay-Sicht wurde in den einbezogenen Feldern keine Veränderung erkannt.

Ein grünes Bedienfeld macht daraus leicht „Pfad vertrauenswürdig“. Genau diese Erweiterung ist nicht durch den Vergleich gedeckt.

Revision 20 vom 19. Juli 2026 ist ein aktiver IPPM-Internet-Draft in der RFC-Editor-Warteschlange. Der erste Editor steht noch aus; IANA vermerkt, dass die geänderte Version erneut geprüft werden muss. Weder Warteschlange noch Standards-Track belegen Implementierung, Interoperabilität oder korrekten Betrieb.

Das Verfahren definiert geschützte Varianten für Pre-allocated Trace, Incremental Trace, Proof of Transit und Edge-to-Edge. Jeder Knoten, der die Kette fortschreibt, besitzt einen eigenen symmetrischen Schlüssel. Der zwölf Oktett lange Nonce enthält Key ID, Encapsulating Node ID und einen 64-Bit-Zähler. Der Startknoten schützt ausgewählte unveränderliche Headerfelder und seine Daten; Transitknoten falten den empfangenen ICV und ihre unveränderlichen Beiträge in den nächsten GMAC-Wert.

Übertragen wird nur der jüngste ICV. Der Validator muss die Teilnehmer erkennen, deren Schlüssel finden und die Reihenfolge rekonstruieren. Wie Knotenkennungen den Schlüsseln zugeordnet werden, bleibt außerhalb des Entwurfs. Das Urteil hängt also von einem lokalen Identitätsregister ab, das die Kryptografie nicht selbst legitimiert.

Ein echter Schlüssel kann eine falsche Aussage schützen

Ein kompromittierter Knoten kann Pakete fälschen oder verwerfen. Bei korrekter Schlüsselbindung kann er nicht unbemerkt als anderer Knoten auftreten oder dessen geschützten Beitrag verändern. Er kann aber unter seiner eigenen legitimen Identität einen erfundenen Messwert melden.

Die Kette hält fest, von welchem Schlüssel eine Aussage stammt und dass die geschützten Bytes später nicht verändert wurden. Sie bestätigt weder Sensorik noch Software oder Absicht. Provenienz ist eine notwendige Eigenschaft einer Aussage, nicht ihr Wahrheitsbeweis.

Deshalb gehören authentischer Beitrag und glaubwürdige Messung in getrennte Felder. Für die zweite Bewertung braucht es Build- und Konfigurationsnachweise, Attestierung, unabhängige Zähler und Vergleichsbeobachtungen.

Der Validator ist ein Machtzentrum

Der Entwurf nennt den Validator ausdrücklich vertrauenswürdig. Er besitzt Schlüsselmaterial und entscheidet abschließend über den ICV. Zugleich kann ein kompromittierter Validator IOAM-Felder fälschen oder falsche Ergebnisse ausgeben; das Verfahren kann dies nicht verhindern.

Das ist eine Governance-Grenze. Ein System, das Soll-Teilnehmer definiert, Schlüsselzuordnungen besitzt, urteilt und die Gegenmaßnahme auslöst, vereint Beobachtung, Gericht und Vollzug. GMAC macht diese Rollen nicht unabhängig.

Jeder Beleg muss Validator-Identität, Software-Build, Konfigurationshash, Schlüsselepoche, Zuordnungsversion und Entscheidungsrichtlinie nennen. Riskante Aktionen brauchen einen zweiten Beobachtungspfad oder eine getrennte Freigabe.

Entfernte Optionen hinterlassen keinen ICV

Ein Angreifer auf dem Pfad kann einen vollständigen IOAM-Option-Type-Header entfernen. Diese Methode mildert den Angriff nicht; Schutz soll das einkapselnde Protokoll liefern. Auch ein Austausch der geschützten Option gegen ihr ungeschütztes Gegenstück bleibt möglich, wenn der Validator die Schutzpflicht nicht kennt.

Darum muss zuerst die Soll-Menge feststehen: Namespace-ID, einkapselnder Knoten, Option-Types und Teilnehmer. Erst der Vergleich mit der beobachteten Menge macht eine ICV-Prüfung vollständig interpretierbar.

Eine fehlende Option bedeutet nicht „keine Auffälligkeit“. Sie kann nie eingefügt, nicht ausgewählt, entfernt oder beim Export verloren worden sein. Diese Zustände brauchen unterschiedliche Behandlung.

Gültige Stichproben ergeben keine vollständige Abdeckung

Geschützte und gewöhnliche IOAM-Optionen dürfen nebeneinander existieren. Verschiedene Namespaces können unterschiedliche Schutzarten verwenden. Um Rechenlast zu begrenzen, kann nur ein Teil des Verkehrs markiert werden.

Die Zahl gültiger Prüfungen verrät daher den Nenner nicht. Ein kritischer Flow kann vollständig fehlen, obwohl tausend Stichproben gültig waren. Abdeckung muss nach Traffic-Klasse, Namespace, Option-Type, Zeitraum und Policy-Generation geführt werden.

Veränderliche Headerfelder sind ebenfalls ungeschützt. Der Beleg muss Felder und Masken nennen. „IOAM ist integer“ wäre eine unzulässige Verallgemeinerung.

Nach dem Export beginnt eine neue Beweiskette

Management-Angriffe und die Integrität exportierter Daten liegen außerhalb des Verfahrens. Direct Export trägt keine IOAM-Data-Fields und darf diese Methode nicht verwenden.

Nach einem gültigen Paket können Parsing, Normalisierung, Transport, Speicherung oder Aggregation den Datensatz verändern. Deshalb müssen Rohoption, Validierungsbeleg und Hash jedes Übergangs erhalten bleiben. Ohne diese Kette lautet der Status Exportintegrität nicht belegt.

Gültige Bytes können zu spät kommen

Selektive Verzögerung wird nicht verhindert. Ein Angreifer kann gerade IOAM-Pakete zurückhalten und eine Stauillusion erzeugen, ohne ein geschütztes Bit zu ändern.

Frische erfordert Erfassungs- und Validierungszeit, Altersbudget, Uhrenqualität und unabhängige Delay-/Loss-Beobachtung. Replay-Schutz erkennt Nonce-Wiederverwendung, macht ein einmaliges Paket aber nicht aktuell.

Nach einem Neustart ohne gesicherten Zählerstand darf der alte Schlüssel nicht erneut genutzt werden; erst eine Rotation ermöglicht die Fortsetzung. Das Replay-Fenster bestimmt zudem die Toleranz für legitime Umordnung.

Ein Beleg statt eines Symbols

Der Beleg enthält Domain, Namespace-ID, Option-Type, Methode, Maske, Paketidentität, Auswahlregel sowie erwartete und beobachtete Optionen/Teilnehmer. Danach folgen Nonce, öffentliche Kennungen, Schlüsselepoche, Mapping-Version, Replay-Bewertung und Validator-Provenienz.

Die Verwahrung von Dekapselung über Export bis Speicherung wird mit Hashes verbunden. Unabhängige Delay-, Loss-, Pfad- und Dienstmessungen, Aktion, Autorität, Rollback und Ergebnis schließen den Vorgang.

Geeignete Zustände heißen für deklarierte Menge gültig, erwartete Option fehlt, Identitätszuordnung unbekannt, Validator-Provenienz ungeprüft, Abdeckung teilweise, Exportintegrität offen und Dienstresultat ausstehend.