North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BCP38 making it work, solving problems
> 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 >
|