RPF
Click on the red underlined text to get to the source
...
Strict Reverse Path Forwarding (Strict RPF) is a simple way to
implement an ingress filter. It is conceptually identical to using
...
... 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 ...
... interface. This method assumes that there is no strict
RPF filtering between the primary and secondary edge routers; in
...
...
Feasible Path Reverse Path Forwarding (Feasible RPF) is an extension
of Strict RPF. The source address ...
... Reverse Path Forwarding (Feasible RPF) is an extension
of Strict RPF. The source address is still looked up in the FIB (or
...
... 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
...
... RIB). Sometimes this method has been implemented
as part of a Strict RPF implementation.
In the case of asymmetric routing ...
... network, this approach provides a way to relatively easily
address the biggest problems of Strict RPF.
It is critical ...
... It is critical to understand the context in which Feasible RPF
operates. The mechanism relies on consistent route advertisements
...
... 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
...
... other routing policies not being up-to-date. The failure modes are
typically similar to "operationally enhanced Strict RPF", as
described above.
...
... will be filtered as well.
In consequence, properly defined, Feasible RPF is a very powerful
tool in certain kinds of asymmetric routing ...
...
Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar
to strict RPF, but differs in that it checks only for the existence
...
... 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 ...
... 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).
...
... 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 ...
... 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
...
... 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 ...
... 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 ...
... addresses.
If other approaches are unsuitable, loose RPF could be used as a form
of contract verification: the other network ...
...
The fifth implementation technique may be characterized as Loose RPF
ignoring default routes, i.e., an "explicit route ...
... traffic.
Like Loose RPF, this is useful in places where asymmetric routing is
found, such as on inter-ISP ...
... found, such as on inter-ISP links. However, like Loose RPF, since it
sacrifices directionality, it loses the ability to limit an edge
...
... 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
...
... 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
...
... interfaces, weaken ingress filtering by using an
appropriate form of loose RPF check, as described in Section 4.1.
5. Ensure, by BGP ...
... Use Loose RPF When Appropriate ...
... 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 ...
... 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
...
... 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 ...
... lists may be too much to ask.
The use of Loose RPF does not seem like a good choice between the
edge network ...
... 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 ...
... ISP's ingress filter is complete. Feasible RPF and Strict RPF with
operational techniques both work quite well for multihomed or
...
... 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 ...
... 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.
...
... 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 ...
... 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 ...
... network and the
ISP. In many cases, a simple strict RPF can be augmented by
operational procedures in the case of asymmetric traffic patterns,
...
... operational procedures in the case of asymmetric traffic patterns,
or the feasible RPF technique to also account for other
alternative paths.
...
... alternative paths.
o Feasible Path RPF check is an extension of Strict RPF. It is
suitable in all the scenarios where Strict RPF ...
...
o Feasible Path RPF check is an extension of Strict RPF. It is
suitable in all the scenarios where Strict RPF is, but multihomed
...
... 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 ...
... 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 ...
... passes through third parties.
o Loose RPF primarily filters out unrouted prefixes such as Martian ...
...
o Ingress filtering with Feasible RPF or similar Strict RPF
techniques could almost always be applied between the ISP ...
... o Ingress filtering with Feasible RPF or similar Strict RPF
techniques could almost always be applied between the ISP and
...
... multicast
destination addresses will always pass the Strict RPF filter or
not. By formally specifying the mechanisms the implementations
...
... o Study and specify Routing Information Base (RIB) -based RPF
mechanisms, e.g., Feasible Path RPF, in more detail. In
...
... RIB) -based RPF
mechanisms, e.g., Feasible Path RPF, in more detail. In
particular, consider under which assumptions these mechanisms work
as intended and where they don't.
...