Your browser is not supported. Please update it.

10 June 2021

CableLabs preps DDoS mitigation, but has horse already bolted?

CableLabs, the venerable industry association that develops a heap of technologies in support of cable operators, has unveiled a DDoS prevention system that looks to detect and block traffic at the network level – for both internal and external attacks. Called Transparent Security, it could help solve a looming problem, and prevent users from getting egg on their face down the line.

Transparent Security (we already hate this name) uses In-band Network Technology (INT) to monitor network traffic. It looks for suspicious behavior, and can then block traffic emanating from a rogue device on a home network. For instance, if a smart speaker was compromised, and started reaching out to a known command-and-control server, an operator using Transparent Security could block that outbound traffic at the source.

Cox Communications appears to have been one of the main proponents, and has been showing off a proof-of-concept test in partnership with CableLabs, for a number of months. The tests there suggest that the tech can identify and mitigate a DDoS attack in one second, and the pair claim that the leading commercially available DDoS mitigation system takes a full minute.

This sounds rather impressive, but we’re not sure there is going to be a clamoring queue for the technology. Operators have yet to be properly burned by an IoT botnet, which leaves us in a proper chicken-or-egg scenario, where adopting such a technology might completely negate that risk, but where the operators are not yet properly motivated.

Deutsche Telekom got whacked by a botnet a few years ago, and we expected such attacks to claim many more victims. But this has not come to pass, and while we’re wary of correlation and causation, this lack of attacks might suggest that operators have done a decent job of keeping a lid on that particular threat.

The trialists report that the additional INT packet headers required to monitor the system do not add any performance overhead. There has been no word on how easily you could bypass the system, however, if you had ill intent.

The technology itself is built on top of the P4 programming language. P4 is open source, and is used to program the data planes inside the operator networks – from the CPE, back to the central cloud. P4 allows you to program the In-band Network Telemetry functions.

As for the hardware, CableLabs says that the expected CPE costs should be similar to the cost of the current general-purpose CPUs. However, CableLabs says that these CPUs would need to be swapped for chiplets, which support programmable data plane functions in specialist cores. Specifically, these chiplets would need to adopt the Open Compute Project’s (OCP) Open-Domain-Specific Architecture (ODSA) open standard.

Consequently, this looks like a next-gen technology, which will require the CPE vendors to make the jump to chiplets entirely. CableLabs does say that many top CPE vendors are already offering P4-compatible equipment, but these are far from commonplace. It will take time to arrive en masse.

However, to sweeten the deal, CableLabs promises that the P4-based programmable data plane can be used for other applications – altering the behavior of the network using an analytics engine, for automation, firewalls, managed router services, and SD-WAN.

Cox says that it has operators on board for both lab and field tests, later this year. As it runs on white-box network switches, Cox and CableLabs report that it is very inexpensive to implement. CableLabs wants to get telcos on board too, and as the project is available on GitHub, it shouldn’t run into too many vendor-lock-in objections.

Of course, all these shiny new use cases hinge on the operator equipment itself not being hijacked. Essentially, the question is how confident are you about the security of your devices, and do you want to try and tackle this problem at the edge of your network or somewhere more central.

Once someone has physical access to a device, it’s essentially game over. With enough time, that device is going to be compromised, and the challenge it poses in resisting the attacker’s methods generally tracks the price of the unit. The cheapest set tops and routers are, generally, going to have the worst anti-penetration capabilities.

Of course, throwing money at the problem isn’t the answer. A network should be architected in such a manner that one hijacked box can’t cause problems to the rest of your operations. Sure, spending four-figures on an immensely secure piece of CPE is a flex, but it’s also a spectacular waste of cash.

However, the miscreants you need to be worried about are not looking to gain physical access to these boxes. Instead, they want to be able to trawl the web and locate vulnerable devices remotely, and then infect these with their desired payloads. For DDoS attacks, this means creating a botnet of devices that you can then use to target specific websites, crushing them under malicious traffic to take that service offline.

The botnet, if it’s any good, should be able to avoid detection. If the compromised device stops working, it will draw the attention of the operator’s customer support teams – betraying its presence, and potentially outing its fellow conspirators.

To that end, the operator needs to consider whether it has any way of checking whether its installed base of CPE has any active infections. If it doesn’t, it needs to start thinking about how to implement such a system, so that action can be taken, if infections are discovered.

Currently, our botnet creators are looking for the easiest route to market – targeting devices that are trivial to hijack, thanks to their use of default passwords and user accounts. We should safely be past the point in history where this was common practice, so we should be able to sleep soundly on that front.

But there may come a point where they look for juicier targets – and what’s juicier than a smug operator that thinks they’re immune? Ever leave an AWS bucket exposed without realizing? Do you check on all the GitHub commits you used in that latest application stack? Got any way whatsoever to check in on your devices?

You should be proactive, but there are business decisions to make. There needs to be a clear return on investment, but it’s hard to properly evaluate how much a security breach is going to cost you in the long run.

Consequently, relying on security tools that run inside your secure cloud-based ecosystem is likely a better investment than trying to lockdown the network-edge – especially as it seems we might be able to conclude that our operators are doing a decent enough job, as we haven’t heard of a horrendous cyberattack originating from their operations … yet.