From owner-nanog@merit.edu Tue Oct 12 20:41:45 2004 Date: Wed, 13 Oct 2004 07:09:10 +0530 From: Suresh Ramasubramanian <suresh@outblaze.com> To: alex@yuriev.com Cc: Steven Champeon <schampeo@hesketh.com>, nanog@merit.edu Subject: Re: BCP38 making it work, solving problems
alex@yuriev.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 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