Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring Unicast Reverse-Path-Forwarding Check

 

Understanding How Unicast Reverse Path Forwarding Prevents Spoofed IP Packet Forwarding

IP spoofing can occur during a denial-of-service (DoS) attack. IP spoofing allows an intruder to pass IP packets to a destination as genuine traffic, when in fact the packets are not actually meant for the destination. This type of spoofing is harmful because it consumes the destination’s resources.

A unicast reverse-path-forwarding (RPF) check is a tool to reduce forwarding of IP packets that might be spoofing an address. A unicast RPF check performs a forwarding table lookup on an IP packet’s source address, and checks the incoming interface. The router or switch determines whether the packet is arriving from a path that the sender would use to reach the destination. If the packet is from a valid path, the router or switch forwards the packet to the destination address. If it is not from a valid path, the router or switch discards the packet. Unicast RPF is supported for the IPv4 and IPv6 protocol families, as well as for the virtual private network (VPN) address family.

Note

Reverse path forwarding is not supported on the interfaces you configure as tunnel sources. This affects only the transit packets exiting the tunnel.

Example: Configuring Unicast Reverse-Path-Forwarding Checking to Prevent DoS and DDoS Attacks

Unicast reverse path forwarding (RPF) helps protect against DoS and DDoS attacks by verifying the unicast source address of each packet that arrives on an ingress interface where unicast RPF is enabled.

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 to filter incoming traffic.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

Large amounts of unauthorized traffic such as attempts to flood a network with fake (bogus) service requests in a DoS attack can consume network resources and deny service to legitimate users. One way to help prevent DoS and DDoS attacks is to verify that incoming traffic originates from legitimate network sources.

Unicast RPF helps ensure that a traffic source is legitimate (authorized) by comparing the source address of each packet that arrives on an interface to the forwarding table entry for its source address. If the device uses the same interface that the packet arrived on to reply to the packet's source, this verifies that the packet originated from an authorized source, and the device forwards the packet. If the device does not use the same interface that the packet arrived on to reply to the packet's source, the packet might have originated from an unauthorized source, and the device discards the packet.

In this example, Device B has unicast RPF configured. Device A is using OSPF to advertise a prefix for the link that connects to Device D. 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.

Figure 1 shows the sample network.

Figure 1: Unicast RPF Sample Topoolgy
Unicast 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

user@B> show interfaces fe-0/1/0.13 extensive

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.

user@A> ping 10.0.0.6 source 10.0.0.17

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.

user@B> deactivate interfaces fe-1/1/1.6 family inet rpf-check
user@A> ping 10.0.0.6 source 10.0.0.17

Meaning

As expected, the ping operation succeeds.