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
- Unicast RPF for Switches Overview
- Unicast RPF Implementation
- When to Enable Unicast RPF
- When Not to Enable Unicast RPF
- 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.
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 1. 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.
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 2. 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.
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.
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.
See Also
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.
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
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces fe-0/0/2 unit 5 family inet address 10.0.0.5/30 set interfaces fe-0/0/1 unit 17 family inet address 10.0.0.17/30 set interfaces fe-0/1/1 unit 25 family inet address 10.0.0.25/30 set interfaces fe-1/1/1 unit 29 family inet address 10.0.0.29/30 set protocols ospf export send-direct set protocols ospf area 0.0.0.0 interface fe-0/1/1.25 set protocols ospf area 0.0.0.0 interface fe-1/1/1.29 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from route-filter 10.0.0.16/30 exact set policy-options policy-statement send-direct then accept
Device B
set interfaces fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/1/1 unit 6 family inet address 10.0.0.6/30 set interfaces fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/1 unit 9 family inet address 10.0.0.9/30 set interfaces fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/0 unit 13 family inet address 10.0.0.13/30 set protocols ospf area 0.0.0.0 interface fe-0/1/1.9 set protocols ospf area 0.0.0.0 interface fe-0/1/0.13 set routing-options forwarding-table unicast-reverse-path active-paths set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32 set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32 set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic set firewall filter rpf-special-case-dhcp term allow-dhcp then accept set firewall filter rpf-special-case-dhcp term default then log set firewall filter rpf-special-case-dhcp term default then reject
Device C
set interfaces fe-1/2/0 unit 10 family inet address 10.0.0.10/30 set interfaces fe-0/0/2 unit 14 family inet address 10.0.0.14/30 set interfaces fe-1/0/2 unit 21 family inet address 10.0.0.21/30 set interfaces fe-1/2/2 unit 26 family inet address 10.0.0.26/30 set interfaces fe-1/2/1 unit 30 family inet address 10.0.0.30/30 set protocols ospf area 0.0.0.0 interface fe-1/2/0.10 set protocols ospf area 0.0.0.0 interface fe-0/0/2.14 set protocols ospf area 0.0.0.0 interface fe-1/2/2.26 set protocols ospf area 0.0.0.0 interface fe-1/2/1.30
Device D
set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30
Device E
set interfaces fe-1/2/0 unit 22 family inet address 10.0.0.22/30
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:
Configure the interfaces.
[edit interfaces] user@A# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30 user@A# set fe-0/0/2 unit 5 family inet address 10.0.0.5/30 user@A# set fe-0/0/1 unit 17 family inet address 10.0.0.17/30 user@A# set fe-0/1/1 unit 25 family inet address 10.0.0.25/30 user@A# set fe-1/1/1 unit 29 family inet address 10.0.0.29/30
Configure OSPF.
[edit protocols ospf] user@A# set export send-direct user@A# set area 0.0.0.0 interface fe-0/1/1.25 user@A# set area 0.0.0.0 interface fe-1/1/1.29
Configure the routing policy.
[edit policy-options policy-statement send-direct] user@A# set from protocol direct user@A# set from route-filter 10.0.0.16/30 exact user@A# set then accept
If you are done configuring Device A, commit the configuration.
[edit] user@A# commit
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:
Configure the interfaces.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30 user@B# set fe-1/1/1 unit 6 family inet address 10.0.0.6/30 user@B# set fe-0/1/1 unit 9 family inet address 10.0.0.9/30 user@B# set fe-0/1/0 unit 13 family inet address 10.0.0.13/30
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface fe-0/1/1.9 user@B# set interface fe-0/1/0.13
Configure unicast RPF, and apply the optional fail filter.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp
(Optional) Configure the fail filter that gets evaluated if a packet fails the RPF check.
[edit firewall filter rpf-special-case-dhcp] user@B# set term allow-dhcp from source-address 0.0.0.0/32 user@B# set term allow-dhcp from destination-address 255.255.255.255/32 user@B# set term allow-dhcp then count rpf-dhcp-traffic user@B# set term allow-dhcp then accept user@B# set term default then log user@B# set term default then reject
(Optional) Configure only active paths to be considered in the RPF check.
This is the default behavior.
[edit routing-options forwarding-table] user@B# set unicast-reverse-path active-paths
If you are done configuring Device B, commit the configuration.
[edit] user@B# commit
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
user@A# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
fe-0/0/2 {
unit 5 {
family inet {
address 10.0.0.5/30;
}
}
}
fe-0/0/1 {
unit 17 {
family inet {
address 10.0.0.17/30;
}
}
}
fe-0/1/1 {
unit 25 {
family inet {
address 10.0.0.25/30;
}
}
}
fe-1/1/1 {
unit 29 {
family inet {
address 10.0.0.29/30;
}
}
}
user@A# show protocols
ospf {
export send-direct;
area 0.0.0.0 {
interface fe-0/1/1.25;
interface fe-1/1/1.29;
}
}
user@A# show policy-options
policy-statement send-direct {
from {
protocol direct;
route-filter 10.0.0.16/30 exact;
}
then accept;
}
Device B
user@B# show firewall
filter rpf-special-case-dhcp {
term allow-dhcp {
from {
source-address {
0.0.0.0/32;
}
destination-address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
user@B# show interfaces
fe-1/2/0 {
unit 2 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.2/30;
}
}
}
fe-1/1/1 {
unit 6 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.6/30;
}
}
}
fe-0/1/1 {
unit 9 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.9/30;
}
}
}
fe-0/1/0 {
unit 13 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.13/30;
}
}
}
user@B# show protocols
ospf {
area 0.0.0.0 {
interface fe-0/1/1.9;
interface fe-0/1/0.13;
}
}
user@B# show routing-options
forwarding-table {
unicast-reverse-path active-paths;
}
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
- Confirm That the Source Addresses Are Blocked
- Confirm That the Source Addresses Are Unblocked
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
Logical interface fe-0/1/0.13 (Index 73) (SNMP ifIndex 553) (Generation 208)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 999390
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Local statistics:
Input bytes : 998994
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Transit statistics:
Input bytes : 396 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 289, Route table: 22
Flags: Sendbcast-pkt-to-re, uRPF
RPF Failures: Packets: 0, Bytes: 0
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.0.12/30, Local: 10.0.0.13, Broadcast: 10.0.0.15, Generation: 241Meaning
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 PING 10.0.0.6 (10.0.0.6): 56 data bytes ^C --- 10.0.0.6 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
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
Deactivate the RPF check on one of the interfaces.
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 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=63 time=1.316 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.263 ms ^C --- 10.0.0.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.263/1.289/1.316/0.027 ms
Meaning
As expected, the ping operation succeeds.