Zusammenfassung

  • KeyID bezeichnet das Master Key Tuple, das das gesendete Segment schützt. RNextKeyID nennt das für künftigen Empfang bevorzugte MKT; es transportiert kein Secret, quittiert keine Lieferung und beweist keinen Sendeschlüsselwechsel des Peers.
  • Der Zustand ist richtungsabhängig. Jeder Endpunkt besitzt einen aktuellen Ausgangsschlüssel und einen bevorzugten Eingangsschlüssel. Ein einziges Feld „aktiver Schlüssel“ vernichtet vier entscheidende Tatsachen.
  • Der alte Schlüssel darf erst nach neuem KeyID und erfolgreichem MAC in beiden Richtungen, stabilem BGP, getestetem Reconnect, null Alt-Abhängigkeit und vollständigem Rollback entfallen.

Der Ausfall kann trotz identischer Secret-Bytes entstehen. Die Abweichung liegt in den lokalen Namen. A installiert das neue MKT mit SendID und RecvID 42. B vergibt nach eigener Konvention SendID und RecvID 43. Im Change heißen beide Objekte „Schlüssel 42“. TCP-AO arbeitet jedoch mit Richtung und wirksamer Kennung, nicht mit der Bezeichnung im Ticket.

A setzt das neue MKT als bevorzugten Empfangskontext. Seine Segmente werden weiter mit KeyID=17 authentisiert, tragen aber RNextKeyID=42. B prüft den MAC mit dem alten MKT und sucht für dieses Socket-Paar ein sendefähiges MKT mit SendID 42. Fehlt ein passendes, bereites Objekt, erfolgt nach RFC 5925 kein Wechsel. Der fehlgeschlagene Wunsch betrifft B→A: B sendet weiter mit 17. Kündigt B später RNextKeyID=43 an, kann auch A den Verkehr A→B nur mit einem bereiten ausgehenden MKT mit SendID 43 umstellen.

Dieses Schweigen ist eine Sicherheitsgrenze. Ein entferntes Byte darf keinen ungeprüften lokalen Schlüssel erzwingen. Gefährlich wird es erst, wenn die Überwachung „kein Fehler“ als „Rotation abgeschlossen“ ausgibt.

Zwei Kennungen, zwei Richtungen

TCP-AO ist TCP Option Kind 29 und enthält Length, KeyID, RNextKeyID und MAC. Das kompakte Format koordiniert bereits bereitgestellte Schlüsselkontexte. Es ist kein Secret-Transport.

KeyID beschreibt das aktuelle Segment. Der Sender setzt die SendID seines current MKT ein. Der Empfänger kombiniert das Byte mit Quell-/Zieladresse und Ports und sucht ein MKT mit passender RecvID. Die SendID einer Seite muss in dieser Richtung die RecvID der Gegenseite treffen.

RNextKeyID bereitet den Verkehr in Gegenrichtung vor. Der Sender veröffentlicht die RecvID des MKT, mit dem er künftige Eingangssegmente prüfen möchte. Der Empfänger dieser Mitteilung ändert sein current_key für ausgehende Segmente nur, wenn lokal ein kompatibles MKT vorliegt.

Die Werte sind weder Hashes noch Versionen. Sie haben keine kryptographische Eigenschaft, keine reservierte Semantik und müssen nicht monoton oder zufällig sein. Sie dürfen je Richtung verschieden sein. Zwei 42er beweisen weder gleiches Secret noch Algorithmus, MAC-Länge, Laufzeit oder Socket-Scope.

RNextKeyID=42 bedeutet also: „Ich kann unter dieser RecvID empfangen, falls du den entsprechenden Ausgangskontext bereits besitzt.“ Es ist keine Lieferbestätigung.

Das MKT ist das eigentliche Betriebsobjekt

Ein Master Key Tuple verbindet das Secret mit einem TCP-Verbindungsidentifikator aus lokalen und entfernten Adressen und Ports; Implementierungen können Bereiche oder Wildcards unterstützen. Hinzu kommen SendID, RecvID, KDF, MAC-Algorithmus und die Entscheidung, ob weitere TCP-Optionen in den MAC eingehen. Die Verwaltung kann Gültigkeiten ergänzen.

Ein eingehendes Segment muss über Socket-Paar und KeyID exakt einem MKT entsprechen. Dasselbe Secret im falschen VRF, in der falschen Adressfamilie, Richtung oder unter einer anderen RecvID ist nicht dieselbe operative Fähigkeit.

Auch die Optionspolicy ist bilateral. TCP-AO schützt seine eigenen Felder stets, wobei das MAC-Feld während der Berechnung genullt wird. Andere Optionen werden MKT-abhängig ein- oder ausgeschlossen. Unterschiede bei Policy, Algorithmus oder Länge lassen die Prüfung trotz identischer Master-Bytes scheitern.

Ein belastbares Inventar enthält deshalb Adressen, Ports, Routinginstanz, SendID, RecvID, Algorithmus, MAC-Länge, Optionspolicy, Laufzeit, current/rnext-Rolle und TCP-Epoche. „42 installiert“ autorisiert keine Löschung.

Der Master Key signiert nicht direkt

TCP-AO leitet Traffic Keys aus MKT und Verbindungsdaten ab: Adressen, Ports und nach Aufbau die Initial Sequence Numbers beider Richtungen. Die Schlüssel sind unidirektional und unterscheiden SYN von späterem Verkehr.

Dasselbe Master-Secret ergibt somit andere Traffic Keys für andere Peers, Richtungen und Verbindungsepochen. Ein Reconnect verändert den Kontext, selbst wenn Adressen und Ports gleich aussehen. Erfolg auf einem alten Socket beweist den nächsten Handshake nicht.

Sequence Number Extensions ergänzen den Sequenzraum bei Wraparound der 32 TCP-Bits und stärken den Replay-Schutz langer Verbindungen. Jede Richtung führt einen eigenen SNE ab Verbindungsaufbau. Ein isoliertes Paket erklärt einen MAC-Fehler nicht ohne seine Epoche.

Ein übereinstimmender Secret-Fingerprint ist nötig, aber nicht hinreichend. IDs, Scope, Richtung, Algorithmus, Optionen, Länge oder Socket-Zustand können weiter auseinanderlaufen.

Eine Session enthält zwei gekoppelte Wechsel

Jeder Endpunkt hält höchstens einen current_key zum Senden und einen bevorzugten rnext_key zum Empfangen. Zwischen A und B bestehen vier materielle Zeiger.

Zuerst wird das neue MKT auf beiden Seiten für Empfang wirksam, während das alte gültig bleibt. Der Readback muss den laufenden Socket zeigen; gespeicherte Konfiguration beweist keine Aktivierung.

Danach kündigt A seine Empfangspräferenz an. B löst die RNextKeyID gegen seine lokale Datenbank auf und wechselt, falls möglich, den Ausgangsschlüssel. Erst Bs erstes neues KeyID-Segment, das A erfolgreich prüft, beweist B→A.

Die Gegenrichtung folgt unabhängig. B kündigt an, A entscheidet lokal. Vorübergehend darf eine Richtung neu und die andere alt sein. Eine Oberfläche muss diesen legitimen Zwischenzustand zeigen.

Abschließend folgt eine begrenzte Überlappung für Verteilung, Retransmits, Messverzug, Reconnect und Rollback. Erst ohne Alt-Abhängigkeit wird das alte MKT entfernt. Ein einzelner Session-Schlüssel bildet diese Folge nicht ab.

Nicht zu wechseln ist eine gültige Antwort

Ein unter 17 korrekt authentisiertes Segment kann eine unbekannte RNextKeyID tragen. Ohne passendes MKT ändert der Empfänger nichts. Die entfernte Bitte erzeugt keinen lokalen Schlüssel, verlängert keine Gültigkeit und umgeht keine Freigabe.

Der gemeinsame Standard definiert eine minimale Sprache; jeder Teilnehmer übernimmt die Änderung nur aufgrund seines prüfbaren Zustands. Die Ankündigung ist noch keine laufende Umsetzung.

Monitoring muss die Wirkung sehen. Ändert sich die ausgehende KeyID? Steigen good-MAC-Zähler am neuen MKT? Treten key-not-found, bad MAC oder ungelöste RNext-Events auf? Established unter 17 belegt nur die alte Kontinuität.

Key Management liegt außerhalb von TCP-AO

RFC 5925 setzt einen Out-of-Band-Prozess oder ein manuelles Verfahren für neue MKTs voraus. Vault, API, Transportkanal, Freigabe, Custody und Audit werden nicht definiert. Auch die Entfernung alter MKTs wird nicht koordiniert.

RFC 6518 verbindet begrenzte Lebensdauer mit Betriebsrisiko: häufige manuelle Wechsel können Fehler und Exposition erhöhen. Der Transport soll ohne Adjacency-Abbruch wechseln können; Key Management muss Frische praktikabel machen. RFC 7211 empfiehlt Empfang vor Senden zu aktivieren, Tabellenkonsistenz zu prüfen und vor Ablauf zu warnen.

Der Autoritätsnachweis verbindet beides: Erzeuger, mögliche Plaintext-Orte, Lieferkanal, lokale IDs, Beginn der Receive-/Send-Gültigkeit, Ende der alten Epoche und Rückkehrberechtigung.

Betriebliche Kontrolle heißt, dass der Operator effektiven Zustand, Belege, Secrets und Rollback beherrscht. Ein Portal ohne Sicht auf beide Enden ersetzt diese Fähigkeit nicht.

Die Entfernung ist die irreversible Kante

Installation erweitert Optionen; Löschung entfernt den Rückweg. Solange das alte MKT besteht, kann es eine verzögerte Richtung oder Rollback tragen. Danach wird jede Inkonsistenz zu TCP- und BGP-Ausfall.

Unbegrenzte Aufbewahrung ist ebenfalls falsch. Ein kompromittiertes Secret bleibt nutzbar, solange ein Empfänger es akzeptiert; endlose Überlappung erlaubt unbemerkte Regression. Richtig ist evidenzgebundene Entfernung.

Die Frist deckt Verteilung, Retransmits, Telemetrieverzug, Reconnect und Rollback. Je Richtung werden letztes altes und erstes neues KeyID dokumentiert, good MACs und fehlende bad/unknown geprüft, BGP und Routenbasis verglichen. Ein neuer Verbindungsaufbau ist Pflicht, weil die MKT-Wahl am SYN vom geerbten Langzeitsocket abweichen kann.

Linux dokumentiert good/bad-, key-not-found- und AO-required-Zähler, MKT-Abfragen und Trace Events. Eine erzwungene Löschung kann zugleich Ersatz-current/rnext setzen, aber die Dokumentation warnt vor Verbindungsbruch, falls der Peer weiter den alten Schlüssel verlangt. Reparaturmechanismus ist kein Freibrief.

Rollback stellt Scope, SendID, RecvID, Algorithmus, Länge, Optionspolicy, Laufzeit und Secret-Herkunft wieder her. „17 zurückspielen“ ist keine vollständige Spezifikation.

Ein gültiger MAC autorisiert keine Route

TCP-AO belegt, dass ein Segment zum erwarteten Schlüsselkontext passt. Es belegt weder Präfixrecht noch korrekten AS_PATH oder einen unverfälschten Peer. Ein legitimer Schlüsselinhaber kann fehlerhafte Routen senden.

RFC 4272 trennt externe Session-Angriffe von falschen Informationen eines echten Peers. RFC 7454 behandelt TCP-Schutz, GTSM, Control-Plane-Filter, Präfixfilter, max-prefix und Pfadpolicy als eigenständige Ebenen.

So muss auch die Diagnose trennen. Bad MAC fällt vor BGP. Eine authentisierte, aber unzulässige Route scheitert an der Importpolicy. Max-prefix kann eine kryptographisch gesunde Session absichtlich schließen. Grün in einer Spalte zertifiziert keine andere.

Der Canary beweist vier Grenzen

Zuerst werden Instanz, Adressen, Ports, Peer, TCP-Epoche und Routenbasis festgehalten. Alle passenden MKTs auf A und B werden mit IDs, Algorithmen, Länge, Policy, Gültigkeit und Rolle gelesen. Secrets werden nur per geschütztem Fingerprint oder kontrolliertem Test verglichen.

Erstens wird Empfangsbereitschaft beider Seiten belegt. Zweitens kündigt A an; Bs erste neue KeyID und As erste erfolgreiche Prüfung werden erfasst. Drittens erfolgt dasselbe unabhängig in Gegenrichtung.

Nach beidseitigem Wechsel folgen KEEPALIVEs und eine begrenzte BGP-Operation. Adj-RIB, Routen und Retransmits werden verglichen. Nach Überlappung und Reconnect wird Nullnutzung des alten MKT belegt, es im Canary entfernt und erneut geprüft.

TCP-AO ist stark, weil seine Autorität schmal bleibt. Unabhängige Systeme koordinieren lokale Labels, ohne dem Draht die Secret-Verteilung zu übertragen. Epoche 42 ist erst real, wenn beide Seiten sie auflösen, beide Richtungen sie erzeugen und prüfen, BGP überlebt, alte Abhängigkeit null ist und Rollback bleibt. Davor ist sie ein Vorschlag.