Secure VoIP telephony in unsecured networks

Posted by ittnerkn Wed, 22 Sep 2010 12:31:00 GMT

The internet has changed the world. People do not write letters any more, they write e-mails, a diary is now called a blog and this blog is written for publishing, and you are reachable all over the world via a conventional telephone network number.

You wonder how does this work? The answer is VoIP1. Most large companies already use IP telephones for the internal communication. The use of secured tunnel connections makes it possible to build worldwide telephone networks using the existing networks and the internet. Even external co-workers or home-workers can be integrated. They are reachable via a corporate phone number and on outgoing calls they make an appearance under their corporate phone number.

The implementation is not that easy as it might seem, as a few basic problems have to be solved in advance. Some of them are described in the following document.

VPN solutions need administration

The integration of external Computers into the corporate network requires administrative work on the client computer as well as on the relevant computers in the corporate network. An administrator can only guarantee the security of the network if a user can not edit the configuration of the affected computers. Therefore the use of the user's home computer is not possible. The usage of corporate hardware is necessary – this is not a very flexible solution. The security of the network is also reduced, as potential intrusion points need to be opened.

SIP and RTP are secure (sometimes)

Secure versions exist for the widely used protocols SIP2 (SIPS) and RTP3 (SRTP), but these can only be used when both/all participants support these protocols. In most of the cases you can assume that the not-secured versions are used.

Networks have borders

Consider an internal call:

The caller sends a defined message commonly known as INVITE to the callee. Besides the number and the name of the caller, this message also contains the IP address of the telephone. Information about the supported media formats is exchanged as an attachment to the INVITE message using a second protocol called SDP4. This part contains the addresses of the ports where the caller wants to receive data of a certain media type.

When the callee accepts the call, they reply with an OK message and appends their own SDP information. This is created by removing all unsupported media formats from the received SDP data and adding their own IP and port addresses.

The protocol layer does not distinguish whether the callee is an end device or a telephony server. Servers relay the SIP messages to the real recipient and thereby edit the content if necessary. This procedure does not concern the participants of the call.

If the caller is behind a firewall outside of the corporate network and tries to establish a call via the corporate server the following situation arises:

To the corporate firewall the caller is an unknown computer trying to connect to a certain computer inside the company. For this to work it is necessary, that the telephony server has a public IP address or an address translation is performed by the firewall.

From a security point of view none of these possibilities is a preferable solution as a sensitive component of the corporate infrastructure – the communication node – becomes vulnerable to attacks.

Failure by design – the SIP NAT problem

Another problem is founded in the SIP protocol itself. The messages contain the IP addresses of the source and target devices. In most cases the devices will be behind a firewall and/or router and therefore their addresses will be non public IP addresses (10.0.0.* or 192.168.*.*). Because of this, they are not reachable from the internet. Even if the telephony server is reachable through the firewall, the connection attempt will fail, as the caller sends a private IP and is not reachable by the telephony server.

Another protocol was developed to solve this issue, the STUN5-protocol. This enables devices to request its own public IP address and the used port from a STUN server on the internet. The STUN server has to be reachable directly on the internet. To circumvent spoofing attacks (pretending to have a different IP and thereby receiving packets originally addressed to someone else) the STUN server has to be trustable. As it is directly reachable over the internet it can be assumed that the server is the target of permanent attacks. This requires comprehensive measures and thereby additional administrative effort to secure the server. But still the success of a session initiation is not guaranteed as the request to the STUN server might use port X, while the outgoing SIP message is sent via port Y. To increase functional safety UDP ports have to be opened permanently which in return reduces security.

Quo vadis VoIP?

In the preceding description the following problems can be identified:

  • Integration of external devices using virtual private networks requires high administrative effort
  • To make use of the secured protocol variants capable devices are needed.
  • Usage over the internet requires the use of STUN servers and defined, opened ports. This increases effort and reduces security of the network.

Is VoIP telephony unsafe?

Yes and no. For internal use VoIP telephony can be considered sufficiently secure as the integrity and security of the data can be assured by other means.

Across networks a sufficient security of VoIP telephony can not be assured, or only with very great technical effort. VPN based solutions are inflexible as they require administration. STUN servers reduce security and increase the effort. Firewalls that can manipulate the SIP messages are available but of course having this capability increases the costs and their use usually, in that they require the binding to a specific manufacturer.

One possible solution – HOB RD VPN

None of the described variants fulfills the requirements of low administrative effort and sufficient protection of the call data and call content at the same time. Because of this HOB is developing an own SIP compatible softphone as an extension for HOB RD VPN.

Basic functions of this softphone are:

  • No local installation required. A current Java6VM on the client computer is sufficient.
  • Central configuration: the user receives the configuration automatically on application start.
  • Secured communication using TCP/SSL or UDP/SRTP independent of the capabilities of the other participant (this applies to the data transfer over the internet).
  • Communication using standard ports using components that fulfill the highest security standards.
  • No additional configuration of the firewall is necessary (depending on the active operational mode minimal changes may be required).

HOB RD VPN has the ability to flexibly extend the corporate telephony network without large effort and enables co-workers to be reachable by phone independently of their desk.

September 2010, Dipl. Ing. IT Heino Stömmer

1 VoIP: Voice Over IP – notation for the use of voice communication via IP networks
2 SIP: Session Initiation Protocol – a recommendation of the IETF for establishing sessions of any kind, not only telephone sessions
http://tools.ietf.org/html/rfc3261
3 RTP: Realtime Transport Protocol – a data exchange protocol for media data (audio/video)
http://tools.ietf.org/html/rfc1889
4 SDP: Session Description Protocol – a protocol to negotiate common formats used for data exchange
http://tools.ietf.org/search/rfc4566
5 Session Traversal Utilities for NAT – a protocol to determine the public IP address of a device which is behind a firewall
http://tools.ietf.org/html/rfc5389
6 Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

no comments |


tp://fredericdevillamil.com')) %>
Powered by typo