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. Combine a few of them with one of the elephants—combined modes and architectural limits—and you have a fully inadequate approach to DDoS that is unable to evolve and scale. In Part 3, we will progress to the two main elephants in the room that have these more severe effects on the success of DDoS protection.
Culture and costs are two main limiting factors to security enforcement. Culture is hard to change, usually ingrained whether it’s right or wrong. High cost is another factor that our culture ties to mitigation solutions.
Culture has to change as it’s now time to realize the inefficiencies of existing DDoS solutions. The right ticket to adequate protection is security disaggregation, and the only way to break the cost barrier is to eliminate the state from forwarding.
Elephant 1: Security & Mission mode
Trying to create the best security solution while dealing with the demands of routing does not lead to success. When you separate network security monitoring and DDoS detection from DDoS mitigation, and move DDoS mitigation into a bump-in-wire, you create a disaggregated network security approach that eliminates router dependency for the security team.
When routing and network security are munged together, the main issue is unexpected growth in the forwarding information base (FIB) due to security team blackhole requirements. FIB is a precious resource that could already be under pressure, carrying full Internet tables.
The other problem is managing the content. We now have two teams influencing the FIB. The network team makes mission mode changes, and the security team injects black holes. We have mission mode core routing and security functionality, trying to share the same resource on an ongoing basis.
Culturally this will not work. Security professionals don’t understand routing very well, and networking doesn’t understand security that well. There are a few with similar hats, but overall it’s two different teams.
Complexities arise when something goes wrong. How do you debug and coordinate between teams? Coordination between groups is critical and no process or function is fully automated.
To aid troubleshooting, the troubleshooting step administrators should be able to turn off features or appliances. Can you do this when both teams are sharing the same device? You don’t want to end up in complicated debugging scenarios. Nobody wants to get calls in the middle of the night trying to figure out why the FIB has suddenly become starved. Or that you cannot insert any more BGP Flowspec due to FIB partitioning and the number was low resulting in FIB repartitioning.
It puts you on the wrong side of the complexity curve, and it’s not worth trying to save the money in exchange of all the problems you will have while trying to manage both.
An inline bump in the wire makes it easy to trace traffic congestion or packet loss. With any mitigation solution, you should be able to switch it to transparent mode quickly. Try to do this on a standard router with RTBH or BGP Flowspec. A bump in the wire mitigator is not a switch, a router or a concentration function. It is a transparent bump in the wire that can be audited quickly by the networking or security team. This type of management is the best way to ensure that network security is not interfering with legitimate traffic routing.
Moving from conservative to defensive
Security engineers are the ones who are the first on call when undergoing a DDoS attack. In a fast changing and hostile scenario, it is important that they take decisive action, using easy to use tools at hand. This is not the time to fiddle with router configurations with an underlying fear of corrupting, disabling or leaving a mess for the routing team to deal with after the attack.
By staging and operating an independent mitigator, you exceed the hardware scale and the capability of the router. It ensures that the contents of the mitigator are always separated from the mission mode router. Therefore, security teams can react more quickly and assertively while under attack.
Often networks have different routers that comprise their periphery. They might have different vintages, and might be from different vendors. It can become difficult for security features like BGP Flowspec or uRPF to find common ground on all the routers. This complicates the operation process for security engineers, often causing them to move to a suboptimal solution, either by centralizing mitigation on security-specific hardware or by simply not employing the best practices.
Stepping forward – moving security and routing out
Separate network security enforcement represents a specialized tool to be used by a security team. With a transparent mitigator, it is easy to troubleshoot and deploy. Network and security admins can quickly determine if the filter is interfering with legitimate connectivity or effectively blocking malicious flows. Moving mitigation out of routers simplifies everything.
Elephant 2: Architectural Limitations
The current security culture immediately defaults to a central architecture and is missing out on some key benefits of an inline perimeter-based approach to security enforcement. An inline solution inserts a stateless appliance at the perimeter edge, right under the nose of a DDoS attack, providing different dimensions to security enforcement.
This line-rate bump-in-the-wire mitigation approach has the further benefit of being invisible to the network and there is no further attack surface added to the network.
Security professionals have put themselves in a corner by making security so expensive that they are forced to centralize. Security appliances have a high cost per port compared to say a standard appliance. As a result, security culture has formulated a comfort with big numbers. When you think you don’t have the budget for inline security functions on the perimeter, the only available option is to centralize.
The so-called centralized designs miss out the dimensions and visibilities that an inline security appliance offers. The ability to react directly at the perimeter provides a cleaner architecture. Mitigation becomes pervasive, and continuous on all flows. It no longer requires traffic redirection to and from a scrubber. Nor does it have an upper bound on how much can be reasonably redirected for mitigation. All of the traffic, all of the time and affordable is a very simple architecture.
Centralizing undermines the capabilities of an inline solution where you don’t have to redirect traffic to a centralized location. When you centralize, you somehow have to redirect traffic with Border Gateway Protocol (BGP) or interior gateway protocol (IGP) tricks and the return path needs to have a provisioned tunnel; both operationally and architecturally messy. A robust design should aim to tweak as little as possible.
A centralized design opens up the additional surface interaction between network and security teams by creating network complexity with routing protocol design and tunnel configurations. Both teams must group together and agree on many design choices.
The perimeter architecture is less annoying as you don’t have to come up with a full architecture of how to redirect traffic. This eases the tension between security and networking professionals, thereby creating a fluid approach to security implementation.
Benefits of inline on-premise
The market is trained not to do distributed inline solutions; it is trained for centralized mitigation. It’s not anyone’s fault; it was pushed by cost, culture and complexity.
Operating in stateless mode and doing forwarding with security in mind as a bump in the wire ends up at a very different price point and solution option. Instead of being cornered into a central only design with heavy stateful appliances in one location, you now have the possibility to spread inline at the perimeters of the network.
The ability to go inline enables security teams to inflate the security bubble to whatever size fits the requirement.
An inline solution may scare some security professionals, whereas redirection is less harmful to mission mode. However, inline distributed architectures offer dimensions not available with centralized designs.
The world is becoming distributed. Nobody wants ingrained holy grails any more, and distribution is the only natural way to scale against largely distributed attacks. Who knows what billions of unsecured light bulbs are going to do to networks! But spreading the design, so every location takes a little hit, is a valid approach.
In the past, inline solutions created barriers to adoption. There was fear. Now it is becoming clear that this is the way forward with one important stipulation. It is a growing trend signifying that inline is the right way to go – if and only if the hardware performance is line-rate.