North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 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). Daniel ~~~~~~ - - - - - - - - - - - - - - - - -
|