jerry at fc.net
Wed Jul 28 21:27:08 UTC 1999
In message <Pine.LNX.4.10.9907281413230.19707-100000 at anime.net>, Dan Hollis wr
>On Wed, 28 Jul 1999, Jeremy Porter wrote:
>> In message <Pine.LNX.4.10.9907281242140.18497-100000 at anime.net>, Dan Hollis
>> >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.
--- jerry at fc.net
Freeside/ Insync Internet, Inc.| 512-458-9810 | http://www.fc.net
More information about the NANOG