Skip Navigation LinksFAQ

Frequently Answered Questions.

How can a UM Labs SIP Security Platform help UC deployment?

Building a UC network, particularly when that network includes components from different vendors and where the network must support remote connections to branch offices, to SIP trunks or to remote users, is not a trivial task. The protocols that drive UC are complex and do not mix well with corporate firewalls or other Network Address Translation (NAT) gateways. To add to the challenge, SIP based UC services from different vendors may implement a different set of SIP options or may handle basic tasks like answering a call or transferring a call in a subtly different way which can introduce interoperability problems.

The range of SIP Security Platform from UM Labs is designed to simplify UC network deployment by automatically handling the complexities of establishing remote UC links and by presenting a standard set of SIP operations to each network component, easing interoperability problems.

At the core of each UM Labs SIP Security Platform is a proxy that handles all SIP traffic (phone registration, call set up etc.) and all RTP traffic (voice and video calls). These proxies work together to handle all local Network Address Translation (NAT) requirements, to manage far-end NAT traversal and to mask incompatibilities between services.

Far-end NAT traversal is the task of ensuring that a UC call can pass correctly through a remote firewall or other NAT Gateway (such as a DSL router or WiFi hotspot) even if that gateway is not under local administrative control.

It is easy to set up and run email and web services, why is UC different?

The answer is because UC applications and the protocols that drive them are considerably more complex than web or email. The core protocols that drive web and email (HTTP and SMTP) are each defined by a single RFC document with a small number of supporting documents. At last count there were over 110 RFC documents relating to SIP, one of the core protocols driving UC.

Coupled with this higher level of complexity, is the fact that SIP based UC systems do not mix well with Network Address Translation (NAT) which means that special handling is needed to get the protocols to pass through a firewall.

Also UC systems do not follow the simple client-server model that is the basis for email and web. With email and web, the relationship between a client application and the server is clear. The client, the web browser or email application, connects to a server and requests information. This model holds even when an email application is receiving a message. New inbound messages are held on the server until the client connects and checks for new messages. This model clearly will not work for UC. It makes no sense for a server to keep an incoming call on hold until the client (the user's phone) connects and checks for new calls. All main components in a UC network, phones and PBXs must be both clients and servers. While UC clients initiate new call, the responsibility of UC servers is to accept incoming calls, make the appropriate handset ring and connect the call when the user picks the phone up.

This requirement for UC components to operate as clients and servers means that we cannot follow the same implementation guidelines for UC that serve well for web and email. This is particularly important when configuring NAT gateways and security devices.

When UC services are set up and particularly when UC networks and components are interconnected, it is necessary to ensure that the core protocols operate correctly, that the lack of a simple client-server relationship between the components of the UC network is taken into account when implementing security controls and that the service can pass through any NAT gateways between those components. These steps make UC deployments considerably more complex than email or web.

Installing a UM Labs SIP Security Platform  at the network perimeter simplifies UC deployment because the SIP Security Platform  is designed to handle the additional protocol complexity and to work with applications that do not assume a simple client server model. In addition, the SIP Security Platform automatically handles NAT, including navigating calls through remote NAT gateways that are not under local control.

I thought that STUN, TURN and ICE were all that I needed, is there a better solution?

STUN, TURN and ICE are all attempts to handle the NAT and far-end NAT traversal challenges of UC. Each is a protocol in its own right, not integrated with the core UC protocols. In fact STUN and TURN are generic solutions for NAT traversal and can be used with any application.

While these protocols can be used to help with the far-end NAT traversal problem they need to be separately implemented and configured. The protocols must be implemented in multiple locations, for example in a UC gateway and in each phone that connects over a NAT link. If you have phones from different vendors you may need to support multiple protocols, while some phones support TURN others may support STUN or ICE.

If a phone configured to run one of these protocols move to a location when there is no NAT between the phone and the PBX (for example a laptop with a soft-phone is connected to the office LAN) then some care is needed to ensure that the service still works.

UM Labs believe that there is a much better solution that using STUN, TURN or ICE to run UC through NAT gateways, that solution is to do nothing!. A UM Labs SIP Security Platform installed at the network perimeter will automatically handle all NAT issues. There is no need to install and configure extra protocols, and no need for any special set up on either the phone or the PBX.

I thought that SIP was a standard, why do I need a Platform as a Service to solve the interoperability problem?

SIP is a standard, but a complex one. As described in the answer to a previous question, there are over 110 RFCs describing the SIP protocol suite. The complexity of the protocol leaves scope for different vendors to handle the same requirement in different ways. These differences are particularly common when more sophisticated services from different vendors are compared. For example Nortel's BCM range of PBXs handles call centres applications (playing a standard welcome message, queuing a call and then connecting the call to an available operator) in a specific way. While this method falls completely within the SIP standard, it is almost certainly different to the method used by Avaya, Cisco or any other vendor. These differences can trigger implementation problems.

A UM Labs SIP Security Platform can mask these problems

Which UC services will work with UM Labs' services?

The UM Labs Platform as a Service will work with any vendor with a SIP implementation that conforms to the core SIP standards.

Why do I need Security for UC and other real-time communication applications?

The short answer is that you need to secure your UC and Unified Messaging applications and network components for exactly the same reason that you need to provide security for email, web and other IP applications. UC is an IP application which runs on IP networks, in many cases on public IP networks where it is open to attack and misuse.

The slightly longer answer is that UC and many other Unified Messaging Applications are more complex than most IP applications and therefore subject to a more complex set of security threats than those other applications. For example UC and UM applications using the Session Initiation Protocol (SIP) rely on three different protocols while email and web applications use only one. Also, most IP applications are based on a simple client-server model. For example when you use a web application your web browser (a client) connects to a web browser and requests information. This simple client-server relationship is blurred in UC. These factors mean that UC and UM applications are subjected to a wider range of threats than other IP applications and that many of those threats are more complex. For these reasons effective security for UC and UM requires specialist security services that address these specific threats.

What are the security risks of running UC?

The security risks can be categorised into three groups:

  1. IP Network level threats

  2. Protocol and Application threats

  3. Content threats

The first group, IP Network level threats, includes the generic set of threats that face all IP applications.

Protocol and application threats include the set of threats that stem from vulnerabilities in, or misuse of, the protocols and applications that drive UC and UM. These are specific to those protocols and applications and include threats ranging from UC call flooding, call hijacking and call termination attacks as well as threats that exploit the personal information transferred by presence services.

Content threats directly attack the content of UC and UM applications such as audio or video streams or messages sent by an IM service. These content threats include unauthorised call monitoring, injection attacks where an audio or video stream is replaced by a stream generated by an attacker and the transfer of malicious or inappropriate content by an IM service. The consequences of unauthorised call monitoring are obvious; the confidentiality and integrity of a voice or video call is compromised. An injection attack can replace one side of a conversation with an advertising message or other audio or video stream generated by an attacker.

Is the risk of attack real?

Any IP application running on a system with network connections is open to attack. Web and email system administrators are familiar with this problem and deploy firewalls and other specialist security devices to combat the problem. UC is no different, if you connect a UC system to an IP network it is open to attack. If anything, the risk of attack and the consequences of a successful attack are greater for a UC application than for web an email. The reason for this is that UC protocols are more complex than those that drive either web or email and therefore are subject to more complex and potentially more damaging vulnerabilities than older applications.

Finally UC systems are being targeted today. More than that, potential attackers are actively scanning the Internet to identify potential targets. These scans use correctly formatted UC protocol messages to identify systems for a more concerted attack. The fact that the attacks use correctly formatted UC requests means that most security systems are powerless to stop the attacks. The attacks range from simple toll-fraud attacks (attempts to make free calls the expense of the targeted organisation) to denial of service attacks aimed at disrupting the UC or UM service.

Why should I allow external connections to my UC network?

UC and Unified Messaging are about communication. To provide effective communication services you need external connections. Those connections may be required to link remote offices, roaming users or home workers, or they may be required to allow users from outside of your organisation to make calls over the Internet. Remote connections are also required when a UC system is connected to a SIP trunk service.

Some UC networks have been installed as direct replacements for a standard phone system and are operated as isolated systems with no external connections in the belief that this approach avoids any security issues.

Firstly, this belief is not well founded, particularly if the operating organisation relies on VLAN technology to maintain this separation (see VLAN question).

Secondly, while the trend is towards Unified Messaging and the integration of voice and data applications it makes no sense to continue to operate a UC network in isolation. Finally, even if corporate policy it not to allow Voice or other real-time communications to external end-point over IP networks, users will often find a way around this policy. A good example is the growing use of Skype in corporate networks. Skype is notoriously hard to control as it is able to navigate through most firewalls. It is far better to recognise that users want services of this type and that there is measurable value to be gained from allowing UC over IP networks and to provide a fully supported and controlled service.

The bottom line is that all UC networks either have or will have links to other networks, either officially sanctioned or informal. Any network link equates to a potential security risk.

I run separate Voice and Data networks, should I be worried about security?

Unless your Voice and Data networks really are completely and physically separated, then you should ensure that an adequate level of security is in place. Complete physical separation of voice and data networks is very rare, simply running voice and data on separate VLANs does not qualify as separation (see VLAN question) . The reality is that most UC systems are linked in some way data networks. Possible points of connection include:

  1. Voice and data services using a common user database

  2. Voice and data integration for CRM systems

  3. Simple TAPI links between applications and a desktop phone to enable click-to-dial and other services

  4. Connecting a user's PC via a PC port on a UC phone

  5. Permitting the use of soft-phones for local or remote uses

  6. Running a SIP trunk connection via an Internet link

    Any link between the voice and data networks have security consequences for both voice and data services.

I use VLANs to separate my Voice and Data networks; do I need any additional security?

The blunt answer is that VLAN technology is not a security technology; it is merely a convenient method of managing traffic separation. If you separate voice and data using VLAN technology the voice and data packets flow over the same network links. Packets from different VLANs are distinguished by tags. VLAN tags are not authenticated or protected in any way. It is extremely easy to fake a VLAN tag and connect an unauthorised device to a VLAN network. Many phones include mini switches that provide a PC port and then run Voice and Data over different VLANs. In this case voice and data separation are completely at the mercy of the security of the phone. Many phones can even be configured to bridge the two networks for diagnostic purposes. There is even an application called UC hopper, readily downloadable, that automates the search for Voice VLANs and then connects the voice and data VLANs. All this means that VLANs should not be considered as a security technology. VLANS offer a good solution for managing network connections, but must be supplemented with effective security.

My ISP provides MPLS and assures me this is all the security I need, do I need more?

MPLS is a WAN protocol that it many ways serves the same purpose as VLAN technology on Local Area Networks. For similar reasons it should not be considered to be as security technology. MPLS or Multiprotocol Label Switching is sometimes used by Service Providers to enable UC traffic to be logically separated from other traffic and given priority. When used in this way, MPLS runs between the service provider and a device in the customer's network (normally a router). MPLS does not provide any additional security for traffic to the Service Provider and has no effect at all on traffic to other destinations.

A more detailed discussion on the need for security on MPLS connections can be found on the UM Labs white paper on MPLS.

I run UC through my standard firewall, does this not make me secure?

Standard firewalls cannot offer effective protection for UC applications. Worse than this, attempting to run UC through a standard firewall is likely to reduce the level of security that the firewall can then provide for other applications.

A previous question outlined the three groups of security threats that face UC applications. Standard Firewalls are designed to protect against IP Level threats. The other threat groups, Protocol & Application and Content threats, rely mostly on sending valid protocol messages which will not be blocked by a standard firewall.

Blocking Protocol and Application threats requires tracking the state of a call. This means that the security devices must understand the status of each active UC call. This status includes the identity of the caller and call recipient and the exact state the call has reached (phone ringing, phone answered, call terminated etc.) This state information is not the same as the state information processed by a stateful inspection firewall.

Effective UC security requires that state is tracked at the application level not at the IP network level. Standard Firewalls, even those described as SIP Aware do not track state at the application level and therefore cannot offer effective defences against Protocol and Application threats.

Content threats cannot be controlled with any standard firewall technology. Effective controls require a combination of the call state tracking described for controlling Protocol and Application threats, plus additional services which include authentication, encryption and content analysis.

The reason why running UC through a standard firewall may reduce the level of security that the firewall provides for other applications, is that UC applications typically use a wide range of network ports. The more calls that are processed, the more ports are used. Configuring the firewall to open the port range needed for UC may adversely impact the security controls provided for other applications.

For more information on the limitations of general purpose firewalls for securing UC, see the UM Labs technical note Firewalls and UC Security.

I use a VPN to secure remote user connections, what are the limitations to this approach?

The formal definition of a Virtual Private Network or VPN is a network in which some of the links are carried by virtual circuits in a larger network. Most VPNs also provide security by overlaying an encryption technology such as IPSec or SSL on these virtual circuits. It is assumed for the purposes of this answer that VPNs include encryption.

The main limitations of VPN technology when applied to UC are that firstly VPNs need some prior configuration before use and secondly VPNs implement a hub and spoke technology. The requirement for prior configuration means that VPNs can typically only be used to secure connections between office locations and users belonging to the same organisation. VPNs are therefore not suitable for securing links to customers or business partners or for securing connections from callers from other organisations.

VPNs connect remote users in a star, or hub and spoke technology, with a virtual link between the user and a central office location. The problem is that not all UC calls follow this topology. One of the potential benefits of UC is that media connections (the call) can be made peer-to-peer. This means that if a remote user calls another remote used from the same organisation, then the call can be connected directly between the two phones. This can offer a very efficient data path, but will bypass the VPN link that each user has established to their office.

Also standard VPN technologies are not optimised for UC. UC relies on the efficient delivery of a large number of small data packets. While VPNs can handle this type of traffic, they can introduce delays and add an overhead to the data transmission that can compromise the voice quality.

VPNs are not the optimal solution for UC. While they can be used there are better solutions for protecting UC calls with encryption and better solutions for managing connections to and from remote users. These solutions do not impose the limitations inherent in most VPN technologies.

I am using a Session Border Platform, why should I consider a UM Labs Platform as a service?

The term Session Border controller, legacy solution covers a very wide range of Platform as a Service types. It has been applied to systems ranging from carrier grade services that might be used to connect national operators down to low-end systems suitable for an office of 10 or fewer people. The term enterprise SBC is now used to differentiate carrier services from those more suitable for enterprise use.

The UM Labs Platform as a Service is designed to meet the requirements of both enterprise users and carriers. The Platform as a Service scales from a low end system supporting up to 10 concurrent active calls to larger systems linked in a resilient cluster supporting many thousands of calls.

The UM Labs SIP Security Platform places a greater emphasis on security and service enablement than most other SBC services. The goal of the UM Labs services is to interconnect UC components and networks as simply as possible while maintaining effective security controls on those interconnections.

Most Session Border Platform s has a different focus. While they also provide interconnection between networks, they achieve this with services such as protocol conversion and media transcoding which are not needed for most enterprise deployments. As many of the larger SBCs tend to be used in trusted Telco networks, they place less emphasis on security than the UM Labs services.

However the biggest difference between a SBC and a UM Labs SIP Security Platform is cost. The UM Labs Platform as a Service line has a much lower entry cost than any SBC Platform as a Service, and for larger networks UM Labs offer a very competitive alternative to a SBC.

The UM Labs Platform as a Service line is compatible with all SIP capable SBCs tested so far. A large organisation running a SBC at the hub of their network should consider running a UM Labs gateway at each of their smaller locations to protect the systems at those locations.

I am concerned about call eavesdropping, how can UM Labs help me?

All UM Labs services include encryption for both SIP signalling and RTP media. SIP signalling handles call setup and other operations such as call transfer and call termination. RTP transports the media streams, the voice call or video conference.

By encrypting both signalling and media the UM Labs SIP Security Platform  protects calls from unauthorised monitoring and eavesdropping.

UM Labs implement the recognised standards for encrypting UC calls established over the Session Initiation Protocol (SIP). SIP Signalling (call set up) traffic is encrypted using TLS. RTP media (voice or video traffic) is encrypted using SRTP. UM Labs' services support strong symmetric key encryption algorithms, up to 256 bit AES for TLS and the defined standard 128 bit or 256 bit AES algorithm for SRTP.