[NCLUG] Egress Filtering

Michael Dwyer mdwyer at sixthdimension.com
Tue Aug 14 17:10:17 MDT 2001


From: "John L. Bass" <jbass at dmsd.com>
> The original assertion was that every ISP should have a mandate to
egress
> filter all evil packets before they exit down stream, and with one
particular
> class of evil packets as a straw man.

I don't know about that.  Maybe 'mandate' is a strong word.  After all,
this is the Internet we're talking about.  The best we can do is
suggest, through the RFC processes. -- And we already do that.  This
document is a "Best Current Practice" document describing how routers
should filter: ftp://ftp.isi.edu/in-notes/bcp/bcp38.txt

The trick is getting people who are in a reasonable position to do this
kind of filtering to actually do it.  I've been watching a lot of
discussion go by on this list, (Thanks, incidently!  Especially for the
fast-route/slow-route explanation!)

I suppose there are ways of trying to get people to follow RFCs.  Check
out this site which lists people who do not follow RFC 2142 (among
others):
http://www.rfc-ignorant.org/

> Most DSL/Cable customers already deploy a firewall/router capable of
handling
> the task at purchased connection speed. It's also this class of
customer which
> lacks the expertise to prevent the abuses of the most concern. In
fact, they
> are specifically the class of systems targeted by virus and trojan
writers.

You brought up KISS -- isn't this where KISS makes sense?  You have
thousands of irresponsible (= unaware of RFC) hosts.  You can attempt to
get each cable modem user and DSL user to correctly set up their modem.
That would be difficult. On the other hand, installing these rules in
the neighborhood headends would be a boon, and rather simple.
We can't get these people to get Code Red compliant <grin>, despite the
scary news stories on TV.  How can we get them to handle anything else?
It makes sense from another angle, too.  If you are having trouble with
an @Home address, what can you do?  There certainly isn't a whois record
for every @Home subscriber. The only thing you can do is beg a solution
of their upstream provider.  After all, they are the ones who answer
abuse@ and security@ addresses.  It is therefore in @Home's best
interest to install filtering if only to avoid the work of dealing with
their users.  (Except...[1] )

> I believe that everyone is responsible for the devices they directly
manage/own,
> and no one else. A customer might choose to outsource part or all of
that obligation
> to a contractor, which might be their ISP, for a fee or bundled into
another service.
> There are a number of ISP's which manage selected customer networks.

This is what has me torn about this.  I would normally agree with you,
simply because if I let @Home filter some traffic, what is to stop them
from, say, filtering other ports?  Say... port 80?  Uh.. bad
example...nevermind.

> My assertion in this thread has been that those customers should be
required
> to filter in their cable/dsl modem/router/firewall/NAT device rather
than
> forcing a mandate on ISP's which can not be handled with current
generation
> router devices on faster megabit plus down stream connections.
Furthermore,

@Home is already doing packet-level filtering on port 80.  Earthlink is
doing similar filtering on port 25.  I'm not even asking them to look at
the port, I'm just asking them to check an address against a couple
masks.  If they can block E-mail and web, they can certainly block
invalid packets.

Okay, how about this:  The whois contact of the smallest possible
netblock is responsible for the traffic coming from that netblock.  So
HP is responsible for everything that comes out of 15-net.  Now, I'm
sure HP subdivides that space down to individual areas, and each smaller
area has a responsible person.  My own IP space sits under the FRII
space, but I am the RP for my own netblock.  FRII should say to me, "You
are responsible for your netblock.  As part of your responsiblity, you
will do these things with your network to protect our network: ... "

> I assert that it's infeasible to hold an ISP accountable for finding a
technical
> solution for every form of evil packet stream a customers network
might be
> able to inject into the network.

It is downright rude -- especially when it actually IS feasible.  When I
see a barrage of pings hitting my broadcast address, all I can do is
write to the admin of the network being attacked.  I've written a number
of letters that look like this:

  I have been blocking attempts to use my network to flood
  yours.  My site is NOT attacking yours, however you are
  likely seeing heavy traffic from other sites.
  I just wanted to let you know what's going on...

DDoS is the perfect crime, and I can't get people to do anything about
it.  It is impractical to try to chase down spoofed packets.  It takes
the cooperation of every network admin along the chain -- and the
ability to locate and contact these admins.  [1]So the "save yourself
trouble" issue I mentioned above isn't even true!  I cannot complain to
@Home, because I can't tell it is FROM @home...

If we dry up their sources of places to spoof from, it becomes less of a
perfect crime, and easier to track.

> Or DOS attacks using packet flooding of an arbitrary type. Just where
does the
> mandate that the ISP find a techical sollution for all types of evil
packets

That's true.  I mentioned in the very first post that this did nothing
to solve the problem of DoS.  It DOES help to fix the problem of using
spoofing to create DoS problems (smurf, land, etc), and makes it easier
to catch the people when they do try to do a DoS attack.  It also makes
it possible to spot these attacks when they happen.  When my router
drops spoofed packets, it tells me -- /allowing/ me to report to the
victims what is happening to their bandwidth.  If one of *my* users
tries to spoof, I also get told by my router -- and in this case, I can
hunt them down and apply a LART to them.

> I stated that this is a slippery slope, and once you start down this
path,
> it is difficult to stop and is almost certainly going to hit solid
technical
> barriers.

Yeah... But people need to think about it, at the very least.  From the
massive volumes of traffic this thread created, it would appear that I
at least made this /list/ think about it.





More information about the NCLUG mailing list