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

["Richard A. Steenbergen" <ras () e-gerbil net>]

On Sun, Jan 21, 2001 at 11:11:55AM -0800, Patrick Greenwell wrote:
> One large provider of hosting services who shall remain nameless in
> the hopes they will become more helpful through private discussion
> recently told one of my clients that placing RFC-1918 filters within
> their borders(the client was being DDOS'd in part from machines within
> that providers network) was "against policy" and they wouldn't do it.
>
> I shudder to think what they tell non-customers(if they even talk to
> them at all.)

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?

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"?

Heh but that being said, some providers are worse at this then others. Two
large hosting services I know of which shall also remain nameless had an
explicit policy of "if you're being attacked, we'll null route you. If you
harm our network, you're gone" in which you were better off not reporting
attacks at all. GlobalCenter used to be very good at putting up customer
filters, but now that they're Exodus that policy will probably change.

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.

-- 
Richard A Steenbergen <ras () e-gerbil net>   http://www.e-gerbil.net/humble
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)