Re: A modest proposal

["Daniel W. McRobb" <dwm () ans net>]

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

Daniel
~~~~~~
- - - - - - - - - - - - - - - - -