North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Inter-provider communications (Re: nobody @home)

  • From: Basil Kruglov
  • Date: Sun Jan 21 16:44:30 2001

On Sun, Jan 21, 2001 at 02:42:58PM -0500, Richard A. Steenbergen wrote:
> How would placing RFC1918 filters on that providers borders help prevent
> attacks originating from that providers network? Perhaps they should have
> been busy tracing the attacker on their network?

<not exactly related, but...>

if you do host an irc server, or shell, or anything related to
chat/irc... at some point attacks will become normal day to day events,
no known NSP (to me) will be tracking those... no resources, time,
most importantly -will- to justify it... "you're getting those daily,
even if we do track this one down for you it won't make a bit of a difference"

as for RFC1918, out-of-bgp table attacks, smurf/fraggle perhaps (?),
new "loose" unicast RPF for Cisco might help, but only if big boys start
putting this at edge (customer aggregation routers) to prevent stupid
customers from spoofing, and at borders (peering points) to deny crap
from peers...

(if I'm not mistaken Verio, one of many who's doing this at some places,
please do correct me if I'm wrong.)

> In all fairness, many large providers have a legitimate point when
> refusing to deploy just any customer-request filter. With most large
> hosting providers, what cisco markets as "core" routers are required for
> customer aggregation. ACLs can have a serious impact on performance and
> stability on these routers. And deploying filters "on their borders" is a
> time consuming, performance impacting, perl-powered mess. Why should they
> go through this for your 1Mbps of normal paid traffic just so you can get
> on irc and taunt the packet kids with your "large provider filters"?

Yes.. yes... yes... personally I'd pay for that traffic, I can even
work in 'no-filter' environment, but only if big boys work together
to track and shut down those attacks, shut down smurf amps if they happen
to be their customers/downstreams, etc.. 

"We provide transit to sh*tload of people, and we are not required to
do any tracebacks, filtering...work with your upstream, bye bye.."; 
I've been getting this quite a lot lately...

And what if my upstream is too damn tired or have no will to deal with it?
Getting transit to someone else is not an option, simply no one is going
to host or deal with you if you or your downstreams are getting 3-5, sometimes
more attacks *daily*. I only see two options  1) get rid of all DoS-getting
applications/clients, 2) peering, more peering, and even more peering never
advertising prefixes that are getting attacked to certain companies that can't
control their customers.


> I've been accused of being anti-Cisco, but the simple fact of the matter
> is that if you have a Juniper with an IP2 you will be able to filter
> things that would make a GSR puke all over itself. "Cisco powered network"
> be damned. Oh and just a quick note, just because someone has the
> technically ability or the willingness to filter packets does not mean
> they will be able to filter it well or stop the attacks.

Oh yes... crisco sucks when it comes to performance.

-Basil