Stephen Griffin wrote:
where for RPF, or traditional traffic filter is access-list foo {permit|deny} ip source wildbits dest wildbits
Hrrmm, since uRPF checks only the source address, the "standard ACL" seems most appropriate to me.
I guess you could use a "standard acl" however I wouldn't recommend it for filtering routes. Even if you could use prefix-lists for uRPF, you would want to match more-specifics, whereas generally you don't want to match (unbounded) more-specifics on route filters.
RtConfig can generate either style from IRR data. It isn't too hard to generate either style from a manual list either.
It certainly wouldn't hurt to have both a prefix-list for route filtering and ACL for the uRPF exceptions. It's just that I am lazy and thought it would be "neat" for one list to fulfill both requirements, since it is essentially the same input data in two different formats.
How would uRPF respond to the following prefix-list? ip prefix-list foo deny 0.0.0.0/0 ge 25
The implicit deny @ the end of the prefix-list seems a better way to accomplish the same result as above (deny anything longer than /24). In other words, instead use a prefix-list containing an explicit list of the permitted networks, rather than pattern matching to deny what bad stuff might be announced.
ip prefix-list foo permit 1.2.3.0/24 ip prefix-list foo permit 0.0.0.0/0 le 16
Would it accept all sources within 1.2.3.0/24? What about 10.0.0.0/8? I guess it could ignore "ge" and "le". Although how it would resolve conflicts is an unknown. It might try to correspond to actual prefixes, but that seems unlikely.
To restate above, just permit explicit networks customer plans to announce & source traffic from. Don't wildcard in customer prefix-lists inbound. Every source packet address received "should" be covered by his prefix-list (even if not the FIB entry best path choice). Every other source IP address packet is dropped. In fantasy land, uRPF "could" confirm that each packet source address matches at least one of the networks in the prefix-list.
Yes, I think there are definitely legitimate reasons why a customer would source traffic from prefixes where the actively selected route does not point back at the interface. This is why acl exceptions and the loose match came to be. With customers, the acl exception is probably appropriate.
Would you agree it is indeed necessary for every BGP customer-facing interface to implement exception checking with strict uRPF? Customer-set communities can change local pref easily enough to break strict uRPF lacking exception checking. But with the ACL permitting exceptions based upon every possible network customer may be sourcing from, the entry doesn't even have to be best path in the FIB to permit the packet. Customer needed only to have gotten the ISP to include it in his prefix-list at some point.