[NCLUG] Egress Filtering

[Michael Dwyer]

----- Original Message -----
From: "John L. Bass" <jbass at dmsd.com>
To: <nclug at nclug.org>
Sent: Tuesday, August 07, 2001 4:36 PM
Subject: Re: [NCLUG] Egress Filtering


> > > Might suggest they either filter for non-existant address blocks
on
> the
> > > network, or cut the size of the subnets.
> >
> > Good suggestion... but think of Charter this way: Qworst, only run
> entirely
> > by marketing people.
>
> Actually, it brings up a good point.  I would not like my ISP doing a
> lot of filtering, but why don't they at least do egress filtering?
>
> Actually - the suggestion is to drop on the floor inbound packets for
which
> there is no subscriber - and avoid the looming arp broadcast storm.
This is
> not subscriber filterin.

No, I'm not talking anything about /incoming/ packets.  I'm talking
about preventing your network from hosting spoofing.  It is
exceptionally difficult to prevent spoofed packets from incoming.  You
can deny source-routed packets, but for stuff like UDP and ICMP, there
isn't a lot you can do about it.

But you /can/ prevent invalid packets from leaving your network. As for
incoming stuff, the Phrack article I linked to includes notes on
prohibiting incoming packets from, for instance, 10.0.0.0/8 networks --
quick filtering on obviously invalid packets.

> Secondly, the problem of egress filtering for a large ISP is they
typically
> route many portable Class C's. Adding that CPU table lookup on routers
isn't
> cheap in terms of processor/memory bandwidth and adds to pass thru
latency.

Yeah, I had heard that before, and I understand why it wouldn't be
feasable to do this at the NAP-level.  But at a single class B or C, it
makes a bit more sense. I'd like to think that at the ISP-level, you
could do this.

Granted, my experience is with nothing larger than a Cisco 2500 on a
Class C, but I couldn't cause an appreciable delay or processor load
doing simple egres filtering.  I've never heard anything other than
anecdotal evidence of problems with reasonably short access lists.

> Okay, so all that dry stuff behind me, I guess the question is, why
> doesn't @Home do this?  Do you know Steve Gibson of the Gibson
Research
> Corporation?  He's a PR-hound if I ever saw one...  Although he has
> moments of sharpness, he mostly seems to do the Geraldo-esque
>
> Where this should be put is the cable modem and DSL boxes - not accept
packets
> outbound that do not match the subscribers subnet/IP.

Agreed!  This would prohibit spoofing from, say, viruses and trojans,
but if you intend to spoof, you could just turn off that rule.  Still,
this would be an excellent thing to have in the subscriber's router...

> It's not necessary to degrade the discussion with personal attacks.
It's way
> to easy to piss on someone else without any knowledge of the
tradeoff's and
> impacts - I suspect few could fit in the guys shoes for a month
without getting
> fired.

The only one who can fire Steve Gibson is Steve Gibson...  I do not
dispute that the man is intelligent -- it is tough to read his tale of
meeting his 13-year old hacker with an IRC client he hacked together
himself from RFC's without feeling a healthy dose of respect for the
man's skills.  But I still detest his grandstanding, and I believe that
his attack of Win XP is misguided.  It is good PR, since its all the
rage to be bashing Microsoft, but I believe that people should be
looking for a network solution to a network problem.  Need I remind you
that raw sockets have been a feature of Unix OSs for some time now?
Granted, as Steve says, there isn't the /volume/ of Unix boxes as there
may be XP boxes.  But he's not looking to solve the problem, he's just
looking to trouble Microsoft.  Microsoft isn't the cause of this
problem.  Raw sockets aren't the cause of this problem.  Routing of
spoofed packets is the problem.

As always, in my frequently un-humble opinion. :)