Reverse path forwarding (RPF) ist eine Technik, welche in modernen Routern Verwendung findet. Sie ermöglicht ein kreisfreies Weiterleiten von Multicast-Paketen in Multicast-Routing und hilft, IP-Adressen-Spoofing in Unicast-Routing zu verhindern.

Multicast RPF

Multicast-RPF, typischerweise einfach als RPF bezeichnet, wird in Verbindung mit einem Multicast-Routing-Protokoll wie beispielsweise MSDP, PIM-SM und PIM-DM verwendet, um eine kreisfreie Weiterleitung von Multicast-Paketen sicherzustellen. In Multicast-Routing hängt die Entscheidung zur Weiterleitung von der Quell-Adresse ab, nicht von der Ziel-Adresse wie beim Unicast-Routing. Das geschieht entweder durch den Einsatz einer dedizierten Multicast-Routing-Tabelle oder alternativ durch die Unicast-Routing-Tabelle des Routers.

Wenn ein Multicast-Paket die Schnittstelle eines Routers erreicht, sieht es die Liste der Netzwerke, welche über diese Schnittstelle erreicht werden können; es überprüft also den umgekehrten Pfad des Pakets. Sollte der Router einen passenden Routing-Eintrag für die Quell-IP-Adresse des Multicast-Pakets finden, so ist der RPF-Check erfolgreich und das Paket wird zu allen anderen Schnittstellen weitergeleitet, die am Multicast dieser Multicast-Gruppe teilnehmen. Sollte der RPF-Check fehlschlagen, so wird das Paket verworfen. Daraus resultierend wird die Weiterleitung des Pakets basierend auf dem Rückwärtspfad statt dem Vorwärtspfad des Pakets entschieden. RPF-Router leiten nur Pakete weiter, welche die Schnittstelle erreichen und auch den Routing-Eintrag der Quelle des Pakets beinhalten, womit jegliche Kreise aufgelöst werden.

Dies ist von kritischer Wichtigkeit bei redundanten Multicast-Topologien. Da dasselbe Multicast-Paket denselben Router über mehrfache Schnittstellen erreichen kann, ist die RPF-Überprüfung ein integraler Bestandteil in der Entscheidungsfindung, ob ein Paket weitergeleitet werden soll oder nicht. Falls der Router alle Pakete, welche die Schnittstelle A erreichen, zur Schnittstelle B weitergeleitet und ebenso alle Pakete, welche die Schnittstelle B erreichen, zur Schnittstelle A weitergeleitet hat und dabei beide Schnittstellen das gleiche Paket erhalten, entsteht eine klassische Routing-Schleife, in der Pakete in beide Richtungen weitergeleitet werden, bis ihre IP-TTLs ablaufen. Selbst wenn der TTL-Verfall berücksichtigt wird, sollten alle Arten von Routing-Schleifen am besten vermieden werden, da diese zumindest temporär die Leistungsfähigkeit des Netzwerks beeinträchtigen.

Die zugrundeliegenden Annahmen des RPF-Checks sind, dass:

• die Unicast-Routing-Tabelle korrekt ist und konvergiert
• der verwendete Pfad von einem Sender zu einem Router und der Rückwärtspfad vom Router zurück zum Sender symmetrisch sind.

Falls die erste Annahme nicht erfüllt ist, ist der RPF-Check fehlschlagen, da er auf die Unicast-Routing-Tabelle des Routers als Ersatzfunktion angewiesen ist. Falls die zweite Annahme nicht erfüllt ist, würde der RPF-Check jeglichen Multicast-Traffic bei allen außer dem kürzesten Pfad vom Sender zum Router ablehnen, was eventuell zu einem nicht optimalen Multicast-Baum führen würde.

In Fällen, in denen die Verbindungen unidirektional sind, kann der Rückwärtspfad-Ansatz gänzlich versagen.

Unicast RPF (uRPF)

uRPF, wie es in RFC 3704 definiert wurde, ist eine Evolution des Konzepts, dass Traffic von bekannten invaliden Netzwerken nicht auf Schnittstellen akzeptiert werden soll, von welchen dieser niemals ausgegangen sein sollte. Die ursprüngliche Idee, wie in RFC 2827 gesehen werden kann, war, Traffic an einer Schnittstelle zu blockieren, falls er von RFC 1918 privaten Adressen stammt. Es ist eine vernünftige Vorgehensweise für viele Organisationen, einfach die Verbreitung von privaten Adressen in ihren Netzwerken zu verbieten, es sei denn, sie werden explizit verwendet. Das ist ein großer Vorteil für den Internet-Backbone, da das Blockieren von Paketen, die aus offensichtlich falschen Quell-Adressen stammen, dabei hilft IP-Adressen-Spoofing zu reduzieren, was üblicherweise in DoS, DDoS, und Netzwerk-Scans zum Verschleiern der Quelle des Scans eingesetzt wird.

uRPF erweitert diese Idee mit Hilfe des Wissens, welches alle Router besitzen müssen, um ihre Arbeit erledigen zu können. Dabei wird ihre Routing Information Base (RIB) oder Forwarding Information Base (FIB) verwendet, um dabei zu helfen, die möglichen Quell-Adressen, welche auf einer Schnittstelle sichtbar sein sollten, weiter einzuschränken. Pakete werden nur dann weitergeleitet, falls diese von der vom Router bestimmten besten Route zur Quelle des Pakets kommen, was sicherstellt, dass:

• Pakete, die eine Schnittstelle erreichen, von einem (potentiell) validen Host stammen, wie im korrespondierenden Eintrag in der Routingtabelle angezeigt wird
• Pakete mit Quell-Adressen, welche nicht durch die Eingabe-Schnittstelle erreicht werden konnten, verworfen werden können, ohne die normale Verwendung zu stören, da diese wahrscheinlich von einer fehlkonfigurierten oder bösartigen Quelle stammen.

Im Fall von symmetrischem Routing, bei dem Pakete über denselben Pfad hin und zurück fließen, und Terminal-Netzwerken mit nur einer Verbindung ist das eine sichere Annahme und uRPF kann implementiert werden, ohne mit vielen Problemen rechnen zu müssen. Es ist insbesondere nützlich, RPF auf Router-Schnittstellen zu implementieren, welche mit Singly-Homed-Netzwerken und Terminal-Subnetzen verbunden sind, da symmetrisches Routing garantiert ist. Wird uRPF so nah wie möglich zur echten Quelle des Traffics verwendet, wird auch gefälschter Traffic gestoppt, bevor er eine Chance hat, Bandbreite zu nutzen oder einen Router zu erreichen, welcher nicht für RPF konfiguriert ist und daher unpassend weitergeleitet wird.

Leider ist es auf dem größeren Internet-Backbone oft der Fall, dass Routing asymmetrisch ist und kein Verlass auf Routingtabellen besteht, um die beste Route von einer Quelle zu einem Router aufzuzeigen. Routingtabellen spezifizieren den besten Vorwärtspfad und nur im symmetrischen Fall kann dieser mit dem besten Rückwärtspfad gleichgesetzt werden. Aufgrund dieser Asymmetrie ist es wichtig, sich beim implementieren von uRPF dieser potentiellen Existenz von Asymmetrie bewusst zu sein, um versehentliches Filtern von legitimem Traffic zu vermeiden.

RFC 3704 gibt mehr Details dazu, wie das grundlegendste Konzept „Diese Quell-Adresse muss in der Routingtabelle für die Eingabe-Schnittstelle sichtbar sein“, bekannt als Strict Reverse Path Forwarding, erweitert werden kann, um einige lockerere Fälle zu beinhalten, die immer noch von Vorteil sein können, während zumindest etwas Asymmetrie zugelassen wird.

Unicast-RPF-Verwechslung

RPF wird oft inkorrekterweise als Reverse Path Filtering definiert, insbesondere wenn es um Unicast Routing geht. Dies ist eine verständliche Fehlinterpretation des Akronyms, da, wenn RPF mit Unicast Routing wie in RFC 3704 beschrieben verwendet wird, Traffic entweder zugelassen oder zurückgewiesen wird, basierend darauf, ob der RPF-Check erfolgreich ist oder fehlschlägt. Der Gedanke dabei ist, dass Traffic zurückgewiesen wird, falls er den RPF-Check nicht besteht und daher gefiltert wird. Allerdings ist die korrekte Interpretation laut RFC 3704, dass Traffic weitergeleitet wird, falls er den RPF-Check besteht. Einige Beispiele der richtigen Verwendung können in Dokumenten von Juniper, Cisco, OpenBSD und am wichtigsten in RFC 3704 gesehen werden, worin die Verwendung von RPF mit Unicast definiert wird.

Während uRPF als Mechanismus zur Zugangs-Filterung genutzt wird, wird dies erreicht durch Reverse Path Forwarding.

Weblinks

• P. Ferguson, D. Senie: RFC 2827 – Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. Mai 2000 (löst RFC 2267 ab, englisch).
• F. Baker, P. Savola: RFC 3704 – Ingress Filtering for Multihomed Networks. März 2004 (löst RFC 2827 ab, englisch).
• Juniper - Configuring uRPF
• Brocade - Configuring uRPF
• Cisco - Understanding uRPF
• Multicast Reverse Forwarding(RPF)
• OpenBSD - Enabling uRPF in pf
• Linux - Enabling RPF in kernel
• Juniper Networks on multicast RPF

Einzelnachweise

1. ↑
2. ↑
3. ↑