Is it time to abandon bogon prefix filters?
Nathan Ward
nanog at daork.net
Mon Aug 18 14:15:51 UTC 2008
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
More information about the NANOG
mailing list