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
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
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
I thought that STUN, TURN and ICE were all that I needed, is there a
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
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
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
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
Why do I need
Security for UC and other real-time communication applications?
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.
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:
IP Network level
first group, IP Network level threats, includes the generic set of threats that
face all IP applications.
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
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
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.
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?
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.
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.
this belief is not well founded, particularly if the operating organisation
relies on VLAN technology to maintain this separation (see VLAN question).
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
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?
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:
Voice and data
services using a common user database
Voice and data
integration for CRM systems
Simple TAPI links
between applications and a desktop phone to enable click-to-dial and other
Connecting a user's
PC via a PC port on a UC phone
Permitting the use
of soft-phones for local or remote uses
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
I use VLANs to
separate my Voice and Data networks; do I need any additional security?
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?
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.
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?
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.
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
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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
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.
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.
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.
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.
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?
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
encrypting both signalling and media the UM Labs SIP Security Platform protects calls from unauthorised monitoring
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.