Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Unicast Reverse Path Forwarding Check for VPNs

Understanding Unicast RPF (Switches)

To protect against IP spoofing, and some types of denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks, unicast reverse-path-forwarding (RPF) verifies that packets are arriving from a legitimate path. It does this by checking the source address of each packet that arrives on an untrusted ingress interface and, comparing it to the forwarding-table entry for its source address. If the packet is from a valid path, that is, one that the sender would use to reach the destination, the device forwards the packet to the destination address. If it is not from a valid path, the device discards the packet. Unless it is protected against, IP spoofing can be an effective way for intruders to pass IP packets to a destination as genuine traffic, when in fact the packets are not actually meant for the destination.

Unicast RPF is supported for the IPv4 and IPv6 protocol families, as well as for the virtual private network (VPN) address family. Unicast RPF is not supported on interfaces configured as tunnel sources. This affects only the transit packets exiting the tunnel.

There are two modes of unicast RPF, strict mode, and loose mode. The default is strict mode, which means the switch forwards a packet only if the receiving interface is the best return path to the packet's unicast source address. Strict mode is especially useful on untrusted interfaces (where untrusted users or processes can place packets on the network segment), and for symmetrically routed interfaces (see When to Enable Unicast RPF.) For more information about strict unicast RPF, see RFC 3704, Ingress Filtering for Multihomed Networks at http://www.ietf.org/rfc/rfc3704.txt.

To enable strict mode unicast RPF on a selected customer-edge interface:

[edit interfaces]

user@switch# set interface-name unit 0 family inet rpf-check

The other mode is loose mode, which means the system checks to see if the packet has a source address with a corresponding prefix in the routing table, but it does not check whether the receiving interface is the best return path to the packet's unicast source address.

To enable unicast RPF loose mode, enter:

[edit interfaces]

user@switch# set interface-name unit 0 family inet rpf-check mode loose

Note:

On Juniper Networks EX3200, EX4200, and EX4300 Ethernet Switches, the switch applies unicast RPF globally to all interfaces when unicast RPF is configured on any interface. For additional information, see Limitations of the Unicast RPF Implementation on EX3200, EX4200, and EX4300 Switches.

Unicast RPF for Switches Overview

Unicast RPF functions as an ingress filter that reduces the forwarding of IP packets that might be spoofing an address. By default, unicast RPF is disabled on the switch interfaces. The switch supports only the active paths method of determining the best return path back to a unicast source address. The active paths method looks up the best reverse path entry in the forwarding table. It does not consider alternate routes specified using routing-protocol-specific methods when determining the best return path.

If the forwarding table lists the receiving interface as the interface to use to forward the packet back to its unicast source, it is the best return path interface.

Unicast RPF Implementation

Unicast RPF Packet Filtering

When you enable unicast RPF on the switch, the switch handles traffic in the following manner:

  • If the switch receives a packet on the interface that is the best return path to the unicast source address of that packet, the switch forwards the packet.

  • If the best return path from the switch to the packet's unicast source address is not the receiving interface, the switch discards the packet.

  • If the switch receives a packet that has a source IP address that does not have a routing entry in the forwarding table, the switch discards the packet.

Bootstrap Protocol (BOOTP) and DHCP Requests

Bootstrap protocol (BOOTP) and DHCP request packets are sent with a broadcast MAC address and therefore the switch does not perform unicast RPF checks on them. The switch forwards all BOOTP packets and DHCP request packets without performing unicast RPF checks.

Default Route Handling

If the best return path to the source is the default route (0.0.0.0) and the default route points to reject, the switch discards the packets. If the default route points to a valid network interface, the switch performs a normal unicast RPF check on the packets.

Note:

On the EX4300, the default route is not used when the switch is configured in unicast RPF strict mode.

When to Enable Unicast RPF

Enable unicast RPF when you want to ensure that traffic arriving on a network interface comes from a source that resides on a network that interface can reach. You can enable unicast RPF on untrusted interfaces to filter spoofed packets. For example, a common application for unicast RPF is to help defend an enterprise network from DoS/DDoS attacks coming from the Internet.

Enable unicast RPF only on symmetrically routed interfaces, and as close as possible to the traffic source stops spoofed traffic before it can proliferate or reach interfaces that do not have unicast RPF enabled. Because unicast RPF is enabled globally on EX3200, EX4200, and EX4300 switches, ensure that all interfaces are symmetrically routed before you enable unicast RPF on these switches, as shown in Figure 4. Enabling unicast RPF on asymmetrically routed interfaces results in packets from legitimate sources being filtered. A symmetrically routed interface uses the same route in both directions between the source and the destination.

Unicast RPF is enabled globally on EX3200, EX4200, and EX4300 switches, to with these devices, be sure that all interfaces are symmetrically routed before you enable unicast RPF on these switches. Enabling unicast RPF on asymmetrically routed interfaces results in packets from legitimate sources being filtered.

Figure 1: Symmetrically Routed InterfacesSymmetrically Routed Interfaces

The following switch interfaces are most likely to be symmetrically routed and thus are candidates for unicast RPF enabling:

  • The service provider edge to a customer

  • The customer edge to a service provider

  • A single access point out of the network (usually on the network perimeter)

  • A terminal network that has only one link

On EX3200, EX4200, and EX4300 switches, we recommend that you enable unicast RPF explicitly on either all interfaces or only one interface. To avoid possible confusion, do not enable it on only some interfaces:

  • Enabling unicast RPF explicitly on only one interface makes it easier if you choose to disable it in the future because you must explicitly disable unicast RPF on every interface on which you explicitly enabled it. If you explicitly enable unicast RPF on two interfaces and you disable it on only one interface, unicast RPF is still implicitly enabled globally on the switch. The drawback of this approach is that the switch displays the flag that indicates that unicast RPF is enabled only on interfaces on which unicast RPF is explicitly enabled, so even though unicast RPF is enabled on all interfaces, this status is not displayed.

  • Enabling unicast RPF explicitly on all interfaces makes it easier to know whether unicast RPF is enabled on the switch because every interface shows the correct status. (Only interfaces on which you explicitly enable unicast RPF display the flag that indicates that unicast RPF is enabled.) The drawback of this approach is that if you want to disable unicast RPF, you must explicitly disable it on every interface. If unicast RPF is enabled on any interface, it is implicitly enabled on all interfaces.

When Not to Enable Unicast RPF

Typically, you will not enable unicast RPF if:

  • Switch interfaces are multihomed.

  • Switch interfaces are trusted interfaces.

  • BGP is carrying prefixes and some of those prefixes are not advertised or are not accepted by the ISP under its policy. (The effect in this case is the same as filtering an interface by using an incomplete access list.)

  • Switch interfaces face the network core. Core-facing interfaces are usually asymmetrically routed.

An asymmetrically routed interface uses different paths to send and receive packets between the source and the destination, as shown in Figure 5. This means that if an interface receives a packet, that interface does not match the forwarding table entry as the best return path back to the source. If the receiving interface is not the best return path to the source of a packet, unicast RPF causes the switch to discard the packet even though it comes from a valid source.

Figure 2: Asymmetrically Routed InterfacesAsymmetrically Routed Interfaces
Note:

Do not enable unicast RPF on EX3200, EX4200, and EX4300 switches if any switch interfaces are asymmetrically routed, because unicast RPF is enabled globally on all interfaces of these switches. All switch interfaces must be symmetrically routed for you to enable unicast RPF without the risk of the switch discarding traffic that you want to forward.

Limitations of the Unicast RPF Implementation on EX3200, EX4200, and EX4300 Switches

On EX3200, EX4200, and EX4300 switches, the switch implements unicast RPF on a global basis. You cannot enable unicast RPF on a per-interface basis. Unicast RPF is globally disabled by default.

  • When you enable unicast RPF on any interface, it is automatically enabled on all switch interfaces, including link aggregation groups (LAGs), integrated routing and bridging (IRB) interfaces, and routed VLAN interfaces (RVIs).

  • When you disable unicast RPF on the interface (or interfaces) on which you enabled unicast RPF, it is automatically disabled on all switch interfaces.

Note:

You must explicitly disable unicast RPF on every interface on which it was explicitly enabled or unicast RPF remains enabled on all switch interfaces.

QFX switches, OCX switches, and EX3200 and EX4200 switches do not perform unicast RPF filtering on equal-cost multipath (ECMP) traffic. The unicast RPF check examines only one best return path to the packet source, but ECMP traffic employs an address block consisting of multiple paths. Using unicast RPF to filter ECMP traffic on these switches can result in the switch discarding packets that you want to forward because the unicast RPF filter does not examine the entire ECMP address block.

Example: Configuring Unicast RPF (On a Router)

This example shows how to help defend ingress interfaces against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks by configuring unicast RPF on a customer-edge interface to filter incoming traffic.

Requirements

No special configuration beyond device initialization is required.

Overview

In this example, Device A is using OSPF to advertise a prefix for the link that connects to Device D. Device B has unicast RPF configured. OSPF is enabled on the links between Device B and Device C and the links between Device A and Device C, but not on the links between Device A and Device B. Therefore, Device B learns about the route to Device D through Device C.

If ingress filtering is used in an environment where DHCP or BOOTP is used, it should be ensured that the packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255 are allowed to reach the relay agent in routers when appropriate.

This example also includes a fail filter. When a packet fails the unicast RPF check, the fail filter is evaluated to determine if the packet should be accepted anyway. The fail filter in this example allows Device B’s interfaces to accept Dynamic Host Configuration Protocol (DHCP) packets. The filter accepts all packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255.

Topology

Figure 6 shows the sample network.

Figure 3: Unicast RPF Sample TopoolgyUnicast RPF Sample Topoolgy

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device A

Device B

Device C

Device D

Device E

Configuring Device A

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device A:

  1. Configure the interfaces.

  2. Configure OSPF.

  3. Configure the routing policy.

  4. If you are done configuring Device A, commit the configuration.

Configuring Device B

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device B:

  1. Configure the interfaces.

  2. Configure OSPF.

  3. Configure unicast RPF, and apply the optional fail filter.

  4. (Optional) Configure the fail filter that gets evaluated if a packet fails the RPF check.

  5. (Optional) Configure only active paths to be considered in the RPF check.

    This is the default behavior.

  6. If you are done configuring Device B, commit the configuration.

Results

Confirm your configuration by issuing the show firewall, show interfaces, show protocols, show routing-options, and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device A

Device B

Enter the configurations on Device C, Device D, and Device E, as shown in CLI Quick Configuration.

Verification

Confirm that the configuration is working properly.

Confirm That Unicast RPF Is Enabled

Purpose

Make sure that the interfaces on Device B have unicast RPF enabled.

Action
Meaning

The uRPF flag confirms that unicast RPF is enabled on this interface.

Confirm That the Source Addresses Are Blocked

Purpose

Use the ping command to make sure that Device B blocks traffic from unexpected source addresses.

Action

From Device A, ping Device B’s interfaces, using 10.0.0.17 as the source address.

Meaning

As expected, the ping operation fails.

Confirm That the Source Addresses Are Unblocked

Purpose

Use the ping command to make sure that Device B does not block traffic when the RPF check is deactivated.

Action
  1. Deactivate the RPF check on one of the interfaces.

  2. Rerun the ping operation.

Meaning

As expected, the ping operation succeeds.