Fear, Uncertainty and Doubt. The sales man’s best friend is now in the hands of SBC marketers, trying to sell their merchandise to “fix” WebRTC.
There has been a slew of webinars, posts and podcasts lately. All of them with a single mission: telling us how great WebRTC is; while at the same time making sure we are scared shitless of it – so we go purchase an “enterprise grade” video system or an SBC. All of it comes from traditional players in the market who have decided to adopt WebRTC, but somehow twisted it to fit their current business model, architecture and product without stopping for a second to see if that’s a long term strategy.
Or maybe they did, and took the easy path towards “phase 1”, where they put something out there on the market, while working on the real version somewhere down the road. Whatever it is, I think it is pointless.
I want to mention one specific post – the vendor itself isn’t the issue here (they all do it, and if I were a marketer at such a vendor, I’d do it as well). This one is about security and SBC:
“SBC vendors like Acme Packet, Dialogic and Sonus are working toward delivering platforms that can apply policies to WebRTC session”
I am no expert about what these vendors are doing, but…
- Dialogic deals with a media server for WebRTC. This one gets used by developers to build their own service
- Acme Packet and Sonus have their SBC products – products which sit between the “browser” and the specific “web server” of the service (if we phrase it in internet terms). This won’t affect any sessions I do out of the well-kept garden of my enterprise (think Tawk.com or some other service)
You see, what I was told is that SBCs deal with protecting the VoIP servers of the enterprise – it makes sure that only those who should can access them, and along the way deals with the headaches of interoperability.
In other words – it adds security to your own service.
The issue with WebRTC and enterprises when it comes to security isn’t only that of the managed services of the enterprise, but rather of the unsanctioned ones – and WebRTC increases their number from 1 (Skype) to hundreds. SBCs won’t help there, and WebRTC is designed to be secured (which is more than I can say for other VoIP protocols used by enterprises).
The doozy in this post?
Even though WebRTC will be standards-based and will be reasonably secure, for every system that gets built, there is someone else trying to break it, Frost and Sullivan’s Brandenburg said.
True. But how is that any different than enterprise video conferencing as we know it today? It is also standardized, reasonably unsecure, and… a lot less maintained. I’d say WebRTC is a quantum leap in the security of video calling over whatever crap you use today in the enterprise.
Stop raising FUD in potential buyers. Explain what problem you really solve and make sure it is a problem your prospects actually have. Yes – there is a need for SBCs, but that need isn’t everywhere and it sure doesn’t exist for the WebRTC-only use cases.
I hear you on the FUD but SBCs can be an important part of a security strategy for many enterprises. As an example:
1. I know WebRTC doesn’t mandate signaling, but it does rely on SDP, and SDP (and other factors) is skewing implementations towards SIP.
2. So you (as an enterprise) now have SIP and you want both your LAN and Internet users (and maybe external users, B2B) to use your WebRTC services.
3. Don’t you want your SIP border to be an SBC, including a SIP B2BUA?
SBCs are by no means a single answer, nor are they the only answer, and there is plenty of FUD, but we know there are many use cases in which the SBC does make sense as part of the overall strategy.
I am missing to see the need for SBC even if WebRTC uses SIP for signaling. If the end point is using trapezoidal connection, then the receiving enterprise sees a traditional SIP connectivity and so will be using an SBC to protect itself. But then WebRTC is not in the picture. If the end point uses triangular connection, the the browser will be using the signaling procedure downloaded by the enterprise. In this case there is no need for SBC since there is nothing to protect and there is no need for protocol mediation.
Hi Aswath, good point and agree SBCs are not necessarily relevant in some use cases, such as triangular. However for trapezoidal we could have SIP signaling (carrying WebRTC SDP) and WebRTC media as you know. Maybe semantics but most would probably label those WebRTC flows (?) and those flows are SBC-relevant.
galeal,
As I stated, my gripe isn’t about SBCs being useless, but about pushing forward and FUDing everyone without really understanding if and when they are needed.
Gelal,
Probably it may be semantics. But let me submit that it is not. Tke the trapezoidal case and for the sake of discussion, let us consider just one WebRTC app. This app does not need SBC in the path towards its client for the reasons I suggested earlier. It needs one on the path to the other server, but that would be the case whether the client is connected to the second server in native mode or via WebRTC.
This is the reason I say that WebRTC does not contribute to increased need for SBC.
But there is one aspect of WebRTC that is neither addressed by the standards nor can be handled by an SBC. And it is not FUD either. Consider the scenario where an enterprise has fiduciary and regulatory requirements that all communications be recorded. Agreed that this enterprise can track all incoming sessions via a self-deployed WebRTC app. But what about sessions originated by its employees utilizing a WebRTC app deployed by a third party.
Since such a connection will utilize a triangular connection, using a signaling procedure contained in Javascript, SBC is of no help and there is no known point to track the session. So the enterprise has only two options – either block all such UDP traffic or forgo the tracking requirement. This is unsatisfactory.
What is needed is for the browser to communicate with the internal policy server and receive a port on a local TURN server and use only that in ICE procedure. Very much like SOCKS. In other words, we need to standardize on the communication between the browser and such a policy server. In my opinion, this is a gaping hole, but then no SBC will be able to do the job as it is.
Aswath: IIRC Justin Uberti mentioned that chrome will use/allow enterprise-wide configuration of TURN servers at some point. It’s somewhere on the discuss-webrtc mailing list…
Which doesn’t solve the problem of recording for regulatory reasons, but I expect enterprises to (rightfully) disallow this kind of uncontrolled traffic.
Philipp: Thanks for the info. Good to know that it is being discussed and will be included at “some point”. But it is curious that we have placed such importance for securing the communications from the end-user point of view and not so much to enterprises’ needs. I hope we also include a way for disabling encryption via configuration.
WebRTC has the potential to disrupt UC market b/c it is easy to provide “guest access”, which in turn undermines a vendor’s hegemony. So I hope we as a group pay attention to the needs of enterprises.
Well…
When I do my Skype calls, they don’t get recorded by my company – just by the NSA.
When I do calls over AT&T Connect, they probably are (or at least can be) – because that’s what the company “prescribed” for me.
When I do calls over GoToMeeting or WebEx because the other party I am dealing with insisted – where does that leave the recording component today?
If your company has no restriction then it is likely it does not have such requirement. Are you suggesting that such requirements are not there for any enterprise? What about financial institutions or some legal entities? Haven’t we read about some enterprises blocking UDP altogether for this reason? Isn’t that why Skype has included TCP 80 in its “ICE procedure”?
Well… there are those who are drafts on adding relay over TCP for WebRTC as well – which makes this whole thing irrelevant at best. Closing up the internet on employees is a hard task, with very limited rewards if any.
I think there are already well established patterns for business security and recording – which is that those communications occur within a controlled (walled) environment. I get all kinds of messages from my doctor, bank, broker that are subject to intense regulations and security, but they didn’t have to work out how to secure and record the world’s email traffic from all their employees and customers to do this – I get email notifications but have to log into a portal to see them and transact business. In the exact same way, if I am going to have a WebRTC voice/video/data session that comes under regulatory control then I will do that through a portal and server application that can secure and record all it wants to (one end of each WebRTC link is anchored somewhere). These interactions are just not going to be P2P connections between random customers and random employees that cannot be centrally managed! Nobody under regulatory constraints is going to do that. So what’s the problem?
I hope no one is really considering using SIP as the signalling protocol for WebRTC. Its the most bastardized, overloaded protocol, hardly understood protocol taken from a simple state to a state where only committee of ex-monopoly distinguished engineers appreciate it. That was my attempt at humour. But seriously with about 15 years of being rammed through the telco sausage maker the SIP protocol is hopelessly over-complicated and carrying too much un-necessary baggage.
The problem I see with SBCs and firewalls in general is that they are physical manifestations of software patches. If the software was written well in the first place and with security “built-in” we wouldn’t need as many patches and SBCs and firewalls as we currently do.
SBC as a policy enforcement device, maybe. But I hope never to have to to write another header manipulation rule kludge on a SBC to fix an interop issue with SIP.
Antonio,
I share your pain.
+1
I think you are tilting at windmills, Tsahi! “Yes, but… you will need all my stuff for real use” is an absolutely standard market-response for any and all existing vendors in any space reacting to any technology change! They cannot be stopped – since it is clearly a business survival requirement to adapt one’s products to new market conditions. You highlight SBCs but everyone will arrive – “you will need” media servers (that you mention), bridges, legacy gateways, integrated UC clients, identity systems, enterprise-appropriate development environments, integrated analytics and reporting, CRM connectors, ERP connectors, mainframe connectors, …. and on and on :)! I think the way to fight the FUD is for the WebRTC world to demonstrate all the interesting use cases where not much of this is important – by coding and shipping!