WebRTC Network Address
Translation
Plantrontics
345 Encinal Street
Santa Cruz
CA
95060
USA
+1 206 661-2398
cary.bran@plantronics.com
Skype
3210 Porter Drive
Palo Alto
California
US
94304
+1 831 440 8771
matthew.kaufman@skype.net
Cisco
170 West Tasman Drive
San Jose
CA
95134
USA
+1 408 421-9990
fluffy@cisco.com
Skype
3210 Porter Drive
Palo Alto
California
US
94304
jdrosen@skype.net
This document outlines the network address translation (NAT)
traversal requirements and for WebRTC client applications.
An integral part of the of the Web Real Time Communications (WebRTC)
will be the ability for client application implementations to have
native, secure Network Address Translation (NAT) traversal capabilities. This document provides
requirements and implementation specifications WebRTC client NAT
traversal.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
This section identifies the requirements for RTC-Web client
applications to connection requirements.
A majority of WebRTC clients will be web browsers and used behind a
NAT and or firewall. WebRTC clients will use a UDP-based data
transmission scheme for multimedia sessions [Open Issue: what draft
should be cited for this requirement?]. UDP has well know NAT
traversal problems and without native capabilities to traverse a NAT,
WebRTC clients will be extremely limited in their functionality.
Fortunately NAT traversal for UDP is a solved problem, but solutions
require that clients transmitting media between each other need to use
the same NAT traversal algorithms. Without a consistent, well
specified NAT traversal mechanism WebRTC client implementations would
likely be inoperable with each other. To address the identified
problems WebRTC clients are REQUIRED to implement the NAT traversal
mechanism as defined in .
Whenever a calling WebRTC client attempts to establish a
connection, the receiving WebRTC client MUST provide consent before
the calling client can transmit data to the receiver. Providing
consent on the receiving end before data transmission commence is
needed to help to prevent malicious attacks by the calling client. All
WebRTC clients are REQUIRED to implement connection management that
provides a consent mechanism for media transmission. Furthermore it is
REQUIRED that consent be given by the recipient before an WebRTC
client can transmit media.
As a note providing consent to open a media connection does not
involve user-level consent, rather it is the responsibility of the
WebRTC client application (e.g. web browser) to enforce this
requirement.
RTC-Web clients MUST support IPv4 to IPv6 transition.
There is no way to meet all the connection management requirements
and maintain compatibility with all legacy phone systems. It is highly
desirable that the WebRTC connection management mechanism be
interoperable with legacy phone systems such as a VOIP endpoints, PSTN
gateways and SIP trunks.
This section specifies the connection management system that will
address the identified requirements.
To address the NAT traversal, data transmission, and
interoperability requirements all WebRTC client applications are
REQUIRED to implement ICE . Implicit to
ICE, and listed here for clarity, WebRTC client implementations will
are also REQUIRED to implement STUN and
TURN .
Additional ICE requirements:
Support of ICE's Aggressive Nomination is REQUIRED
Support of ICE's Regular Nomination is OPTIONAL
WebRTC media gateways MAY implement ICE-Lite instead of full
ICE
Of the connection management requirements listed above, the least
obvious is how ICE will satisfy being a consent mechanism for data
transmission . The reason
ICE can satisfy this requirement is due to its reliance on STUN
transactions to succeed in order to establish a connection. The
success of a STUN transaction can be viewed as semantically the same
thing as a recipient providing consent to transmit data. Conversely
the failure of the STUN transaction would semantically map to the
recipient rejecting the request to transmit data.
This section specifies the web browser implementation requirements
for WebRTC client connection management.
To meet the WebRTC connectivity requirements, web browser vendors
MUST natively support ICE . Access to
the web browser's ICE implementation will be defined in the W3C
WebRTC-API specification .
Alternate proposals have been made that advocate for natively
exposing STUN APIs in the web
browser. The ICE implementation would be realized via a JavaScript
library that uses the browser's native STUN API. After reviewing the
alternate proposals the solution several issues were identified.
JavaScript running within "real world" web applications
cannot reliably handle the ICE timing and pacing requirements.
An example of this is long running JavaScript code from embedded
advertisers. A big JavaScript file can take a significant amount
of time to execute and can prevent web application timers from
firing in correctly. Given the pacing requirements for ICE are
in the 20ms range, it is highly likely that ICE will break if it
is implemented in a JavaScript library.
Multiple implementations of a JavaScript ICE library is a
logistical nightmare. Coordinating updates, bug fixes,
enhancements and a testing matrix for interoperability at
Internet scale will simply be impossible.
Web browsers MUST provide a mechanism to configure access to a
STUN server.
Below are some proposed mechanisms by which the STUN server could
be configured:
A preference page, similar to the what web browser's use for
configuring web proxy settings
Exposed as a JavaScript API and added to the W3C WebRTC-API
specification
Regardless of the mechanism adopted by the web browser vendor,
the following configuration data is REQUIRED to be exposed and
settable through the web browsers configuration mechanism:
STUN Server Address - the IPv4 or IPv6 address of the STUN
server
STUN Server Port
Credentials to access the STUN server (these are not STUN
generated credentials)
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
To guard against spoofing RTC-Web client applications are REQUIRED
to:
Internally encapsulate the generation of STUN transaction IDs
Block read/write access to the generated STUN transaction IDs
This draft incorporates ideas and text from the IETF mailing list. In
particularly we would like to acknowledge, and say thanks for, work we
incorporated from Timothy Terriberry and Christopher Blizzard.
WebRTC 1.0: Real-time Communication
Between Browsers
Ericsson
Voxeo
Cisco
Mozilla
The Real-Time Communications on the Web (RTC-Web) working group
is tasked with standardizing protocols for real-time
communications between Web browsers. The two major use cases for
RTC-Web technology are real-time audio and/or video calls and
direct data transfer. Unlike most conventional real-time systems
(e.g., SIP-based soft phones) RTC-Web communications are directly
controlled by some Web server, which poses new security
challenges. For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call. Unrestricted
access to such an API would allow any site which a user visited to
"bug" a user's computer, capturing any activity which passed in
front of their camera. This document defines the RTC-Web threat
model and defines an architecture which provides security within
that threat model.