SBC for WebRTC?
In an earlier post, I talked about WebRTC going through the “SIP Cycle.” In that post, I noted that the objections raised by the “TDM Community” when SIP was introduced, are very similar to the objections raised by the “SIP Community” about the rise of WebRTC. Another aspect of the “SIP Cycle” is that SIP started as a very simple architecture that moved telephony away from the traditional “stove-pipes” of technology into a distributed architecture that relied more on intelligent endpoints. SIP then went through so many iterations, permutations and functional expansions, that eventually one of the main functions of the Session Border Controller (SBC) became enabling networks that implemented different versions of SIP to continue to exchange traffic.
This then give rise to idea that an SBC will also need to be part of WebRTC implementations as WebRTC goes through gyrations similar to those of SIP. From the 30,000 foot view, it seems likely. However, due to the complexity and multi-function nature of the SBC, I believe that this needs a bit deeper technical exploration than I can give. So I’ve invited Alex Vishnev, who has held positions such as CTO and VP of Solutions Architecture at VoIP companies, to give a more in-depth analysis of this topic. You can find Alex on twitter at @vishnev.
(BTW: Please remember to Like or Share to let me know that you have taken a look. Thanks.)
To answer the question regarding the need for an SBC in a WebRTC implementation, we need to decompose and understand the functionality of the SBC.
The SBC’s main function is twofold: (1) protect the edge of the network and (2) provide secure peering arrangements with partners/providers. The SBC is an application aware firewall that understands certain protocols and performs deep packet inspection to make sure that the payload matches information offered by single protocol or interworking multiple protocols (i.e. SIP and RTP). In the case of SIP, SBC applies strict policies to enforce validity of SIP signaling and provide SIP normalization where appropriate. Below are a few use cases for the SBC:
- Derives meaning from SIP signaling and only opens ports corresponding to the media that has been declared in SDP portion of the request.
- Protects lower transport layers (UDP and TCP) from various packet-based attacks (SYN Flood, UDP/ICMP DoS flood, Spoofing, PoD- ping of death, packet fragmentation, etc.) without slowing down underline applications to a crawl.
- Protects both signaling and media path of the SIP network.
- Protects the network from application specific DoS (SIP Registration Flood, Brute Force, Malicious Signaling, etc.).
- Used for Hosted NAT traversal allowing customers behind various firewall/NAT to establish audio/video communication with the remote.
Now, let’s review the requirements for WebRTC.
First, WebRTC clients handle NAT traversal natively by implementing ICE/STUN/TURN protocols and exchanges. A defined process of trial and acceptance of each route candidate is performed by the signaling layer. The SBC is not required for this use case.
Second, RTP media is multiplexed over a single port rather than a range of ports (i.e. SIP implementation). Firewall rules can be easily put in place to open a single UDP port and protect it with a high degree of confidence from the attacks described above. In addition WebRTC clients encrypt media with SDES/SRTP (old method) or DTLS-SRTP (new method) providing an extra layer of security. I don’t believe that placing an SBC in the path will add any additional benefits over the existing approach.
Third, WebRTC signaling is done over HTTP(S) protocol where the client uses certificate validation to make sure that the server is authentic. Implementations using self-signed certificates are more open for an attack then those using public CA. However, the possibility of the attack is no different than the one that would hit existing web servers. HTTP reverse Proxy validates incoming requests and routes authenticated requests to the application. Reverse proxy accepts and terminates HTTPS requests on the “red” interface and then forwards authenticated HTTPS requests to the “green/trusted zone”. In addition to the careful planning of your VLAN structure and system management, an enterprise can sufficiently secure an access from the “red” zone client to a “green” zone user/application. This use case does not warrant the use of SBC.
With exception of signaling adaption, I don’t see the need for an SBC in WebRTC deployments. According to the WebRTC recommendation, signaling is left up to the implementer. There are a number of incompatible signaling methods (ROAP of WS, SIP over WS, SIP, etc.). That is where I believe we need to have a network element/gateway that allows to use different WebRTC implementation within the network without resource duplication.