TSRs and Encryption

Simon Woodhead

Simon Woodhead

24th May 2023

By Simon Woodhead

There’s a bogus narrative circulating that the Telecommunications Security Act 2021 doesn’t apply to all but the largest entities. 

That is incorrect – the Act applies to all, and the precise and detailed secondary legislation, the Electronic Communications (Security Measures) Regulations 2022, applies to everyone, save for the smallest of the small. 

As ever, in this industry, things cannot be simple. We have three instruments in play – the Act, which at section 105A creates the same legal obligations for an IT maintainer running 3CX on a Raspberry PI with 3 seats for one customer as it does for BT. Then we have the Regulations, which make specific demands, such as encryption, services being able to operate only on UK assets etc, of those with a turnover more than £634k, and the Code of Practice which has the dual role of providing guidance for all on the interpretation of the Regulations and requiring larger entities to procure specific outcomes by various dates between now and 2027, depending on the specific rule and their turnover. 

Turnover wise, entities are placed into three pigeon holes based on annual revenue (revenue being the Ofcom admin fees concept of revenue, not just Companies House revenue – the difference is a whole other lecture for another day, but suffice to say if you fall into these categories, your finance team know the difference) – Tier 1 with £1bn+, Tier 2 with £50m+ and Tier 3 with £634k+. 

Tier 3 providers are subject to the Act and the Regulations and have been required to comply since the Regulations came into force last year. For them, the Code is guidance, but an outage today will be assessed against this framework, and in any event, given the largest have specific deadlines to hit for specific technical outcomes, a lot will inevitably trickle down faster than people think. 

So, it matters and you have work to do! There, I’ve told you and you can choose to ignore me, but we’ll be coming back to this as we chart our own course through it, which I’ll attempt to describe now. Ignorance is no excuse though, and Ofcom have already said they will take pro-active measures with respect to Tier 1 and 2 operators (read: audit) and an incident-based approach to Tier 3. Basically, ignorance and inaction will only cut it until you have an outage. 

Simwood, by virtue of our interconnects with Tier 1 customers and peers, is on a journey already, which I wanted to describe here to help customers plot their own course (or indeed decide they’d much sooner be a Simwood Partner or Dealer for an easy life!). As we’ve seen with the “CLI changes” which we actually implemented 5 years ago, take this as a heads-up of the next industry kerfuffle in 5 years time when those who have done nothing realise they’re out of business if they don’t! They’ll tell you then it is “new”; it won’t be.

The first requirement we want to discuss, by our reading, is to encrypt signalling and media over a network where it is not under your direct control. We’re concerned primarily with voice but this applies to everything. One obvious challenge is “where is the network?”, because logically a service spans beyond a network edge and in services like FTTP with the last mile over third party infrastructure, the precise edge is somewhat grey. Are ISPs required to put VPN appliances in every home? Arguably, yes. Will they? Probably not and defensibly so! 

They’ll logically argue that the demarcation of their network is perhaps the closest unbundled exchange, but that still leaves a massive exercise in encryption from that exchange back. The ‘direct control’ piece is interesting too as in theory, by our reading, it means a cross-connect between two of our own racks in Telehouse North requires encryption but a cross-connect in a tin-shed you own doesn’t. That’s perhaps a bad example because while a shed you own is under your control, it is unlikely to have the requisite level of security to tick other boxes that Telehouse naturally does. That perhaps leads you to: every cross connect outside your rack needs encryption, which is our position. Regardless, the connectivity from said shed or datacentre almost certainly does need encryption and we expect this’ll be where most people get caught by it. 

A large proportion of the traffic within the Simwood network, between our racks and data-centres, is already encrypted, but to be honest not all. In theory, someone could tap the right fibre in a sewer under London and we’d potentially be in breach. We need to address that as, I believe, does every other network in operation, but we have a plan to get there as, I believe, few others do! It’ll be resolved elegantly as part of our ongoing network refresh to get to a point of 100% encryption outside a single rack across our own network, without compromising performance or availability. That there is the hard part.

That leaves IP voice peers and customers to discuss. For peers, as many are Tier 1 anyway we’re already on the runway because they only have until March 2024 and aren’t the fastest moving animals. They don’t tend to like TLS+SRTP as a solution, perhaps because it involves expensive magic-box crypto licences, which are an order of magnitude more expensive than the basic magic-box licences; perhaps also that’s why they don’t offer encryption to their customers! That’s a shame, as we have offered TLS+SRTP pretty much forever, buy- and sell-side and it is the better solution. In practice though, solutions are being and will be dictated by the Tier 1s, with sharp edges knocked off by us where possible. They will probably look like IPsec tunnels over whatever fabric is in-place (including IXP peering and direct cross connects) or, against my every instinct, their magic box of one flavour or another, filling our racks and killing polar bears. If you interface with a Tier 1 (whether customer or vendor) expect them to be giving you a choice of getting compliant by March 2024 or getting off their network, or look out for them on the naughty list next year.

Now, customers, which is the bit of most relevance to most readers of this. We’ve offered TLS+SRTP forever, and that is in our opinion the gold-standard because it enables the introduction of encryption whilst retaining the distribution of applications. Sticking your 60 servers behind a single VPN appliance is dumb – it may tick the encryption box but introduces a massive single point of failure. Yes, you could have 2 appliances, hell you could have 60, but however many you have you’ve introduced a failure domain that isn’t there if you just go with TLS+SRTP on your existing stack. So, it is no surprise that this is our preferred option which is and always has been a no-cost option for Simwood customers. By contrast, we suspect others will want to offset the magic box costs when they eventually introduce it! So in short: you can turn on TLS+SRTP on inbound and outbound traffic at any time today and we continue to encourage that you do; the ball is in your court!

Lastly, we recognise that TLS+SRTP has been available for ever but very few customers have ever bothered to implement it. Considering we have the brighter more technically astute end of the market, we expect penetration globally is very very low and have to recognise that. There are myriad of reasons why, such as buggy OpenSSL libraries, no magic-box support or indeed simply a fear of touching what is working (although we’d remind you that the Regulations also require patches to be installed within 14 days!) We’re therefore making IPSec available as an option for customers for whom it is more suitable. We know mobile operators love it and those running Cisco kit have an easy one-line set-up, but for those on other platforms it can be more tricky. There will be a charge for this which we’ll announce when we have established a level of interest, so please get in touch if you’re interested. 

Please don’t read that to mean we’re gauging how much we can get away with charging! Rather, we want to understand how expensive this is likely to be to support based on the quantity and profile of customers wanting this solution. For everyone else, especially those who are more towards the cloudy and DevOps end of the spectrum, but still don’t like TLS+SRTP, we have another solution brewing that we think you’ll love and you won’t get anywhere else; watch this space.

I hope that helps someone but naturally, do use our Community Slack if you want to discuss any of this, or contact us directly if we can help.

Related posts