How Current Security Architectures Fail to Defend Against DDoS Attacks

April 12, 2017

How Current Security Architectures Fail to Defend Against DDoS Attacks

In part one of this series, we looked at how existing DDoS mitigation techniques lag when combined with traditional routing gear. They are unable to adapt to the fast-moving landscape to defend against DDoS attacks. To handle volumetric attacks, companies need to disaggregate DD0S mitigation from detection with a lean hardware approach (simple yet high performance) that can be coupled with any leading DDoS detection software. This is what Corsa Red Armor is about.

But, to know you’re heading in the right direction, it’s always important to think hard about where you currently stand. It’s worth digging into the inadequacies of current security architectures to defend against DDoS.

Rigid ASICs

Within conventional routers and switches, the packet processing logic is not designed with security in mind. ASICs have a semi-rigid pipeline of packet processing that is baked into the chip. The rigid architecture encounters challenges when processing obscure packets relating to security threats.

A standard appliance ASIC has parsers at the front end designed to pick up the specific protocols that are listed on their data sheets. Within a standard networking framework, the parsers operate inside a packet at one protocol layer at a time. For example, if you have MPLS over Ethernet and IP inside MPLS, there will be a pre-structured view of what should be done at an Ethernet, MPLS and IP level.

However, security is a different type of beast, and nothing is ever standard. Within a security framework, many different things can happen along with a variety of packet types; all received at once and at one scale. Standard ASICs are not built to cope with security functionality efficiently. Conventional routers leverage Layer 3 5-tuple matches which are efficient for their purpose. However, adequate security requires us to look deeper into the Layer 4 header and TCP options.

If we take this one step further we may, for example, have untagged Ethernet packets without MPLS Headers injected into the system in an unexpected way, with the ability to raise the alarm. This does not naturally fit into the ASIC model, for what we should be doing with untagged packets that don’t have MPLS framing in them.

Packet Parsing & Rate Limits

The capacity to parse packets in any way and in the hardware, offers flexible match criteria to respond to the most evolving security threats. When it comes to packet header parsing, you should have the ability to match on any Layer 3 and Layer 4 field in the packet header and in the hardware.

Traditional approaches, for example, the RTBH Blackholing, only provides destination based blackholing, thereby limiting the flexibility and rules granularity. Traditional Blackholing can filter against 1M destination or source IP address in FIB, which is a pretty decent scale but it cannot rate the limit and has no granularity.

Traditional router-based BGP FlowSpec has 500–50,000 entries in ACL, but this is shared with QoS and other router features. And so, it is challenging and risky to share such an important resource between routing and security on a standard router.

Flaky uRPF

Unicast Reverse Path Forwarding (uRPF) is not always supported and when it is different, vendors have varied implementations. Even the same platform with different OS versions may have different implementations.

If you have a mixture of older and newer equipment, the feature differences will make it hard to roll out a streamlined service across the entire domain universally. You may have to pick and choose different features in different parts of the network depending on the platform and OS version. Some features get implemented while others do not.

Some vendors can have touchy implementations depending on what gear you have rolled out. More than often, anything touchy in security results in loss of service (LOS).

Unscalable NPUs

NPU don’t fall into the same traps as ASICs. They have excellent flexibility but don’t always have the sufficient scale.

More than often they slip into stateful processing. When this happens, the burden on the NPU grows, for example, regarding packet reassembly and looking deep into the headers. Individual vendors dramatically lose performance by instantly degrading functionality and creating pockets of new security risks. There are recorded cases where some vendors under heavy stateful inspection end up passing the Google Chrome protocol through with zero inspection.

Creeping into state introduces rate and scale limitations, especially when you want to do smart things quickly. Many NPU security appliances do stateful firewalling up to the line rate but if you want to go one step further, to say an IDS layer, it drops to 10% of the line rate.

Whereas if you begin with stateless as a starting point, you can reach higher Mpps far beyond what a NPU can keep pace with. Stateless only approaches but does not creep into a domain where users are expecting stateful functionality out of the same box. They operate at the boundary and stay close to the perimeter of stateful processing but never actually go there. This offers a clean, efficient approach to security by creating a technical demarcation that results in a performance optimized solution, easy to run and manage. This is a unique design point as there are not too many vendors building NPU systems that are 100% stateless.

State Will Always Get You

Maintaining state within the network degrades performance and increases complexity. When state is maintained, it overwhelms and slows the forwarding process. Best practice recommends keeping state to specific functions, most certainly away from the forwarding hardware. However, this is usually not the case with traditional DDoS mitigation solutions.

Everyone agrees that to have the state inspection on a Terabyte network is not realistic. Forwarding has to be done in the hardware, and it cannot have state in it. Visibility into packets is not required to forward traffic, so it has no real reason to be there. State inspection should be performed on a subset of traffic and therefore should be scaled separately.

To scale and operate at peak performance, most modern networks push the state and complexity to certain areas. Both the Internet and Multiprotocol Label Switching (MPLS) networks drive complexity right to network edges, keeping the Core role to pure IP forwarding.

The same concepts apply to the data centre world. The state/complexity is pushed to the edge leaf nodes with overlays, while the core only forwards packets to the destination address. The core devices interact in a very shallow way, and there is no filtering or policy implementation. This is the only way to scale a data centre.

The same principles are applied to the security model by pushing the heavy inspection and complexity to individual appliances; most surely away from the forwarding plane. With security disaggregation, forwarding does not get hampered since you are not trying to do the inspection and forwarding at the same time.

Inspection and analysis are usually sub-line rate and now, with the disaggregated approach, can be on different platforms. As a result, we have line-rate forwarding and enforcement with sub-rate inspection and analysis combined into one source of intelligence.

Creeping into State

Some security vendors don’t have a clean line around stateful and stateless functionality. Their data sheets will show a mixture of features that are stateful and stateless. Everyone is trying to do a better job, but a good understanding is essential in order to know what happens as soon as you cross that line and become stateful.

Initially, the solution becomes more complicated and the price goes up. However, the price is usually rationalized within the existing culture of security professionals in the sense that security devices are supposed to be expensive. But the price shouldn’t be this gigantic.

If you move into the world of state, one general issue is reassembly. When packets arrive out of sequence, you will end up with large buffers to hold on to the out of sequence packets, until the trailing packets arrive. Reassembly causes everything to work hard concerning the number of instructions per packet that you have to run. This is also often used as an exploit where an attacker deliberately delivers an exploit to blow up your buffers.

Even if the line rate is not high, just to maintain the state is a task by itself. Many resources that used to support state can grow and somewhere there have to be registers and memory keeping track of all the flows.

An Obvious Conclusion

It’s quite clear that the evolution of DDoS solutions has created a situation that is far from ideal. A minefield of inadequacies that leave you with a lame duck approach to DDoS protection for 100G. And, even if you can band-aid your way out of a few, it still seems the road ahead is rocky. In the following post, we will explore this rough terrain so you can start to develop your strategy for escaping the wasteland and finding your way to real-world 100G DDoS mitigation.

Related Articles

In part 1 and part 2 of this series on DDoS protection, we addressed the core deficiencies with traditional mitigation solutions such as rigid ASIC, unscalable NPUs, inadequate packet parsing and too much state. All these things by themselves drag down a solution. Read more

I am catching up on my reading and just read the 4th quarter Akamai report on the state of the internet. For those of us who follow information security, it provides a fascinating, and ultimately, harrowing look into the current state of mega DDoS attacks. Here is what struck me … Read more

Tuesday evening, September 20, 2016, was a warm, rainy day in Northern Virginia that had given no hint of what was to come. And then, at 8:00 pm, BOOM! The biggest distributed denial of service (DDoS) attack the world had ever seen Read more