In the referenced message, Steven W. Raymond said:
Stephen Griffin wrote:
Tell them they will need to register their routes in the IRR, even if they don't necessarily advertise all or any of them. Build your exceptions based upon the irr, as for all bgp-speaking customers.
not route-filtering. You use the irr-data to populate the exceptions to strict-mode rpf. The irr is more of a flight-plan of possibility. If the customer registers both sets of routes, and you use that data to build the acl, then it doesn't matter what the customer announces to you. Anything which fails the actual rpf check, will then be passed through the acl to selectively override the rpf check.
What about existing customers that don't yet use the IRR? Say you filter some BGP customers' route announcements using manually-built prefix-lists. Have found that by using distribute-list in (instead of prefix-list), one can simply refer the distribute-list # in the strict uRPF configuration and accomplish both functions (route filtering + uRPF) easily with one ACL.
the IRR is merely an input vector. an alternate input vector is manual entry. the output would be an acl or prefix-list. I don't believe the format of a routing-use acl and an RPF-use acl is the same. My recollection is that when used for route filtering you have: access-list foo {permit|deny} ip network wildbits netmask wildbits where for RPF, or traditional traffic filter is access-list foo {permit|deny} ip source wildbits dest wildbits 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.
e.g.: ip verify unicast source reachable-via rx 49 access-list 49 permit x.x.x.x 0.0.0.255 access-list 49 permit y.y.y.y 0.0.0.252 access-list 49 deny any log
Prefix-lists are preferable over ACL-based distribute-lists. Hey Cisco, please make uRPF configuration accept either distribute-lists or prefix-lists for the exception branching. I realize that to IOS ACLs and prefix-lists are not the same, but the benefits of prefix-lists vs. distribute-lists are many.
How would uRPF respond to the following prefix-list? ip prefix-list foo deny 0.0.0.0/0 ge 25 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.
It sounds that a lot of networks rely on IRRs for building BGP customer route filters. What method then is used for the cases where a customer is not already using the IRR? Forced IRR registration before BGP turnup? Or do you fallback on filtering by using prefix- or distribute-lists?
In my experience, providers that require IRR registration often allow the customer to register their own objects, or offer to proxy-register their customers objects. The preference generally being on the customer registering their own objects, since it gives the customer the greatest degree of control (especially should they change providers.)
What's NANOG's opinion: assuming that uRPF is implemented on all customer interfaces, are there any legitimate purposes for a customer to forward packets with source IP addresses not currently routed by the transit provider towards the customer (either static or BGP)?
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. If the customer exhibits sufficient clue, and demonstrates that they are doing RPF checks, I could definitely see relaxing restrictions against them. If they are providing transit to other BGP-speakers, this is probably the case. As in all things, you know your customer best, so you know how loose you are willing to make things, with the potential that it may make you look bad.