This section serves as an introduction to different operational
techniques used to implement ingress filtering as of writing this
memo. The mechanisms are described and analyzed in general terms,
and multihoming-specific issues are described in Section 4.
There are at least five ways one can implement RFC 2827, with varying
impacts. These include (the names are in relatively common usage):
o Ingress Access Lists
o Strict Reverse Path Forwarding
o Feasible Path Reverse Path Forwarding
o Loose Reverse Path Forwarding
o Loose Reverse Path Forwarding ignoring default routes
Other mechanisms are also possible, and indeed, there are a number of
techniques that might profit from further study, specification,
implementation, and/or deployment; see Section 6. However, these are
out of scope.
2.1. Ingress Access Lists
An Ingress Access List is a filter that checks the source address of
every message received on a network interface against a list of
acceptable prefixes, dropping any packet that does not match the
filter. While this is by no means the only way to implement an
ingress filter, it is the one proposed by RFC 2827 [1], and in some
sense the most deterministic one.
However, Ingress Access Lists are typically maintained manually; for
example, forgetting to have the list updated at the ISPs if the set
of prefixes changes (e.g., as a result of multihoming) might lead to
discarding the packets if they do not pass the ingress filter.
Naturally, this problem is not limited to Ingress Access Lists -- it
is inherent to Ingress Filtering when the ingress filter is not
complete. However, usually Ingress Access Lists are more difficult
to maintain than the other mechanisms, and having an outdated list
can prevent legitimate access.
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
through the interface. This method assumes that there is no strict
RPF filtering between the primary and secondary edge routers; in
particular, when applied to multihoming to different ISPs, this
assumption may fail.
Feasible Path Reverse Path Forwarding (Feasible RPF) is an extension
of Strict RPF. The source address is still looked up in the FIB (or
an equivalent, RPF-specific table) but instead of just inserting one
best route there, the alternative paths (if any) have been added as
well, and are valid for consideration. The list is populated using
routing-protocol specific methods, for example by including all or N
(where N is less than all) feasible BGP paths in the Routing
Information Base (RIB). Sometimes this method has been implemented
as part of a Strict RPF implementation.
In the case of asymmetric routing and/or multihoming at the edge of
the network, this approach provides a way to relatively easily
address the biggest problems of Strict RPF.
It is critical to understand the context in which Feasible RPF
operates. The mechanism relies on consistent route advertisements
(i.e., the same prefix(es), through all the paths) propagating to all
the routers performing Feasible RPF checking. For example, this may
not hold e.g., in the case where a secondary ISP does not propagate
the BGP advertisement to the primary ISP e.g., due to route-maps or
other routing policies not being up-to-date. The failure modes are
typically similar to "operationally enhanced Strict RPF", as
described above.
As a general guideline, if an advertisement is filtered, the packets
will be filtered as well.
In consequence, properly defined, Feasible RPF is a very powerful
tool in certain kinds of asymmetric routing scenarios, but it is
important to understand its operational role and applicability
better.
Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar
to strict RPF, but differs in that it checks only for the existence
of a route (even a default route, if applicable), not where the route
points to. Practically, this could be considered as a "route
presence check" ("loose RPF is a misnomer in a sense because there is
no "reverse path" check in the first place).
The questionable benefit of Loose RPF is found in asymmetric routing
situations: a packet is dropped if there is no route at all, such as
to "Martian addresses" or addresses that are not currently routed,
but is not dropped if a route exists.
Loose Reverse Path Forwarding has problems, however. Since it
sacrifices directionality, it loses the ability to limit an edge
network's traffic to traffic legitimately sourced from that network,
in most cases, rendering the mechanism useless as an ingress
filtering mechanism.
Also, many ISPs use default routes for various purposes such as
collecting illegitimate traffic at so-called "Honey Pot" systems or
discarding any traffic they do not have a "real" route to, and
smaller ISPs may well purchase transit capabilities and use a default
route from a larger provider. At least some implementations of Loose
RPF check where the default route points to. If the route points to
the interface where Loose RPF is enabled, any packet is allowed from
that interface; if it points nowhere or to some other interface, the
packets with bogus source addresses will be discarded at the Loose
RPF interface even in the presence of a default route. If such
fine-grained checking is not implemented, presence of a default route
nullifies the effect of Loose RPF completely.
One case where Loose RPF might fit well could be an ISP filtering
packets from its upstream providers, to get rid of packets with
"Martian" or other non-routed addresses.
If other approaches are unsuitable, loose RPF could be used as a form
of contract verification: the other network is presumably certifying
that it has provided appropriate ingress filtering rules, so the
network doing the filtering need only verify the fact and react if
any packets which would show a breach in the contract are detected.
Of course, this mechanism would only show if the source addresses
used are "martian" or other unrouted addresses -- not if they are
from someone else's address space.
The fifth implementation technique may be characterized as Loose RPF
ignoring default routes, i.e., an "explicit route presence check".
In this approach, the router looks up the source address in the route
table, and preserves the packet if a route is found. However, in the
lookup, default routes are excluded. Therefore, the technique is
mostly usable in scenarios where default routes are used only to
catch traffic with bogus source addresses, with an extensive (or even
full) list of explicit routes to cover legitimate traffic.
Like Loose RPF, this is useful in places where asymmetric routing is
found, such as on inter-ISP links. However, like Loose RPF, since it
sacrifices directionality, it loses the ability to limit an edge
network's traffic to traffic legitimately sourced from that network.
