ISP DDoS Protection May Not Cover All of Bases

Most organizations cannot rely solely on on-premise solutions because of the volumetric aspects of DDoS attacks. Multi gigabit-sized attacks cause on-premise connection lines to fill up, and organizations to go offline. Vulnerabilities with CDNs also has limitations for organizations. On-premise and cloud-based solutions offer protections that most ISPs are not able to deliver effectively. Some ISP’s have much better detection and DDoS mitigation capabilities, and next-generation offerings may include WAF and DDoS automation and integration. Every ISP is different and actual protections will vary over time and with vendors.

Reasons Why an ISP May Not be Able to Provide Full Protection

1. Many examples demonstrate that an organization can be a victim of collateral damage when the ISP fails during massive DDoS campaigns. Even when outsourcing to specialty providers like DYN for DNS, total outages are possible. Latency becomes an issue when your ISP is fighting off DDoS attacks of larger volumes. If your ISP has 100Gbps of total bandwidth and takes on 80Gbps worth via DDoS attacks, what happens to your organization if you are NOT consuming DDoS services from them?

2. The ISP does not know your applications, so how can it profile web and app-based applications? Does it know normal HTTP, HTTPS and APPbased rates and normal behaviors? Unless it commits to doing a full proxybased WAF offering, legitimate users will be blocked during an attack. This does not take into account SSL and other encrypted protocols, which require escrow certificates and keys with the ISP. Many organizations have compliance requirements that prevent something along these lines, especially with noncompliant ISP’s.

3. SSL Encryption is a norm for most applications. To effectively combat SSL DDoS attacks, mitigation requires some level of SSL inspection. Only one OEM has patented asymmetric SSL protection. SSL “proxy” or always-on decryption is a very latency-expensive proposition, and thus on-premise equipment only allows for “under attack” SSL challenge response. Other methods that use always-on SSL proxy style mitigation introduce a lot of latency or are extremely expensive for overprovisioning. This also causes issues with compliance if the payload is inspected in SSL-proxy mode.

4. Many ISPs ‘blackhole’ traffic by routing it away from the intended target so its uplink capacity is not exceeded. However, this blocks traffic indiscriminately, effectively blocking off websites or apps. Roughly, 50% of ISPs utilize this method at one time or another.

[You might also like: Why ISP DDoS Services Typically Fail]

5. Burst attacks are short-lived DDoS attacks where the attacker knows that a DDoS “scrub” or traffic diversion will be put in place. Average time to mitigation with ISPs is over 15 minutes. Short burst attacks can be very damaging to environments, and by the time the ISP responds to the attack, it could be over (only to return again shortly). This method of attack has become common because of ISP scrubbing methods.

6. Even if your organization isn’t paying for DDoS services, is it paying for bandwidth expansions because of DDoS being a normal way of life? Many ISP’s pass the buck to customers by expanding bandwidth capabilities. Prices could reflect this expansion of bandwidth, even if you don’t buy into this business model. The question to ask is: are they consuming new circuits from tier 1 providers who have the fastest circuit, or have they expanded with lower grade circuits for DDoS attacks? How would the latency of your applications be affected if their emergency circuits are utilized?

7. ISPs are typically local to your physical geography. This means the attack generally has to come to your ISP’s network before they can scrub it. In larger scale attacks, this can disrupt their upstream ISPs and interconnects between countries. This can result in upstream ISPs blackholing legitimate traffic to protect their links, and thus impacting legitimate users. Global DDoS scrubbing uses larger networks, which can stop the attack before the ISP sacrifices your traffic to maintain their transit customers.

8. Multiple ISPs – more than one ISP, you must buy services from all of them and they are not coordinated. The more ISPs that are used, the bigger the problem becomes. Finding effective strategies to deal with DDoS attacks and getting accountability between competing ISP vendors becomes a major challenge.

9. Asymmetric scrubbing center models are generally how an ISP handles an attack, but protection from, certain kinds of attacks can be severely limited because they aren’t seeing the full conversation. This leads to overmitigation and false positives. Asymmetric issues compound with use of multiple ISPs.

10. Brute force DDoS attacks and BotNet scrubbing attacks are generally not considered “DDoS” from ISP levels. The ISP may be completely blind to brute force attacks that consistently lock out legitimate users, or application- based botnet attacks that challenge applications. Imagine a hotel chain with all rooms placed on booking holds for 24 hours, every day. The same scenario happens with e-Commerce providers with inventory and shopping carts, airlines and railways with tickets, etc.

11. Default ISP detection mechanism is based on Netflow. Neflow detection works based on thresholds, and typically if the pipe is 1Gbps. Typical enterprise threshold are TCP 90% (within TCP let’s say 75% Http, 20% Https) and 8% UDP and 2% ICMP. With this threshold approach, many of the low & slow attacks are bypassed and damage customer infrastructure.

12. Lack of certifications – ISPs do not have certifications like ICSA and NSS Labs for DDoS and WAF.

ISPs Are Only Concerned with the Link, Not the Applications

ISP/Telco DDoS Scrubbing vs. Radware Hybrid-Enabled Cloud Scrubbing


Read the 2016–2017 Global Application & Network Security Report by Radware’s Emergency Response Team.

Download Now

David Hobbs

As Director of Security Solutions, David Hobbs is responsible for developing, managing, and increasing the company’s security practice in APAC. Before joining Radware, David was at one of the leading Breach Investigation Firms in the US. David has worked in the Security and Engineering arena for over 20 years and during this time has helped various government agencies and world governments in various cyber security issues across all sectors.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center