In the referenced message, Steven W. Raymond said:
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.
true, although I'ld still use extended acl or prefix-list for route-filtering.
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.
I prefer to think of it as optimal, rather than lazy. :)
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.
I agree that explicit matches are good. My concern is when you build in safeguards for a customer-input stream (any automated system not requiring clued review).
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.
Well, I could see having a safety-net of denies at the top built-in, since you wouldn't necessarily want your customer to register things like rfc1918, your aggregates, or long prefixes. This would lead to optimzing with deny 0.0.0.0/0 ge 25 (or whatever you consider too long). I agree that it would be nice, but I don't see it happening.
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.
It may not be necessary, but it is (imho) advisable, for the reasons you mention. Other, general cases would be multi-homed static customers, where you may statically route an aggregate to all locations, and route smaller chunks to individual locations. Others would be specific cases, based upon combined customer/provider needs. If a BGP customer was providing transit to others, and actively doing RPF checks themselves (and you trust them) I could see just doing loose checks against them.