[논문 리뷰] On-Demand WebRTC Tunneling in Restricted Networks

Thomas Sandholm, Boris Magnusson외 1명|arXiv (Cornell University)|2013. 12. 23.

IPv6, Mobility, Handover, Networks, Security참고 문헌 16인용 수 3

한 줄 요약

이 논문은 제한된 기업 및 병원 네트워크에서 RTP 미디어 트래픽을 안전하고 온디맨드로 터널링할 수 있도록 하는 WebRTC 게이트웨이 솔루션을 제시한다. 이는 두 단계 터널 아키텍처를 사용하며, 로컬 게이트웨이가 동적 포트 할당을 처리하고, 중앙 공용 게이트웨이를 통해 포트 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 트래픽의 안전하고 온디맨드 터널링을 가능하게 하기 위해.
• 병원 네트워크 환경에서 실제 조건에서 게이트웨이 솔루션의 지연, 세션 설정 오버헤드 및 확장성 평가하기 위해.
• 여러 동시 스트림이 존재할 경우에도 사용자 경험을 유지할 수 있으며 성능 저하가 최소화됨을 입증하기 위해.

제안 방법

• 세션 설정 중 SDP 오퍼/어드밴스 및 ICE 캐릭터스 정보를 추출하기 위해 WebRTC JSEP 신호 메시지를 가로채기.
• 각 로컬 네트워크에 로컬 게이트웨이(LGAT)를 배치하여 브라우저 수정 없이도 ICE/STUN 프로토콜을 지원하는 WebRTC 피어를 모방하기.
• 로컬 게이트웨이에서 중앙 게이트웨이(CGAT)로 포트 80을 통해 임대 기반의 UDP 터널을 설정하여 여러 미디어 스트림의 안전한 멀티플렉싱 가능하게 하기.
• 중앙 게이트웨이를 통해 로컬 게이트웨이 간 트래픽을 중계하여 서로 다른 네트워크에 있는 브라우저 간의 엔드 투 엔드 통신을 가능하게 하기.
• 단일 로컬 게이트웨이 및 중앙 게이트웨이 연결을 통해 여러 동시 스트림을 멀티플렉싱하고, 동적 세션 할당 및 종료를 수행하기.
• SRTP 암호화를 활용하여 게이트웨이 인fra구조가 도청을 할 수 없도록 엔드 투 엔드 보안을 확보하기.

실험 결과

연구 질문

• RQ1 제한된 방화벽이 외부 트래픽을 포트 80에서만 허용하는 환경에서 WebRTC 미디어 트래픽을 신뢰성 있게 터널링할 수 있는가?
• RQ2 로컬 게이트웨이와 중앙 게이트웨이를 사용하는 두 단계 터널 아키텍처로 인해 WebRTC 미디어 스트림에 추가되는 지연은 어느 정도인가?
• RQ3 한 개의 게이트웨이에서 사용자가 감지할 수 있을 정도로 지연이 발생하기 전까지 몇 개의 동시 WebRTC 스트림을 처리할 수 있는가?
• RQ4 브라우저 소스 코드 수정 없이도 솔루션을 배포할 수 있는가? 개별 호스트 설정이 필요할까?
• RQ5 동시 스트림 워크로드 하에서 게이트웨이의 성능은 어떻게 확장되며, RTT와 잼프에 어떤 영향을 미치는가?

주요 결과

• 게이트웨이는 동시 스트림당 일관되게 18–20 ms의 RTT 오버헤드를 유발하며, 10개 이상의 스트림이 활성화될 때까지 사용자에게 감지되지 않는다.
• 동시 스트림이 종료되면 약 20 ms의 RTT 감소가 관찰되어, 오버헤드가 각 활성 스트림에 직접 기인함을 확인할 수 있다.
• RTT가 200 ms를 초과하기 전까지 게이트웨이당 최대 10개의 동시 스트림을 지원할 수 있으며, 이는 감지 가능한 지연의 임계값으로 간주된다.
• 세션 설정 오버헤드는 수용 가능한 수준이며, 1~5초 범위이며, 로컬 호스트 게이트웨이를 사용할 경우 약간의 성능 이점이 있다.
• 와이파이 및 고성능, 저성능 장치를 포함한 다양한 테스트 환경에서 저지연과 안정된 성능을 유지한다.
• 아키텍처는 확장 가능하며, 여러 로컬 및 중앙 게이트웨이 간 로드 밸런싱이 가능하여 병원과 같은 대규모 환경에 배포할 수 있다.