Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

RE: dsl providers that will route /24

  • From: David Schwartz
  • Date: Tue Mar 27 18:24:30 2001

> On Tue, 27 Mar 2001, David Schwartz wrote:

> > 	I'm sure we've all heard stories of major network
> > disruptions being caused
> > by this type of filtering policy. ISP1 filters routes it hears from
> > CUSTOMER1. So the fact the CUSTOMER1's filters are broken is
> > never noticed.
> > Then one day, ISP1 accidentally breaks its filters. Boom!

> Um, look at what you wrote.  Filter breaks, Boom.

	Exactly, because the presence of the filter allowed the actual problem to
be ignored. In this case, the error isn't in applying the filter --- you
have to in this case because too much damage could be done too quickly
without it. The error was in pretending that the filter solved the problem.

> We egress filter on our customers routers and ingress filter on our
> routers.  That way, in the event of either breaking down, there is
> (hopefully) still an appropriate filter in place to prevent a Boom!

	Do you confirm that the egree filters are working? Or do you assume that
the presence of the ingress filters allows you to not worry about it?

	Filters are a necessary tool in cases where large amounts of damage can be
done in very small amounts of time. But they don't solve any actual
problems, they just minimize the damage.

> > 	Filtering should be a last resort if there is no other way
> > to accomplish
> > the desired goal or where small misconfigurations on the other
> > end have the
> > ability to cause massive damage in a very small amount of time.
> > Filtering
> > should _never_ be used to hide a real problem unless there is
> > absolutely no
> > other option. In this case, there are *many* other options.

> Forgive me if I (and the vast majority of the network ops I know) don't
> subscribe to this point of view.  Filter, Filter, Filter.  If you want to
> know about broken customer filters, filter on their ingress to your
> network with logging.

	The problem is, the filter will block legitimate traffic. IP does not
provide any sure way to tell a spoofed packet from an unspoofed packet.

	Do an informal survey. Ask network operators who ingress filter whether
they log and investigate packets that hit the filter. I will bet you that
more than 2/3 say they don't. In other words, the filter substitutes for
fixing the problem, and the problem could be as serious as a root

> Flat out not filtering just so you know when "there is a problem" is, in
> my humble opinion, irresponsible network administration.

	That's not the reason I don't filter. I don't filter because the filter
will stop legitimate traffic and isn't necessary if the network is
competently administered. So long as you can quickly resolve the problem
when there is actual abuse, the filter is not the right solution.


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.