> From [EMAIL PROTECTED] Tue Oct 12 20:41:45 2004 > Date: Wed, 13 Oct 2004 07:09:10 +0530 > From: Suresh Ramasubramanian <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Steven Champeon <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: BCP38 making it work, solving problems > > > [EMAIL PROTECTED] [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 > fast. > > 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) > > srs >