Zusammenfassung

  • GTSM lässt geschützten BGP-Verkehr mit TTL beziehungsweise Hop Limit 255 starten und akzeptiert nur Werte innerhalb einer genehmigten Netzdistanz.
  • Der Test erschwert entferntes Spoofing, authentisiert aber weder Peer noch TCP/BGP-Inhalt. Ingress-Filter, TCP-AO, Control-Plane-Schutz und Routenpolicy behalten eigene Aufgaben.
  • Belastbare Evidenz verbindet beide Richtungen: ausgehende 255, Ankunftswert, wirksame Schwelle, frühester Drop-Zähler, TCP/BGP-Zustand und Routenergebnis.

Die spontane Reparatur lautet hops 3. Sie kann die Sitzung wiederherstellen. Zugleich erweitert sie den Kreis möglicher Einspeisepunkte, deren Pakete den Nähetest bestehen. Die Zahl ist daher kein bloßer Verfügbarkeitsregler. Sie ist ein topologisches Vertrauensbudget.

Der Restwert und seine Aussagegrenze

IPv4 TTL und IPv6 Hop Limit sind acht Bit breit; 255 ist ihr Maximum. Bei gewöhnlicher Weiterleitung reduziert jeder Router den Wert. GTSM beginnt am Maximum und prüft am Ziel, wie viel davon übrig ist.

Ein direkt verbundener Peer liefert 255. Bei Multihop verbraucht der Pfad Einheiten. Die zitierte Cisco-Dokumentation beschreibt die Mindestannahme als 255 minus konfigurierter Hop-Zahl. FRRouting stellt neighbor PEER ttl-security hops NUMBER bereit. Zählweise und Zusammenspiel mit Multihop-Befehlen sind Implementierungsdetails. Die plattformübergreifende Regel lautet: erwarteten Bereich ableiten und ihn durch Paketmitschnitt bestätigen.

Ein Wert 253 bei einer Schwelle 253 belegt nur, dass das Paket unter normalen Annahmen nicht weiter als erlaubt geroutet wurde. Er nennt keinen Absender. Ein weit entfernter Angreifer kann nicht oberhalb 255 beginnen, um Dekremente auszugleichen. Ein Angreifer auf demselben Link wie der legitime Peer kann denselben hohen Wert setzen.

GTSM ist damit stark gegen Entfernung, nicht gegen Nähe.

Trusted ist kein Wahrheitsurteil

RFC 5082 ordnet Pakete einer registrierten GTSM-Sitzung als Trusted ein, wenn ihr Wert im erwarteten Bereich liegt, und als Dangerous, wenn er außerhalb liegt. Unknown bezeichnet Verkehr, den GTSM keiner geschützten Sitzung zuordnen kann.

Diese Begriffe betreffen allein den Entfernungstest. Ein kompromittierter echter Peer kann einen bösartigen UPDATE senden, der für GTSM Trusted ist. Ein legitimer Peer auf einem neuen, längeren Pfad kann Dangerous werden.

Entscheidend ist außerdem die Stelle der Klassifikation. GTSM soll knappe Control-Plane-Ressourcen schützen. Erfolgt der Drop erst im BGP-Prozess, hat das Paket möglicherweise bereits Linecard-Bandbreite, CPU-Queue, Kernel und TCP beansprucht. Je näher die Trennung an Weiterleitung und Line Rate liegt, desto größer der DoS-Nutzen.

Ein einzelner Zähler reicht deshalb nicht. Hardware, Control-Plane-Policy, Kernel-Sichtbarkeit, TCP-Socket und BGP-Prozess müssen eine Beweiskette bilden. Der erste Punkt, an dem das Paket verschwindet, zeigt, welche Ressource wirklich geschützt wurde.

Vier Tatsachen hinter einer Konfigurationszeile

RFC 5082 definiert für bestehende Protokolle keine allgemeine automatische GTSM-Aushandlung. Beide Seiten konfigurieren die Beziehung manuell, senden mit 255 und setzen passende Empfangsgrenzen.

Das Inventar muss genehmigte Topologie, konfigurierten Hop-Wert, beobachteten Pfad und tatsächlich durchgesetzte Schwelle getrennt führen. Sie können durch ECMP, Failover, Loopback-Migration, Plattformwechsel, Service Chains oder unterschiedliche IPv4/IPv6-Pfade auseinanderlaufen.

Eine Konfigurationszeile beweist Absicht, nicht das ausgesendete Paket oder den Drop-Ort. Auch Established ist kein Nachweis: Ist GTSM auf beiden Seiten versehentlich aus, kann die Sitzung ebenso gesund erscheinen.

Darum gehört ein negativer Test zur Abnahme. Ein Paket exakt an der Grenze muss die nächste Schicht erreichen; eines eine Einheit darunter muss am vorhergesagten frühen Zähler enden und darf für TCP/BGP unsichtbar bleiben.

Multihop macht aus Nähe einen Durchmesser

Direkte Nachbarschaft ist der klarste Fall. Der legitime Peer liefert 255, jede gewöhnliche Routerpassage verändert den Wert. RFC 5082 beschränkt seine deutlichste Anwendbarkeitsaussage auf inhärent begrenzte Topologien, besonders direkte Peers.

Multihop kann weiterhin entfernte Quellen ausschließen. Innerhalb des zugelassenen Durchmessers können jedoch weitere Positionen denselben Test erfüllen. RFC 7454 weist ausdrücklich auf diese geringere Wirksamkeit hin.

Jede Reserve braucht einen Grund. Fünf erlaubte Hops bei einem normalen Zwei-Hop-Pfad können einen dokumentierten Ausfallweg abdecken oder aus einer alten Vorlage stammen. Nur der erste Fall ist eine bewusste Kontinuitätsentscheidung.

Hin- und Rückweg sind eigene Verträge. A erreicht B über zwei Router, B erreicht A über drei. SYN passiert, SYN-ACK fällt. Ein längeres ECMP-Mitglied kann sporadische Ausfälle erzeugen. Werte werden deshalb nach Richtung, Adressfamilie, Pfad und Session Epoch gespeichert, nicht aus einem einmaligen Traceroute abgeleitet.

Tunnel verschieben die sichtbare Entfernung

Ein Tunnel kann das innere Paket weit transportieren, ohne dessen TTL zu reduzieren. Nahe am Peer erscheint dann ein hoher innerer Wert, obwohl die Einspeisung weit entfernt erfolgte. Andere Modelle kopieren oder propagieren Werte; MPLS Uniform, Pipe und Short Pipe unterscheiden sich.

RFC 5082 behandelt vertrauenswürdige Tunnelendpunkte, Integrität und Quellvalidierung als Sicherheitsannahmen. Die Dokumentation muss festhalten, wer am Headend einspeisen kann, wie innere und äußere Werte behandelt werden, wo entkapselt wird und welche Filter dort gelten. „Ein Tunnel ist ein Hop“ ist keine belastbare Abstraktion.

DDoS-Scrubbing, virtuelle Router oder Firewalls können Peer-Adressen bewahren und dennoch die gesamte Entfernungsaussage verändern. Jeder Vermittler, der die GTSM-Arithmetik beeinflusst, gehört in die Vertrauensgrenze.

Fragmente bilden eine weitere Lücke. Nicht initiale Fragmente enthalten keinen TCP-Header für die frühe Zuordnung zur BGP-Sitzung. Reassembly kann genau die knappen Ressourcen verbrauchen, die geschützt werden sollen. RFC 5082 empfiehlt Fragmentierung zu vermeiden; MTU, ICMP und Fragment-Policy benötigen eigene Prüfungen.

Nähe, Identität und Routenrecht bleiben getrennt

GTSM fragt nach plausibler Distanz. Ingress Filtering fragt, ob eine Quelladresse an dieser Schnittstelle plausibel ist. TCP-AO schützt Authentizität und Integrität eines Segments im Schlüsselkontext. Control-Plane-Policy begrenzt Ressourcen. BGP-Policy entscheidet über die Route.

Ein On-Link-Angreifer kann GTSM bestehen und an Quellvalidierung scheitern. Ein On-Path-Angreifer wahrt die Distanz, weshalb kryptographische Authentisierung nötig ist. Ein authentisierter, kompromittierter Peer kann unerlaubte Präfixe senden; lokale Import-Policy muss sie verwerfen. Unknown-Verkehr braucht unabhängiges Policing.

GTSM als Authentisierung zu bezeichnen, bläht seine Aussage auf. Es wegen dieser Grenze für nutzlos zu halten, unterschätzt es. Seine präzise Rolle ist, topologisch unplausiblen Fernverkehr früh und billig auszuscheiden.

Ein Canary mit vorhergesagtem Scheitern

Vor einer Pfadänderung werden beide Richtungen erfasst: Ausgang 255, Ankunftsverteilung, Schwelle und erster Durchsetzungszähler. Normal-, Wartungs-, ECMP- und glaubwürdige Fehlerpfade werden modelliert.

Sinkt der legitime Mindestwert auf 252, muss die Organisation entweder die Topologie in der alten Grenze halten oder einen größeren Durchmesser genehmigen. Eine temporäre Erweiterung erhält Ablaufdatum und Rollback.

Am isolierten Canary werden drei Fälle gesendet: oberhalb, exakt an und eine Einheit unter der Schwelle. Die ersten beiden gelangen weiter; der letzte endet am prognostizierten Drop-Punkt. Separat folgen On-Link-Spoofing, falscher TCP-Schlüssel und eine unerlaubte Route eines authentisierten Peers. Jeder Fall muss in seiner zuständigen Schicht scheitern.

Nach dem Cutover werden GTSM-Drops, TCP-Retransmits, Authentisierungsfehler, BGP-FSM und Routen korreliert. Eine fehlende Route beweist keinen TTL-Drop; ACL, Schlüssel, NOTIFICATION und Policy erzeugen dasselbe äußere Symptom.

Rollback stellt Pfad oder explizite beidseitige Schwellen wieder her. GTSM einseitig abzuschalten und die andere Seite maximal zu öffnen, behebt die Anzeige, nicht die Sicherheitsregression.

Das Paket mit 252 war nicht per se falsch. Es widersprach einem Vertrag für 253. GTSM bleibt zuverlässig, wenn seine Autorität dort endet: Nähe erlaubt nur die nächste Prüfung, nicht Identität, Integrität oder Routenrecht.