Understanding Unicast RPF (Routers)
For interfaces that carry IPv4 or IPv6 traffic, you can reduce the impact of denial of service (DoS) attacks by configuring unicast reverse path forwarding (RPF). Unicast RPF helps determine the source of attacks and rejects packets from unexpected source addresses on interfaces where unicast RPF is enabled.
-
You can protect a network by applying unicast RPF check feature at the edge (on customer facing interfaces) of the network. In an ISP environment, this can impact the network which can impose on a scaled setup. In case if you have already protected the edge of your network, a packet with a spoofed IP source address would not even appear in a core facing interface. In this case, unicast RPF check is not necessary. Enabling unicast RPF feature can impact the control plane performance, so use it where it is required. So it is strongly recommended not to enable this feature on the network core (internal) interfaces.
Currently on PTX platforms, configuring BGP flow specification (flowspec) creates an implicit filter to set the VRF instance. On PTX platforms, the filter lookup precedes the source/destination IP lookup. Therefore, source and destination IP lookup happens within the context of the VRF instance.
Unicast RPF and Default Route
When the active route cannot be chosen from the routes in a routing table, the router chooses a default route. A default route is equivalent to an IP address of 0.0.0.0/0. If you configure a default route, and you configure unicast RPF on an interface that the default route uses, unicast RPF behaves differently than it does otherwise.
To determine whether the default route uses an interface, enter the show route command:
user@host> show route address
address is the next-hop address of the configured default
route. The default route uses the interfaces shown in the output of the show route command.
The following sections describe how unicast RPF behaves when a default route uses an interface and when a default route does not use an interface:
- Unicast RPF Behavior with a Default Route
- Unicast RPF Behavior Without a Default Route
- Unicast RPF with Routing Asymmetry
Unicast RPF Behavior with a Default Route
On all routers except those with MPCs and the MX80 router, unicast RPF behaves as follows if you configure a default route that uses an interface configured with unicast RPF:
Loose mode—All packets are automatically accepted. For this reason, we recommend that you not configure unicast RPF loose mode on interfaces that the default route uses.
Strict mode—The packet is accepted when the source address of the packet matches any of the routes (either default or learned) that can be reachable through the interface. Note that routes can have multiple destinations associated with them; therefore, if one of the destinations matches the incoming interface of the packet, the packet is accepted.
On all routers with MPCs and the MX80 router, unicast RPF behaves as follows if you configure a default route that uses an interface configured with unicast RPF:
Loose mode—All packets except the packets whose source is learned from the default route are accepted. All packets whose source is learned from the default route are dropped at the Packet Forwarding Engine. The default route is treated as if the route does not exist.
Strict mode—The packet is accepted when the source address of the packet matches any of the routes (either default or learned) that can be reachable through the interface. Note that routes can have multiple destinations associated with them; therefore, if one of the destinations matches the incoming interface of the packet, the packet is accepted.
On all routers, the packet is not accepted when either of the following is true:
The source address of the packet does not match a prefix in the routing table.
The interface does not expect to receive a packet with this source address prefix.
Unicast RPF Behavior Without a Default Route
If you do not configure a default route, or if the default route does not use an interface configured with unicast RPF, unicast RPF behaves as described in Configuring Unicast RPF Strict Mode and Configuring Unicast RPF Loose Mode. To summarize, unicast RPF without a default route behaves as follows:
Strict mode—The packet is not accepted when either of the following is true:
The packet has a source address that does not match a prefix in the routing table.
The interface does not expect to receive a packet with this source address prefix.
Loose mode—The packet is not accepted when the packet has a source address that does not match a prefix in the routing table.
Unicast RPF with Routing Asymmetry
In general, we recommend that you not enable unicast RPF on interfaces that are internal to the network because internal interfaces are likely to have routing asymmetry. Routing asymmetry means that a packet’s outgoing and return paths are different. Routers in the core of the network are more likely to have asymmetric reverse paths than routers at the customer or provider edge. Figure 1 shows unicast RPF in an environment with routing asymmetry.
In Figure 1, if you enable unicast RPF on interface so-0/0/0, traffic destined for Router A is not rejected. If you enable unicast RPF on interface so-1/0/1, traffic from Router A is rejected.
If you need to enable unicast RPF in an asymmetric routing environment, you can use fail filters to allow the router to accept incoming packets that are known to be arriving by specific paths. For an example of a fail filter that accepts packets with a specific source and destination address, see Configuring Unicast RPF.
Configuring Unicast RPF Strict Mode
In strict mode, unicast RPF checks whether the incoming packet has a source address that matches a prefix in the routing table, and whether the interface expects to receive a packet with this source address prefix.
If the incoming packet fails the unicast RPF check, the packet is not accepted on the interface. When a packet is not accepted on an interface, unicast RPF counts the packet and sends it to an optional fail filter. If the fail filter is not configured, the default action is to silently discard the packet.
The optional fail filter allows you to apply a filter to packets that fail the unicast RPF check. You can define the fail filter to perform any filter operation, including accepting, rejecting, logging, sampling, or policing.
When unicast RPF is enabled on an interface, Bootstrap Protocol (BOOTP) packets
and Dynamic Host Configuration Protocol (DHCP) packets are not accepted on the
interface. To allow the interface to accept BOOTP packets and DHCP packets, you
must apply a fail filter that accepts all packets with a source address of
0.0.0.0 and a destination address of
255.255.255.255. For a configuration example, see Configuring Unicast RPF.
For more information about defining fail filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.
To configure unicast RPF, include the rpf-check statement:
rpf-check <fail-filter filter-name>;
You can include this statement at the following hierarchy levels:
-
[edit interfaces interface-name unit logical-unit-number family (inet | inet6)] -
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6)]
Using unicast RPF can have several consequences when implemented with traffic filters:
-
RPF fail filters are evaluated after input filters and before output filters.
-
If you configure a filter counter for packets dropped by an input filter, and you want to know the total number of packets dropped, you must also configure a filter counter for packets dropped by the RPF check.
-
To count packets that fail the RPF check and are accepted by the RPF fail filter, you must configure a filter counter.
-
If an input filter forwards packets anywhere other than the inet.0 or inet6.0 routing tables, the unicast RPF check is not performed.
-
If an input filter forwards packets anywhere other than the routing instance the input interface is configured for, the unicast RPF check is not performed.
In the aforementioned bulleted list, the first, second-last, and last points are not applicable for MX platforms because on MX platforms uRPF is processed prior to the execution of firewall filters. uRPF check is processed for source address checking before any FBF (filter-based forwarding) actions are enabled for static and dynamic interfaces. This applies to both IPv4 and IPv6 families.
On ACX and MX Series routers:
-
The uRPF fail filter is supported on ACX1000, ACX2000, ACX4000, and ACX500, ACX5048, and ACX5096. The filter is not supported on ACX5448, ACX710, ACX7100-32C, ACX7100-48, ACX7509, and all routers of ACX7000 series.
- The uRPF fail filter cannot match packets failed at ingress port check (strict mode).
- The uRPF fail filter can match packets failing source IP lookup but cannot match packets failing the input interface check (strict mode).
- The uRPF fail filter applies only to interface-specific instances of the firewall filter.
- The uRPF fail filters do not support reject and routing-instance actions.
Configure unicast RPF strict mode, and apply a fail filter that allows the
interface to accept BOOTP packets and 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.
To configure unicast RPF in strict mode:
Configuring Unicast RPF Loose Mode
By default, unicast RPF uses strict mode. Unicast RPF loose mode is similar to unicast RPF strict mode and has the same configuration restrictions. The only check in loose mode is whether the packet has a source address with a corresponding prefix in the routing table; loose mode does not check whether the interface expects to receive a packet with a specific source address prefix. If a corresponding prefix is not found, unicast RPF loose mode does not accept the packet. As in strict mode, loose mode counts the failed packet and optionally forwards it to a fail filter, which either accepts, rejects, logs, samples, or polices the packet.
To configure unicast RPF loose mode, include the mode:
Configuring Unicast RPF Loose Mode with Ability to Discard Packets
Unicast RPF loose mode has the ability to discard packets with the source address pointing to the discard interface. Using unicast RPF loose mode, along with Remote Triggered Null Route filtering, provides an efficient way to discard packets coming from known attack sources. BGP policies in edge routers ensure that packets with untrusted source addresses have their next hop set to a discard route. When a packet arrives at the router with an untrusted source address, unicast RPF performs a route lookup of the source address. Because the source address route points to a discard next hop, the packet is dropped and a counter is incremented. This feature is supported on both IPv4 (inet) and IPv6 (inet6) address families.
To configure unicast RPF loose mode with the ability to discard packets, include the
rpf-loose-mode-discard family (inet | inet6) statement at
the [edit forwarding-options] hierarchy level:
rpf-loose-mode-discard {
family {
inet;
}
}
In this example, no special configuration beyond device initialization is required.
Configure unicast RPF loose mode, and apply a fail filter that allows the interface
to accept BOOTP packets and 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.
To configure unicast RPF loose mode with the ability to discard packets:
Configuring Unicast RPF on a VPN
You can configure unicast RPF on a VPN interface by enabling unicast RPF on the
interface and including the interface statement at the
[edit routing-instances
routing-instance-name] hierarchy level.
You can configure unicast RPF only on the interfaces you specify in the routing instance. This means the following:
-
For Layer 3 VPNs, unicast RPF is supported on the CE router interface.
-
Unicast RPF is not supported on core-facing interfaces.
-
For virtual-router routing instances, unicast RPF is supported on all interfaces you specify in the routing instance.
-
If an input filter forwards packets anywhere other than the routing instance the input interface is configured for, the unicast RPF check is not performed.
Configure unicast RPF on a Layer 3 VPN interface:
[edit interfaces]
so-0/0/0 {
unit 0 {
family inet {
rpf-check;
}
}
}
[edit routing-instance]
VPN-A {
interface so-0/0/0.0;
}
Configuring Unicast RPF
Configure unicast RPF strict mode, and apply a fail filter that allows the interface
to accept BOOTP packets and 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.
[edit firewall]
filter rpf-special-case-dhcp-bootp {
term allow-dhcp-bootp {
from {
source-address {
0.0.0.0/32;
}
address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-bootp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp-bootp;
}
}
}
}