In message <Pine.LNX.4.10.9907281413230.19707-100000@anime.net>, Dan Hollis wr ites:
On Wed, 28 Jul 1999, Jeremy Porter wrote:
In message <Pine.LNX.4.10.9907281242140.18497-100000@anime.net>, Dan Hollis wr ites:
Anyone for a weekly 'bogons transit list'? The problem being, that you would need to know where these packets originated, and if you knew that, you could probably get the problem fixed in the first place.
You really think so? Some of us have tried to persuade the 'big names' to filter completely bogus source addresses, and were blown off.
I was talking about the source of the problem. The upstream transit providers that "blew you off" were not the source of the problem. They only contributed to it.
Lack of a soci-technological solution for interprovider backtracing limits the utility of this, and since you can't really pin point the 10 ten bogon transit providers you don't have much ability to shame people into fixing their stuff.
You can at least conclusively show who is transporting the invalid-source-address-packets to the endpoint. That is, conclusively show that the next-to-last-hop isnt properly filtering.
But that doesn't really do any good. They have valid reasons for not running IP verify unicast reverse path on their backbone routers due to asymetric routing. Maybe we should ask Cisco for a "no ip bogons" command. If we start now it might be ready for release 13.0 of IOS. Its doesn't scale for transit providers to filter, the only solution is to filter at the source, which is not feasable with your suggestions, as the source has not been identified. Yes it would be good to filter. Maybe it should even be a BCP. Maybe the next router requirements should require routers to filter bogons at wire rate. Interprovider cooperation to track and filter the packets is the correct solution, however difficult it might be.
-Dan
--- jerry@fc.net Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net #include <sys/machine/wit/fortune.h>