A modest proposal

Currently, anyone can program their computer to repeatedly dial a
given business phone line and fill up a company's inbound phone lines,
making a denial of service attack. Why isn't the phone system about
to die because of it?

The phone company keeps a record of every incoming and outgoing call
on every line, and performs all sorts of analysis on time of day and
carrier, and who gets paid for it. I think that 50% of the cost of
providing phone service is the accounting and billing. However, anytime
one has a problem with obscene callers, war dialers, etc, you call
the police and bingo, the men in blue are knocking on the door of the
perpetrator. The caller could dial from a payphone, etc, but what
you've essentially done is make it more dangerous/expensive to conduct
this activity than what it is worth. People that do this sort of
activity are usually cowards, because they're not bold enough to
park a truck bomb outside the object of their hatred. Up the ante,
and they're out of the game.

I've been following some of the activity on various IP accounting
schemes and the size of those nifty matrices, but frankly, ISPs need
to spend the money to make this a reality and keep accounting data
for at least several days or a week.

Now I'm a systems guy rather than a router guy,
so I'm not going to even propose that this take place in the router
or somebody will be lecturing me about silicon switched route
processors or something similar. I used to do it with ip accounting
on a cisco and perl scripts to yank the information off. This is
still a reasonable approach for small sites. It seems to me that a
good workstation setup for accounting on the segments attached to the
interexchange points could do all of this adequately. You'd need a
good freeware software package and preferably a web interface that
could be accessed by the right people at the right time. The web
interface would take 10 times as long to write as the collection
software. Once a few of the large carriers make this a prequisite for
peering, it would be widespread.

Unfortunately, it's currently harder to do this from a workstation (at
least all that I've seen) than it is from a router. I've yet to see a
w/s that'll sniff at better than 4-5K pps sustained, and that's not even
accounting for disk I/O and other issues. If someone knows of a w/s
that can do this at pps rates in excess of 40,000 pps (even better,
100,000 pps so I don't have to search yet again next year), that won't
cost me 4 mortgages, I'd love to hear about it. The only thing I've
seen that'll do this to date is the oc3mon stuff, and that currently
only works for OC-3 fiber. I'm not so much interested in actually
deploying such boxes all over the network, but they sure would be nice
to have at hand.

I hate to say it (particularly since it's been said over and over,
recently by Curtis), but I think the best bet for doing this is a hook
in the forwarding code on the routers to capture X bytes of 1:N packets,
aggregate a handful of them in memory, then shove them out a private
interface. N of 1 would be nice, as would X of a large enough value to
hold IP and TCP headers, IP options, and the link encapsulation (128
makes a nice word-boundary value and is what we used on the NSFNET) but
I could probably live with N of 50 (again what we used in the NSFNET
days, and I traced two SYN floods a few months ago w/ only 1:50 sampling
even though very few packets were sent according to the site; they were
running tcpdump... unfortunately, the folks owning the peer at the
border I tracked it to were unable to help me track it further since
they didn't have access to this kind of data).