Re: BCP38 making it work, solving problems

[Robert Bonomi <bonomi () mail r-bonomi com>]

> 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