Zusammenfassung

  • FlowSpec verteilt Paketkriterien und Filteraktionen; eine sichtbare Route belegt den Kontrollzustand, nicht das Weiterleitungsergebnis.
  • Externe Regeln hängen normalerweise von der Prüfung gegen Unicast-Routen ab und müssen nach einer Änderung der besten Route erneut geprüft werden.
  • Regeln und Aktionen können sich überlagern oder widersprechen; IPv6-Parser und Hardwaregrenzen können die Ausführung verhindern.
  • Zum Abschluss gehören der genaue NLRI, Geräteprogrammierung, Zähler, Paketproben sowie Messungen am Angriffsziel und am legitimen Verkehr zusammen.

Man stelle sich einen DDoS-Controller vor, der eine Regel für ein Ziel und einen Port erzeugt. Sekunden später ist sie auf dem Route Reflector und in den Kontrollzuständen dreier Edge-Router sichtbar; die Incident-Anzeige wird grün. Auf einem großen Eingangslink läuft der Verkehr dennoch weiter, weil die Linecard das Merkmal der oberen Schicht nicht in Hardware übersetzen konnte. Die BGP-Beobachtung stimmte. Die Aussage über den Filter nicht.

Das ist ein hypothetischer Betriebsablauf, kein Vorwurf an ein bestimmtes Netz oder Produkt. Er trennt die verteilte Anweisung von ihrer Ausführung auf Paketen.

Was die Route tatsächlich überträgt

RFC 8955 codiert eine Flow Specification als n-Tupel in einer BGP-NLRI. Komponenten können Quell- und Zielpräfix, Protokoll, Ports, TCP-Flags, Paketlänge, DSCP und Fragmente beschreiben. Ein Paket passt nur, wenn es die Schnittmenge aller Komponenten erfüllt. Der erste Nachweis ist daher der decodierte Ausdruck, nicht die Bezeichnung im Dashboard.

Extended Communities tragen Aktionen wie Begrenzung nach Byte- oder Paketrate, Sampling, Route-Target-Umleitung und Markierung. Die Standardaktion für eine passende Regel ist normale Annahme. Eine Rate von null steht für Verwerfen. Eine Regel ohne die erwartete Aktion kann vorhanden sein, ohne den Verkehr zu stoppen.

Mehrere Regeln können auf denselben Fluss passen. Die Reihenfolge ist unabhängig von der BGP-Ankunft, doch Aktionen können kollidieren. Bleibt der Konflikt bis zur Weiterleitung bestehen, entscheidet die Implementierung, welche Aktion gilt. Einheitliche Verteilung garantiert deshalb kein einheitliches Geräteverhalten.

Die Prüfung hängt vom Unicast-Zustand ab

Ohne abweichende Konfiguration muss eine externe Regel ein Zielpräfix enthalten, denselben Ursprung wie die beste passende Unicast-Route haben und darf keine spezifischere Route eines anderen Nachbar-AS erfassen. Die erste Bedingung kann ausdrücklich gelockert werden; auch die Prüfkonfiguration gehört somit zum Beleg.

Die beste Unicast-Route kann unabhängig von FlowSpec wechseln. RFC 8955 verlangt dann eine erneute Prüfung. Eine zuvor zulässige Regel kann unzulässig werden, obwohl ihre Ankündigung noch im Collector liegt. Der Datensatz muss Prüfpunkt und zugrunde liegenden Unicast-Zustand nennen.

RFC 8956 erweitert das Verfahren auf IPv6 mit AFI 2 und SAFI 133 oder 134. Bei der Validierung muss der Offset des Zielpräfixes null sein. Ungewöhnliche Headerketten und Hardwaregrenzen können außerdem verhindern, dass Kriterien oberer Schichten umgesetzt werden. Eine Kontrollentscheidung beseitigt diese Grenze nicht.

Das Ergebnis braucht Paketdaten

RFC 8955 empfiehlt Headerprotokolle und Trefferzähler je Regel. Für Gerät, VRF, Schnittstelle und Linecard ist festzuhalten, ob die Regel kompiliert, abgelehnt oder angenähert wurde, welche Priorität und Aktion verblieben und ob die Zähler zu den Angriffspaketen passen.

Danach müssen Verkehr am Opfer, Verlust legitimer Pakete, Umleitungskapazität und Wirkung des Rückzugs gemessen werden. Ein steigender Drop-Zähler kann das falsche Aggregat treffen; ein sinkender Angriff kann unzulässigen Kollateralschaden verdecken. Aus der FlowSpec-Route allein folgt beides nicht.

Quellen