rp_filter详细介绍

内核文档：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt 搜其关键字，可见rp_filter定义如下：

rp_filter - INTEGER

0 - No source validation.

1 - Strict mode as defined in RFC3704 Strict Reverse Path

Each incoming packet is tested against the FIB and if the interface

is not the best reverse path the packet check will fail.

By default failed packets are discarded.

2 - Loose mode as defined in RFC3704 Loose Reverse Path

Each incoming packet's source address is also tested against the FIB

and if the source address is not reachable via any interface

the packet check will fail.

Current recommended practice in RFC3704 is to enable strict mode

to prevent IP spoofing from DDos attacks. If using asymmetric routing

or other complicated routing, then loose mode is recommended.

The max value from conf/{all,interface}/rp_filter is used

when doing source validation on the {interface}.

Default value is 0. Note that some distributions enable it

in startup scripts.

在RFC3704文档https://tools.ietf.org/html/rfc3704#page-5 中可见Strict Reverse Path Forwarding定义如下：

Strict Reverse Path Forwarding (Strict RPF) is a simple way to

implement an ingress filter. It is conceptually identical to using

access lists for ingress filtering, with the exception that the

access list is dynamic. This may also be used to avoid duplicate

configuration (e.g., maintaining both static routes or BGP prefix-

list filters and interface access-lists). The procedure is that the

source address is looked up in the Forwarding Information Base (FIB)

• and if the packet is received on the interface which would be used to forward the traffic to the source of the packet, it passes the check.

Strict Reverse Path Forwarding is a very reasonable approach in front

of any kind of edge network; in particular, it is far superior to

Ingress Access Lists when the network edge is advertising multiple

prefixes using BGP. It makes for a simple, cheap, fast, and dynamic

filter.

But Strict Reverse Path Forwarding has some problems of its own.

First, the test is only applicable in places where routing is

symmetrical - where IP datagrams in one direction and responses from

the other deterministically follow the same path. While this is

common at edge network interfaces to their ISP, it is in no sense

common between ISPs, which normally use asymmetrical "hot potato"

routing. Also, if BGP is carrying prefixes and some legitimate

prefixes are not being advertised or not being accepted by the ISP

under its policy, the effect is the same as ingress filtering using

an incomplete access list: some legitimate traffic is filtered for

lack of a route in the filtering router's Forwarding Information

Base.

There are operational techniques, especially with BGP but somewhat

applicable to other routing protocols as well, to make strict RPF

work better in the case of asymmetric or multihomed traffic. The ISP

assigns a better metric which is not propagated outside of the

router, either a vendor-specific "weight" or a protocol distance to

prefer the directly received routes. With BGP and sufficient

machinery in place, setting the preferences could even be automated,

using BGP Communities 2. That way, the route will always be the

best one in the FIB, even in the scenarios where only the primary

connectivity would be used and typically no packets would pass

更多具体rp_filter细节可以查阅这个帖子。