[33711] in North American Network Operators' Group
Re: Inter-provider communications (Re: nobody @home)
daemon@ATHENA.MIT.EDU (Roland Dobbins)
Sun Jan 21 18:50:30 2001
Message-ID: <3A6B753B.779F3D62@netmore.net>
Date: Sun, 21 Jan 2001 15:48:11 -0800
From: Roland Dobbins <rdobbins@netmore.net>
Reply-To: rdobbins@netmore.net
MIME-Version: 1.0
To: nanog@merit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
Depending upon where you want to do your filtering, you can manage
pretty well with
a Catalyst 5500 + MLS-RP or a 6500 in the same configuration.
Basil Kruglov wrote:
>
> 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
--
------------------------------------------------------------
Roland Dobbins <rdobbins@netmore.net> // 408.730.2158 voice
