[NCLUG] Egress Filtering

[mike cullerton]

[i have snipped and added some comments -mac]

on 8/10/01 1:41 AM, Sean Reifschneider at jafo-nclug at tummy.com wrote:

>> The way to fix this is egress filtering.  The main CSU router that
>> serves 129.82.0.0 could institute one little filtering rule.  The rule
> 
> You have to be *VERY* careful with adding filtering to large routers.  It's
> easy enough to say when you're managing a router handling a single 1.5mbps
> line.  It doesn't necessarily translate to a router handling multiple
> 45+mbps connections and doing all sorts of dynamic routing, etc...
> 
> High-end routers tend to work by having less powerful CPUs, and rather
> smart interface cards.  These cards will often determine where a packet has
> to go before the entire packet is even received from the wire, and handing
> it off directly to another interface.  This is called the "fast path".
> The packet never even makes it to the main router or is handled by the CPU.
> 
> The addition of a single filter rule can be enough to move a packet from
> the fast path to the slow path (where the CPU has to look it up and compare
> it to different filters).

the addition of a _single_ filter rule will force the router to process
_all_ packets from that interface. that is, if your router has _no_ access
lists, it will fast switch all packets as sean has explained. however, if
you apply an access-list (even with a single rule in it) to an interface,
_all_ packets for that interface will have to be shipped off to the main
processor for handling. this can be a _dramatic_ increase in load for even a
moderately used router.

note that each additional rule in an access-list will have only a nominal
affect on the load. it is turning on filtering that introduces the real
increase. this means that in most cases, if you are already filtering, you
can't use load as an excuse to not filter spoofed packets leaving your
network.

> Also consider that you're often not dealing with just "your" IPs, but with
> multi-homed or otherwise diverse sets of IPs.  Even just dropping private

this can actually be a real pain in the butt for large networks. however,
this too should not be used as an excuse.

> addresses is more complex than a single rule adding "10.*", as there are a
> number of those unroutable blocks...

ok, 3 rules.
 10.0.0.0/8
 172.16.0.0/12
 192.168.0.9/16

> 
> Adding the filters to your borders with leaves can often be done -- putting
> them on terminal servers.  However, Ascend equipment has historically not
> had much in the way of capabilities for doing this, and even with Livingston
> who has had capabilities for easily managing this functionality it can get
> complex.  Instead of a single rule you can end up having to manage filter
> rules across an ever increasing number of boxes.  The leaves is really
> where it should happen though...

i couldn't have said it better myself. push the rules to the edges. let the
big routers just fast switch packets as much as possible.

> 
> I'm a fan of filtering out IPs that aren't in your block.  It's not more
> widely done, particularly on "main" routers because of performance and
> maintenance issues.

well, perhaps it's time for them to get a bigger router :)

> 
> The problem can at times be identifying what is spoofed.  If you are
> pass traffic for another AS, you may not know what IP addresses can validly
> be coming from your network.

(i should know better than to disagree with sean, but here goes :)

um, you should always know what ip's are valid for your network. anything
else is bad (tm).

taking your example, if you are passing traffic for another AS (a peer or a
downstream), you should be running bgp, you should have a list of networks
they will announce over bgp and you should be filtering those announcements.
you can then create an access-list based on those announcements and apply it
to the traffic coming in over that interface.

we aren't really discussing the case where they are an upstream.

> 
>> I cannot think of any reason not to do egress filtering.  I have heard
>> it said that access lists slow down Cisco routers too much.  This would
>> certainly be a Bad Thing, but would that one high level rule really do
>> that much?
> 
> As explained above, yes it may.  However, there aren't very many networks
> that could do it with just a single rule...  For even a fairly small ISP it
> could easily be 5 rules (again, talking about their core router, if you
> will).

as above, it is the initial rule that really determines your boxes ability
to filter. after that, a couple more rules will not matter.

if you aren't filtering, you should be. if your router can't handle it, get
a bigger router.

all this being said, a couple thoughts for the other side of the argument...

managing large networks is an amazing task. if you have many customers who
are multi-homed to you and others, and they have different route
announcements coming to you over different sessions, all this can get real
hairy real fast. managing all this can be a nightmare. sometimes, as sean
hinted at above, this makes filtering spoofed packets very difficult.

however, if everyone who isn't in this boat did filter, the world would be a
better place.

> 
>> really a reason to not do this?  Does your network prohibit spoofed
>> packets?
> 
> Mine currently?  Nope, not enough router huevos...

if you are a stub network (one way in and out) it isn't unreasonable to
expect your upstream to perform this task for you.

you shouldn't feel terrible if you are a single small network with a couple
ip addresses and you don't filter because your dsl/cable router basically
sucks in terms of advanced features and you really can't pull it off.

> I *HAVE* set up ISP
> networks in this way (again, mostly rules on the leaves of the networks
> because of CPU resource starvation on the "main" routers...

um, me too ;)

> 
> Sean


 -- mike cullerton

(although at times, it's like i've forgotten everything i knew)