At Arbor, we totally understand everyone's concern for privacy. We don't gather any kind of data that isn't already available to your network provider. In fact, our system collects data from the network in much the same fashion as a network engineer might during a DDoS outbreak. However, instead of wasting the time of a service provider's best engineer tracking attacks through the network, a provider can let our system automatically detect and trace the anomalies in real-time. Arbor networks in *no* way collects any form of personalized data. We only provide tools for network operations to detect and respond to traffic anomalies.
Unfortunately, inserting probes into the "exchange points where major networks interconnect" isn't going to accomplish much.
First of all, all of the major network do not exchange traffic directly over the exchange points, but rather through dedicated peering circuits.
Thanks for pointing this out. We need to change that sentence on the webpage.:) You're right, most of the Internet's traffic is exchanged at private peering points. The handful of public exchange points have been increasingly bypassed. That's why the Arbor DDoS solution specifically target's a provider's peering points (both private and public).
How do they differentiate a DDOS attack or a site being slashdotted ( or does that qualify as a DDOS?:P )
Arbor's technology is used to detect bandwidth anomalies. Like I said in a different post, sometimes you let them pass by (like a slashdotting), sometime you may need to take action if your customer's network can't handle the traffic. Our tools are built to let a network op/eng staff manage the flow of traffic in their network.
So all it does is spit out a sample configuration that has to be actively applied to the routers in question? Even if you place an ACL on the receiving side ( pretending that linerate OC-12 car/acl's is truly feasible ) you have done nothing to mitigate any of the affects on the peers network and the potentially full peering link between the two networks.
This assumes that the DDOS is going to be hitting the servers as well. In fact, several recent DDOS attacks have been not at servers ( since it is no longer usually a single server but many ) but at the infrastructure leading up to those servers.
The most useful place to counteract a DDoS attack is to place barriers as close to the source as possible. That's exactly why Arbor's take has been to distribute the detection and countermeasures upstream in the network. Putting an ACL on the customer's access router is only marginally better than putting a firewall between the flood and the server.
I wish Arbor well in peddling their proprietary "patent-pending" technology, but don't expect to see this running on any major networks anytime soon.
Thanks for the well wishes. You'd be surprised to know who's running with our technology.:)
I agree with you: there's no difference to Arbor between a DDoS attempt and a slashdotting. To us a large bandwidth anomaly is a large bandwidth anomaly (looks like a huge duck, it probably is a huge duck). We're providing tools for network operators to get a handle on the traffic in their networks, specifically large bandwidth anomalies -- regardless of their cause. Sometimes the duck is only slashdot and you let it waddle by. Sometimes the duck kicks your network's butt and you'd like to do something about it.
I also agree with you about the centralized company approach to DDoS. Our position is to make sure that we give network operators the tools to make sure that the perimeter of their own "island" of the Internet is secured. If they want to cooperate, we'll give them the tools to do that too.
Clearly, bandwidth-based attacks will continue to evolve (eg Zapatista protests), however, you can only slice a huge bandwidth flood so many ways. It's not a needle in a haystack.
Slashdot Mirror
At Arbor, we totally understand everyone's concern for privacy. We don't gather any kind of data that isn't already available to your network provider. In fact, our system collects data from the network in much the same fashion as a network engineer might during a DDoS outbreak. However, instead of wasting the time of a service provider's best engineer tracking attacks through the network, a provider can let our system automatically detect and trace the anomalies in real-time. Arbor networks in *no* way collects any form of personalized data. We only provide tools for network operations to detect and respond to traffic anomalies.
-Rob Malan
CTO, Arbor Networks
Unfortunately, inserting probes into the "exchange points where major networks interconnect" isn't going to accomplish much. First of all, all of the major network do not exchange traffic directly over the exchange points, but rather through dedicated peering circuits.
Thanks for pointing this out. We need to change that sentence on the webpage. :) You're right, most of the Internet's traffic is exchanged at private peering points. The handful of public exchange points have been increasingly bypassed. That's why the Arbor DDoS solution specifically target's a provider's peering points (both private and public).
How do they differentiate a DDOS attack or a site being slashdotted ( or does that qualify as a DDOS? :P )
Arbor's technology is used to detect bandwidth anomalies. Like I said in a different post, sometimes you let them pass by (like a slashdotting), sometime you may need to take action if your customer's network can't handle the traffic. Our tools are built to let a network op/eng staff manage the flow of traffic in their network.
So all it does is spit out a sample configuration that has to be actively applied to the routers in question? Even if you place an ACL on the receiving side ( pretending that linerate OC-12 car/acl's is truly feasible ) you have done nothing to mitigate any of the affects on the peers network and the potentially full peering link between the two networks.
This assumes that the DDOS is going to be hitting the servers as well. In fact, several recent DDOS attacks have been not at servers ( since it is no longer usually a single server but many ) but at the infrastructure leading up to those servers.
The most useful place to counteract a DDoS attack is to place barriers as close to the source as possible. That's exactly why Arbor's take has been to distribute the detection and countermeasures upstream in the network. Putting an ACL on the customer's access router is only marginally better than putting a firewall between the flood and the server.
I wish Arbor well in peddling their proprietary "patent-pending" technology, but don't expect to see this running on any major networks anytime soon.
Thanks for the well wishes. You'd be surprised to know who's running with our technology. :)
-Rob MalanCTO Arbor Networks
I agree with you: there's no difference to Arbor between a DDoS attempt and a slashdotting. To us a large bandwidth anomaly is a large bandwidth anomaly (looks like a huge duck, it probably is a huge duck). We're providing tools for network operators to get a handle on the traffic in their networks, specifically large bandwidth anomalies -- regardless of their cause. Sometimes the duck is only slashdot and you let it waddle by. Sometimes the duck kicks your network's butt and you'd like to do something about it.
I also agree with you about the centralized company approach to DDoS. Our position is to make sure that we give network operators the tools to make sure that the perimeter of their own "island" of the Internet is secured. If they want to cooperate, we'll give them the tools to do that too.
Clearly, bandwidth-based attacks will continue to evolve (eg Zapatista protests), however, you can only slice a huge bandwidth flood so many ways. It's not a needle in a haystack.