North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: BCP38 making it work, solving problems
- From: Robert Bonomi
- Date: Tue Oct 12 22:56:53 2004
> From firstname.lastname@example.org Tue Oct 12 20:41:45 2004
> Date: Wed, 13 Oct 2004 07:09:10 +0530
> From: Suresh Ramasubramanian <email@example.com>
> To: firstname.lastname@example.org
> Cc: Steven Champeon <email@example.com>, firstname.lastname@example.org
> Subject: Re: BCP38 making it work, solving problems
> email@example.com [12/10/04 13:16 -0400]:
> > > If I, and my little 7-man company, can afford to have me solve the
> > > problem on our end, why the heck can't you do the same?
> > You can do it because you are a 7-man company. So can I. However, companies
> > the size of Sprint cannot do it.
> Most filtering that I've seen (email, router, whatever) that just works great
> for a 7 man company will not work when you serve several million users,
> that's a fact.
Certain _basics_ *are* applicable, regardless of scale.
e.g. perimeter filtering of inbound packets w/ RFC-1918 a _source_ address,
except for specific ICMP status/response messages.
e.g. perimeter filtering of inbound packets with a _source_ address that
is in *your* assigned address-space.
Some medium-big (and up) operators implement 'RFC-1918 source' filters on
their gateways to the 'external internet', but *not* on their customer
interfaces. Which means that one of their customers can be attacked via
such means, by *another* of their customers. And, after the fact, they
can't even tell =which= of their customers done the deed. Similarly,
one customer can 'spoof' another customer of that same provider.
> One false positive report per week from 7 users. How many per week - or per
> day - when you have 40 million users, is a question that gets answered real
> A lot of the bad filtering (or lack of filtering, for that matter) decisions
> I've seen at large network providers and ISPs is generally where they are
> also unresponsive to their users and to the internet community that reports
> stuff to them (quite a few places I could name where most role accounts seem
> to funnel straight to /dev/null)