North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BCP38 making it work, solving problems

  • From: Robert Bonomi
  • Date: Tue Oct 12 22:56:53 2004

> 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