NSPs and filters

Its not feasible to filter packets on customer gateway routers. When you
impose a packet filter on a GW router customer interface, all packets
destined to that customer have to be matched to an access-list and then
forwarded down the pipe or dropped. This increases the load on the
router CPU, because it is used to switching the packets. Now you have to
analyze each packet which takes up CPU time.

This is not a nice thing to do to a router, especially while the router is
trying to keep up with 50 other customers... And if more than 1 customer
wants this type of service, you start really feeling the load.

I'm not saying UUNet should install whatever filters I want on their
routers. I'm just saying the net would be a MUCH nicer place if NSP's all
did ingress filtering on their customer connections. If current routers
can't handle the load this would create, then NSP's need to find vendors
willing to deliver the necessary power, or they need to rethink the way
they design their networks.

I'm not saying UUNet should install whatever filters I want on their
routers. I'm just saying the net would be a MUCH nicer place if NSP's all
did ingress filtering on their customer connections. If current routers
can't handle the load this would create, then NSP's need to find vendors
willing to deliver the necessary power, or they need to rethink the way
they design their networks.

Most of my customers have customers who in turn have customers, not a few of
whom are multi-homed. Same for UUNET, ...

So, at POP X, I take in maybe 100 prefixes, with maybe 1000 at some POPs.
How do I build and maintain that filter list, and how long does it take each
packet to get through it with a router that also does real routing?

randy

I've got this big pile of money and hardware. How do I turn it into an
international internet backbone?

A certain minimal level of network security should be a part of any
responsible network. Perhaps its not practical to run with filters on
every router...especially core and big exchange routers. But you can
strongly encourage (perhaps require) that all your customers enforce sane
filters where applicable. Somewhere in the internet food chain, it is
very much practical to install filters, and someone needs to make sure
they are in place.

Given that ISP market is differentiated by the lowest common denominator at
this point, this is unlikely to happen. Customers and potential customers vote
with their money, and so far, it is very unclear whether doing the "right
things" in this regard give any network a competitive advantage. In fact, it
could be argued that this constitutes a competitive disadvantage since
engineering for filtering and other such niceties tend to drive up the cost.

I suppose that things would be different if we had an educated consumer base,
but that seems unlikely to happen any time soon.

Furthermore, for many, their connection model of customers makes it
impractical for them to filter.

The best we can do is for each individual sites/networks to do what they can.
Given the current enviroment, something like universal ingress/egress
filter deployment is an impossible task.

However, I'm not saying that since things are impossible, don't bother
doing anything. For those of us who have the customer connection model to
support ingress/egress filtering, this should be done at the edges.

Also, once we are able to buy real routers that can perform these tasks as
part of their aggregation functionality, I'd argue that ingress/egress
filtering _should_ become the norm. (not that I'd bet on that happening)

For those who maintain a CPE, it's trivial to integrate ingress/egress
filtering to the automated process that's part of installation. This has been
done in various different places in the past, the most familiar example to me
being CICNet.

-dorian

Jon Lewis <jlewis@inorganic5.fdt.net> writes:

A certain minimal level of network security should be a part of any
responsible network.

Out of curiosity, do you yourselves do source-based IP
filtering at all your edges? (Dialups, dedicated
customers, gateways to your own PeeCee/Workstation gear,
and so on and so forth)

I don't disagree with you: everyone *ought* to filter out
bogus source addresses, and this *ought* to happen as
close to the edge as possible, so that a reasonable "tree
of trust" would assist in tracking down where any given
source-spoofing attack could *not* be coming from.

Without this "tree of trust", the farther away you get
from the valid origin of any given prefix, the less reliable
your decision to filter or not filter a packet that claims
to be originated there will be.

This gets awkward for large providers, since they probably
don't want to cause outages to customers or customers'
customers, or customers' customers' customers...

On the other hand, in a purely PA-addressed Internet, this
is very simple, so much so that filtering could even be
done on very large amounts of traffic, even without
routers which are specifically designed with source-based
filtering in mind.

However, once again the addressing shortcomings of IPv4
(and these are duplicated in IPv6) get in the way of
building a scalable, reliable, secure Internet without
involving NAT devices.

Somewhere in the internet food chain, it is
very much practical to install filters, and someone needs to make sure
they are in place.

Yes: if from your perspective you are certain that a
particular interface should only generate source addresses
within a certain prefix, or conversely you can guarantee
that the only valid source for packets originated with
that prefix is across a particular interface or small set
of interfaces, then building safety-providing filters that
do not cause unwanted disconnectivity is easy.

The problem is in the certainty...

  Sean.