Bogon filtering using BGP bogon route servers
In theory this looks like a nice solution to the problem, a centralized organ making sure the lists are up-to-date and spreaded to connected participants within a minute. However I was thinking about this today and there is a tiny glitch. And that is "what about more-specifics?". The bogon route server project makes sure you don't get another route matching the exact prefix, but a more-specific route will be accepted by your bgp process and nicely inserted in your routing table. So it looks like this approach only has very very little effect.
Some people use the argument that with the route set in your routing table packets destined for these locations will be blackholed, however in the DFZ you will never have these routes for starters so they already will be blackholed. And if they do appear they'll be routed to that destination, but that will also occur if we use the cymru bogon server (but only in the situation where this means more-specific routes).
The case that a more-specific bogon is announced is more common then that an entire /8 network is announced, so I think the bogon server is absolutely no solution for this problem, unless they are going to announce it in de-aggregates of say /27 it has some effect. To explain this a little more, let's take the following example:
CYMRU = remote router, OUR = our router.
CYMRU announces 2.0.0.0/8 tagged with their bogon community 65333:888
OUR sees the community and rewrites the nexthop to our blackhole IP.
OTHER announces 2.0.1.0/24
OUR sees the route, and enters it in the routing table with OUR's nexthop.
And voila bogons are happily traveling trough the network. Unless my understanding of the route-map is not 100%, this effectively shows that the CYMRU approach has no use whatsoever and static prefix-lists are the way to go.
This Post
Calendar
Personal
Recent Comments
Archives
Counter
Stuff
Sam () (URL) - 19 December '05 - 19:18