[論文レビュー] 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

ひとこと要約

本論文では、ポート80での出力接続のみを許可する制限的な企業および病院ネットワークにおいて、2ホップトンネルアーキテクチャを用いて、RTPメディアトラフィックを安全かつオンデマンドでトンネリングするWebRTCゲートウェイソリューションを提示する。ローカルゲートウェイを活用して動的ポート割り当てを処理し、中央公開ゲートウェイを介してポート80でトラフィックをリレーギャンブルする仕組みにより、ファイアウォールの変更やブラウザの変更なしに、低遅延かつスケーラブルなピアツーピア通信を実現し、同時に処理されるストリーム1本あたり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トラフィックの安全かつオンデマンドのトンネリングを可能にすること。
• 病院ネットワーク環境という現実の条件下で、ゲートウェイソリューションの遅延、セッションセットアップオーバーヘッド、スケーラビリティを評価すること。
• 複数の同時ストリームが存在する状況下でも、ユーザー体験が許容範囲内を保ち、パフォーマンス劣化が最小限に抑えられることを実証すること。

提案手法

• セッションセットアップ中にSDPのオファー/アンサーおよびICE候補情報を抽出するため、WebRTC JSEPシグナリングメッセージをインターセプトすること。
• 各ローカルネットワークに、ブラウザの変更なしにICE/STUNプロトコルをサポートするWebRTCピアを模倣するローカルゲートウェイ（LGAT）をデプロイすること。
• ローカルゲートウェイから中央ゲートウェイ（CGAT）への、ポート80を介したリースベースのUDPトンネルを確立し、複数のメディアストリームのセキュアなマルチプレクシングを可能にすること。
• 中央ゲートウェイを介してローカルゲートウェイ間のトラフィックをリレーギャンブルし、異なるネットワークに存在するブラウザ間のエンドツーエンド通信を実現すること。
• 1つのローカルゲートウェイおよび中央ゲートウェイ接続上に複数の同時ストリームをマルチプレクシングし、動的セッションの割り当てと終了を管理すること。
• SRTP暗号化を活用してエンドツーエンドのセキュリティを確保し、ゲートウェイインfraストラクチャによる盗聴を防止すること。

実験結果

リサーチクエスチョン

• RQ1 出力接続がポート80でのみ許可される制限的なファイアウォールを通過するWebRTCメディアトラフィックを、信頼性を持ってトンネリングできるか？
• RQ2 ローカルゲートウェイと中央ゲートウェイを用いた2ホップトンネリングアーキテクチャが、WebRTCメディアストリームに導入する遅延オーバーヘッドはどの程度か？
• RQ3 1つのゲートウェイが、ユーザーに感知可能な遅延が生じるようになるまで、同時に処理できるWebRTCストリームは最大何本までか？
• RQ4 ブラウザのソースコードの変更なしに、個別のホスト設定の要件なしに、このソリューションをデプロイできるか？
• RQ5 複数ストリームの同時処理負荷下でのゲートウェイのパフォーマンスはどのようになるか？RTTおよびジッタにどのような影響を与えるか？

主な発見

• ゲートウェイは、同時に処理されるストリーム1本あたり、一貫して18–20 msのRTTオーバーヘッドを発生させる。これは、10本を超えるストリームがアクティブになるとユーザーに感知され始める。
• 同時に処理されるストリームが終了すると、RTTは約20 ms低下するため、オーバーヘッドが各アクティブストリームに直接起因していることが示された。
• 1つのゲートウェイが10本の同時ストリームまで処理できるが、RTTが200 msを超えると、ユーザーに感知可能な遅延と見なされる。
• セッションセットアップのオーバーヘッドは許容範囲内であり、1〜5秒の範囲に収まり、ローカルホストゲートウェイを使用する場合にわずかなパフォーマンス優位性が得られた。
• ワイヤレスネットワークを含む、ハイエンドおよびローエンドデバイスを用いた複数のテスト設定において、ジッタが低く安定したパフォーマンスを維持した。
• アーキテクチャはスケーラブルであり、複数のローカルおよび中央ゲートウェイに負荷分散できるため、病院のような大規模環境への展開が可能である。