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. My heart practically skips a beat when I read about another SIP service climbing out of its physical shell and going virtual.
However, the best part of my job is when I get to walk away from my PC, phones, 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’s near and dear to my heart.
The cream of the crop comes once a year in the form of the International Avaya Users Group’s “Converge.” I have been speaking at IAUG conferences for many years now and look forward to each one like a Minnesotan waits for summer. This year, Converge2014 will be held in Dallas, Texas during the last week of April and I’ve already received the green light to present three different topics. Today I would like to spend a little time writing about one of those topics, “Building a Secure SIP Network.”
Building a Secure SIP Network
When you think about security in terms of SIP and VoIP, you need to consider four different areas. First, you want to protect the SIP signaling. Second, you need to protect the media stream. Third, you need to ensure that people are who they say there are. Lastly, you need to create a secure network edge that prevents the bad guys from sneaking into your business and compromising your VoIP network.
Let’s begin with protecting SIP signaling. 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 it, or the REFER that moves an existing conversation from one party to another. In all there are 13 SIP requests.
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.
To protect SIP signaling you need to encrypt it. This is no different than encrypting your web traffic when you purchase something online. 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 your SIP Requests and SIP Responses so they cannot be understood by anyone other than the sender or recipient of the messages.
In the SIP world, media is sent using something called Real-Time Protocol or RTP. RTP is 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.
For a deep dive into SIP challenges, please see my blog, Proving it with SIP Authentication.
Session Border Controllers
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 a 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? In theory you could, but you will probably regret that decision. SBCs are designed to deal with the bursty, small-packet nature of VoIP communications. Delay and jitter will destroy a VoIP conversation and SBCs are able to inspect and relay SIP messages and media at near wire speed. The SBC is the first line of defense for secure VoIP.
Please make sure that you read my blog articles, The SBC Placement Bible and Andrew’s Session Border Controller Checklist for more of my thoughts on session border controllers.
Please Come to Dallas
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 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 had been secured.
If you are attending Converge2014 (why wouldn’t you?) and would like to learn more about SIP security, make sure that you sign up for Session 501 with yours truly. I promise to make it worth your while.
Tao, Zen, and Tomorrow 
HI Andrew,
enjoy the conference! I would add one thing… SIP & RTP are just other IP services on a network, which means traditional means of separating and securing IP traffic are also valid; and in some cases the correct/only method as some older devices may no support SIP/TLS or SRTP. So Using VLANs, L2TP(v3)/GRE tunnels, IPSec paths and the like are also valid means and I would go further – correct methods for separation and securing communications.
Neill.
Good points although I am seeing less and less of that. VPNs and such are becoming the modern day modem when it comes to security risks. I see enterprises thinking more in terms of securing the application and its protocols and less in terms of creating a secure tunnel for anything that might be on that device.