Summary: Has a DISCUSS. Needs 8 more YES or NO OBJECTION positions to pass.
I have significant concerns about the recommendation (in §3.7) to use Algorithm A. I think that the considerations to select an Algorithm are not clear and potentially impossible to verify. Also, the selection of Algorithm A creates a vulnerability that could result in legitimate traffic dropped. §3.7 (Summary of Recommendations) says that "if the scenario does not involve complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be applied on customer interfaces." From Figure 4, how does the operator of ISP4 know that it is not in a "challenging scenario" (§3.3)? How can ISP4 tell the difference between ISP2 not propagating routes vs it not even being connected to AS1? By definition, each autonomous system can have its own set of policies, which may not be known by any of their upstreams. In short, I find the guidance provided in the document to select an algorithm not clear enough to really be actionable -- specially in a document tagged to be a BCP. Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because he/she thinks they may not be in a "challenging scenario"), then it opens the door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was flowing fine and then it stopped. I am balloting DISCUSS because the guidance provided for the selection of an Algorithm is not clear enough to be certain that the selection is the correct one; and the election of Algorithm A creates a vulnerability (as explained in the text) that is not mentioned.
(1) The implementation of the EFP-uRPF method is expected at a transit AS. However, that AS has no control over what the origin AS and others announce. I find the use of rfc2119 keywords in §3.2 inappropriate because none of the actions are under the control of the AS implementing uRPF and can't be Normatively enforced. (2) §3.5: "Prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF lists." How? Note that the Introduction already sets the stage by saying that "the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." If ROAs SHOULD be used (§3.5), why is origin validation only "possibly (in the future)" considered (§1)? Maybe a better statement would be that "routes SHOULD be validated using prefix filtering, origin validation and IRR route objects". (3) How does EFP-uRPF work when multiple border routers are present in the AS, some customer facing and some not (which I assume to be the normal case)? I'm asking because §3.1 describes the method when "prefixes with the same origin AS were received on different interfaces (at border routers)", and the example talks about the Local Adj-RIB-Ins. I think there's a missing explanation of how the routers with the customer-facing interfaces learn about *all* the received routes if the local policy might select a single BGP best route. OTOH, maybe I'm missing something. (4) The document assumes familiarity with terminology such as "customer cone" or "lateral peer", that is not explained anywhere. The average operator will most likely know what those terms mean and how they apply to their network. However, those operators are not the only people reviewing this document. A short explanation or reference would be nice. (5) Please use the rfc8174 template. (6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to be part of BCP 84, is that correct? I'm not sure how to let the RFC Editor know that is the intent, but it should be made clear somewhere.