[论文解读] On-Demand WebRTC Tunneling in Restricted Networks

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

IPv6, Mobility, Handover, Networks, Security参考文献 16被引用 3

一句话总结

本文提出了一种WebRTC网关解决方案，通过双跳隧道架构，在仅允许出站连接的端口80的限制性企业及医院网络中，实现安全的按需RTP媒体流量隧道传输。通过本地网关处理动态端口分配，并利用中央公共网关通过端口80中继流量，该系统在无需更改防火墙配置或浏览器设置的情况下，实现了低延迟、可扩展的点对点通信，每路并发流仅增加18–20 ms开销。

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.

研究动机与目标

• 解决在仅允许通过端口80进行出站连接的限制性网络中WebRTC媒体流量穿越的问题。
• 消除对外部中继服务器动态公网端口分配的需求，该需求通常在企业及医院环境中被阻止。
• 在不修改浏览器运行时环境的前提下，实现隔离本地网络中浏览器之间WebRTC RTP和RTCP流量的安全、按需隧道传输。
• 在医院网络环境中，评估网关解决方案在真实条件下的延迟、会话建立开销及可扩展性。
• 证明即使存在多路并发流，该解决方案仍能保持可接受的用户体验，性能下降微乎其微。

提出的方法

• 拦截WebRTC JSEP信令消息，以在会话建立期间提取SDP Offer/Answer及ICE候选信息。
• 在每个本地网络中部署本地网关（LGAT），其模拟WebRTC对等方并支持ICE/STUN协议，无需浏览器修改。
• 通过端口80从本地网关到中央网关（CGAT）建立基于租约的UDP隧道，实现多个媒体流的安全多路复用。
• 利用中央网关在本地网关之间中继流量，实现跨不同网络的浏览器之间的端到端通信。
• 在单个本地网关与中央网关连接上多路复用多个并发流，支持动态会话分配与终止。
• 利用SRTP加密确保端到端安全性，防止网关基础设施窃听。

实验结果

研究问题

• RQ1 是否能够通过仅允许端口80出站的限制性防火墙，可靠地隧道传输WebRTC媒体流量？
• RQ2 使用本地网关和中央网关的双跳隧道架构，为WebRTC媒体流引入的延迟开销是多少？
• RQ3 单个网关在延迟变得对用户可感知之前，能够支持多少路并发WebRTC流？
• RQ4 该解决方案是否可在不修改浏览器源代码或无需单独主机配置的情况下部署？
• RQ5 在并发流工作负载下，网关的性能如何扩展，对RTT和抖动有何影响？

主要发现

• 每路并发流，网关引入了恒定的18–20 ms RTT开销，当并发流超过10路时，用户才可能察觉到延迟。
• 当某路并发流终止时，RTT约下降20 ms，表明该开销可直接归因于每条活跃流。
• 在RTT超过200 ms（被认为是可感知延迟的阈值）之前，单个网关最多可支持10路并发流。
• 会话建立开销可接受，范围为1至5秒，使用本地主机网关时略有性能优势。
• 该解决方案在多种测试配置下均保持低抖动和稳定性能，包括使用高端和低端设备的有线网络。
• 该架构具有可扩展性，可跨多个本地网关和中央网关进行负载均衡，适用于医院等大规模环境的部署。