WebRTC gateway

Implementation and Evaluation of Security
on a Gateway for Web-based Real-Time
Communication
Tuukka Koistinen
Ericsson
Supervisor: Prof. Jörg Ott
Advisor: M.Sc. Tuomas Erke
22.5.2014
Agenda
•
•
•
•
•
•
Introduction
WebRTC Architecture
Objectives and Scope
Implementation
Measurements
Conclusions
2
Introduction
3
Introduction
• WebRTC: Web-based Real-Time Communication
– Joined effort to bring real-time communication to browsers
4
Introduction
• WebRTC: Web-based Real-Time Communication
– Joined effort to bring real-time communication to browsers
5
Introduction
• WebRTC standardization ongoing
– WebRTC working group at W3C: browser interface
– RTCWEB working group at IETF: media plane protocols
W3C – World Wide Web Consortium
IETF – Internet Engineering Task Force
6
WebRTC Architecture
7
WebRTC Architecture
• Signaling through centralized server(s)
• Peer-to-peer multimedia communication
8
SRTP – Secure Real-time Transmission Protocol
UDP – User Datagram Protocol
HTTP – Hypertext Transfer Protocol
WebRTC Architecture
• Signaling:
–
–
–
–
Session Description Protocol (SDP) for session details
Offer/Answer model to exchange SDP
Call signaling protocol up to service providers (SIP, XMPP, ...)
JavaScript for browser API
• Media path:
– Secure Real-Time Transmission Protocol (SRTP) for media
– Datagram Transport Layer Security (DTLS) for encryption key
management and binary data security
– Interactive Connectivity Establishment (ICE) to traverse through
Network Address Translators (NAT)
9
SIP – Session Initiation Protocol
XMPP – Extensible Messaging and Presence Protocol
API – Application Programming Interface
Objectives and Scope
10
Objectives and Scope
• Initial setup: Existing gateway prototype to connect
WebRTC with IP Multimedia Subsystem (IMS)
– Missing/incomplete security functionalities
• Goal: Implement required features
– DTLS, SRTP, ICE
• Evaluation: Measure performance
– Processing load, packet delay
– Estimate maximum number of calls
11
Implementation
12
Implementation
• Prototype setup
– Focus on the media plane node Media Relay
13
WCG – Web Communication Gateway
STUN – Session Traversal Utilities for NAT
REST – Representational State Transfer
Implementation
• ICE
– Supported, but incomplete
– Establish connection through NATs
– Uses Session Traversal Utilities for NAT (STUN)
• DTLS
– libedtls
– Create DTLS connection
– Derive keying material for SRTP stack
• SRTP
– libesrtp
– SRTP encryption/decryption
14
Measurements
15
Measurement Test Setup
• Browser-to-browser WebRTC calls
• Single Media Relay
– Media goes through twice
16
RX – Receiver
TX – Transmitter
SDS – Service Development Studio
Measurement Results
• Call types:
Name
Encryption Audio
format
Video
format
Video size Browser
A-RTP
No
PCMU
-
-
Leif
SD-RTP
No
PCMU
H.264
800x600
Leif
A-SRTP
Yes
Opus
-
-
Chrome
SD-SRTP
Yes
Opus
VP8
800x600
Chrome
HD-SRTP
Yes
Opus
VP8
1280x700
Chrome
• Leif: modified Chromium browser to test the early
prototype
– No DTSL-SRTP, H.264 video codec
17
Measurement Results
• Traffic in the interfaces, kilobytes per second
RX – Receiver
TX – Transmitter
18
Measurement Results
• Processing load of the Media Relay process
19
Measurement Results
• 10 HD video calls, CPU load as a function of total traffic
20
Measurement Results
• 10 audio calls, CPU load as a function of total traffic
21
Measurement Results
• Estimated maximum number of calls:
– Maximum bitrate / total traffic generated the call type
• Three estimates based on different traffic values
– Median: CPU load to 100% with median bitrates
– 3rd Quartile: Leaves a margin for variance
– Max: ”Safe” estimate, 100% only when all calls on max bitrates
Call
Median
3rd Quartile
Max.
A-SRTP
75
74
69
SD-SRTP
49
34
19
HD-SRTP
17
14
12
• Median delay at Media Relay stayed practically the
same (~ 0.15 ms)
22
Conclusions
23
Conclusions
• WebRTC functionality was investigated from a gateway
perspective
• Necessary security functions were implemented to the
existing WebRTC gateway prototype
• The WebRTC gateway successfully proved to work with
Chrome and Firefox
• Reasonably good performance for a prototype system,
both in terms of CPU load and delay
• Future work already ongoing: Transcoding, Traversal
Using Relays around NAT (TURN), ...
24
Questions?
25

Download Report