The Curious Case of Skinny: Our Implementation of SCCP
by Tim WalkerBy Tim Walker
In a recent Application and Threat Intelligence (ATI) update, we added emulation of Cisco’s proprietary Skinny Call Control Protocol (SCCP) [PDF link] to the portfolio of 130+ protocols supported by the BreakingPoint Storm CTM. Last week I had a chance to talk with BreakingPoint CTO Dennis Cox as well as Frank Gifford, our engineer who did the hands-on work with SCCP, to talk about what went into adding this complex protocol.
Why We Added SCCP
The main reason is that Cisco itself needed SCCP emulation added to the BreakingPoint Storm CTM. Even though they developed the protocol, they needed our help to validate it on their equipment.
But here’s where things took a curious turn. Cisco is famous for promoting open standards in networking protocols. Searching the IETF database for mentions of “Cisco” in RFCs yields 825 results, which reflects how much work Cisco and its engineers put into these standards. But unlike the hundreds of open protocols that Cisco has promoted, SCCP remains closed.
We have no idea why SCCP is the odd duck; maybe a lawyer at Cisco decided to block it. In any event, we had to reverse-engineer the protocol without the benefit of a spec. Fortunately, that’s something we’re good at.
What SCCP Does
According to Cox, Skinny is a “very complex” VoIP protocol with “lots of little objects” in it, which enable many features related to messaging, conference calling, notifications, and so on. It uses Real-time Transport Protocol (RTP) over User Datagram Protocol (UDP) for audio, and essentially functions as Cisco’s proprietary equivalent to Session Initiation Protocol (SIP).
The protocol was born at the startup Selsius in the late 1990s, and became part of the Cisco product line when Cisco acquired that company in 1998. Since then it has been through many iterations—and, apparently, has been built by many different hands. Cox and Gifford agreed that inconsistencies in the structure of the protocol give the impression that SCCP has been “grown, not made.” When he was implementing it, for example, Gifford discovered wide differences in the formats for packet headers related to different actions. As Cox put it, “To a newcomer just encountering the protocol, its structure doesn’t make sense.”
What It Was Like to Implement SCCP
In a word: complicated. According to Cox, SCCP is probably the second most-detailed protocol BreakingPoint has ever implemented, after the Common Internet File System (CIFS). It has 133 different actions, which point to many different file types. Cox contrasted it to a straightforward protocol like Hypertext Transfer Protocol (HTTP), which has only 9 actions, most of which point at the Uniform Resource Identifier (URI).
Since we want our simulation to reflect the real-world conditions that SCCP network operators will face, Gifford went through each of the 133 actions, sorting out all the picky details. (Along the way, he found some interesting vulnerabilities in the protocol. Look for more on that in a future post.)
Who Benefits from Our SCCP Emulation
The first beneficiary is Cisco, which can use our SCCP functionality to validate and improve its own products as they are being engineered. Beyond that, the protocol will benefit anyone who uses SCCP-based VoIP systems within their corporate networks.
Accurate simulation of complex telephony protocols is important now, and it will only get more important in the future, considering how much enterprise bandwidth is being eaten up by telephony and especially telepresence. Enterprises cannot afford to let their infrastructures be overwhelmed by these growing demands, which means they need realistic simulations to validate their networks, data centers, and the devices within them. Since doing this will only get more demanding over time, we’ll keep on adding protocols, simple or complex, to keep up with the challenge. Even when we have to reverse-engineer them.
If you have questions or thoughts on our SCCP implementation, please leave them in the comments below.
blog comments powered by Disqus
