Reverse path forwarding

from Wikipedia, the free encyclopedia

Reverse path forwarding (RPF) is a technique that is used in modern routers . It enables the circular forwarding of multicast packets in multicast routing and helps prevent IP address spoofing in unicast routing.

Multicast RPF

Multicast RPF, typically simply referred to as RPF, is used in conjunction with a multicast routing protocol such as MSDP , PIM-SM and PIM-DM to ensure circular forwarding of multicast packets. In multicast routing, the decision about forwarding depends on the source address, not on the destination address as in unicast routing. This is done either through the use of a dedicated multicast routing table or alternatively through the router's unicast routing table.

When a multicast packet reaches the interface of a router, it sees the list of networks that can be reached via this interface; so it checks the reverse path of the packet. If the router finds a suitable routing entry for the source IP address of the multicast packet, the RPF check is successful and the packet is forwarded to all other interfaces that participate in the multicast of this multicast group. If the RPF check fails, the packet is discarded. As a result, the forwarding of the packet is decided based on the reverse path instead of the forward path of the packet. RPF routers only forward packets that reach the interface and also contain the routing entry of the source of the packet, thereby breaking up any circles.

This is of critical importance in redundant multicast topologies. Since the same multicast packet can reach the same router over multiple interfaces, the RPF check is an integral part of the decision-making process whether a packet should be forwarded or not. If the router forwards all packets that reach interface A to interface B and all packets that reach interface B to interface A and both interfaces receive the same packet, a classic routing loop is created in which Packets are forwarded in both directions until their IP TTLs expire. Even if TTL decay is taken into account, it is best to avoid all types of routing loops, as they affect the performance of the network, at least temporarily.

The underlying assumptions of the RPF check are that:

  • the unicast routing table is correct and converging
  • the path used from a sender to a router and the reverse path from the router back to the sender are symmetrical.

If the first assumption is not met, the RPF check will fail because it depends on the router's unicast routing table as a substitute function. If the second assumption is not met, the RPF check would reject all multicast traffic for all but the shortest path from the sender to the router, which would possibly lead to a non-optimal multicast tree.

In cases where the links are unidirectional, the reverse path approach can fail entirely.

Unicast RPF (uRPF)

uRPF, as it was defined in RFC 3704 , is an evolution of the concept that traffic from known invalid networks should not be accepted on interfaces from which it should never have originated. The original idea, as can be seen in RFC 2827 , was to block traffic on an interface if it came from RFC 1918 private addresses. It is sensible practice for many organizations to simply prohibit the distribution of private addresses on their networks unless they are specifically used. This is a great benefit for the Internet backbone , as blocking packets coming from obviously incorrect source addresses helps reduce IP address spoofing, which is commonly found in DoS , DDoS , and network scans to obscure the Source of the scan is used.

uRPF extends this idea with the help of the knowledge that all routers must have in order to be able to do their work. Here, their is Routing Information Base (RIB) or forwarding information base (FIB) used to help to further restrict the possible source addresses, which should be visible on an interface. Packets are only forwarded if they come from the best route determined by the router to the source of the packet, which ensures that:

  • Packets that reach an interface come from a (potentially) valid host, as indicated in the corresponding entry in the routing table
  • Packets with source addresses that could not be reached through the input interface can be discarded without disrupting normal use, as they are likely to come from a misconfigured or malicious source.

In the case of symmetrical routing, where packets flow back and forth over the same path, and terminal networks with only one connection, this is a safe assumption and uRPF can be implemented without facing many problems. It is particularly useful to implement RPF on router interfaces that are connected to singly homed networks and terminal subnets because symmetric routing is guaranteed. If uRPF is used as close as possible to the real source of the traffic, fake traffic is also stopped before it has a chance to use bandwidth or reach a router that is not configured for RPF and is therefore forwarded inappropriately.

Unfortunately, on the larger Internet backbone, it is often the case that routing is asymmetrical and there is no reliance on routing tables to point out the best route from a source to a router. Routing tables specify the best forward path and only in the symmetrical case can this be equated with the best backward path. Because of this asymmetry, it is important to be aware of this potential existence of asymmetry when implementing uRPF in order to avoid accidentally filtering legitimate traffic.

RFC 3704 gives more details on how the most basic concept, "This source address must be visible in the routing table for the input interface," known as Strict Reverse Path Forwarding , can be expanded to include some looser cases that still exist may be beneficial while allowing at least some asymmetry.

Strict fashion

In strict mode, every incoming packet is tested against the FIB. If the incoming interface is not the best backward path, the packet check will fail. By default, failed packets are discarded.

  • Example command on Cisco devices: ip verify unicast source reachable-via {rx} - Strict mode, {any} - loose mode

Feasible fashion

In feasible mode, the FIB receives alternative routes to a given IP address. If the inbound interface matches any of the routes associated with the IP address, the packet is forwarded. Otherwise the package is discarded.

Loose fashion

In loose mode, the source address of every incoming packet is tested against the FIB. The packet is only discarded if the source address can not be reached via a single interface on the router.

Unicast RPF confusion

RPF is often incorrectly defined as reverse path filtering, especially when it comes to unicast routing. This is a understandable misinterpretation of the acronym, since when RPF is used with unicast routing as described in RFC 3704 , traffic will either be allowed or denied based on whether the RPF check succeeds or fails. The idea is that traffic will be rejected if it does not pass the RPF check and is therefore filtered. However, according to RFC 3704 , the correct interpretation is that traffic is forwarded if it passes the RPF check. Some examples of proper usage can be seen in documents from Juniper, Cisco, OpenBSD, and most importantly RFC 3704 which defines the use of RPF with unicast.

While uRPF is used as a mechanism for access filtering , this is achieved through reverse path forwarding .

Web links

Individual evidence

  1. ↑ [1]
  2. ↑ [2]
  3. ↑ [3]