Session Border Controllers: Black Magic for VoIP?
Written by martyndavies on Jun 27, 2007 - 11:19 PM
Session Border Controllers are a new type of appliance that many organisations are turning to in order to help manage the growth of VoIP in enterprises. Some view the SBC as a security box, like a “firewall for VoIP”, where others see it as having generally useful functionality to support the use of SIP in all its guises. Session Initiation Protocol, SIP, is well known as the protocol that is used in all kinds of VoIP and video applications, but it also provides protocols for instant messaging and the communication of presence messages. SIP is therefore at the heart of many IM applications that people use on the desktop today, like Windows Messenger and GoogleTalk. It is also used in business-focused collaboration tools like Microsoft’s Office Communications Server (OCS) and Live Communications Server (LCS) or IBM Lotus Sametime.
The job of an SBC, then, is to sit in amongst the streams of SIP, and facilitate voice, video, IM and presence, which could mean protection against denial-of-service (DoS) attack at the SIP interface, but could equally mean just simply overcoming connectivity difficulties such as getting past NAT or firewall devices. Jeff Carr, VP of SIP Solutions for BorderWare: “the SBC market is evolving very rapidly right now. If you go back and look at the origins of the SBC, it’s somewhat of a made-up term, the notion of session border control. It comes with a range of different functions, encompassing security, peering, codec translation. An SBC right now is a definition in flux.”
Early SBCs were aimed at service providers, and with a hefty price tag attached. Service providers often require protection and management at the peering edge, i.e. the interface with other service providers. However, there is another use for SBCs, and that is at the interface with endpoints, what some companies call the access edge. Rod Hodgman, VP of Marketing of Covergence describes it like this: “There are two applications: there’s peering and there’s access edge, and one SBC can do both. Peering is about connecting a small number of well-known, trusted interfaces between partners, where as the access edge is about connecting hundreds of thousands, or potentially millions of unknown, untrusted connections from diverse endpoints.”
Jeff Carr: “The market for SBCs is evolving very rapidly based on user needs. Enterprises have much different needs from tier-one carriers, and traditional SBCs were really developed 5,6,7 years ago, and are highly specialised devices; a switch for VoIP. What enterprises need is a subset of those features, and they need something more flexible and scaleable.”
In the high-end, service provider market, SBCs are still often built with every conceivable protocol built-in, such as H.323, H.248 and MGCP as well as SIP. Companies like Acme Packet and Newport Networks have large proprietary, rack mount boxes like this that offer many protocols. Newer entrants have often decided to focus on SIP alone, since this is where a lot of investment is going, and SIP will clearly one day be dominant at the access interface. For SBCs that will only be used at the access edge, this is a logical simplification, and this illustrates one of the differences from the peering edge.
Software Meets Hardware
Long established SBC vendors tend to use a lot of proprietary hardware in their solutions. In contrast, companies like Covergence and BorderWare, prefer to use an industry-standard chassis, or in other words a PC. Obviously, PCs come in many form factors now including 1U and 2U rack-mount servers, moving up to the carrier-grade Advanced TCA (ATCA) chassis, where every slot can hold a single-board computer. This makes the SBC essentially a “software” device that can scale as required to any level of demand.
Jeff Carr: “Many traditional SBCs are based on highly proprietary hardware that they build and sell, and that approach certainly works in some segments of the market, but we offer a software-based SBC product, so it will run on a variety of hardware platforms, anything that can run Linux or Solaris, which is just about everything today.”
Covergence market a solution based on their software, hosted in an ATCA chassis, so this is also essentially a scaleable software solution. They have a range of different appliances, based on different form factors, but all essentially running the same application software.
Whither the firewall?
IT managers have for a long time looked to the firewall as being a “magic box” that solves all security needs. Firewalls have a role in securing the web, FTP, and email, and have been augmented with application layer gateway (ALGs) to tackle a whole range of different protocols. Some firewalls even have “SIP aware” functionality to help them in the VoIP environment. So why are firewalls failing in the area of VoIP, and why are SBCs needed? Jeff Carr: “The SIP protocol is much different from traditional protocols we’ve seen so far. The RTP or media side is real-time, very high density, and the way that it interacts with traditional firewalls is very different. Firewalls are typically packet-level devices, where SIP is an application layer protocol. SBCs have the application awareness to be able to understand not just what a packet is doing, but what is the application, what is the protocol doing.”
VoIP connections are made up of two components: the SIP signalling connection, and the RTP media (audio) stream itself. SIP tends to use datagrams (UDP) to transport the messages, and RTP uses UDP transport exclusively. One of the problems is that firewalls and NAT (Network Address Translation) features in many enterprise routers handle UDP badly, sometimes blocking incoming UDP entirely. An added complication is that RTP uses dynamically-allocated port numbers for the media streams, so a firewall has to know when and where to open ‘pin-holes’ to allow the datagrams through. Firewall and NAT traversal is a huge problem for VoIP systems.
The Many Hats of SBCs
If you compare SBCs, you find that while they share a core set of features, each company has its own special focus, and its own unique niche within the SBC business.
For example, BorderWare’s SIPAssure is part of a family of products that are modular in nature. If you use BorderWare tools to secure your web and your email, then security information can be shared between the components in order to identify problem domains on the Internet and block them out. Jeff Carr: “One of the tools we use is the BorderWare Security Network, which is a global IP behaviour and reputation service that can in realtime analyse content from a particular IP address or domain, and decide whether it is legitimate. We are already analysing multiple other protocols like email, web and FTP, so we’re using that data to collate and decide whether specific domains are potential senders of SPIT content.”
BorderWare also use partnerships to add value to their solutions, so for example they partner with Phil Zimmermann for Zfone, so that SIPAssure can work with encrypted audio streams coming from Zfone equipped clients. Jeff Carr: “What Zfone provides is the encryption for the media side or voice side of the SIP session. Zfone offers a much more elegant way of supporting encryption, so we adopted that into our product.” They also work with SSL experts F5, and one interesting feature of SIPAssure is its ability to offer load balancing between multiple SBCs, with proxy fail-over in the case of individual box failure.
Covergence have developed expertise in their Eclipse product in the area of enabling real-time collaboration tools. In addition to VoIP, SIP protocols are also used in instant messaging and in presence (extensions to the protocol known as SIMPLE), and Covergence have unique functionality in this area. Rod Hodgman: “We have made [Microsoft] LCS to be interoperable with IBM Sametime instant messaging and presence. Our product allows customers to make these systems interoperable and control migration over time.”
Covergence also have a Web Services-based API that allows real-time monitoring and control over SBC policy, which can integrate into the applications of companies using Service Oriented Architecture (SOA). Another specific focus is the number of qualified endpoints tested against the Eclipse; on their website you can find information on more than 75 SIP phones they have tested.
Looking around, you will find other companies that have a strong focus on lawful intercept, looking to exploit opportunities like CALEA, and call-tapping regimes across the world. Others like to position themselves as being “IMS-ready” platforms, by tracking standards evolution, such as the ETSI TISPAN recommendations.
Hocus Pocus?
Some people in the SIP research community say that SBCs are “a solution looking for a problem to solve”, and criticize SBCs for their lack of end-to-end transparency for SIP. According to the critics, the boxes often have too much ‘special sauce’, so that no two SBCs behave in exactly the same way, and in fact even the definition of what an SBC is, or what it does, are much too loose.
Jeff Carr comments: “Traditional SBCs are very monolithic devices, with a lot of special sauce to make things work. What we try to provide is a very straightforward, RFC-compliant SIP device, that allow customers to implement SIP proxies, RTP proxies and security features. Traditional SBCs are not a bad solution, but they are aimed at the problems of service providers, we’re aimed at the enterprise market where customers have different requirements.”
How do Covergence respond to the critics? Rod Hodgman: “We’re at an early stage in SIP now, it’s very very early, and it will take a while before standards to begin to provide uniformity across SBCs. To the extent that it is a problem, and I’m not sure that it is, I would say that as the industry matures that will iron itself out, and that these systems solve more problems than they theoretically create today.”
SBCs certainly solve useability problems created by NATs and Firewalls. Therefore near-end and far-end NAT traversal features are standard, Rod Hodgman describes these as “table stakes” features for SBCs. Also, most enterprises would like to think that their VoIP system has reasonable protection from a DoS attack that could disable the telephone system.
Who's Got an SBC?
For BorderWare’s SIPAssure, one example is PBX/Communications Platform vendor Mitel who have an OEM arrangement with BorderWare. Mitel have a product for hosted VoIP to enterprises called the 3600. Mitel use SIPAssure as part of the solution, integrated into the 3600 to provide security features for SIP, and Mitel’s own MiNET protocol.
Covergence just recently announced a partnership with network services company Interoute, who have just launched a federation service for users of Microsoft OCS and LCS. This allows companies with LCS or OCS to federate with other companies, to enjoy IM, presence and free VoIP calling between companies. The Eclipse SBC has a role here enabling the real-time collaboration links, as well as securing the edge of the core network.
The SBC is a much misunderstood box, and even the definition of an SBC is a living, breathing thing. But whether it’s a “VoIP firewall”, or simply the box that allows your remote workers’ phones to connect, it’s sure that we will be seeing many more of these rolled-out in the years to come.
The job of an SBC, then, is to sit in amongst the streams of SIP, and facilitate voice, video, IM and presence, which could mean protection against denial-of-service (DoS) attack at the SIP interface, but could equally mean just simply overcoming connectivity difficulties such as getting past NAT or firewall devices. Jeff Carr, VP of SIP Solutions for BorderWare: “the SBC market is evolving very rapidly right now. If you go back and look at the origins of the SBC, it’s somewhat of a made-up term, the notion of session border control. It comes with a range of different functions, encompassing security, peering, codec translation. An SBC right now is a definition in flux.”
Early SBCs were aimed at service providers, and with a hefty price tag attached. Service providers often require protection and management at the peering edge, i.e. the interface with other service providers. However, there is another use for SBCs, and that is at the interface with endpoints, what some companies call the access edge. Rod Hodgman, VP of Marketing of Covergence describes it like this: “There are two applications: there’s peering and there’s access edge, and one SBC can do both. Peering is about connecting a small number of well-known, trusted interfaces between partners, where as the access edge is about connecting hundreds of thousands, or potentially millions of unknown, untrusted connections from diverse endpoints.”
Jeff Carr: “The market for SBCs is evolving very rapidly based on user needs. Enterprises have much different needs from tier-one carriers, and traditional SBCs were really developed 5,6,7 years ago, and are highly specialised devices; a switch for VoIP. What enterprises need is a subset of those features, and they need something more flexible and scaleable.”
In the high-end, service provider market, SBCs are still often built with every conceivable protocol built-in, such as H.323, H.248 and MGCP as well as SIP. Companies like Acme Packet and Newport Networks have large proprietary, rack mount boxes like this that offer many protocols. Newer entrants have often decided to focus on SIP alone, since this is where a lot of investment is going, and SIP will clearly one day be dominant at the access interface. For SBCs that will only be used at the access edge, this is a logical simplification, and this illustrates one of the differences from the peering edge.
Software Meets Hardware
Long established SBC vendors tend to use a lot of proprietary hardware in their solutions. In contrast, companies like Covergence and BorderWare, prefer to use an industry-standard chassis, or in other words a PC. Obviously, PCs come in many form factors now including 1U and 2U rack-mount servers, moving up to the carrier-grade Advanced TCA (ATCA) chassis, where every slot can hold a single-board computer. This makes the SBC essentially a “software” device that can scale as required to any level of demand.
Jeff Carr: “Many traditional SBCs are based on highly proprietary hardware that they build and sell, and that approach certainly works in some segments of the market, but we offer a software-based SBC product, so it will run on a variety of hardware platforms, anything that can run Linux or Solaris, which is just about everything today.”
Covergence market a solution based on their software, hosted in an ATCA chassis, so this is also essentially a scaleable software solution. They have a range of different appliances, based on different form factors, but all essentially running the same application software.
Whither the firewall?
IT managers have for a long time looked to the firewall as being a “magic box” that solves all security needs. Firewalls have a role in securing the web, FTP, and email, and have been augmented with application layer gateway (ALGs) to tackle a whole range of different protocols. Some firewalls even have “SIP aware” functionality to help them in the VoIP environment. So why are firewalls failing in the area of VoIP, and why are SBCs needed? Jeff Carr: “The SIP protocol is much different from traditional protocols we’ve seen so far. The RTP or media side is real-time, very high density, and the way that it interacts with traditional firewalls is very different. Firewalls are typically packet-level devices, where SIP is an application layer protocol. SBCs have the application awareness to be able to understand not just what a packet is doing, but what is the application, what is the protocol doing.”
VoIP connections are made up of two components: the SIP signalling connection, and the RTP media (audio) stream itself. SIP tends to use datagrams (UDP) to transport the messages, and RTP uses UDP transport exclusively. One of the problems is that firewalls and NAT (Network Address Translation) features in many enterprise routers handle UDP badly, sometimes blocking incoming UDP entirely. An added complication is that RTP uses dynamically-allocated port numbers for the media streams, so a firewall has to know when and where to open ‘pin-holes’ to allow the datagrams through. Firewall and NAT traversal is a huge problem for VoIP systems.
The Many Hats of SBCs
If you compare SBCs, you find that while they share a core set of features, each company has its own special focus, and its own unique niche within the SBC business.
For example, BorderWare’s SIPAssure is part of a family of products that are modular in nature. If you use BorderWare tools to secure your web and your email, then security information can be shared between the components in order to identify problem domains on the Internet and block them out. Jeff Carr: “One of the tools we use is the BorderWare Security Network, which is a global IP behaviour and reputation service that can in realtime analyse content from a particular IP address or domain, and decide whether it is legitimate. We are already analysing multiple other protocols like email, web and FTP, so we’re using that data to collate and decide whether specific domains are potential senders of SPIT content.”
BorderWare also use partnerships to add value to their solutions, so for example they partner with Phil Zimmermann for Zfone, so that SIPAssure can work with encrypted audio streams coming from Zfone equipped clients. Jeff Carr: “What Zfone provides is the encryption for the media side or voice side of the SIP session. Zfone offers a much more elegant way of supporting encryption, so we adopted that into our product.” They also work with SSL experts F5, and one interesting feature of SIPAssure is its ability to offer load balancing between multiple SBCs, with proxy fail-over in the case of individual box failure.
Covergence have developed expertise in their Eclipse product in the area of enabling real-time collaboration tools. In addition to VoIP, SIP protocols are also used in instant messaging and in presence (extensions to the protocol known as SIMPLE), and Covergence have unique functionality in this area. Rod Hodgman: “We have made [Microsoft] LCS to be interoperable with IBM Sametime instant messaging and presence. Our product allows customers to make these systems interoperable and control migration over time.”
Covergence also have a Web Services-based API that allows real-time monitoring and control over SBC policy, which can integrate into the applications of companies using Service Oriented Architecture (SOA). Another specific focus is the number of qualified endpoints tested against the Eclipse; on their website you can find information on more than 75 SIP phones they have tested.
Looking around, you will find other companies that have a strong focus on lawful intercept, looking to exploit opportunities like CALEA, and call-tapping regimes across the world. Others like to position themselves as being “IMS-ready” platforms, by tracking standards evolution, such as the ETSI TISPAN recommendations.
Hocus Pocus?
Some people in the SIP research community say that SBCs are “a solution looking for a problem to solve”, and criticize SBCs for their lack of end-to-end transparency for SIP. According to the critics, the boxes often have too much ‘special sauce’, so that no two SBCs behave in exactly the same way, and in fact even the definition of what an SBC is, or what it does, are much too loose.
Jeff Carr comments: “Traditional SBCs are very monolithic devices, with a lot of special sauce to make things work. What we try to provide is a very straightforward, RFC-compliant SIP device, that allow customers to implement SIP proxies, RTP proxies and security features. Traditional SBCs are not a bad solution, but they are aimed at the problems of service providers, we’re aimed at the enterprise market where customers have different requirements.”
How do Covergence respond to the critics? Rod Hodgman: “We’re at an early stage in SIP now, it’s very very early, and it will take a while before standards to begin to provide uniformity across SBCs. To the extent that it is a problem, and I’m not sure that it is, I would say that as the industry matures that will iron itself out, and that these systems solve more problems than they theoretically create today.”
SBCs certainly solve useability problems created by NATs and Firewalls. Therefore near-end and far-end NAT traversal features are standard, Rod Hodgman describes these as “table stakes” features for SBCs. Also, most enterprises would like to think that their VoIP system has reasonable protection from a DoS attack that could disable the telephone system.
Who's Got an SBC?
For BorderWare’s SIPAssure, one example is PBX/Communications Platform vendor Mitel who have an OEM arrangement with BorderWare. Mitel have a product for hosted VoIP to enterprises called the 3600. Mitel use SIPAssure as part of the solution, integrated into the 3600 to provide security features for SIP, and Mitel’s own MiNET protocol.
Covergence just recently announced a partnership with network services company Interoute, who have just launched a federation service for users of Microsoft OCS and LCS. This allows companies with LCS or OCS to federate with other companies, to enjoy IM, presence and free VoIP calling between companies. The Eclipse SBC has a role here enabling the real-time collaboration links, as well as securing the edge of the core network.
The SBC is a much misunderstood box, and even the definition of an SBC is a living, breathing thing. But whether it’s a “VoIP firewall”, or simply the box that allows your remote workers’ phones to connect, it’s sure that we will be seeing many more of these rolled-out in the years to come.
Reply from aswath on Jun 28, 2007 - 03:31 PM
Reply from dean on Jun 28, 2007 - 05:40 PM
| Quote: |
| SBC could also be a natural place to do wiretapping. |
We had a demo of the SIPassure SBC from BorderWare at VoN Stockholm, and that does offer wiretapping facilities. And you're right, it's the natural place to do it.
Yes, the cost is bandwidth, and it's a factor for consideration as you point out. But it is a depreciating cost, particularly with more and more dark fibre being lit up as datacentre interconnects.
From our rack in Telehouse for example, we can route, via Linx to thousands of global IPX's free under common peering arrangements for IP traffic. If we're routing traffic to the PSTN gateway, the media has to come in to our network anyway - it makes no difference if it arrives at an SBC or arrives directly at the gateway. It's still on "our" bandwidth.
If the SBC is in a peering path and the call is SIP to SIP, then the probability is the peered party is on a network that is interconnected through an IPX peering exchange anyway, and the bandwidth cost is reduced to zero (in other words there is IP peering at Layer 1/2, and SIP peering at Layer 5).
If it's sitting in between two of our own members, then it is costing money as we could just as easily route peer to peer. That's where the bandwidth cost hits.
I would say it's only about 5% of call traffic, at the moment, that's routed inter-member peer to peer in this way.
So whilst it's a factor, at the moment it isn't a huge one for most ITSP's.
Reply from master5 on Jul 20, 2008 - 07:29 PM
Reply from BoneStorm on Nov 18, 2008 - 07:29 PM
| Quote: |
| A better way to do lawful intercept is by mangling the SDP to a media proxy only when necessary and letting it go point to point otherwise. |
That's precicely what you can't do. By law the suspects must not know that they are supervised. Tampering around with SDP connect information on a case by case basis will be recognized.
| Forum Rules and Guidelines | About VoIP User | Privacy Policy |
All logos and trademarks in this site are property of their respective owner. Comments and posts are property of the poster, all the rest (c) 2003-2008 VoIP User Limited. VoIP User Limited is incorporated in England and Wales under Company Number 6694577. No part of this site may be reproduced without our prior consent. |
