Reverse-path forwarding: Difference between revisions

Revision as of 02:01, 11 February 2017

Latest revision as of 16:22, 11 August 2025

(50 intermediate revisions by 21 users not shown)

Line 1:

{{short description|Multicast routing technique to minimize loops and enhance security}}

{{Unreferenced|date=November 2009}}

{{No footnotes|date=May 2019}}

'''Reverse path forwarding (RPF)''' is a technique used in modern [[router (computing)|router]]s for the purposes of ensuring loop-free forwarding of [[multicast]] packets in multicast [[routing]] and to help prevent [[IP address spoofing]] in [[unicast]] routing.

'''Reverse -path forwarding''' ('''RPF)''') is a technique used in modern [[router (computing)|router]]s for the purposes of ensuring loop-free forwarding of [[multicast]] packets in multicast [[multicast routing]] and to help prevent [[IP address spoofing]] in [[unicast]] routing.<ref>{{cite web

== Multicast RPF ==

*| [httpurl=https://www.juniper.net/techpubsdocumentation/software/erx/erx50x/swconfig-routing-vol1/html/ip-multicast-config7.html#120398 Juniper Networks on multicast RPF]

Multicast RPF, typically denoted simply as RPF, is used in conjunction with a multicast routing protocol such as [[Multicast Source Discovery Protocol|MSDP]], [[Sparse multicast|PIM-SM]] and [[Dense multicast|PIM-DM]] to ensure loop-free forwarding of multicast packets. In multicast routing, the decision to forward traffic is based upon source address and not on destination address as in unicast routing. It does this by utilizing either a dedicated multicast routing table or alternatively the router's unicast routing table.

| title=Reverse Path Forwarding

| date=2010

| publisher=[[Juniper Networks]]

| access-date=2021-05-12}}</ref>

In standard unicast [[IP routing]], the router forwards the packet away from the source to make progress along the distribution tree and prevent routing loops. In contrast, the router's multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree at the source of the multicast. This approach is known as reverse-path forwarding.

When a multicast packet enters a router's interface, it will look up the list of networks that are reachable via that interface i.e., it checks the reverse path of the packet. If the router finds a matching routing entry for the source IP address of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in multicast for that multicast group. If the RPF check fails, the packet will be dropped. As a result, the forwarding of the packet is decided based upon the reverse path of the packet rather than the forward path. RPF routers only forward packets that come into the interface that also holds the routing entry for the source of the packet, thus breaking any loop.

== Multicast RPF ==

This is critically important in redundant multicast topologies. Because the same multicast packet could reach the same router via multiple interfaces, RPF checking is integral in the decision to forward packets or not. If the router forwarded all packets that come in interface A to interface B and it also forwarded all packets coming in interface B to interface A and both interfaces receive the same packet, this will create a classic [[routing loop]] where packets will be forwarded in both directions until their IP [[Time to live|TTL]]s expire. Even considering TTL expiry, all types of routing loops are best avoided as they involve at least temporary network degradation.

Multicast RPF, typically denoted simply as RPF, is used in conjunction with a multicast [[routing protocol]] such as [[Multicast Source Discovery Protocol|MSDP]], or [[SparseProtocol multicast|PIM-SM]]Independent and [[Dense multicast|PIM-DMMulticast]] to ensure loop-free forwarding of multicast packets. In multicast routing, the decision to forward traffic is based upon source address and not on destination address as in unicast routing. It does this by utilizing either a dedicated multicast routing table or, alternatively, the router's unicast routing table.

When a multicast packet enters a router's interface, itthe willrouter looklooks up the list of networks that are reachable via that interface (i.e., it checks the reversepaths pathby ofwhich the packet could have arrived). If the router finds a matching routing entry for the source IP address of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in multicast for that multicast group. If the RPF check fails, the packet will beis dropped. As a result, the forwarding of the packet is decided based upon the reverse path of the packet rather than the forward path. RPF routersBy only forwardforwarding packets that come into the interface that also holds the routing entry for the source of the packet, thusloops breaking anyare loopprevented.

The underlying assumptions of RPF check are that:

* the unicast routing table must be correct and converged.

* the path used from a sender to a router and the reverse path from the router back to the sender are symmetric.

This is critically important in redundant multicast topologies. Because the same multicast packet could reach the same router via multiple interfaces, RPF checking is integral in the decision to forward packets or not. If the router forwarded all packets that come in interface A to interface B and it also forwarded all packets coming in interface B to interface A and both interfaces receive the same packet, this will create a classic [[routing loop]] where packets will be forwarded in both directions until their IP [[Time to live|TTL]]s expire. Even considering TTL expiry, all types of routingRouting loops are best avoided as they involve at leastunnecessarily temporaryconsume network degradationresources.

If the first assumption is not true, the RPF check will fail because it depends upon the router's unicast routing table as a fallback. If the second assumption is not true, the RPF check would reject multicast traffic on all but the shortest path from the sender to the router and would eventually lead to non-optimal multicast tree.

The underlying assumptions of an RPF check are that:,

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

*# the unicast routing table must beis correct and converged.stable and,

*# the path used from a sender to a router and the reverse path from the router back to the sender are symmetric.

If the first assumption is not truefalse, the RPF check will fail because it depends upon the router's unicast routing table as a fallback. If the second assumption is not truefalse, the RPF check would reject multicast traffic on all but the shortest path from the sender to the router andwhich would eventually lead to a non-optimal multicast tree. In cases where the links are unidirectional, the reverse-path approach can fail altogether.

== Unicast RPF (uRPF) ==

'''Unicast RPF''' (uRPF), as defined in RFC 3704, is an evolution of the concept that traffic from known invalid networks should not be accepted on interfaces from which theyit should never have originated. The original idea as seen in RFC 2827 was to block traffic on an interface if it is sourced from forged IP addresses. It is a reasonable assumption for many organizations to simply disallow propagation of private addresses on their networks unless they are explicitly in use. This is a great benefit to the [[Internet backbone]] as blocking packets from obviously bogus source addresses helps to cut down on IP address spoofing which is commonly used in [[denial of service|DoS]], [[distributed denial of service|DDoS]], and network scanning to obfuscate the source of the scan.<ref>{{cite web

| url=https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding

| title=Understanding Unicast Reverse Path Forwarding

| publisher=[[Cisco Systems]]

| access-date=2021-05-12}}</ref>

uRPF extends this idea by utilizing the knowledge all routers must have to do their jobs usingin their [[routing information base]] (RIB) or [[forwarding information base]] (FIB) to do their primary job, to help further restrict the possible sourcessource addresses that should be seen on an interface. Packets are only forwarded if they come from a router's best route to the source of a packet. Packets coming into an interface come from valid subnetworks, ensuringas indicated by the corresponding entry in the routing table are forwarded. Packets with source addresses that: could ''not'' be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source.

* packets coming into an interface come from (potentially) valid hosts, as indicated by the corresponding entry in the routing table.

* packets with source addresses that could ''not'' be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source.

In cases of symmetric routing, routing where packets flow forwardboth and reversedirections downthrough the same path, and terminal networks withconnected onlyvia a onesingle link, this is a safe assumption and uRPF can be implemented without many anticipated problems. It is particularly useful to implement RPF on routers' interfaces that are connected to singly homed networks and terminal subnets as symmetric routing is guaranteed. Using uRPF as close as possible to the real source of traffic also stops spoofed traffic before it has any chance of using bandwidth or reaching a router whichthat is not configured for RPF and thus inappropriately forwarded.

Unfortunately, it is often the case on the larger Internet backbone that routing is asymmetric and the routing tables cannot be relied upon to point to the best route for a source to get to a router. Routing tables specify the best forward path and only in the symmetric case does that equate to the best reverse path. Because of this asymmetry itIt is important when implementing uRPF to be aware of the potential for asymmetry to exist to prevent accidental filtering of legitimate traffic.

RFC 3704 gives more details on how to extend the most basic "this source address must be seen in the routing table for the input interface" concept known as '''strict reverse -path forwarding''' to include some more relaxed cases that can still be of benefit while allowing for at least some asymmetry.

===Strict mode===

In strict mode, each incoming packet is tested against the FIB and, if the ''incoming'' interface is not the best reverse path, the packet check will fail. By default failed packets are discarded.{{efn|name=command|Example command on Cisco devices: ip verify unicast source reachable-via {rx} - Strict mode, {any} - loose mode}}

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

===Feasible mode===

In feasible mode, the FIB maintains alternate routes to a given ipIP address. If the ''incoming'' interface matches with any of the routes associated with the IP address, then the packet is forwarded. Otherwise, the packet is dropped.

===Loose mode===

In loose mode each incoming packet's source address is tested against the FIB. The packet is dropped only if the source address is not reachable via ''any'' interface on that router.{{efn|name=command}}

== {{anchor|Filtering}}UnicastFiltering RPFvs. confusionforwarding ==

RPF is often incorrectly definedinterpreted as Reversereverse-path Path Filtering''filtering'', particularly when it comes to unicast routing. This is an understandable misinterpretationalternate interpretation of the acronym in that when RPF is used with unicast routing as in RFC 3704, traffic is either permitted or denied based upon the RPF check passing or failing. The thought being that traffic is denied if it fails the RPF check and is therefore filtered,. howeverWhile asuRPF peris RFCused 3704as thean correct interpretation is that traffic isingress '''forwarded'filtering'' ifmechanism, it passesis the RPF check. Several examples of the proper usage can be seen in documentsaffected by [http://www.juniper.net/techpubs/software/junos/junos56/swconfig56reverse-interfaces/html/interfaces-family-config15.htmlpath Juniper], [http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html Cisco], [http://www.openbsd.org/faq/pf/filter.html#urpf OpenBSD], and most importantly RFC 3704 which defines the use of RPF with unicast''forwarding''.

Reverse path filters are typically used to disable asymmetric routing where an IP application has a different incoming and outgoing routing path. Its intent is to prevent a packet entering one interface from leaving via the other interfaces. Reverse-path Filtering is a feature of the [[Linux Kernel]].<ref>{{cite web

While uRPF is used as an ingress '''filtering''' mechanism, it is affected by reverse path '''forwarding'''.

| url=https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security/

| title=rp_filter and LPIC-3 Linux Security

=={{anchor|RPB}}Reverse path broadcast==

| date=2020-08-27

{{Empty section|date=February 2017}}

| website=theurbanpenguin.com

| access-date=2021-05-12}}</ref>

== See also ==

* [[Flooding (computer networking)]]

* [[Flooding algorithm]]

==Notes==

== External links ==

{{Notelist}}

* RFC 2827

* RFC 3704

* [http://www.juniper.net/techpubs/software/junos/junos56/swconfig56-interfaces/html/interfaces-family-config15.html Juniper - Configuring uRPF]

* [http://www.brocade.com/downloads/documents/html_product_manuals/NI_05500c_SWITCHING/wwhelp/wwhimpl/common/html/wwhelp.htm#context=NetIron_05500c_SwitchingGuide&file=RPF.24.2.html Brocade - Configuring uRPF]

* [http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html Cisco - Understanding uRPF]

* [http://blog.ipexpert.com/2010/12/13/multicast-reverse-path-forwarding-rpf/ Multicast Reverse Forwarding(RPF)]

* [http://www.openbsd.org/faq/pf/filter.html#urpf OpenBSD - Enabling uRPF in pf]

* [http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html Linux - Enabling RPF in kernel]

* [http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/html/ip-multicast-config7.html#120398 Juniper Networks on multicast RPF]

==References==

{{Reflist}}

== External links ==

* {{cite IETF |RFC=2827 |title=Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing}}

* {{cite IETF |RFC=3704 |title=Ingress Filtering for Multihomed Networks}}

[[Category:Routing]]