Posts

Secured Approach to Cloud Telephony Services

A Secured Approach to Cloud Telephony Services

Secured Approach to Cloud Telephony Services

Image credit: Flickr user opensourceway

One of the common dilemmas to most “mission critical” cloud service providers is whether an on-premise border gateway or tool should be part of their architecture for connecting on-premise software and HW appliances to their cloud services.

The purposes of such a border gateway or tool are various and depend on the cloud services provided. For example, a familiar tool is the AWS Storage Gateway. This gateway connects on-premise appliances to the Amazon Cloud storage services. Other cloud services such as big data analytics and network performance monitoring architecture may include on-premise tools for remote sniffing, data gathering, filtering, transforming, preliminary analysis and mass data transport.

When thinking of using a cloud service for enterprise telephony, a common decision point is whether to connect the enterprise IP Phones directly to the telephony service provider or to deploy an on-premise cloud appliance.

Actually, an enterprise cloud-based VoIP services architecture, dictates the need for an on-premise Session Border Controller for basic operation solving connectivity, (i.e. NAT traversal), security, resilience and quality issues.

Connecting the enterprise to the service provider cloud through VPN

Trying to reduce costs, VoIP service providers often bypass connectivity and security issues by connecting the Enterprise to the cloud using VPN over IPsec or MPLS-VPN service with or without standard End-to-End Service Level Agreements and performance reporting.

Both VPN-IPsec and VPN-MLPS connections simulate a L2/L3 LAN with the service provider. This architecture obviates the need for NAT traversal and on-premise VoIP security, as VoIP clients and IP phones share the same IP subnet with the service provider SBC.

Enterprise-Cloud-Over-VPN

VPN connection between the enterprise and the service provider

Adding Multitenancy

This approach may be satisfying for private or dedicated cloud architectures, although it doesn’t provide a solution for resiliency and voice quality monitoring. However, for cloud-based VoIP service providers who provide service to multiple enterprises, this approach is problematic.

Multi-tenant-SBC

Multiple tenants connected to the service provider through VPN

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server or HW system, serving multiple client-organizations. Although multitenancy can be achieved by running multiple instances of the application, in most cases multi-tenancy is designed by virtually partitioning an SBC data and configuration. Each tenant works with a segregated non-bleeding virtual application instance.

Multi-tenant cloud-based VoIP services share a single application server instance (i.e. IP PBX, application servers) and network entities instance (i.e. access SBC, peering SBC) between several tenants.

Seemingly, multi-tenant shouldn’t present any security or other issue, but in reality, this tenant segregation is almost impossible since, after all, tenants may share network interfaces (same IP and port 5060), and a SIP trunk or MGW in the northbound, so the segregation is not complete. An attack on one of the tenants or a misconfiguration of one of the shared resources, compromises all of the tenants’ security. In such a case,  as the tenants are sharing the same L2/L3 with the service provider and relying on the service provider IDS (intrusion detection server) and IPS (intrusion prevention server), a simple intrusion can be destructive.

Cloud-Appliance

 An SBC as demarcation point between the enterprise and the service provider

Isolating the enterprise from other tenants’ security threats

Organizations that can’t afford compromising their security and can’t trust 3rd party security services, should deploy an enterprise SBC as a demarcation point.

An Enterprise SBC provides:

  • Support for back-to-back user agent (B2BUA) functionality
  • Security and privacy (personal information is not forwarded to the cloud)
  • Emergency calls and regulatory
  • Resiliency
  • Remote Agent termination
  • Registration throttling
  • Voice Quality Monitoring
  • Call Admission Control and Rate Limiting.
  • Registrations overload and avalanche protection
  • On-premise recording, the SBC forks the calls

Finally, cloud-based VoIP services can be connected to an Enterprise via VPN-IPsec or VPN-MLPS without the need for an Enterprise SBC. However in choosing this path, the enterprise loses much of the above mentioned functionality related to the SBC and puts the enterprise in a security risk as well.

Image: AudioCodes SBC Configuration Wizard

Making SBC Configuration Human

When I visited a 777 cockpit for the first time, what struck me most was all the buttons. I thought to myself, how on earth do the pilots know what to do with them all?

Looking at an SBC configuration reminds me of that same experience and over the years I played aroundwith quite a few SBCs of the SBCs out on the market.

Putting things into perspective, a typical SBC user manual is a few hundred pages long. A typical vendor’s beginner SBC course would run three days or more.

In light of this reality, one of the first questions an experienced customer would ask when considering an SBC would be, “just how complex is the SBC to configure?”

The perception of complexity is well rooted in reality and for good reason. It is not that SBC vendors lack UX (User Experience) knowledge or capabilities. The complexity is derived from the flexibility of the different VoIP standards, which means that every vendor can implement the standards in a different way. An advanced SBC is expected to deal with all of this complexity and interwork between different parts of the network on multiple layers, including SIP, media and IP. The SBC needs to be able to classify groups of users according to multiple attributes, to maintain access lists, manage security, routing and more.

Complexity has its price

The implications of SBC complexity are serious. For one, such complexity raises the cost of installation as technicians need to spend more time on site; it increases the chance of misconfiguration resulting in communication errors and increased support costs. Overall, the complexity of an SBC constitutes a hurdle in the transition to SIP trunking.

But does it have to be that complex?

Consider the following:

  • As it does elsewhere, the 80/20 rule holds true for SBCs as well. 80 percent of SBC customers only use 20 percent of the SBC’s configuration options.
  • The variance between similar deployments of different customers is relatively small. By ‘similar deployments’ I refer to a setup which involves certain kinds of PBX (and software releases), a SBC, and a service provider’s SIP trunk service.

The bottom line is that when looking at two different customers that have similar setups, each customer’s configuration will only differ marginally. The difference would usually include IP addresses and other layer 3 to 4 settings, number manipulation rules, authentication passwords and several additional parameters.

Taking the wizard route

A configuration wizard is a well-known user interface concept common in desktops and web applications. The wizard is used to get the user up and running quickly in just a few steps, leaving the advanced application configuration to a later stage using a parameter centric GUI.Image: AudioCodes SBC Configuration Wizard

The 80/20 rule and the typical similarity between deployments makes the wizard approach a perfect fit for an SBC configuration.

At AudioCodes, we adopted this approach and have developed an SBC configuration wizard application.

Starting with the deployment similarities, we defined “interoperability templates” which in practice is a configuration set which relates to a certain kind of PBX and a service provider’s SIP trunk service. (It can also relate to hosted services and PBX to PBX setups.)

The user configuring the SBC is asked to insert the PBX model, service provider and SBC types into the wizard. After that, all that’s left to do is to provision a few more parameters.

AudioCodes routinely updates its interoperability templates database, which currently comprises over 60 different templates! Every time the SBC wizard is used, it connects to the AudioCodes cloud database and downloads the latest interoperability templates.

After filling in the wizard screens, an SBC configuration file is created. The file can be sent directly to the SBC from the wizard.

In some cases, the configuration will now be complete, leaving the SBC in an operational mode. In other cases, the user would already be able to send calls through the SBC, but would still need to complete the installation by configuring a few additional parameters on the device web GUI.

The end result achieved through using the SBC configuration wizard is a substantial reduction in time and complexity in configuring an AudioCodes SBC. In most cases, it takes no more than five minutes to get initial calls going.

If you, too, have felt “lost in configuration”, where finding the right knob to turn is like finding a needle in a haystack, we would like to hear about your experience and how you navigated through.