Government scrutiny is headed our way

> For those who don't bother filtering "because it's too hard or too
> complicated", if you don't want or can't afford to put the work into tight
> ingress filtering on all interfaces, it's really easy to just say "our IP
> blocks are A, B, and C. Allow input with source addresses in A, B, or C,
> deny everything else." That will at least protect the rest of the
> internet from your lusers.

Right. That's what we do on the dial plant today, because there isn't a
syntax available on our RAS hardware which says "allow anything with this
RADIUS assigned or dynamic address block (depending on the account) and deny
everything else". So we have to relax the filters to be "allow anything from
netblocks A, B, and C, block everything else" since the syntax we really
want isn't available.

I believe RADIUS has a facility for setting ifilt and ofilt based on the
particular user based on the Framed-Filter-ID. So, for dynamic users,
you could set a filter that allows the Dynamic IP range of that NAS for
single-host users. For network users, you could either use blocks like
are listed now, or you could set up a filter per user through the choicenet
features (Livingston). At the very least, with a rational allocation
policy, it should be possible to limit the filters to some subset of
Every IP we own.

We do that for all dial and ISDN inbound connections today, and have been
for a long time.

Some people don't. That's the problem.

Still, that's good enough. You can't launch a DOS attack against ANOTHER
provider from our plant this way. We also have directed broadcasts shut
off network-wide, so attempts to bounce pingstorms off our internal plant
(even to internal targets) don't work either.

That's the 95th percentile solution, and is a hell of a lot more than most
other ISPs do. Most don't do ANY filtering of any kind. I've tested this
against accounts on other providers, and most will happily forward packets
with ANY source address from dial customers.


I understand the CPU problems filtering ingress on a DS-3 to a customer,
for example, if the box has a bunch of other interfaces. But in that case
you should insist (contractually) that the *CUSTOMER* router have the
filters on ITS interface which talks to you, and TEST it from time to time.

Actually, with Cisco's running the newer Fast Drop code, filtering on a DS-3
is not that big a deal. Especially when you consider that this can be done
with a simple access-list.