3. Clarifying the Applicability of Ingress Filtering
What may not be readily apparent is that ingress filtering is not
applied only at the "last-mile" interface between the ISP and the end
user. It's perfectly fine, and recommended, to also perform ingress
filtering at the edges of ISPs where appropriate, at the routers
connecting LANs to an enterprise network, etc. -- this increases the
defense in depth.
Because of wider deployment of ingress filtering, the issue is
recursive. Ingress filtering has to work everywhere where it's used,
not just between the first two parties. That is, if a user
negotiates a special ingress filtering arrangement with his ISP, he
should also ensure (or make sure the ISP ensures) that the same
arrangements also apply to the ISP's upstream and peering links, if
ingress filtering is being used there -- or will get used, at some
point in the future; similarly with the upstream ISPs and peers.
In consequence, manual models which do not automatically propagate
the information to every party where the packets would go and where
ingress filtering might be applied have only limited generic
usefulness.
3.2. Ingress Filtering to Protect Your Own Infrastructure
Another feature stemming from wider deployment of ingress filtering
may not be readily apparent. The routers and other ISP
infrastructure are vulnerable to several kinds of attacks. The
threat is typically mitigated by restricting who can access these
systems.
However, unless ingress filtering (or at least, a limited subset of
it) has been deployed at every border (towards the customers, peers
and upstreams) -- blocking the use of your own addresses as source
addresses -- the attackers may be able to circumvent the protections
of the infrastructure gear.
Therefore, by deploying ingress filtering, one does not just help the
Internet as a whole, but protects against several classes of threats
to your own infrastructure as well.
Ingress filtering on peering links, whether by ISPs or by end-sites,
is not really that much different from the more typical "downstream"
or "upstream" ingress filtering.
However, it's important to note that with mixed upstream/downstream
and peering links, the different links may have different properties
(e.g., relating to contracts, trust, viability of the ingress
filtering mechanisms, etc.). In the most typical case, just using an
ingress filtering mechanism towards a peer (e.g., Strict RPF) works
just fine as long as the routing between the peers is kept reasonably
symmetric. It might even be considered useful to be able to filter
out source addresses coming from an upstream link which should have
come over a peering link (implying something like Strict RPF is used
towards the upstream) -- but this is a more complex topic and
considered out of scope; see Section 6.
