[31471] in North American Network Operators' Group
Re: netscan.org update
daemon@ATHENA.MIT.EDU (John O Comeau)
Sun Sep 24 21:51:54 2000
Date: Sun, 24 Sep 2000 21:49:59 -0400 (EDT)
From: John O Comeau <jcomeau@world.std.com>
To: Brian Wallingford <brian@meganet.net>
Cc: nanog@merit.edu
In-Reply-To: <Pine.LNX.4.10.10009242018150.7717-100000@cerise>
Message-ID: <Pine.SGI.3.95.1000924212315.8351A-100000@world.std.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
Filtering by AS, in my admittedly limited understanding of BGP, would
prevent anyone on your network from receiving any of the advertisements
from that AS; traffic would still reach its address space if you have
default routes set up, as I'd assume most providers would. The null routes
to the /32 broadcast address would seem to me to be the least costly way
of preventing people on your network from initiating smurf attacks. Of
course, it doesn't protect you from receiving them. List #2 as proposed by
Mr. Woodcock would help, but primarily if your upstreams used it;
if it fills your inbound pipe, it's already done its damage to your whole
network. Policy-routing the traffic to null at that point is equivalent to
rearranging deck chairs on the sinking Titanic.
And since most smurfs would not try to hit someone on the same network as
the smurf initiator, simply setting up suitable access lists preventing
spoofed IPs from leaving your network would also keep your network from
being the initiator.
I'd like to see developed a way of cutting irresponsibly-operated networks
off from the rest of the world entirely, but don't have any workable ideas
on how to go about it. A "do-not-advertise-to" BGP attribute would, even
if implementable, suffer from the default-routes issue mentioned above. If
a bit-bucket ASN were set up somewhere on a major backbone, and you had a
"advertise-only-to" attribute to use, then perhaps all traffic
from an evil network could be harmlessly sunk before reaching you. But I
haven't thought that through very well either, and it's probably seriously
flawed too...
jcomeau@world.std.com aka John Otis Lene Comeau
Home page: http://world.std.com/~jcomeau/
Disclaimer: Don't risk anything of value based on free advice.
"Anybody can do the difficult stuff. Call me when it's impossible."
On Sun, 24 Sep 2000, Brian Wallingford wrote:
>
> I've only quickly skimmed the messages leading up to this, so I may be
> reiterating others' sentiments; but, I'd expect that most amplifiers are
> hosted by a relatively small number of ASNs. As such, filtering of those
> AS' may bring about a wake-up call.
>
> Considering this, filtering by prefix, while certainly effective, could
> also be very personnel/cpu intensive, especially when targeting small
> blocks.
>
> Policy-routing to null0 will impact your own border performance, which
> (even if negligible) rubs me the wrong way principle-wise.
>
> I'd lean toward AS filtering, though such would require widespread
> implementation to be effective.
>
> This is sounding an awful lot like other "social/political" Internet
> issues, isn't it? :)
>
> cheers,
> -brian
>
> On Sun, 24 Sep 2000, Bill Woodcock wrote:
>
> :
> : It's sounding like what we're working our way around to is that two
> : separate BGP feeds would be needed:
> :
> : 1) One with an announcement of all of the /32s which are broadcast
> : addresses of amplifier networks, so that operators can route traffic
> : _destined_ for those /32s to Null0.
> :
> : 2) Another with an announcement of all of the whole blocks of amplifier
> : addresses, so that operators who choose to can create policy-routes which
> : specify that traffic _originating_ from those addresses (and which are
> : _also_ ICMP echo-replies, perhaps) gets policy routed to Null0.
> :
> : I'd guess that feed #1 would be an easy sell, and that many fewer people
> : would use feed #2 as well, but both seem like good ideas.
>
>
