Ingress filtering is typically performed to ensure that traffic
arriving on one network interface legitimately comes from a computer
residing on a network reachable through that interface.
The closer to the actual source ingress filtering is performed, the
more effective it is. One could wish that the first hop router would
ensure that traffic being sourced from its neighboring end system was
correctly addressed; a router further away can only ensure that it is
possible that there is such a system within the indicated prefix.
Therefore, ingress filtering should be done at multiple levels, with
different level of granularity.
It bears to keep in mind that while one goal of ingress filtering is
to make attacks traceable, it is impossible to know whether the
particular attacker "somewhere in the Internet" is being ingress
filtered or not. Therefore, one can only guess whether the source
addresses have been spoofed or not: in any case, getting a possible
lead -- e.g., to contact a potential source to ask whether they're
observing an attack or not -- is still valuable, and more so when the
ingress filtering gets more and more widely deployed.
In consequence, every administrative domain should try to ensure a
sufficient level of ingress filtering on its borders.
Security properties and applicability of different ingress filtering
types differ a lot.
o Ingress Access Lists require typically manual maintenance, but are
the most bulletproof when done properly; typically, ingress access
lists are best fit between the edge and the ISP when the
configuration is not too dynamic if strict RPF is not an option,
between ISPs if the number of used prefixes is low, or as an
additional layer of protection.
o Strict RPF check is a very easy and sure way to implement ingress
filtering. It is typically fit between the edge network and the
ISP. In many cases, a simple strict RPF can be augmented by
operational procedures in the case of asymmetric traffic patterns,
or the feasible RPF technique to also account for other
alternative paths.
o Feasible Path RPF check is an extension of Strict RPF. It is
suitable in all the scenarios where Strict RPF is, but multihomed
or asymmetric scenarios in particular. However, one must remember
that Feasible RPF assumes the consistent origination and
propagation of routing information to work; the implications of
this must be understood especially if a prefix advertisement
passes through third parties.
o Loose RPF primarily filters out unrouted prefixes such as Martian
addresses. It can be applied in the upstream interfaces to reduce
the size of DoS attacks with unrouted source addresses. In the
downstream interfaces it can only be used as a contract
verification, that the other network has performed at least some
ingress filtering.
When weighing the tradeoffs of different ingress filtering
mechanisms, the security properties of a more relaxed approach should
be carefully considered before applying it. Especially when applied
by an ISP towards an edge network, there don't seem to be many
reasons why a stricter form of ingress filtering would not be
appropriate.
