Service providers are relieved to rid themselves of the performance and interoperability constraints of working with extremely large hardware infrastructure in exchange for softswitch and IP network build-outs that open the door to economies of scale, flexibility and creative partnering.
Despite the advantages, service providers should consider the vulnerabilities that could offset the productivity and flexibility gains. They should think about network-to-enterprise vulnerabilities, in particular, as more and more enterprises "piggyback" on their networks through popular IP PBX and SIP trunking services.
SIP is the principle protocol in IMS that has proven itself to be valuable to enterprises and their service providers. In the last 18 months, SIP-savvy companies - usually small-to-midsized companies - have increasingly used SIP trunking to connect IP-PBXs directly to NGN/IMS networks. As operators use SIP-over-packet networks to enable real-time voice, video and multimedia services, they open the door to converged services that could leverage seamless roaming between mobile, public Wi-Fi and private networks for a wider range of services and devices. With SIP, they can also operate independently of any underlying transport protocols. For that reason, SIP has become prevalent for call control in VoIP for wireline and wireless 3G networks.
With all the advantages, it's easy to make security between the enterprise and service provider network an afterthought.
"When you think of the vulnerabilities at the border between enterprise and service provider, there are potential vulnerabilities for hackers, criminal organizations, or people looking to obtain information for free services," says Ed Elkin, director of marketing of IMS at Alcatel-Lucent. "With broadband continuing to spread and more interconnections through IP PBX or trunking services, not to mention the pervasive IP environment, there's more traffic than ever passing between enterprise customers' networks and service providers' edge equipment."
For that reason, softswitch networks, and the peer-to-peer interconnections have created a somewhat unruly Wild West atmosphere as operators move away from centrally managed networks. It's a very different environment than the days of TDM where enterprises connected media switches or gateways to service providers through a "known quantity" such as ISDN. Rather, the IP networks of today lack centrally managed security policies, protocols and technologies. What's needed is some sort of centrally located management or control over the core, access networks and clients; otherwise, it becomes challenging to manage security at the network boundary, and to manage interoperability and monitoring capabilities.
"If service providers don't consider how to secure and manage these services, they will have a tough time sustaining performance and security levels as demand grows," says Elkin, noting that already, configuration and provisioning headaches are being invoked by such problems as network avalanches or registration floods resulting from IP PBX problems. That of course can also touch off residual customer experience issues resulting from the subsequent loss of service and dissatisfaction among enterprise customers.With so much sensitive data transversing networks for financial institutions, government agencies, medical facilities and others, there should be a holistic view for security across VoIP infrastructure, IP PBX, unified communications servers, and myriads of network elements that can be associated with those services and applications. All are potentially vulnerable to outside attack, and conversely, all can pose potential threats to service provider environments as well.
The challenge for end-to-end security is that each enterprise customer procures infrastructure from multiple vendors. Adding fuel to the fire is the dearth of standards and protocols that exist, especially on the media side. With so much variability from implementation to implementation for the service provider, adjusting and normalizing for each of its enterprise customers becomes more and more challenging.
For example, a video conferencing system with H.323 signaling might have to interface with a UC server that supports SIP if there is to be optimization of service reach for a customer.
For these reasons, it would behoove both enterprises and service providers to think more about security policy and proper protections north of the enterprise and south of the service provider.
Consequently, there has been a tremendous amount of noise around IMS specifications and the equipment they spawn, such as media gateways, session border controllers (SCBs) and other IMS platforms.
SBCs: jack of all trades?
As increased security and enhanced features are necessary for VoIP networks, it is expected that activity in the SBC market will continue to heat up. SBCs deliver a set of functions that control session-based traffic, which is comprised of the signaling protocols used to setup, maintain and eventually tear down the communications, and the media, which is the actual content (voice, video, etc.). They have become one of the fastest-growing segments within the network security space, offering protection against a slew of vulnerabilities and threats through functions such as:
- Denial-of-service (DOS) attack prevention
- Admission controls (to defend against traffic overloads)
- Access controls (to defend against unauthenticated or unauthorized use)
- Fraud prevention (to defend against toll fraud, theft of service, etc.)
- Encryption and topology hiding (to prevent eavesdropping or directed attacks
- Detection and removal of worms, viruses and other malware
- Monitoring and reporting on all of these aspects.
But the risk of having all of these functions in a single network element is that ultimately there could be performance hits on the SBC. As a result, there has been substantial debate about the best strategy for deploying SBCs, and whether standalone/integrated or embedded/decomposed solutions were best.
"In talking about SBCs, you want to consider using the terminology 'standalone' versus 'embedded' rather than 'standalone' vs. 'integrated,' as the concept of an integrated SBC actually means that signaling and media controls - the two essential functions of session border controllers - are integrated into the SBC solution," explains Jonathan Zarkower, director of product marketing at Acme Packet.
In other words, some SBC solutions separate signaling and media control between two or more network elements. This approach is often called a "decomposed SBC."
Conversely, in an integrated SBC, signaling and media control functions are combined in a single element. Zarkower believes there is evidence that the integrated model offers better scalability, a more comprehensive set of functionality and greater cost savings when compared to a decomposed model, in which key functions are divided among multiple devices.
"An integrated model utilizing a purpose-built architecture and internally coordinated signaling and media is far more efficient than relying on external protocols for functional coordination and it also reduces interoperability concerns," says Zarkower.
However, others claim that there maybe advantages to a distributed approach, depending on the situation.
"With a more distributed approach, you can embed functions with other capabilities. That means the border function can go with an IMS control, or with media gateway control. So by embedding the border function with other functions, you get tight-knit synergy, where now you provide a network - instead of looking locally at just interface point," says Alcatel-Lucent's Elkin. The company considers SBC as part of its border gateway function, which addresses security, policy management and interworking among media and signaling types.
Despite the pros and the cons of embedded versus integrated, it does seem integrated SBC approaches are winning out.
"I think the market has spoken, and standalone SBCs have won," according to Zarkower. Acme Packet's Chad Hart, manager competitive and market analysis agrees, pointing to the fact that 99% of Acme Packet's customers use integrated solutions today.
Indeed, many vendors that previously offered embedded solutions are moving to an integrated model. Just recently, Sonus seemed to validate that trend, as the company announced it is moving to an integrated approach, as has Cisco and Juniper.
Some attribute the fading of embedded solution to architectural constraints. "When an embedded SBC resides within a softswitch or media gateway that utilizes a TDM bus rather than a bus designed for high-speed IP, you are locating the SBC function or feature on a blade in an element that uses it for a secondary role. That doesn't always work well," says Zarkower. This is one reason he claims why the approach of embedding a SBC in a media gateway or router is far less popular than using the standalone/integrated category of SBC.
He also thinks embedded SBCs are fading because of the additional processor cycles necessary with an embedded approach. "In a decomposed [embedded] model, you have additional processor cycles for external signaling," explains Hart. "Second, there are additional protocols that have to run on interfaces between decomposed SBC elements, notably H.248 and Diameter." That essentially meant that any time there was a signaling message to process on external interfaces, there'd be extra CPU power consumed. That issue is supposed to be mitigated in the integrated model, as functional coordination takes place within the system.
Cisco's Robert Synnestvedt, senior marketing manager for IMS, believes there is certain functionality people should look for in an SBC, including: DDOS protection, white list and black list creation, call admission control to defend against harmful traffic loads, IPSec and LS for signaling authentication and security, and SRTP for media security.
"Beyond SBC, service providers and enterprises consider the SBC just part of the security arsenal, as they see the benefits of a firewall support for the common VoIP protocols and NAT translations for private address hiding," says Synnestvedt.
In addition to choosing the type of SBC best suited to a company, it must also determine the best location. Much of the time, in an enterprise with SIP trunking, the SBC would reside at both the customer premise and service provider premise. Typically, SBCs are sold in pairs, particularly in critical environments so that if one fails there's a second to back it up. Service providers will usually have one SBC for a series of customers, and an enterprise will usually possess one SBC for each physical branch location.
"There's a risk of putting too much functionality into the SBC, but putting functionality at the edge of the network makes no sense, so you can offload routing tables and simplify the architecture with things like a SIP signaling router to simplify and lower operation expenditure," notes Vince Lech, VP of product marketing for Tekelec. "Carriers very wisely realize they need to protect the network with SBCs at the edge, but with a hodgepodge of switches they have to look at the bigger picture of the signaling layer in the network and how they can build it out over time as they move to IMS."
"Because the SBC is not a silver bullet, it guards borders of the network, but doesn't solve all SIP problems, it is important that service providers moving to NGN consider how they will evolve to IMS when looking at security issues," said Lech.