Many of the security solutions developers have relied on in the past introduce latency, making them less-than-ideal for developers of real-time applications. However, there are options to ensure protection without sacrificing speed or quality. With Subspace, security can be handled natively in the network that was explicitly designed for real-time protection.
Application security and network security are two of the most important considerations for developers. With standard applications, there are often simple solutions. But for real-time applications, security has been a challenge, and the options can seem limited.
Security and Latency — It’s a Problem
Security is important, but in the world of real-time communications, so is speed. Unfortunately, many of the security solutions developers have relied on in the past introduce latency, making them less-than-ideal for developers of real-time applications.
You can’t sacrifice speed to improve security. But it’s also a bad idea to decrease security to improve latency issues.
It’s a catch-22. What’s a developer to do?
The security measures that are available to most web applications simply aren’t appropriate for real-time use. Content delivery networks (CDNs) and application firewalls are high-latency solutions that were not designed for, nor intended for use with real-time applications.
Although CDNs are more efficient than a single server, they still aren’t designed for real-time traffic. There’s no time to populate your real-time data across a delivery network.
Physical distance makes a difference when you use CDNs as well. The further a user is from the nearest server storing the information, the longer it takes for the information to reach the user. This means some users will experience more latency and have a less pleasant experience, introducing more problems for a real-time application with a global user base.
Then, there’s firewalls, another commonly considered security measure which use control over incoming data as a protection mechanism. Again, this causes latency. Even application delivery networks (ADNs), which are used in live broadcasts, have a 30-second tolerance. It’s true, “Live” isn’t actually live at the enterprise level. If a massive telecom company can’t manage security in real-time, how can others?
Better, But Still Not Great
There are some additional options beyond CDNs and firewalls, but each comes with its own drawbacks when used for real-time applications.
Session Border Controls
In voice over Internet Protocol (VoIP) cases, Session Border Control (SBCs) can be used to help secure session initiation protocol (SIP) services. SBCs also allow VoIP traffic to get through firewalls without sacrificing security, but their use may also affect the quality of service.
“Depending on network architecture, this may mean a transit across a rather long call path — and this introduces latency into the connection,” writes Mike Jude in TechTarget.
SBCs were once simply part of what carriers provided, so no one else paid much attention or had reason to be concerned with how they functioned. However, as technology has developed and grown and real-time applications dominate our lives, it’s now mission critical for enterprises to know that traffic is moving smoothly between networks.
In addition to introducing latency, SBCs can also be expensive to maintain since they require maintenance, monitoring, and they increase architecture complexity. Complicated configuration and operation necessitates the use of experts — through hiring or contracting — both for the initial setup and for ongoing maintenance. Not only does it require an investment up front, but it’s also not a solution that can be put in place and forgotten. With additions and changes to voice services, SBCs must be configured to recognize and interoperate with them. When IT teams must actively manage these SBC devices, it reduces their bandwidth to work on other initiatives and increases overhead.
Along with the problems of latency and complexity, SBCs also introduce a challenging dynamic that causes both enterprises and carriers to ask, “Who is in control?”
For visibility into security measures and how to adapt them, the enterprise, of course, would prefer to secure the network connections themselves. But the carrier must address things like quality of service, legal questions regarding the interception of voice traffic, and voice connection management. With carriers unable to cede control of securing network connections, there’s still a security problem from the enterprise point of view.
Web real-time communication (WebRTC) provides a partial solution, but ADNs have never been a “thing” in WebRTC and communications. The framework was developed to provide peer-to-peer communication between web browsers and mobile applications. Even though it’s a better solution than firewalls, CDNs, or SBCs, WebRTC still presents some challenges, specifically how developers can make sure it works in different networks.
There are three ways to overcome the challenges of peer-to-peer communication using WebRTC applications:
- The browser must learn, as best it can, the topology between itself and the peer that it is trying to communicate with
- Establish connectivity on the best path
- A fallback mechanism
The fallback mechanisms used in WebRTC usually involve Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN), or Traversal Using Relay NAT (TURN). The Internet Engineering Task Force and the Web Real-Time Communications Working Group collaborated to standardize this technology.
Network address translation, NAT, is a common mechanism for giving local network admins control of topology. NAT is often used in conjunction with a firewall. Most of the time, the combination does a fine job of protecting a private set of IP endpoints, but it cannot do the same for peer-to-peer communications.
TURN services have typically been packaged to solve enterprise problems only. However, as with most solutions, a TURN server can increase media latency. It’s also necessary to have a high-end TURN server, which could be located within the enterprise network or on the public internet. A TURN server on the internet requires a high bandwidth connection and both the server, its operation and maintenance, as well as the connection itself add to the expense of using TURN services for an enterprise.
So far, engineering has addressed situations in which clients are on an enterprise network that resorts to blocking User Datagram Protocol (UDP), preventing BitTorrent, or freezing out other unwanted traffic.
UDP is an alternative to Transmission Control Protocol (TCP), a connection-oriented and slower protocol. Developers have used UDP TURN to translate TCP to UDP in the backend, but this process incurs a quality of service cost. UDP also has some other disadvantages and can lead to network packets being lost, arriving late, or arriving out of order. Sure, it may be faster, but more errors make it less of a solution than was hoped for.
A Security Solution That Works
Although it may seem as if the options are limited, real-time applications do have a means of ensuring protection without sacrificing speed or quality. Security can be handled natively in the Subspace network, which was explicitly designed for real-time protection.
Many of our features might normally be managed using a dedicated edge server. We deploy them inline, so you don’t have to pay the cost of going to a location and have that server do it. And, we can make protections happen inline before the data actually gets to the servers.
In other words, you don’t need to dedicate limited resources to maintain WebRTC to have security, and you don’t have to depend on firewalls, CDNs, or other partial solutions.
Subspace believes security should be provided inline, with little extra effort on your part.
Want to start building on Subspace today? Sign up here.