On Sun, 5 May 2002, Stephen Griffin wrote:
In the referenced message, Christopher L. Morrow said:
On Sat, 4 May 2002, Stephen Griffin wrote:
In the referenced message, Iljitsch van Beijnum said:
On Fri, 3 May 2002, Stephen Griffin wrote: For multihomed customers, these sets of prefixes should be identical, just like with single homed customers. The only time when those sets of prefixes is NOT the same is for a backup connection. But if a connection is a pure backup for incoming traffic, it's reasonable to assume it's a pure backup for outgoing traffic as well, so as long as the backup is dormant, you don't see any traffic so no uRPF problems.
Not always the case, customer behaviour can not be accurately modeled.
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.
---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.