In the referenced message, Christopher L. Morrow said:
On Sun, 5 May 2002, Stephen Griffin wrote:
In the referenced message, Christopher L. Morrow said:
I was hoping someone else might mention this, BUT what about the case of customers providing transit for outbound but not inbound traffic for their customers? We have many, many cases of customers that are 'default routing' for their customers that get inbound traffic down alternate customers or peers or wherever... uRPF seems like a not so good solution for these instances :( especially since some of these are our worst abusers :(
-Chris
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.
I'm not really sure how one customer IRR filtered (one example customer) is going to matter here, this is the equivalent of a customer connected via 2 t1's one to AT&T and one to UUNET, not announcing EVER his ATT routes to UU nor his UU routes to ATT. How would you know what traffic to expect from this customer at any point in time? He could just push all traffic over his ATT link outbound and only pull in UU on UU and ATT on ATT. Route filters aren't really a solution to this problem.
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.
---rant removed---
If there was some particular situation where neither IRR-based exceptions, or customer-specific exceptions just couldn't work, then do what you _can_ do. loose RPF checks based upon matching _any_ prefix, and interface filter inbound and outbound on known bogons. this, at least, constrains the area of ipv4 which can be used for spoofing, which is better than where you started.
Access-lists on interfaces?? This does not scale, puts my network at risk and will certainly break some 'legitimate' traffic. Additionally, as I've said before, spoofed attacks don't really bother me, they are more easily stopped and tracked.
The object is to keep the interface acls short, and use the rpf logic to get rid of as much as you can. Rather than using interface acls themselves to emulate a strict rpf check. If you filter only known bogons (RFC1918, as an obvious example) I don't see what will be broken, except that which was broken to begin with. Along with things like compiled access-lists, the impact can be kept quite small. You can even add in performance circuit-breakers to speed things up. For example, allowing established TCP sessions, will (without even compiling the acls) allow a first-match circuit breaker on a large percentage of traffic. While spoofed traffic may not be a concern for as701, I know I, at least, would prefer not to get spoofed traffic via that network. I'm sure other paying customers probably feel similarly. I don't see how access-lists on edge interfaces don't scale, if they are all the same short anti-bogon acl. Junipers should be able to handle this ok, Cisco Engine3 (Edge) should be able to handle fine for GSR. I thought AS701 was moving towards vendor-J on the edge, as it was, but maybe I'm misremembering. Even if it isn't possible for as701 to rpf check/filter in every possible scenario, whatever _is_ possible would be appreciated (by me at least). "Progress, not perfection" as the saying goes...