Zusammenfassung

  • GTSM prüft die Nähe eines Pakets anhand der IPv4-TTL oder des IPv6-Hop-Limits; es authentisiert weder den Absender noch ersetzt es den kryptografischen Schutz der BGP-TCP-Sitzung.
  • Die Aussage hängt vom konfigurierten Hop-Radius, Eingangsfiltern, dem Vertrauen in direkte Nachbarn und dem Tunnelverhalten ab.
  • Peer-Sicherheit braucht einen verbundenen Nachweis: Hop-Wert, Interface und Tunnel, genehmigter Nachbar, TCP-AO-Schlüsselstatus, Sitzung und Verantwortliche.

Der Cross-Connect wurde gerade verlegt. Beide BGP-Router senden weiterhin mit TTL 255, und jedes empfangene Paket besteht die GTSM-Prüfung. Das Änderungsprotokoll erklärt deshalb den entfernten Peer für authentisiert.

Die Schlussfolgerung ist stärker als der Beleg. Die Prüfung zeigt, dass ein Paket innerhalb der zulässigen Hop-Grenze eingetroffen ist. Sie zeigt allein nicht, welches autorisierte System es erzeugte, ob ein Gerät auf demselben Link es fälschen konnte, ob ein Tunnel die sichtbare Entfernung veränderte oder ob das Segment einen gültigen kryptografischen Authentikator trug. Sitzung und GTSM können korrekt funktionieren, während das Wort „authentisiert“ unbelegt bleibt.

RFC 4271 betreibt BGP über TCP. Zwei Systeme stellen zuerst eine TCP-Verbindung her und tauschen danach BGP-Nachrichten aus. Daraus entstehen vier getrennte Fragen: Kam das IP-Paket aus plausibler Entfernung? Gehört das TCP-Segment zur geschützten Verbindung? Akzeptierte der konfigurierte BGP-Nachbar die Sitzung? Besitzt die Organisation dahinter weiterhin die Autorität zum Routenaustausch? Eine grüne Anzeige beantwortet nicht alle vier.

RFC 5082 baut GTSM auf einer einfachen Asymmetrie auf. Ein direkt verbundener Protokoll-Peer sendet mit dem Maximalwert 255. Jeder weiterleitende Router verringert den Wert; ein Empfänger, der 255 erwartet, kann daher Verkehr verwerfen, der wahrscheinlich weiter entfernt entstand. Erfolgt die Klassifizierung nahe an der Line-Rate-Hardware, schützt sie zudem knappe Control-Plane-Ressourcen vor gefälschten Paketen.

Das ist nützliche Sicherheit. Sie verkleinert die Angriffsfläche und bietet vor teurer Protokollverarbeitung einen günstigen Topologietest. Deshalb empfiehlt RFC 7454 TTL Security für direkt verbundene BGP-Peerings.

Die Grenze ist ebenso klar. RFC 5082 sagt ausdrücklich, dass GTSM keine Authentisierung ersetzt und nicht gegen Spoofing oder Replay durch Angreifer auf dem Übertragungsweg schützt. Ein kompromittiertes direktes Gerät ist nah genug. Ein Angreifer im vertrauten Segment ebenfalls. Auch ein Paket, das an einem akzeptierten Tunnelende erzeugt oder entkapselt wird, kann nah genug erscheinen. Der Erfolg belegt konfigurierte Nähe, nicht Urheberschaft.

Multihop-Betrieb macht den Unterschied deutlicher. GTSM kann für Loopbacks oder mehrstufige Sitzungen einen TTL-Radius statt exakt eines Hops akzeptieren. Jeder zusätzliche Hop erweitert jedoch die Orte, von denen ein plausibles Paket eintreffen kann. Eine Topologieänderung kann die Aussage verändern, ohne den Zahlenwert zu ändern.

Tunnel schaffen eine zweite Mehrdeutigkeit. RFC 5082 untersucht mehrere IP- und MPLS-Fälle, weil die innere TTL am Peer von Kapselung, Propagationsmodus und der Rolle des Entkapselungsknotens abhängt. Integrität und Endpunkt des Tunnels werden damit Teil des Belegs. Ein GTSM-Alarm nach einer Migration kann einen neuen Pfad zeigen; eine bestandene Prüfung zertifiziert den Tunnel nicht.

Kryptografische Segmentauthentisierung beantwortet eine andere Frage. RFC 5925 definiert TCP-AO für langlebige TCP-Verbindungen wie BGP. Ein Message Authentication Code wird mit verwalteten Master Key Tuples und verbindungsspezifischen Verkehrsschlüsseln über gebundenes Material berechnet. Sequence Number Extensions verhindern Replay, wenn der normale TCP-Sequenzraum umläuft. Ein gültiges Ergebnis stützt die Aussage, dass ein Halter des akzeptierten Schlüsselmaterials das Segment erzeugte.

TCP-AO beseitigt die Governance nicht. Betreiber müssen Schlüssel einer Peering-Beziehung zuordnen, an beiden Enden installieren, Gültigkeit festlegen, Wechsel koordinieren und alte Schlüssel entfernen. Ein gültiger MAC unter einem längst zu entfernenden Schlüssel kann kryptografisch korrekt und betrieblich unautorisiert sein. Ebenso darf ein GTSM-Erfolg bei fehlender TCP-AO-Prüfung nicht zur Identität aufgewertet werden.

Zusammen sind die Kontrollen stark, weil sie unterschiedlich ausfallen. GTSM filtert unplausibel entfernten Verkehr, Eingangsfilter reduzieren Quellfälschung, TCP-AO authentisiert Segmente und die BGP-Nachbarkonfiguration bindet die Sitzung an die genehmigte Beziehung. Keine darf den Namen einer anderen übernehmen.

Quellen