[NCLUG] Egress Filtering

mike cullerton michaelc at cullerton.com
Tue Aug 14 18:12:13 MDT 2001


on 8/14/01 3:57 PM, John L. Bass at jbass at dmsd.com wrote:

> 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'm not sure about the original assertion. what i'm suggesting is that
'everyone' filter packets leaving their network when going 'upstream'.
additionally, if you are in the business of selling internet access, you
should be filtering packets coming into your network from non-transit
'customers'.

i'm not really talking about the big boys here. they pretty much pass on any
packet they receive. that is the nature of their business. what i'm talking
about is the folks who are not 'tier 1'.

[btw, i believe my "up" stream means the same thing as john's "down" stream]

> 
> The proposal is a political one, about if ISP's should accept that mandate,
> rather than their customers. The obvious implication is that ISP's must then

i don't see it as an either or.

> accept full responsibility for all packets that exit their networks,
> independent
> of their customers responsibilities and actions.  It completely begs the
> question
> of do customers have the same obligation, and should customers be also
> required
> to filter at their firewall/router to the ISP? After all, in the internet food

in the perfect world, everyone would filter. however, if you are in the
business of selling network connectivity, my feeling is you have a
professional responsibility to the community to filter 'bad' packets.

> chain, even regional ISP's are customers of a down stream provider. Does this
> mandate extend to the large "ISP's" like MCI, Sprint, Level3, Alternet which
> form the backbone, and where it's nearly impossible to manage huge long filter
> lists at every gateway router?

as i said above, this doesn't make sense for them (even if they had the
processing power) it is their business to pass packets basically for
everyone.

> 
> There are technical merits on both sides of the fence, the strongest being
> that
> in ATM and BGP networks the router/switch at the egress may not examine IP
> headers,
> but rather exclusively use the ATM port id, ASN, or other destination ID from
> a
> frame header which encapsulates/aggregates the ip packet(s) in transport to
> select
> the out bound port for a packet. Such devices are typically running in switch
> mode,
> where the destination ID can be handled at wire speed without processor/router
> intervention.
> 
> At speeds above 100mbps, which include ATM and other transport protocols which
> use
> OC-3 and OC-12 fibre connections, there does not exist a processor/memory
> technology

i'm talking about the network layer. at the network layer, you decide where
to go based on ip address. if a datagram reaches at ATM port (or like
device) the routing decision has already been made somewhere.

also, what percentage of networks in the global routing tables originate in
networks described here? 1%? 5%? what i'm all talking about is catching them
before they get to networks like this.

> capable of doing IP header routing at wire speed. Many existing routers have a
> difficult time somewhere between 1mbps and 100mbps, depending on the number of

i've not seen this. ymmv.

> subnets in use on it's ports. Corporate customers with such highspeed links
> are very likely to also incurr a difficultly implementing this egress
> filtering
> mandate.

unlikely in my experience. corporate customers are more likely to have fewer
networks to announce and can often aggregate.

> 
> 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.

most dsl/cable customers i know do _not_ have a box sophisticated enough to
perform the tasks we've all suggested. also, the lack of expertise cited
here suggests the solution may not lie with the end customer.

more importantly, if you are a customer of an isp, the isp should have
filters in place to keep traffic from you limited to the ip addresses
assigned to you. most of the equipment i've seen for these kinds of
connections already have this capability built in as part of the customer
config. this is not a big deal.

> 
> I believe that everyone is responsible for the devices they directly
> manage/own,

i agree, wholeheartedly.

> and no one else. 

i disagree. i believe an isp is responsible for the ip space originating
within it.

> 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.
> 
> 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,

then filter the packets when they come into the network at the remote-access
edge type box, not the brand new upstream whoopdeedoo box.

btw, it's my feeling that isp's should want to do this. it is in the best
interest of the community and that is good for business. i don't think any
of this stuff should be legislated or anything. an isp could very well
require it of a customer though.

> 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.

i assert that for the vast majority of networks, it is entirely feasible to
limit the traffic leaving a network to addresses (really) originating within
that network.

> 
> There will always be a class of evil packets for which it is impractical to
> filter
> down streams, out bound Code Red attacks for example. The router would not
> only
> have to examine the IP headers, but scan packet content for a particular
> signature.
> 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
> stop?

whoa! that's a whole new can of worms :)

if this is the stuff you've been thinking about when saying the technology
isn't there at wire speed yet, i totally agree.

> 
> 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.

true. from what i've seen though, this isn't the reason the filtering isn't
being done. lack of knowledge and laziness seem to top the list.

> 
> We can certainly agree to disagree in the end, as each of us has differing
> experiences,
> needs and objectives. There is certainly no need to twist any element of this
> discussion into directed personal attacks, or attempt to force any participant
> to defend an artifically constructed unpopular position.

i haven't noticed any personal attacks. sorry if you took anything i wrote
that way. it surely wasn't intended in that manner.

i don't think we differ much on this issue.

> 
> John
> 
> 
> 
> on 8/14/01 11:26 AM, Quent at quent at pobox.com wrote:
> 
>> Of course there's no answer to this; it depends on the situation.  Where I
>> work we have some pretty huge pipes where filtering just isn't too practical.
>> It's like hooking a garden hose to a water main :-)
> 
> hmmm... to me, it's more like running the water through a screen.
> 
> if you already have some filtering in place, adding
> 
> filter 10.0.0.0/8
> filter 172.16.0.0/12
> filter 192.168.0.9/16
> 
> to the beginning of your filter won't add a discernable (sp?) load.
> 
> also, depending on the networks you have and your ability to aggregate them,
> adding 
> 
> filter <!my ip block>
> 
> shouldn't add much of a load either.
> 
> really large networks with lots of ip space should have staff in place to
> manage the network, including a way to manage the list of allowed network
> addresses. (not to mention a router that can handle the load)
> 
> my $.02
> mike
> 
> btw, frii filtered when i worked there.
> 
> -- mike cullerton   michaelc at cullerton.com
> _______________________________________________
> NCLUG mailing list
> NCLUG at nclug.org
> http://www.nclug.org/mailman/listinfo/nclug
> 


 -- mike cullerton





More information about the NCLUG mailing list