* Reader agrees with network security logic
A few weeks ago, we wrote a newsletter (see first link below) in which we argued that security services – especially for defenses against threats such as distributed denial-of-service attacks, could be more effectively handled within the network than on the network edge. Turns out that some of the service providers agreed with us, as evidenced by a few announcements over past few weeks (see links below for examples). And we weren’t tipped off in advance about these announcements – honest!
In response to the above-referenced discussion of network-based services, we heard from our longtime friend and associate, Bob Mercer. Even though the response below is a bit longer than a typical newsletter, we found Bob’s thoughts to be so thought provoking that we really didn’t want to try to compress them. Consequently, we’re giving you Bob’s feedback with only the most minimal edits. Bob wrote:
“Responding to your article about network-based functions, such as intrusion detection and spam filtering, I think there is good logic to what you are saying. In fact, you’d think that IF these functions were going to be network-based, you would want to execute them as close to the source as possible. That is, why allow such traffic to go any further through the network than [is] absolutely necessary? Instead, the provider, preferably in cooperation with other ISPs, should detect and choke off such traffic as early as it can be detected.
“That thought causes me to be HEAVILY struck by a sense of deja vu all over again. Looking back at least 30 years, and I assume still receiving some degree of attention today, telephone companies followed that philosophy with respect to a large volume of traffic that might be destined for a particular exchange during an unusual event.
“The classic example is a radio station that runs a promotion that triggers a large volume of calls to win prizes. The calls would all be headed for the exchange serving the station, and if allowed to flow unfettered through the network, could cause the exchange in question to malfunction due to the incoming call processing load. The situation is tsunami-like – that is, the originating exchanges all over a metro area, and even the network near those originating exchanges, might not even detect the modest increase in calls at their source, but the closer the calls get to the destination, the worse the situation gets.
“In some metro areas, NYC being one I know of, radio stations had to use special telephone numbers with a CO code not normally used – 950 or 953 was typical. That way, exchanges all over the area could filter calls based on that code, and prevent the build-up at the destination. The station had to pay a premium for the use of such a code, to compensate the company for the cost of choking the calls. They were heavily incented to do so, because there were pretty severe penalties if a radio station or other business customer did not cooperate and its incoming call volume per time unit exceeded a penalty threshold.
“It was the case then, and I suspect still the case today, that the reason stations often advertise that the nth caller (n > 1) will win a prize is to avoid traffic bursts and avoid the need to use special numbers or pay a premium for call choking. BTW, the choking is much easier to do with SS7, because SS7 includes a call gapping function that causes only a certain call rate to a particular destination, and I gather (although not sure) that the SS7 capability can be exercised on a 10-digit basis, or at least for any given terminating CO code, which ended the need to use special codes.
“One more well-known case where calls simply HAD to be choked early in the network: the President Carter call-in one Saturday afternoon (circa 1974, if I am remembering correctly).
“It was well understood that the event would generate a huge volume of calls, and that was indeed the case. It was thought to be untoward to bomb telephone service in the D.C. area out of existence by trying to deliver a zillion calls through the toll and local network near D.C. The way that was handled was to assign an 800-number exchange code that was not otherwise in use at the time (this was before the days of 10-digit 800-call routing using SS7, so the “CO code” part of the 800 number served as an “area code” for routing 800 calls). All over the country, central offices were configured with only two trunks to that exchange, ensuring that the large volume of attempts never progressed very far in the network.
“I was in the Network Performance Characterization Department at Bell Labs, and we subsequently analyzed a sample of switching records to see what customers did during the event. Some people managed to place over 300 call attempts per hour during the call-in, and from our data, we were able to infer that MILLIONS of call attempts took place! As I remember, Carter actually handled something less than 10 calls during the time he was on the air. Also, we were amused to discover people continued to call the number WELL after the event was over!
“But I digress: my point is, not only does there seem to be merit in your idea — assuming customers are willing to turn over such critical functions to their provider, which might NOT be the case (*) – but for severe attacks, the provider might want to work cooperatively with other ISPs to choke off illicit traffic as early as it can be detected, tough task though that might be if you don’t know to be watching for an attack.
“(*) My guess is that customers might often opt for a hybrid where THEY still have their own security mechanisms in place, but also utilize a service offered by their provider to avoid the messages choking their access line or ever reaching their premises.”
By the way, we totally agree with the footnote that end-users will need a hybrid solution. Some security functions need to stay at the customer premises. However, there are many networking functions that are most appropriately placed inside the network. And the really good news is that the availability of these services is rapidly increasing.
