[24664] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: SYN spoofing

daemon@ATHENA.MIT.EDU (Jeremy Porter)
Wed Jul 28 17:57:08 1999

To: Dan Hollis <goemon@sasami.anime.net>
Cc: John Fraizer <John.Fraizer@EnterZone.Net>, bandregg@redhat.com,
	nanog@merit.edu
In-reply-to: Your message of "Wed, 28 Jul 1999 14:19:01 PDT."
             <Pine.LNX.4.10.9907281413230.19707-100000@anime.net> 
Date: Wed, 28 Jul 1999 16:27:08 -0500
From: Jeremy Porter <jerry@fc.net>
Errors-To: owner-nanog-outgoing@merit.edu




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>


home help back first fref pref prev next nref lref last post