Zusammenfassung

  • draft-ietf-idr-fsv2-content-filter-00 vom 2. November beschreibt einen festen Inhaltsvergleich für FlowSpec v1 und v2. Der Text ist ein Internet-Draft der IETF-Arbeitsgruppe IDR.
  • Ausgangspunkt, Offset, Bytefolge und Maske bestimmen den Treffer. Bei FSv2 ist die Inhaltskomponente verpflichtend: Kann ein Gerät sie nicht ausführen, darf es die gesamte Route lokal nicht installieren.
  • Ohne den Bytevergleich würde dieselbe Aktion auf mehr Verkehr wirken. Über vertrauenswürdige BGP-Nachbarn, Autorisierung, Verbreitung und Ressourcen entscheidet der Betreiber.

Der Fehler steckt im weggelassenen Detail

FlowSpec verbreitet Filterregeln über BGP. Die bisherigen IP-Grundkomponenten prüfen vor allem Header-Felder. Ein neuer Entwurf der IDR-Arbeitsgruppe ergänzt den Blick auf eine feste Bytefolge im Paket. Für einen bekannten Angriff kann ein solches Muster den Treffer genauer machen. Wenn ein Gerät das Muster nicht prüfen kann, droht jedoch das Gegenteil: Die übrige Regel trifft mehr Pakete als vorgesehen.

Das Verfahren ist ein eng umrissener Bitvergleich. OType bestimmt den Anfang eines IP-Headers, der IP-Nutzlast oder einer UDP- beziehungsweise TCP-Nutzlast. Offset zählt ab dort weiter; Inhalt und Maske legen die relevanten Bits fest. Ein Beispiel des Entwurfs verbindet zwei Bytes am Anfang einer TCP-Nutzlast mit einem Zielpräfix. Semantisches Lesen einer Anwendung ist damit nicht gemeint.

Die Länge im Format reicht von einem bis 255 Bytes. Das sagt nichts darüber aus, wie viel ein konkreter Chip filtern kann. FSv2 kennzeichnet die Paketinhalt-Komponente als verpflichtend. Überschreitet eine gültige Regel die örtliche Kapazität, gilt die gesamte FlowSpec-Route für die lokale Installation als ungeeignet. Der Vergleich darf nicht stillschweigend entfallen, während eine Drop-, Umleitungs- oder Drosselungsaktion mit den übrigen Bedingungen aktiv wird. Das wäre aus einer schmalen Signatur ein breiteres Netz gemacht.

Der Offset ist ebenfalls kein universeller Ortsname. Bei IPv6 beginnt die IP-Nutzlast hinter dem festen Header; Erweiterungsheader liegen dann im zählbaren Bereich. Werden sie auf dem Weg verändert, kann derselbe Offset andere Bytes treffen. Bei Tunneln kann die äußere Hülle den Bezugspunkt verschieben. Der Entwurf empfiehlt, gegebenenfalls das entkapselte innere IP-Paket zu prüfen oder den Bezugspunkt eindeutig festzulegen.

Die Autoren nennen kontrollierte Filterorte, zusätzliche Header-Bedingungen, vertrauenswürdige BGP-Peers und begrenzte Verbreitung. ACL-, UDF- und TCAM-Einträge sind endlich. Tests mit OpenBGPD, FRRouting und programmierbaren Switches werden beschrieben; Zahlen zu einem Produktionseinsatz fehlen. Die neue Leitplanke ist greifbar: Ein Gerät ohne den präzisen Vergleich bekommt keinen Freibrief für einen gröberen Filter.

Originalquellen