Editorial:

>    There are at least five ways one can implement RFC 2827, with varying
>    impacts. These include:
> 
>    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

Are these names in common usage, or are they defined by this document?
I ask because some of them don't make intuitive sense to me and better
names might be appropriate. More later...

>    An Ingress Access List is a filter that checks the source address of
>    every message received from a network against a list of acceptable
>    prefixes, dropping any packet that does not match the filter. While

s/from a network/ received on a network interface/? This check is per
interface, in essence, since a key part of the check is knowing what
interface the packet arrived on.

>    However, Ingress Access Lists must be kept up-to-date manually; for

"must be"? I can believe this is the case in practice, but this does
not seem an inherent requirement. later, the document talks about
tying this list into routing protocols.

Suggest:

s/must be .. manually/are typically maintained manually/

>    However, Ingress Access Lists must be kept up-to-date manually; for
>    example, forgetting to have the list updated at the ISPs when
>    starting to multihome might lead to discarding the packets if they do
>    not pass the ingress filter.

Also, I don't think its correct to assume that multihoming breaks
ingress filtering. What breaks it is a change in the list of legit
prefixes. That can happen not just because of multihoming. And
multihoming doesn't automatically cause this.

Better:

    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.

>    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 has come from the "expected direction", it passes the
>    check.

To be clear, is the check:

   "the packet is received on an interface
   other than the one it would send packets out on when forwarding
   traffic to the source of the packet?"

Might be good to say this.

>    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 destinations.  For example, this may not hold e.g. in the case

Is the above correct, or is it that the route must propage to all
routers doing the Feasible RPF checking? 

> 2.4 Loose Reverse Path Forwarding

>    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, not where the route points to.

It is not clear (to the reader) that default routes are included here 
as "routes". It  would be good to make the clear here. (this becomes
more clear when one gets to the next section.)
 
Also, this isn't RPF, as RPF by defn. means checking the
direction. Change term perhaps? Call it "Route Presence Check"
perhaps?

> 2.5 Loose Reverse Path Forwarding Ignoring Default Routes

Call it "Explicite Route Presence Check" (or something)?

>    The fifth implementation technique may be characterized as Loose RPF
>    ignoring default routes. 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 in addition to an extensive (or even full) list of
>    more specific routes.

Suggest replacing last sentence with something like:

    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.

>    limitations of ingress filters for multihomed networks. Options
>    include:

Might be better to number these, since you later refer to them by "the
third", etc.

>    o  Ensure that edge networks only deliver traffic to their ISPs that
>       will in fact pass the ingress filter.

A better transition to section 4.1 would help. For the above item, its
not clear to the reader that this will be discussed later in the
document (section 4.3), even though the text talks about the other
points.

>    Therefore, the use of Loose RPF cannot be recommended in this
>    scenario.

Which scenario is being referred to here? where asymetric routing is
in use? be explicit.

> 4.3 Send Traffic Using a Provider Prefix Only to That Provider

This is a funny definition of multihoming. What benefits do you
actually get from being multihomed in this scenario? Do people
actually do this? Or is a key point that the tunnel that gets created
gets routed via the other ISP, rather than internal to the site? (if
so, saying this would be good).

>    Ingress filtering is typically performed to ensure that traffic
>    arriving in one network legitimately comes from a computer in the
>    other network.

better:

   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.

Nits:

>    problems of its own when e.g. multihoming. This document describes

s/when e.g./when, e.g.,/

(occurs elsewhere too)

>    filtering, by verifying that their prefix are not used in the source
>    addresses in packets received from the Internet. In other attacks,

s/prefix/prefixes/

   best route there, the alternative pajths (if any) have been added as

spelling

>    discarding any traffic they do not have a "real" route to ,and

s/,and/, and/

>    defence in depth.

spelling