Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

michael.dillon at bt.com michael.dillon at bt.com
Fri Mar 2 15:31:49 UTC 2007


>  No, the SP can't be the 'Internet  
> firewall' for customers, 

They can if the SP supplies and manages the CPE device. Nowadays, a lot
of functionality could potentially be provided in a CPE device. Hardware
cost and hardware capabilities are no longer barriers to doing this.
There is still software cost, of course, but that can get amortized over
many years and many, many subscribers.

> but protecting one's  
> customers from being spammed/packeted from purported source 
> addresses  
> which are by definition nonsensical (as well as protecting everyone  
> else's customers from same) doesn't seem much to ask.
> 
> What's needed here are better/easier/less brittle mechanisms for  
> same.  Until such time as they're invented and deployed, let's not  
> make the perfect the enemy of the merely good, yes?

Less brittle mechanisms don't need to be invented. There is nothing hard
about putting an operational process in place to manage bogon filtering.
There is also nothing hard about writing some software to update bogon
filters. People do this kind of thing every day in network operations
without much fanfare precisely because it is nothing special. It's just
good operational practice in a company that does not expect its vendors
to spoonfeed them everything.

There's kind of a disease in the telecomms business. Many years ago
someone got the idea that developing telecomms devices and systems was
one business, and operating those devices and systems was another. Over
time this crystalized into the idea that an operator bought platforms
from vendors and then operated those platforms according to the vendor's
instructions. This may be good for the capital investment industry
(banks etc.) but it fails when there is a need for creativity in the
telecomms operator. Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.

--Michael Dillon




More information about the NANOG mailing list