No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Building a Secure SIP Network

For the most part, I love my job. I love sifting through Wireshark traces trying to find needles in SIP haystacks. I get excited learning about new IP communications products, and my heart practically skips a beat when I read about another SIP service climbing out of its physical shell and going virtual.

The best part of my job, however, is when I get to walk away from my PC, IP telephones, and LAN analyzers to meet with the users of unified communications technology. It doesn’t matter if it’s a regional user’s group or a series of one-on-one meetings with IT professionals. I love solving problems and helping people understand the technology that is near and dear to my heart.

With that in mind, today I thought I’d delve into one of the session topics I will be speaking on at the upcoming International Avaya User’s Group’s (IAUG) “Converge” conference in Denver, where I hope to help users solve the problem of securing a SIP network.

When you think about security in terms of SIP and VoIP, you need to consider four different areas:

SIP is comprised of two types of messages. The first is called the SIP Request, or SIP Method. This could be the INVITE that begins a SIP conversation, the BYE that ends one, or the REFER that moves an existing conversation from one party to another. You may be surprised to learn that for all that SIP can do, there are only 13 request types. Clearly, big things come in small packages.

The second message type is the SIP Response. This might be the “180 Ringing” response that’s generated when a telephone begins to ring, or the “200 OK” response that’s sent when that ringing phone is answered. With the exception of the ACK Method, one or more response messages is sent for every request.

To protect SIP signaling you need to encrypt it. This is no different than encrypting Web traffic for online purchases. In the case of Web messages, that’s done with HTTPS, or Secure Hypertext Transfer Protocol. With SIP, it’s called Transport Layer Security, or TLS. TLS encodes SIP Requests and SIP Responses so they cannot be understood by anyone other than the sender and recipient of the messages. While the mechanics of TLS are fairly complicated, encryption is essentially accomplished with public and private certificates. Data encrypted with a public certificate can only be decrypted with its private certificate counterpart.

In the SIP world, media is sent using something called Real-Time Protocol, or RTP, an encapsulation protocol for the data bits that make up the voice conversation. The media might be G.711, G.729, or G.722. It’s RTP’s job to get the data to where it needs to go without any concern as to what that data might be. To protect RTP, you must encrypt it. This is known as Secure Real-Time Protocol, or SRTP. SRTP ensures that if someone captures a LAN or WAN trace of your voice conversation, it cannot be played back. Only the sender and receiver of the RTP stream can decipher and listen to a conversation.

It is important to ensure that SIP messages have not been spoofed. Just because I say that I am Andrew Prokop in a SIP message doesn’t guarantee that I really am Andrew. I need to prove it.

Built into SIP is the ability to challenge messages. A challenge forces the sender to return his or her encrypted credentials. A subscriber database such as Active Directory is then queried to verify the authenticity of those credentials. This prevents a rogue SIP client from pretending to be an authorized user on your network in order to gain access to your communications resources or play havoc with existing calls.

The Session Border Controller (SBC) is the least understood component of SIP Security, but that really shouldn’t be the case. In its most simplistic sense, an SBC is a firewall for SIP. It prevents unauthorized SIP traffic from entering your network. It also performs deep packet inspection of all SIP messages to ensure that they don’t contain anything malicious.

So, why not just run SIP traffic through your data firewall? You could, but you would probably regret that decision. Firewalls are designed to work with larger, more evenly paced packets, while SBCs are designed to deal with the bursty, small-packet nature of VoIP communications. Delay and jitter will destroy a VoIP conversation, and SBCs inspect and relay SIP messages and media at near wire speed. Additionally, firewalls do not contain the specialized hardware that SBCs use for encryption, decryption, and transcoding.

I’ve addressed SBCs a number of times here on No Jitter. For a more detailed explanation of the features an enterprise SBC provides, I recommend that you take a look at The Fine Art of Choosing the Right SBC.

We take for granted the need for firewalls, virus checkers, and secure browsers for our Web activity, and it’s essential that we think along those same lines when it comes to SIP and VoIP communications. Thankfully, with the proper configuration, policies, and services, we can assure ourselves that every time we pick up a SIP telephone, start a video conference, or send an instant message, our identity has been protected and our conversation has been secured.

IAUG’s Converge conferences are one of my favorite places to meet, greet, and speak to unified communications professionals. I have been speaking at IAUG gatherings for many years and look forward to each one like a Minnesotan looks forward to the arrival of summer. Like the glutton for punishment that I am, at this year’s Converge2015, taking place June 14 to 18, I signed up to present seven different breakout sessions. (I know … what was I thinking?)

To learn more about this important topic while seeing me walk and talk in person, I invite you to attend my security presentation at Converge2015 -- Session 406, Monday, June 15 at 1:00. Tell them No Jitter sent you.

Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.

Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn