SIP fundamentals

Table of contents

1. SIP vulnerabilities
   This section discusses some of the Session Initiation Protocol (SIP) vulnerabilties that exists and the different ways that they are being regarded.
2. SIP testing
   Testing the abilities of SIP is an important part of the approval process for making it a standard. This section discusses what is being done and how.
3. SIP-based phones
   As more people implement VoIP and look at the different devices available, many are looking at what might be needed after SIP becomes a standard. This section covers basic considerations about SIP-based phones.

Session Initiation Protocol (SIP) is a signaling protocol typically used for telephony, instant messaging and Internet conferencing. It was developed by IETF in 1999. The text-based protocol is similar in many respects to HTTP and SMTP.

SIP VULNERABILITIES

Like many Internet protocols, SIP was designed with simplicity, not security, in mind. And, although H.323 was created to meet broader goals, security issues have plagued it as well. Some vulnerabilities are inherent in the protocols themselves; others have been introduced by the developers who turn these standards into products. The following are some examples:

• Plaintext SIP messages are trivial to modify or inject, particularly over broadcast media. Although SIP is not encrypted, it can be protected using IPsec, SSL/TLS or S/MIME. However, even then, some header fields like "To" and "Via" must remain visible so SIP requests can be routed correctly. Attackers can thus send spoofed INITIATE requests containing phony IP addresses. Or an attacker who captures SIP setup messages can use spoofed "BYE" requests to disrupt calls in progress.
• Researchers also discovered dozens of denial-of-service (DoS) vulnerabilities in the INVITE message processing of many SIP implementations. According to CERT Advisory CA-2003-06, "Exploitation of these vulnerabilities may result in denial-of-service conditions, service interruptions, and in some cases may allow an attacker to gain unauthorized access to the affected device."

@38837

These are just a few of the SIP Common Vulnerabilities and Exposures (CVEs) found over the past few years. To be fair, many other Internet protocols are vulnerable to spoofing or buffer overflows. But given the high availability associated with the public switched telephone network, companies moving to VoIP may be more sensitive to these threats. Furthermore, as RFC 3261 acknowledges, "SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all and its user-to-user operation make security far from trivial."

A first line of defense for IP voice networks is a Session Initiation Protocol (SIP)-enabled firewall working in conjunction with existing firewalls. "A SIP perimeter device can provide full application-layer security with authentication and protection against transport and protocol attacks," Graydon said.

SIP TESTING

SIPIT
There is a portal which lists all the SIP interoperability test events which you should definitely take a look at. These special tests take place over the course of a week, and are open to anyone that has a working type SIP product, but unfortunately not to the general public. These tests, aptly named Session Initiation Protocol Interoperability tests (SIPITS) are done with the goal of increasing the usage and functionality of SIP and its implementations. The SIPITs are held bi-yearly with different companies hosting each event. One example of tests they do is peer-to-peer tests, which focus on scenarios that require the coordination of two or three implementations. A summary of one test done at a recent conference is a multi-proxy forking. This test stresses, among other things:

• via formation (including branch) and parsing
• hop-hop non-200 final responses and ACKs
• e-e 200 final responses and ACKs
• propagation of client-initiated CANCEL

They encourage only people with endpoint implementation (including gateways) to join. In this case, any example capable of parallel forking is acceptable. Parallel forking enables a user to be called simultaneously on several SIP devices. The faint-hearted need not apply!

SipX
One product I have looked at is sipX, which is marketed as an open source enterprise PBX. The SIP-based VoIP product combines call routing using proxy servers from other products that are distributed through SIPfoundry, a Massachusetts based not-for-profit organization (founded in 2004).

The Linux-based product is a 100% SIP implementation, intended for end-users, OEMs and developers. It combines a PBX with voicemail, auto-attendant and a SIP proxy. Here is a screen print of what their GUI software looks like.

This foundation clearly illustrates the importance of the interoperability and testing of their products. As a result of these initiatives, they have established a test framework (SFTF) which allows SIP vendors to test their devices for common errors. The testing is done with the intent to improve the interoperability of these devices.

There are two parts to the framework. The first allows programmers to write their own tests for SIP devices. The second is a group of implemented tests, which use the framework to test SIP user agents for errors. They promote the standardization of SIP and the interoperability of SIP products, which is important to the future growth of SIP.

Through this project, SIPfoundry is working towards an achievable goal of ensuring that all products subscribe to certain standards that will drive the technology. Too often today, companies will give lip service to the importance of standards, testing and working together. This is definitely the case with more traditional profit-based companies. Where open source has the advantage here is that much of what is done is non-profit, so there is more of an incentive to work with one another, rather then compete for profits. That bodes well for the success of the industry moving forward.

SIP-BASED PHONES

SIP-based phones can offer various options that a non-SIP IP phone will not be able to give. For instance, SIP will enable the reuse of HTTP headers and can also set up a relative session during conversations. In many cases, it also allows more options for interoperability between equipment. With SIP, URL-dialing can be used, as well as some other enhanced features of universal messaging.

Non-SIP phones may have similar options that can be configured (check first with the manufacturer), but interoperability will likely be the biggest difference. It can be quite a savings for a global corporation to have equipment choices for each region of the globe.

The SIP technology mimics the traditional POTS network in that it works to assure that all packets travel the same paths, which can enhance the quality of the voice conversation -- unless there is a fault. This means that the re-assembly device (the phone) on the other end is likely to get the packets in order thus decreasing latency.