White Paper - SIP, Security and Session Controllers
Executive Summary
Delivering SIP services in the public network brings with it several security issues. Both users and Service Providers must understand these security issues, but the burden is with the Service Provider to offer a secure and reliable service to the user. This means they must show that the service does not compromise existing security and that the user's public presence is protected and managed. The Service Providers must also secure their own networks from outside attacks and service abuse.
This White Paper examines the SIP security issues faced by users and looks at how the Service Provider can overcome these through the deployment of Session Controllers in the access network and in the core that are SIP aware.
What problems do users face?
The Firewall - a Brick Wall
When you fire up your browser and surf the Internet from your desk at work, have you ever wondered what is going on in the network? You take it for granted that you have the freedom to access web sites, yet at the same time you expect to be kept safe from malicious attacks on your machine. The important fact that helps to keep you safe is that you requested the information from the Web. This means that the devices keeping your network safe will allow your outgoing connection to the Web server and accept the reply returning from it. This enables the Firewall to reject incoming messages that it was not expecting.
Using a SIP phone to make a call over IP means setting up two separate connections. One connection is for signalling messages, the other for the media. Naturally, these two connections are related. The clients making and receiving the call use information in the signalling connection to learn how to make the media connection. This works well when the clients are in the same network. However, the devices such as NATs and Firewalls that separate networks are unaware that these connections are related. This means an invitation in the signalling connection to send voice to a particular address will be invisible to a Firewall. The Firewall will therefore reject the incoming voice.
Figure 1 - The Firewall
Now think of making a phone call to Bill's phone who is outside your network. First, your phone sends out an invitation to Bill. This goes out through the Firewall and finds Bill's IP phone. Bill answers the call, his phone sends an acknowledgement back to your phone, which will reach you as the Firewall accepts the reply on the same port. However, when the phones send media, any Firewalls in the path will probably pass the outgoing media, but reject the incoming media. The result is the call appears to connect, but the voice path is broken.
Now think of what happens when you receive a phone call. You don't know you are going to receive the call and you don't know where it is coming from. The Firewall sees an unexpected incoming message from an unknown source so it blocks it. So, the call fails to reach you.
|
IPsec and VoIP
