|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Is it time to abandon bogon prefix filters?
On 19/08/2008, at 2:01 AM, Sam Stickland wrote: I think you misunderstand the meaning of the "ip verify unicasr source reachable-via any" command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped. If you read his post, I think you'll find that he understands perfectly. He is talking about both packet filtering, and prefix filtering. Scenario (exactly what Pete describes, but a bit more verbose): - We have bogon filtering using the method you describe. It works great, because we don't have any routes for things that are in bogon space, so we drop those packets on the floor. - Attacker has a BGP session with a carrier that, for whatever reason, doesn't filter their customer's announcements. Attacker advertises a longer prefix in bogon space than we have null routed, and that advertisement makes it on to the the wider network. - Because we now have an advertisement, we're going to accept packets sourced from that prefix. BGP triggered bogon filtering is no longer working for us, for that particular prefix. The question is, is this scenario really that likely, and if it is, is it going to happen often enough for it to be a problem? I would say that with the decrease in attackers using false source IPv4 addresses (because they all have big bot nets with throwaway nodes, so why bother hiding where those nodes are?), then this sort of attack loses value. Then again, not everyone who does these attacks thinks them through, so who knows? It's also obviously very easy to trace the source of these announcements, however that doesn't necessarily find the guilty party, in the case of a hacked router for example. I agree that bogon filtering with a Team Cymru BGP feed is good - it will do the job most of the time. However, it cannot be considered a complete solution. -- Nathan Ward
|