[Paper Review] On-Demand WebRTC Tunneling in Restricted Networks

Thomas Sandholm, Boris Magnusson+1 more|arXiv (Cornell University)|Dec 23, 2013

IPv6, Mobility, Handover, Networks, Security16 references3 citations

TL;DR

This paper presents a WebRTC gateway solution that enables secure, on-demand tunneling of RTP media traffic through restrictive corporate and hospital networks using a two-hop tunnel architecture. By leveraging local gateways to handle dynamic port allocation and relaying traffic via a central public gateway over port 80, the system achieves low-latency, scalable peer-to-peer communication without requiring firewall changes or browser modifications, with only 18–20 ms overhead per concurrent stream.

ABSTRACT

In this paper we present the implementation of a WebRTC gateway service that can forward ad-hoc RTP data plane traffic from a browser on one local network to a browser on another local network. The advantage compared to the existing IETF STUN (RFC 5389), TURN (RFC 5766) and ICE (RFC 5245) protocols is that it does not require a public host and port mapping for each participating local host, and it works with more restrictive firewall policies. WebRTC implements ICE which combines STUN and TURN probes to automatically find the best connection between two peers who want to communicate. In corporate networks, simple hole punching and NAT traversal techniques typically do not work, e.g. because of symmetric NATs. Dynamic allocation of ports on an external 3rd party relay service is also typically blocked on restricted hosts. In our use case, doctors at hospitals can only access port 80 through the hospital firewall on external machines, and they need to communicate with patients who are typically behind a NAT in a local WiFi network. VPN solutions only work for staff but not between patients and staff. Our solution solves this problem by redirecting all WebRTC traffic through a gateway service on the local network that has a secure tunnel established with a public gateway. The public gateway redirects traffic from multiple concurrent streams securely between local gateway services that connect to it. The local gateways also communicate with browsers on their local network to mimic a direct browser-to-browser connection without having to change the browser runtime. We have demonstrated that this technique works well within the hospital network and arbitrary patient networks, without the need for any individual host configuration. In our evaluation we show that the latency overhead is 18-20 ms for each concurrent stream added to the same gateway service.

Motivation & Objective

• To address the challenge of WebRTC media traffic traversal in restrictive networks where only port 80 is allowed for outbound connections.
• To eliminate the need for dynamic public port allocation on external relays, which is typically blocked in corporate and hospital environments.
• To enable secure, on-demand tunneling of WebRTC RTP and RTCP traffic between browsers in isolated local networks without modifying browser runtimes.
• To evaluate the latency, session setup overhead, and scalability of the gateway solution under real-world conditions in a hospital network setting.
• To demonstrate that the solution maintains acceptable user experience even with multiple concurrent streams, with minimal performance degradation.

Proposed method

• Intercepting WebRTC JSEP signaling messages to extract SDP offers/answers and ICE candidate information during session setup.
• Deploying a local gateway (LGAT) on each local network that mimics a WebRTC peer and supports ICE/STUN protocols without browser modifications.
• Establishing lease-based UDP tunnels from local gateways to a central gateway (CGAT) over port 80, enabling secure multiplexing of multiple media streams.
• Using the central gateway to relay traffic between local gateways, enabling end-to-end communication between browsers across different networks.
• Multiplexing multiple concurrent streams over a single local gateway and central gateway connection, with dynamic session allocation and teardown.
• Leveraging SRTP encryption to ensure end-to-end security, preventing eavesdropping by the gateway infrastructure.

Experimental results

Research questions

• RQ1 Can WebRTC media traffic be reliably tunneled through restrictive firewalls that only allow outbound traffic on port 80?
• RQ2 What is the latency overhead introduced by a two-hop tunneling architecture using local and central gateways for WebRTC media streams?
• RQ3 How many concurrent WebRTC streams can a single gateway handle before the latency becomes perceptible to users?
• RQ4 Can the solution be deployed without modifying browser source code or requiring individual host configurations?
• RQ5 How does the performance of the gateway scale under concurrent stream workloads, and what is the impact on RTT and jitter?

Key findings

• The gateway introduces a consistent 18–20 ms RTT overhead per concurrent stream, which is not perceptible to users until more than 10 streams are active.
• When a concurrent stream is terminated, the RTT drops by approximately 20 ms, indicating that the overhead is directly attributable to each active stream.
• The system supports up to 10 concurrent streams per gateway before RTT exceeds 200 ms, which is considered the threshold for perceptible lag.
• Session setup overhead is acceptable, ranging from 1 to 5 seconds, with a slight performance advantage when using a local host gateway.
• The solution maintains low jitter and stable performance across multiple test configurations, including wired networks with high-end and low-end devices.
• The architecture is scalable and can be load-balanced across multiple local and central gateways, enabling deployment in large-scale environments like hospitals.