First, one must ask why a site multihomes; for example, the edge
network might:
o use two ISPs for backing up the Internet connectivity to ensure
robustness,
o use whichever ISP is offering the fastest TCP service at the
moment,
o need several points of access to the Internet in places where no
one ISP offers service, or
o be changing ISPs (and therefore multihoming only temporarily).
One can imagine a number of approaches to working around the
limitations of ingress filters for multihomed networks. Options
include:
1. Do not multihome.
2. Do not use ingress filters.
3. Accept that service will be incomplete.
4. On some interfaces, weaken ingress filtering by using an
appropriate form of loose RPF check, as described in Section 4.1.
5. Ensure, by BGP or by contract, that each ISP's ingress filter is
complete, as described in Section 4.2.
6. Ensure that edge networks only deliver traffic to their ISPs that
will in fact pass the ingress filter, as described in Section
4.3.
The first three of these are obviously mentioned for completeness;
they are not and cannot be viable positions; the final three are
considered below.
The fourth and the fifth must be ensured in the upstream ISPs as
well, as described in Section 3.1.
Next, we now look at the viable ways for dealing with the side-
effects of ingress filters.
4.1. Use Loose RPF When Appropriate
Where asymmetric routing is preferred or is unavoidable, ingress
filtering may be difficult to deploy using a mechanism such as strict
RPF which requires the paths to be symmetrical. In many cases, using
operational methods or feasible RPF may ensure the ingress filter is
complete, like described below. Failing that, the only real options
are to not perform ingress filtering, use a manual access-list
(possibly in addition to some other mechanisms), or to using some
form of Loose RPF check.
Failing to provide any ingress filter at all essentially trusts the
downstream network to behave itself, which is not the wisest course
of action. However, especially in the case of very large networks of
even hundreds or thousands of prefixes, maintaining manual access-
lists may be too much to ask.
The use of Loose RPF does not seem like a good choice between the
edge network and the ISP, since it loses the directionality of the
test. This argues in favor of either using a complete filter in the
upstream network or ensuring in the downstream network that packets
the upstream network will reject will never reach it.
Therefore, the use of Loose RPF cannot be recommended, except as a
way to measure whether "martian" or other unrouted addresses are
being used.
4.2. Ensure That Each ISP's Ingress Filter Is Complete
For the edge network, if multihoming is being used for robustness or
to change routing from time to time depending on measured ISP
behavior, the simplest approach will be to ensure that its ISPs in
fact carry its addresses in routing. This will often require the
edge network to use provider-independent prefixes and exchange routes
with its ISPs with BGP, to ensure that its prefix is carried upstream
to the major transit ISPs. Of necessity, this implies that the edge
network will be of a size and technical competence to qualify for a
separate address assignment and an autonomous system number from its
RIR.
There are a number of techniques which make it easier to ensure the
ISP's ingress filter is complete. Feasible RPF and Strict RPF with
operational techniques both work quite well for multihomed or
asymmetric scenarios between the ISP and an edge network.
When a routing protocol is not being used, but rather the customer
information is generated from databases such as Radius, TACACS, or
Diameter, the ingress filtering can be the most easily ensured and
kept up-to-date with Strict RPF or Ingress Access Lists generated
automatically from such databases.
For smaller edge networks that use provider-based addressing and
whose ISPs implement ingress filters (which they should do), the
third option is to route traffic being sourced from a given
provider's address space to that provider.
This is not a complicated procedure, but requires careful planning
and configuration. For robustness, the edge network may choose to
connect to each of its ISPs through two or more different Points of
Presence (POPs), so that if one POP or line experiences an outage,
another link to the same ISP can be used. Alternatively, a set of
tunnels could be configured instead of multiple connections to the
same ISP [4][5]. This way the edge routers are configured to first
inspect the source address of a packet destined to an ISP and shunt
it into the appropriate tunnel or interface toward the ISP.
If such a scenario is applied exhaustively, so that an exit router is
chosen in the edge network for every prefix the network uses, traffic
originating from any other prefix can be summarily discarded instead
of sending it to an ISP.
