Back

IP Network

How will your voice service fare with the Internet turned off?

Simon Woodhead

Simon Woodhead

29th July 2020

By Simon Woodhead

What would you do if all your voice providers were unreachable over the public Internet? Are you prepared and know it’ll make no difference, or are you relying on it never happening?

If you’re in the latter camp, you may have ignored our previous pleas such as “Surviving Somebody Else’s DDoS” back in 2015 and you’ve probably been watching the news regarding likely repercussions to the Huawei 5G ban and Hong Kong opining rather nervously.

The prospect of a major DDoS event is something that has kept me awake for years. VoIP doesn’t require much bandwidth so some often wonder why the Simwood network is so much more extensive than our peers, why we run such modern high-end networking equipment and why we pay for enough public edge bandwidth to carry well over 1m concurrent calls. They’ll similarly wonder why we pay quite a bit to maintain external DDoS scrubbing capability of 1Tbps+. Finally, we have many many times either of those capacity on what I’d call the private edge. And I still don’t sleep at night.

We run absolutely no Chinese routing equipment on the network. Zilch, but we’re quite rare in doing so. Why? Because it is so damn cheap! Other networks we know are riddled with it which makes the talk about 5G somewhat moot. If you’re the customer of a major UK access provider, I’d wager your packets have traversed a Chinese switch to read this. Forget DDoS, if Huawei is a vehicle of the Chinese Government as is being suggested, and if they have the backdoors that have been intimated, the single most disruptive thing they could do is switch the damn stuff off. That would cripple many more networks than is appreciated to an extent that I think would surprise. “Oh but it isn’t in the core” they’ll cry, but I think “So what, you have to go through an edge to reach the core”. Don’t start me on the prospect of compensating the cheapskates either! Alas, I digress!

One of the reasons I worry so much is that VoIP traffic, RTP in particular, looks rather like many common attack vectors. For a web host or an e-commerce website, if they see a lot of UDP, it is unusual and potentially a common attack – DNS or NTP reflection spring to mind. And it scares them so much because unlike TCP which has congestion control built in, UDP just keeps on coming. UDP is the majority of our traffic and we rely on its relentlessness to make voice calls real-time, but that also makes handling it in an attack tricky, and it makes keeping services up over and above an attack even harder.

We maintain such a surplus of edge capacity because if one’s port is full in the event of an attack, you’ve already lost. If there is headroom and the kit is powerful enough, you can just drop offending packets on the floor and maintain service. That is one plan A as it were should Simwood be under attack. I say ‘one’ plan A as an attack against a specific target address that is disposable would yield a different plan A.

Plan B is to leverage our off-net scrubbing so in theory the only traffic we see is filtered and we have way more edge capacity available to deliver dirty traffic into the scrubbers. That has worked well in previous drills but we obviously haven’t tested it when a hugely resourced nation-state is launching a distributed attack against multiple targets in another.

Beyond that we’d start shutting things down. By ‘things’ I mean we’d be shutting down congested public edge ports in an effort to bring the traffic in without congestion or not bring in problematic traffic at all. Put another way we’d be shunning traffic in the hope of getting rid of more bad than good – network chemo you could say. Assuming the transit operators are themselves in a position to deliver full ports to us in this kind of situation, we’d shut ports to them down. If we shut down all IP transit, we’d be unreachable from large swathes of the Internet as our address ranges wouldn’t be announced anywhere reachable by many. It’d be a good thing in this circumstance but it’d also include the customers of networks who refuse to peer with us, such as the UK incumbent and largest access provider. The good news is most alternative networks do peer because, well, you know. Thankfully, only 10% of our traffic actually comes in over bought Internet Transit.

Of course, the nature of a DDoS is that it is ‘distributed’. Traffic will originate from infected machines comprising botnets, and other assets, everywhere. In theory all our public peering ports will light up too, especially considering the global peers we have including many other countries’ incumbents including in Asia. We wouldn’t want to shut down our public peering ports on LINX etc. entirely as we have hundreds of peering sessions there delivering the majority of traffic, but we would instead shut-down problem sessions and would likely end up with a few dozen sessions with key peers delivering a manageable level of traffic.

Lastly, there are those who are directly connected to us. This is generally still peering, and they still reach us over what are essentially public addresses, but reached privately over direct fibre into the network or from on-net. Our largest customers fall into this bracket, as do our largest peers. Even in a situation where our addresses were unreachable from most of the world, these peers would enjoy access to and from the Simwood network because of this connection to the private edge. They’d also be blissfully unaware of any time elapsed enacting the above because their service has carried on.

Does that include you? If you’d like it to, talk to us about Direct Connect. For LINX members, we’ll welcome a public peering session on LON1 or LON2, but we also have a large bundle of PI fibre pre-patched and waiting for peering over PI.

Or you can just wing it like our competitors seem to or rely on the fact there’ll be bigger targets. The trouble is with a brute force DDoS attack, there will be collateral damage in unexpected places and it is hard to foretell where.

Related posts