uRPF Design Consideration

by | May 12, 2024 | 0 comments

While the Anti-Spoofing uRPF technology and mechanism are well-known, determining when and where to apply it in Strict or Loose mode can be confusing. This writing aims to simplify understanding from a Design perspective and provide practical use cases.

Why is uRPF useful in the first place?

To detect spoofed IP source addresses, the uRPF function has become essential. We may ask, why not just use ACLs instead? Indeed, we can use an ACL to only allow traffic from the networks that are expected to be behind a specific ingress interface.

Well, managing ACLs can become challenging when dealing with multiple routers, interfaces, and routes that frequently change. Imagine hundreds of lines long with frequent changes to respond to evolving or new incidents.

By employing uRPF for “IP traffic source address verification” in conjunction with the “routing control and forwarding plane,” no reconfiguration changes are necessary when there are topology changes or new prefix assignments.

How does uRPF work ?

Unicast RPF verifies all packets entering the configured interface. When a packet arrives at a router interface where uRPF is enabled:

  • When uRPF STRICT Mode is configured : After receiving a packet, uRPF performs a lookup on the source IP address in the FIB to determine which outgoing interface is used to reach it. If the ingress interface is the same as the FIB interface, the packet is permitted.
  • When uRPF LOOSE Mode is configured : After receiving a packet, uRPF performs a lookup in the RIB and permit the trafic only if the source IP address exists in the routing table.
    • The word “Loose” is used because it relaxes or loosens the “Strict Mode” restrictions.

Let’s go through a few scenarios.

Use Case : uRPF applied in the CE – Dual-Homed scenario :

As we can see, Strict Mode poses a problem whenever there is an asymmetric flow, where a packet traverses from a source to a destination via one path and takes a different path when it returns to the source (or vice versa).

Use Case : We can still use uRPF Strict Mode even in Dual/MultiHomed scenario

We can still enforce strict mode by forcing the prefered route over a specific interface, for example, by applying a BGP weight. This can be used to override the Local Preference learned from the CE-to-CE iBGP session in an active/standby CE scenario. Alternatively, we can opt for a static route, although it’s less dynamic.

Even if these workarounds make uRPF Strict mode work in a Dual-Homed scenario, they can reduce flexibility, especially when the customer desires autonomy by adjusting themself BGP attributes to use only the CE1 or CE2 as primary for example.

Use Case : uRPF applied in the PE – Dual-Homed scenario :

If uRPF cannot be applied on the CE devices, whether because they are not managed by the Provider or due to the need for additional security measures, it can be configured on the PE routers to enforce security at another layer (even in addition to those configured on the CE or not).

As shown in the diagram below, there are also cases where client CEs are not dual-homed on the same PE device. In this scenario, we can always force the directly connected CE to be preferred by using BGP weight for example.

But be careful here, as we also lose some flexibility. For instance, if another site’s “CE” is or will be connected in the future to the same PE, traffic between those will be forced directly due to the weight in our case. This happens even if the customer would want to deprioritize it using BGP attributes such as as-prepend or MED. But in cases where the PE router is dedicated to this peering, you should have no problem enforcing local routes via BGP Weight.

Use Case: When is uRPF Loose Mode less or not effective ?

In the following diagram, we can see customers (can be MPLS or ISP) connected to the same physical PE device in which uRPF Loose mode has been configured :

The security risk with Loose Mode is significant when applied on a router where multiple sites, customers (e.g. with different VRFs leaking into each other), exist in the same routing table. Since it will most likely have the full routing table of a customer/perimeter or the full internet routing table in an ISP router/VRF, the router may allow any spoofed traffic coming from the subnets listed in that routing table.

It’s important to note that similar scenarios can arise when using uRPF Loose mode on the CE in cases of multiple interconnections, or on routers interconnecting different zones within a data center, and so on.

Howerver, when uRPF is implemented on a dedicated CE routers toward the LAN of the customers in dual-homed mode with CE-to-CE iBGP Peering, the Loose Mode does not pose a security risk as long as it only receives the default route provided by the PE (so it doesn’t possess the full table). If you don’t have the CE-to-CE iBGP session, Strict Mode can be the best choice.

Use Case : uRPF on Multi-ISP peerings :

If an ISP peers with another one for redundancy purposes or if it peers with multiple ISPs, then:

  • Configuring uRPF in Strict mode can be disruptive in Multi Internet-peering environments, where traffic may often follows asymmetric paths
  • Configuring uRPF in Loose mode for these peerings is ineffective. Routers at Internet peering points typically maintain the Full Internet Routing table. Therefore, all Internet traffic passing through the uRPF check will be considered legitimate since almost all the Networks exist in the same table.
    • Therefore, only packets with source addresses belonging to networks not listed in the global routing table would be dropped (e.g., non-routable IP addresses – Martian Address, IPv6 addresses that are not yet assigned/announced in the Global Internet, etc.)

Even in this case, some Companies/ISP do still configure uRPF in Loose mode to enable the Source RTBH mechanism, but that’s for another episode 🙂

What about the default route

You might wonder why someone would configure uRPF toward where the default route was learned, considering it allows traffic from any source, correct ? To prevent this situation in case the default route wasn’t expected, the majority of vendors, only consider the default route if an explicit configuration command “allow-default” is configured. This adds an additional check to ensure that the user explicitly wants to accept the default.

  • In Strict mode, with ‘allow-default’, if traffic from a spoofed IP address comes from the interface where the default route points AND at the same time, that source address exists and points to another interface, then the packet will be dropped. This is a case where it is useful.
  • In Loose mode, with ‘allow-default’, all packets are automatically accepted. Therefore, it makes no sense to configure unicast RPF Loose mode on interfaces where the default route is or expected to be received. However, if there is a static pointing to some next-hop/interface or to Null0 for S/RTBH, uRPF will still count that as a drop action, regardless of whether there is a default route configured in the routing table.

The key here is that the router still verifies the reverse path of the incoming packet, even when the allow-default option is enabled in both Loose and Strict mode.

Let’s summatize :

When to apply uRPF :

  • Strict Mode :
    • When a Customer is mono-homed, Strict mode provide all its benefit.
    • In dual-homed scenario, as any asymmetric traffic may be dropped, you can configure uRPF Strict mode by forcing the routing protocol (so the FIB) using for example BGP weight, static routes, or configure an ACL exception with the uRPF :
      • The result is that all traffic passing through that router will prefer the locally prioritized route (next-hop/interface).
  • Loose Mode :
    • When a customer is dual-homed, there might be asymmetric traffic, and this is where Loose mode is interesting. But keep in mind
    • The security risk with Loose Mode is especially significant when applied on a router (Like PE router) that have the full routing table of the company/customers. Therefore, the router may then allow any spoofed traffic coming from the subnets listed in the routing table.
    • From an ISP perspective, Loose mode has no real benefit when a company or ISP is connecting to multiple ISPs and is receiving the full Internet table. Yet, the two factors that you will get with Loose mode in those cases are:
      • Drop traffic coming from non-routable IP addresses – Martian Address, IP addresses that are not yet assigned/announced in the Global Internet , etc.
      • If you need to enable and work with the S/RTBH mechanism
    • If uRPF loose mode is not available on the device you are trying to design/configure, remember that you can configure traditional, ideally automated, ACLs instead to make an exception to the Strict mode.

Where to apply uRPF :

  • The most effective way, is to apply uRPF at the network edge facing customers and servers (access layer), where it is not intended to forward traffic for other networks, similar to a stub network.
    • So, implement uRPF at the closest customer point, such as on the Customer Edge (CE) device when managed by the service provider or/and on the Provider Edge (PE) device when managed by the customer, on access switches, etc.
      • If you have already secured the edge of your network, a packet with a spoofed source IP address would not even reach a core-facing interface.
    • uRPF may not be limited to just edge devices; depending on the security level you want to achieve, this is where the concept of security in depth becomes important. In some cases, applying uRPF to the core-facing interfaces can be beneficial and enhance security, regardless of the mode chosen. But because this could also add too much complexity, its effectiveness truly depends on the criticality of the environment and the security requirements.
  • Every ISP shall configure uRPF to safeguard the Internet against various attacks, particularly when Provider IP addresses are assigned to end users.
    • Those attaks include Smurf, some DDoS, amplification, certain floods, and all related spoofing attacks!
  • Even for private MPLS customers, implementing uRPF should be mandatory, since spoofing can significantly impact IT security. Imagine a malicious user spoofing the IP address of an infrastructure device, bypassing firewall restrictions, and overwhelming the SIEM servers with false logs to hide their tracks.

Others things to know before applying uRPF :

Now, the conclusion :

Let’s reformat the information about when to apply Strict or Loose Unicast Reverse Path Forwarding (uRPF) mode:

  1. Mono-Homed Scenarios:
    • For both Customer Edge (CE) and Provider Edge (PE) routers, use Strict mode, whether on ISP or Private Network.
  2. Multi-Homed Scenarios:
    • MPLS/Private Network:
      • On PE routers:
        • Use Strict mode by configuring the router to prioritize its directly learned routes using BGP weight, static routes, etc.
        • Use Loose mode but be aware that spoofed IPs sourced from networks existing in the routing table will bypass the check : This is a case where Loose mode is less preferable for security reasons.
          • The key point here is whenever there is a possibility of having asymmetric traffic, and Loose Mode is to be applied, consider which subnets are present in the routing table since they will bypass the check. The more routes you have, the higher the risk.
      • On CE routers (if it involves a dedicated router/VRF and the default route is received from the backbone rather than the full table of the customers)
        • Use Strict mode if there is no CE-to-CE iBGP session or link,
        • Use Loose mode if there is a CE-to-CE iBGP session or link : This is a case where Loose mode does not pose or add any security risk at all.
    • ISP:
      • Use Strict mode only if the ISP is mono-homed (e.g., Tier 3 ISPs serving residential customers or equivalent).
      • Use Loose mode when needed in scenarios like S/RTBH or to deny non-routable IP addresses (Martian Address), IP addresses that are not yet assigned/announced in the Global Internet , etc, But be aware that since the Full Internet Table is present, Loose mode will allow all spoofed traffic sourced from networks present in it (in the table).

Hopefully, now you have a better understanding of why, where, when, and which mode of uRPF to implement.

Mehdi SFAR (CCDE 2021:3, CCIE #51583)

Submit a Comment

Your email address will not be published. Required fields are marked *