Zusammenfassung

  • Striktes Reverse-Path-Forwarding kann ein legitimes Paket ablehnen, wenn dessen Eingangsinterface nicht dem Interface entspricht, das die beste Route zurück zur Quelladresse vorsieht. RFC 3704 stellt genau diese Spannung heraus.
  • Feasible-Path-RPF berücksichtigt bekannte Alternativen, sofern sie konsistent verbreitet werden; Loose-RPF toleriert asymmetrische Wege, gibt aber einen großen Teil des richtungsbezogenen Nachweises auf.

Der Router prüfte den Rückweg

Ein Netz mit zwei Providern sendet ein Paket über Provider B. Die Quelladresse gehört zu einem Präfix, das dieses Netz verwenden darf. Ein weiter entferntes Gerät empfängt das Paket über die B-seitige Schnittstelle. Beim Rückwärtssuchen findet es jedoch Provider A als bevorzugten Weg zur Quelle. Striktes RPF verwirft das Paket. Der Router hat den Absender nicht identifiziert; er hat den Eingangsweg mit seiner eigenen Routingansicht verglichen.

RFC 3704 erschien im März 2004 als Best Current Practice 84 und aktualisierte RFC 2827, die frühere Empfehlung zum Eingangsfiltern. Das Ziel, gefälschte Quelladressen einzudämmen, blieb bestehen. Mehrfach angebundene Netze und asymmetrische Wege erschwerten aber die Beweisführung: Der tatsächlich genutzte Hinweg muss nicht dem Weg entsprechen, den das Routing für die Rückrichtung auswählt.

RFC 3704 behandelt RPF nicht als einen einzigen Schalter. Eine Zugriffsliste kann pro Schnittstelle zulässige Präfixe prüfen und ist gut nachvollziehbar, doch eine manuell gepflegte Liste kann Änderungen bei Adressen oder Providern verpassen. Striktes RPF fragt die Quelladresse dynamisch in der Forwarding Information Base (FIB) ab und akzeptiert sie nur, wenn sie über das Interface der besten Route eintrifft. An einer symmetrischen Kundengrenze ist das einfach. Bei einem asymmetrischen Rückweg, einer fehlenden Route oder einer Provider-Policy kann derselbe Test legitimen Verkehr verwerfen.

Zusätzliche Pfade müssen überall bekannt sein

Feasible-Path-RPF bezieht alternative Routen in den Test ein, statt nur die gerade beste Route in der FIB zu verwenden. In einem Mehranbieter-Netz kann das verhindern, dass ein korrekt adressiertes Paket allein deshalb scheitert, weil vorübergehend ein anderer Weg bevorzugt wird.

Die Alternativliste ist jedoch keine vollständige Karte aller denkbaren Pfade. RFC 3704 setzt voraus, dass relevante Routenankündigungen alle prüfenden Router konsistent erreichen. Eine Route-Map oder Provider-Policy kann dazu führen, dass ein Anbieter ein Präfix kennt, ein anderer nicht. Wird die Ankündigung gefiltert, kann auch das Paket gefiltert werden. Eine scheinbar lokale Sicherheitsregel hängt damit von Steuerungsentscheidungen mehrerer administrativer Domänen ab.

Loose-RPF geht den umgekehrten Kompromiss ein. Es prüft, ob überhaupt eine Route zur Quelle existiert, nicht ob sie auf das Eingangsinterface zeigt. Das verträgt Asymmetrie, kann aber auch gefälschte, routbare Quelladressen passieren lassen. Eine Default-Route macht die Bedingung noch schwächer, sofern die Implementierung sie nicht gesondert behandelt. RFC 3704 sieht Loose-RPF daher nicht als Hauptfilter zwischen Kunde und Provider; sinnvoller kann es sein, upstream nicht geroutete oder reservierte Quellen auszusortieren oder zu kontrollieren, ob ein anderes Netz überhaupt filtert.

Weitere Optionen machen den Koordinationsaufwand sichtbar: Jeder Provider muss die Kundenpräfixe vollständig führen, gegebenenfalls über providerunabhängige Adressen und BGP. Bei providergebundenen Präfixen kann ein Netz jede Quelle nur über den zuständigen Anbieter leiten. Zugrifflisten lassen sich auch automatisiert aus Kundendatenbanken erzeugen. Jede Wahl verlagert Arbeit zwischen Routern, Netzen und Betreibern. Keine macht Routingzustand zum Identitätsnachweis.

Je näher die Prüfung an der Quelle stattfindet, desto genauer lässt sich feststellen, welche Adressen ein angeschlossenes System verwenden darf. Weiter entfernte Router können meist nur sagen, dass eine Quelle zu einem erreichbaren Präfix gehören könnte. Mehrere Filterebenen können Rückverfolgbarkeit verbessern, identifizieren aber weder einen konkreten Angreifer noch die flächendeckende Einführung eines Verfahrens. RFC 8704 aktualisierte RFC 3704 im Jahr 2020 mit erweitertem Feasible-Path-uRPF. Das zeigt die fortdauernde Arbeit am Kompromiss, nicht dessen universelle Einführung oder eine Lösung für jede Topologie.

Die richtige Frage lautet daher nicht, ob „strict“ oder „loose“ immer besser ist. Entscheidend ist, welche Information die Prüfung nutzt: die beste Rückroute, mehrere bekannte Alternativen oder nur irgendeine Route. Das Ergebnis hängt von der Tabelle und dem Ort der Prüfung ab. RFC 3704 machte vollständige Routinginformation zur gemeinsamen Betriebsverantwortung.

Quellen