Skinny/SCCP

The Skinny protocol is the casual name for a complex, lightweight VoIP protocol signaling scheme owned by Cisco Systems, Inc., and is in use for all VoIP telephones that Cisco produces. The formal name is SCCP, for Skinny Client Control Protocol, and was originally designed by the Selsius Corporation, which Cisco acquired. Skinny is a proprietary protocol that allows “skinny clients”, such as Cisco IP telephones, to communicate with each other via Cisco CallManager (CCM). The Skinny clients are small, user-friendly devices that work in conjunction with a CCM. The CCM also acts as a proxy to relay communications to H.323 clients and the PSTN.

Skinny Specifications

Skinny (SCCP) is the exclusive protocol used by Cisco brand IP telephones, as well as some phones developed by other manufacturers. Using the Skinny protocol, an IP phone will use normal TCP/IP to communicate with the Cisco CallManager. If the Cisco phone needs to communicate with a non-Skinny client, then the CCM acts as a proxy gateway, allowing the two to communicate, at which time the phones will start using UDP. However, when a Skinny phone wishes to communicate with another Skinny phone, the two will use RTP/UDP packets for communication.

Skinny Operation

The ability for Skinny clients to communicate with each other is governed by the Cisco CallManager (CCM) on the same network. When an IP phone wishes to dial another on the same network, the user takes the phone off-hook and begins dialing the necessary numbers. As the numbers are entered, they are transmitted to the CCM over TCP packets. The CCM performs a “digit analysis” to determine if they match another phone number in the database. If so, the CCM communicates with the receiving phone, causing it to start ringing and to send a ring back to the calling phone. Once the second phone goes off-hook, the CCM sends packets to both phones requesting their IP address and open UDP port on which to accept the RTP media. The CCM also checks the media capabilities of each phone to determine if they can directly communicate with each other, or if a transcoder is required to allow the communication. Once the CCM has received the connection information from each phone, it proceeds to transmit the information to the other phone, so that each phone has the connection information of its peer. At this point, the CCM creates an RTP/UDP channel for the phones to pass data through for communication. Once either of the phones goes on-hook and disconnects the line, the CCM terminates the channel. An example of this connection process is shown in Figure 1.

 
Figure 1: The Skinny Client Communication Process

Security Implications for Skinny

Similar in implications to the other protocols discussed previously, the largest problem with the Skinny (SCCP) protocol is the fact that all traffic that uses it is sent in the clear, with no encryption taking place unless the device is capable and configured to support Transport Layer Security (TLS). Ultimately, this means that people with malicious intent on the same network segment are able to capture the traffic using a network sniffer. This allows such people to store recorded conversations, or to even capture the numbers that a particular phone dials during a time period.

Note

While the SCCP/Skinny protocol was not designed for the transfer of secure data, some protocols are. Cisco CallManager 4.0 introduced Secure SCCP, or simply “Secure Skinny” to add beefier security to a Cisco VoIP network. Secure SCCP encrypts all data between IP telephones and the Cisco CallManager using TLS.

Certain Cisco CallManager versions also suffer from a known vulnerability. This vulnerability takes advantage of malformed SCCP packets sent to a vulnerable Cisco IOS (internal operating system). If successful, the exploit is able to cause devices, or the entire CCM, to reboot. The issue is documented as Cisco bug ID CSCee08584, and can be fixed by upgrading or migrating the IOS of the affected hardware.

Session Description Protocol

SDP

SDP, short for Session Description Protocol, is a simple protocol that allows clients to share information about a multimedia stream to clients wishing to connect. Further extensions on the protocol also allow clients to share their multimedia abilities with other devices. As its name denotes, it is used primarily to describe a client’s session abilities. It plays an integral part in VoIP communications to share the fact that a communication session is taking place, and to provide information to other clients so that they have the ability to join and interact with the session, such as with a group teleconference.

SDP was first described in RFC 2327 in April 1998, and the original RFC still defines the protocol’s basic abilities today. There are updates, though, to the RFC, such as RFC 3266, which adds IPv6 support to SDP. Other associated RFCs include the RTCP attribute in SDP (RFC 3605), TCP-Based Media Transport in SDP (RFC 4145) and PSTN/Internet Interworking (PINT), a set of extensions to SIP and SDP for IP Access to Telephone Call Services (RFC 2848). A fairly recent RFC, RFC 3407, allowed the clients the ability to share their multimedia abilities to other devices.

SDP Specifications

SDP is used as a specification protocol, not as an actual transport protocol (or even a session negotiation protocol, although higher-level protocols like SIP may add that capability above it). In other words, SDP does not actually transfer data between clients, it just establishes a structure for communicating the attributes for those data streams. The data must be transferred using another transport protocol, such as SAP, SIP, RTSP, or HTTP. The information contained within an SDP packet is in ASCII text, and although it was not designed for human readability, it is easy to decipher. An SDP packet is broken into multiple lines of text, where each line represents a single field and its corresponding value. Common data fields include

• v (Protocol Version)
• o (Owner of session, Session ID, Session Version, Network Type, Address type, and Owner’s IP Address)
• s (Session name)
• i (Session description)
• u (URI of subject material)
• e (E-mail address of Session Point of Contact)
• p (Phone number of Session Point of Contact)
• c (Connection information: IP version and CIDR IP address)
• e (Encryption key as clear text, base64, uri, or prompt)
• m (Media type, connection port, transport method, and format list)
• t (Session begin and end times)
• a (Attribute)

The following is an example of SDP data for supplying capabilities:

v=0
o=bsmith 2208988800 2208988800 IN IP4 68.33.152.147
s=-
e=bsmith@foo.com
c=IN IP4 20.1.25.50
t=0 0
a=recvonly
m=audio 0 RTP/AVP 0 1 101
a=rtpmap:0 PCMU/8000
a=rtpmap:1 GSM/8000
a=rtpmap:101 telephone-event/8000

SDP Operation

Once a device has been queried, usually by a client sending an SIP request, it forms an SDP packet to send back. This SDP packet supplies all of the critical information about the session capabilities that the device offers. In its simplest form, this data contains the owner information, the audio and video codecs supported, and which ports connections are accepted on. In queries for particular sessions, the reply contains the session name, the session description, connection ports, and the range of time when the session will be active. All time stamps in SDP data are formed using Network Time Protocol (NTP) values. Additionally, the session ID and session version, which must be unique values, are generally created using NTP values to signify the current date and time.

Much of the current SDP usage is documented in RFC 4317, which describes the SDP Offer/Answer model. In this model, when a client wishes to communicate with another, ittransmits an SDP offer packet. This packet is arranged in a structure similar to the following example, provided by RFC 4317:

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

Reading through this packet, you can see that the owner line describes that the packet sender is “alice” who is listening for connections on host.atlanta.example.com. his data is sent to the person with whom she wishes to communicate. Once the other person has received the data and wishes to continue the connection, an answer packet is returned. Here is an example of this answer:

v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49170 RTP/AVP 32
a=rtpmap:32 MPV/90000

In this example, Alice is initiating a connection with Bob. Alice’s Offer packet identifies that she supports three types of audio connections (PCMU, PCMIA, and iLBC), as well as two types of video connections (H.261 and MPV). Once Bob’s client has received the invitation and parsed the values, it chooses a compatible audio and video format and responds back.

Security Implications for SDP

Similar to the security issues of RSVP, much of the security implications for SDP arise due to the fact that a person can easily read session IDs and connection information off of a network segment and then tamper with existing communications. In seeing existing connection offers, and their corresponding SDP replies, an eavesdropper could use the information to determine devices that are allowing VoIP communications, and also spoof his way into an existing communication. An attacker may also be able to collect SDP offers and replay them at a later time, overriding values for ongoing communications, with the potential to disable audio feeds. However, nearly all security issues with SDP can be solved by using protocols to handle user authentication, such as SIP.

RSVP | Support Protocols

RSVP, short for the Resource ReSerVation Protocol, is a protocol designed to allow clients on networks to negotiate bandwidth to provide and maintain a high Quality of Service (QoS) for a specific connection. Normally, TCP/IP will make a best effort to route packets from one machine to another as quickly as possible. However, due to the dynamic routing of internetworking, where packets take completely different routes each time they are transmitted, this cannot be guaranteed. This creates a special issue for VoIP communication, which requires a high QoS to maintain seamless and non-interruptive communication between two people. VoIP can be an especially demanding protocol that requires long periods of high bandwidth and low latency, and without RSVP, these conditions may fall below acceptable levels which could result in a loss of quality or disconnections. RSVP allows a dedicated path across a network between each client so that packets are routed randomly around, which retains a high level of bandwidth, and less latency RSVP is especially useful for WAN connections within a global organization to maintain these set paths inside a network, as many Internet routers do not support the protocol.

The RSVP protocol was first described in RFC 2205 in late 1997. Further modifications were made to this RFC, and the best current practices for the RSVP protocol are now discussed in RFC 3936, created in late 2004. There are also other RFCs that describe additional extensions and uses for the RSVP protocol. These include RSVP for LSP Tunnels (RFC 3209) and RSVP security properties (RFC 4230).

RSVP Protocol

The RSVP protocol works by transferring UDP packets from the recipient of the data transfer to its sender. This allows the data recipient to control whether to use regular TCP/IP or to use a dedicated path of travel between the two clients. The connection recipient initiates this path by sending a constructed RSVP packet to the connection initiator. This packet will contain a specific Message Type that indicates the action that should be acted upon. The common Message Types for an RSVP protocol are

• Path
• Resv (Reservation Request)
• PathErr (Path Error)
• ResvErr (Reservation Error)
• PathTear (Path Teardown)
• ResvTear (Reservation Teardown)
• ResvConf (Reservation Confirmation)

The RSVP packet also carries a data payload containing specific information on how the path should be constructed. The payload contains information such as:

• Session (Destination IP, Tunnel ID, Extended Tunnel ID)
• Hop (the neighboring router’s IP)
• Time Values (the refresh interval)
• Explicit Route (a list of routers between the two devices that creates the data path)
• Adspec (specifies the minimum path latency, MTU, and bandwidth requirements)

RSVP Operation

To create a dedicated path of travel, the RSVP protocol relies heavily on its Path and Resv messages. The Path message packet is used to define the path of routers to be used for communication between the two clients. This packet is sent from the receiving end of the communication towards the sender. As it passes through each individual router, the router examines the packet to determine its neighboring IP addresses, to which it must route packets to. The Resv message, or Reservation request, is equally important. The Resv message is sent from each router to its neighboring router, one hop at a time. The Resv packet helps create the reservation on each router involved in the path. The transfer of Path and Resv packets is detailed in Figure 1.

 
Figure 1: Creating an RSVP Path

Once a path has been created, with each router maintaining a reservation for the data, it must be updated routinely to remain open. If a router has not received a Resv and Path packet before the refresh interval on the path has been exhausted, then the router will remove the reservation from itself. As Resv and Path packets arrive to maintain the reservation, they may also make changes to it. If the path between the clients is to change to substitute routers, the recipient just sends a new Path message with the updated path and it will become effective. Each router will continually update its stored information based on the packets it continually receives during the transmission.

Once the communication between the two devices has ended, they initiate a teardown of the path. Although, realistically they could just stop transmitting RSVP packets and eventually the reservations on the routers would expire, it is recommended that they formally tear down the path immediately after finishing the connection. The teardown may be initiated by either side of the communication, or from any of the routers within the communication. A PathTear packet may be sent downstream from the sender, or a ResvTear may be sent upstream from the receiver. As each router in the path receives a teardown packet, they will immediately remove the path reservation and forward the packet onto the next hop in the path.

Security Implications for RSVP

Many of the security issues with the RSVP protocol involve actions that a person with malicious intentions could take to either disrupt traffic or capture it. For one, as the Path and Resc packets are transmitted across the network, they each include a session ID that can be used to uniquely identify a particular RSVP session. This data is also sent as clear text, where anyone who is armed with a network sniffer can capture the data. Knowing the session ID, a person could then use the same session ID and send a Path message to one of the routers in the path. This new Path could alter the path of the network, leading the network transmission to a completely different client than intended. Or, it could be used to disrupt the communication completely, preventing an RSVP connection to take place between the two devices.

There are various solutions that have come about to resolve issues like this. For one, the Session ID could be encoded into a public key that will be included in each packet, as well as a timestamp that acts as a digital signature. If the two devices are within the same localized network, a third-party server could be used to establish the identities of each device. Many such security implications and solutions were drafted by various authors, including Hannes Tschofenig, in an Internet Draft located atwww.tschofenig.com/drafts/draft-ietf-nsis-rsvpsec-properties-06.txt.

DHCP | Support Protocols

The Dynamic Host Configuration Protocol (DHCP) is a protocol that was designed to allow network configuration of clients and workstations. Every workstation and device that is making use of a network must be assigned a unique IP address, as well as assigned a subnet mask and gateway IP address. In a network environment where there are hundreds, or thousands, of workstations, this could become an administrative nightmare. DHCP is a popular answer to this problem, automatically assigning IP addresses and other relevant configuration information to each individual device as it comes online.

DHCP is a critical support protocol in the VoIP world because it allows VoIP phones and devices to be portable from one network to another. Instead of manually configuring the device after plugging it into each network, the device simply “pings” the network to find an existing DHCP server. The device then automatically receives an IP address and network details from the server and is then immediately useable on the network, without any interaction with the user.

The DHCP protocol was first discussed in RFC 1531 and RFC 1541 in 1993. Currently, RFC 2131 describes DHCP, and has made the previous RFCs obsolete. There are many RFCs that describe additional extensions and uses for DHCP, though—for example, DHCP for IEEE 1394 (RFC 2855) and DHCP for SIP servers (RFC 3361).

DHCP Protocol

The primary function of DHCP is to supply critical network information to clients automatically, to reduce the effort of a network administrator in manually configuring various devices on a network. For DHCP to work, there must be a DHCP server (or relay) running on the network segment where clients will be connecting. The DHCP server listens constantly for incoming UDP packets on port 67, a port reserved for DHCP usage. When a new, DHCP-enabled device is connected to the network, it sends a broadcast packet to detect any running DHCP servers. The DHCP server then responds with a DHCP offer, which contains an assigned IP address.

Eight types of packets are used within the DHCP protocol:

• Discover
• Offer
• Request
• Decline
• ACK
• NAK
• Release
• Inform

DHCP Operation

When a client first joins a network, either by being plugged into the network segment or by being powered on, it does not have an IP address assigned to it. In order to request one, it sends a DHCP Discover packet across the network. It does so by sending a packet from IP address 0.0.0.0 to the broadcast IP address 255.255.255.255, which allows the packet to reach every single device on the network segment. This packet may include information about the client itself, such as the network interface’s MAC address and the computer’s designated host name.

Once a server has received a DHCP Discover packet, it immediately checks its preset range (scope) of IP addresses to determine the next available number. Optionally, the DHCP server will also compare the requestor’s MAC address against a local table to determine if the client is allowed to receive an IP address. After an address has been chosen, a DHCP Offer packet is transmitted back to the requesting client, targeted by its MAC address. This packet includes the assigned IP address, the lease time of the IP address, subnet mask, gateway address, and chosen DNS servers, as well as other network information that is to be implemented into the client.

Once the client has received a DHCP Offer packet, it responds with a DHCP Request packet. This packet is similar to the original DHCP Discover packet in that it is sent from 0.0.0.0 to 255.255.255.255. This packet serves to notify the server that the client has accepted the assigned IP address, and also notifies all other clients on the network segment that the assigned IP address has been taken. Finally, the server responds back to the client with a DHCP Acknowledgement (ACK) to confirm the address has Request has been received. This communication between the client and DHCP server is detailed in Figure 1.

  
Figure 1: The DHCP Process

Security Implications for DHCP

A variety of security concerns come into play whenever DHCP is enabled on a network segment. These security issues don’t deal so much with leaked data such as passwords. Instead, they focus more on access into a network from unauthorized clients. A basic DHCP server runs under the assumption that any DHCP Discover and Request should be honored as an authorized client. In this setup, any device that requests network information will be able to receive it, no questions asked. However, this opens the door for any person with physical access to the network to be able to plug in unauthorized devices and receive network access.

A number of ways exist to reduce this network exposure, from modifying the network switches to modifying the DHCP configuration. Most of these security implementations involve verifying the MAC address of the client device before allowing it to receive an IP address. One of the more extensive fixes is to enable port security on the implemented network switches. With port security in place, the physical connection port can be locked to allow only a single MAC address access through it. This can help prevent employees, or contractors, from installing a small network hub or wireless router, and giving multiple devices access to the network.

However, an easier method is to provide DHCP addresses just to devices that have a particular MAC address assigned to them. All network devices have a MAC address coded into them, and these addresses follow a set structure. The first six bytes of the MAC address specifies the vendor ID, or the company that manufactured the device. If you wish to restrict DHCP to just particular VoIP phones or devices on your network, this is possible by identifying the vendor ID on the devices and configuring the DHCP server to provide addresses only to devices that have the same vendor ID. For example, Grandstream Networks VoIP phones all have a vendor ID of 00:0B:82.

Another security issue that can arise with DHCP is coupled with TFTP, and the security risks associated with it. If a network uses a TFTP server to transmit bootable disk images to computers, much of the configuration material to specify where these particular disk images are located is located within the DHCP responses. When clients receive a DHCP offer, they can choose to take advantage of this information, depending on their boot states. However, a malicious user could monitor these packets to determine the location of any TFTP servers, as well as the particular files used on these servers.

Tip

To ease the installation of IP telephones, create a separate scope of IP addresses with a MAC filter to only allow IP telephones to lease an address. Collect the unique vendor IDs from the authorized telephones to create this filter.

SNMP | Support Protocols

SNMP, short for Simple Network Management Protocol, is a high-level protocol and architecture that allows for the monitoring and maintenance of network devices to detect problems, and to fine-tune the network for performance. There are two key versions of SNMP in use today, SNMPv1 and SNMPv2. While the two share many commonalities, there are some very beneficial additions made to SNMPv2. However, as many people disagreed with the security profiles implemented into SNMPv2, it has remained less popular and less used than SNMPv1. Since that time, a newer version of SNMP was released: the Community-Based SNMP, or SNMPv2c. However, the current standard, adopted in 2004, is SNMPv3. SNMP plays a useful role in maintaining and administering VoIP networks by allowing a person the ability to easily monitor the bandwidth and performance of all the major components of a network.

The SNMP protocol is defined under RFC 1157 as SNMPv1, and the characteristics of its immediate successor, SNMPv2, are defined in RFC 1902. SNMPv2c is officially detailed in RFC 1901 and in RFC 1908. SNMPv3 is defined in RFC 3411 and RFC 3418.

SNMP Architecture

An SNMP implementation on a network involves three components to be integrated: the devices to be managed, agents, and Network Management Systems (NMSes). The devices to be managed are simply computers or devices on the network that reside on the network. These are the devices that an administrator would like to monitor on the network. Each device must have an agent installed on them, which is a software application that continually monitors the device for predefined events or errors and transmits them to a centralized management server, an NMS. The NMS collects all of the data that is routinely transferred from the various network devices and correlates it into useful information for an administrator to read and evaluate.

However, even with all of these components working together on a network, there still must be a structure to all of the individual data that can be gathered across a network by an NMS. This is implemented by the use of a Management Information Base (MIB). See Figure 1 for a diagram on how these components work together.

 
Figure 1: SNMP Network Components

SNMP Operation

The SNMP protocol works under a very simplified model of data collection and control of the managed devices. Only a few basic commands are used in the SNMP protocol, such as GETKEQUEST, GETNEXTREQUEST, SETREQUEST, and TRAP. An NMS invokes GETREQUEST to collect data from a device, and GETNEXTREQUEST to retrieve the next value in a set. An NMS can also invoke the SETREQUEST command to save data to a managed device. The TRAP command is the only one not initiated by the NMS; it is sent out by the client to report any unusual activity it has detected.

On the client side, the Management Information Base (MIB) acts as a tree that catalogs all of the various data components of the system or device. Each of these data components are known by their object identifiers (OIDs). The OID is made up of multiple sets of numbers, each separated by a period, in a structured order similar to that of an IP address. As a general rule, all OIDs begin with .1.3.6.1.2.1, except on many Cisco devices which use .1.3.6.1.4.1.9. To request a data value, an established OID must be specified. For example, to request the system up time, OID .1.3.6.1.2.1.1.2 is read.

SNMP Architecture

The SNMP protocol has many areas that require careful attention and configuration simply due to the amount of information that could be leaked out to malicious users. Since all of this data is retrievable by anyone requesting it, there must be some safeguards put in place to prevent unauthorized users from being able to read data, or modify it. This is performed by the use of a community string. A community string acts as a password to group data into either read-only or read-write areas. By default, most software is setup to use a default community string of “public” for their read-only data. Likewise, many implementations use a default community string of “private” for their read-write data. It is particularly dangerous to leave such community strings in place, as they are well known to malicious users, and an unchanged read-write community string allows an attacker the ability to modify critical data on a device.

---

Are You Owned?—Are You Allowing Sensitive Data to Be Leaked?

Due to the open nature of SNMP, allowing any person to easily request data, unique community strings should be defined for network components that you can administer. Proper care must also be taken in evaluating IP telephones to ensure that they do not have unsecured SNMP access available. Otherwise, all of your SNMP-enabled components, such as workstations, servers, routers, and phones, can disclose sensitive information to anyone who asks. Unless you are constantly monitoring network traffic, you may not even know that this information is being gathered by malicious people within your network environment—or, even worse, being modified to cover unauthorized actions.

This issue came to light recently when it was discovered that the Cisco 7920 Wireless IP Phone contained a fixed community string that allowed malicious users to gather and modify data on the devices. The vulnerability and its fix were given a Cisco bug ID of CSCsb75186. They can also be reviewed at http://securitytracker.com/id?1015232.

Likewise, similar SNMP vulnerabilities surfaced with the Hitachi IP5000 phone. These devices did not have a protected community string, which meant that any person could have full SNMP access to all of the data on the device, including the ability to alter and erase it.

On a lesser scale, the UTstarcom F1000 IP phone featured the default public community string, which allowed anyone to view data stored on the phone, some of which could be considered sensitive. Additionally, when using SNMP scanning software, the phone suffered from numerous SNMP issues that required a full reboot to fix.