On Sun, 5 May 2002, Stephen Griffin wrote:
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.
Perhaps I'm confused (which is likely in this case) but if the traffic is being transitted by 2 or 3 as's before it gets to me through 'default' routing how am I to know it was coming?
---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.
Any access-list of any length severly impacts edge performance, if it works at all, and puts the network at risk. This is not dogma, this is proven time and again on a large operational network. They are never placed for 'permanent' reasons. It is expected that customers will properly handle their traffic... yes they don't always do it, but it is expected.
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.
Compiled access lists? Wow, you are a braver man than I. My experience with them has been 'sub optimal' to say the least. Where known traffic flows and known patterns, with reasonable route table sizes, are available compiled acls work fine. The internet is none of these :(
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.
How large is your edge? Do you have routers with +900 interfaces? Management of acls on interfaces, even if the gear were to support it, isn't feasible, nor is just dropping in an E3 card a solution, acls don't work reliably on E3 cards :( E2 cards are just as fun :( the really fun part comes with the 'limited' route table incurred with PSA acls on E2 cards! Anyway, the point here is acls on interfaces are not a solution at the backbone level. At the individual provider level its sure a nice thing, and likely it should be done, but not on the backbone. As to randomly filtering 1918 address space, at your edge that's fine, I'm not sure breaking things for those places that use 1918 internally and thus originate 'legitimate' 1918 address sources for 'error conditions' is a great plan. (please see last 16 flame-fests on martian filtering) -Chris