One document matched: draft-cbran-rtcweb-nat-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cbran-rtcweb-nat-01"
ipr="noDerivativesTrust200902">
<front>
<title abbrev="Abbreviated-Title">RTC-Web Network Address
Translation</title>
<author fullname="Cary Bran" initials="C." surname="Bran">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 206 256-3502</phone>
<email>cbran@cisco.com</email>
</address>
</author>
<author fullname="Matthew Kaufman" initials="M.K." surname="Kaufman">
<organization>Skype</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<region>California</region>
<country>US</country>
<code>94304</code>
</postal>
<phone>+1 831 440 8771</phone>
<email>matthew.kaufman@skype.net</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>Skype</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<city>Palo Alto</city>
<region>California</region>
<country>US</country>
<code>94304</code>
</postal>
<email>jdrosen@skype.net</email>
</address>
</author>
<date day="6" month="September" year="2011" />
<abstract>
<t>This document outlines the network address translation (NAT)
mechanisms and requirements for RTC-Web client applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An integral part of the success and adoption of the Real-Time
Communications Web (RTC-WEB) will be the ability for RTC-Web
applications to have native, secure Network Address Translation (NAT)
traversal capabilities. This specification proposes NAT traversal
requirements and implementation specification for RTC-Web client
applications.</t>
<t>The NAT requirements fit into a series of specifications have been
created to address RTC-Web codec, security, data transmission, non-media
data, signaling and negotiation and use case requirements. More
information on the RTC-Web can be found here:</t>
<t>[TODO put links to supporting drafts here]</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Connection Management Requirements">
<t>It is quite probable that many RTC-WEB client applications, such as
web browsers will be deployed behind a NAT. To set up secure data plane
sessions, all RTC-WEB client application implementations are REQUIRED to
implement ICE <xref target="RFC5245"></xref> or ICE-Lite Section 2.7 of
<xref target="RFC5245"></xref>. Implicit to supporting ICE, all RTC-WEB
client applications are REQUIRED to implement Simple Traversal of User
Datagram Protocol (UDP) Through Network Address Translators (NATs)
(STUN) <xref target="RFC3489"></xref> and Traversal Using Relays around
NAT (TURN) <xref target="RFC5766"></xref>.</t>
<t>There are two deployment scenarios for RTC-WEB client applications.
The first scenario is when applications are deployed behind NAT and have
to worry about NAT traversal. The second scenario is when the
application is not behind a NAT, such as an RTC-WEB application that is
always connected to the public Internet. As stated in section 2.7 of
<xref target="RFC5245"></xref>, ICE requires that both endpoints to
support it in order for ICE to be used on a call.</t>
<t>With regards to RTC-WEB client applications that are deployed behind
a NAT or do not have a public IP address are REQUIRED to support ICE
<xref target="RFC5245"></xref>, applications that have a public IP
address are REQUIRED to support ICE-Lite and MAY fully support ICE.
RTC-WEB client applications that fully support ICE are REQUIRED to
support AGGRESSIVE NOMINATION, and MAY support REGULAR NOMINATION.</t>
</section>
<section title="ICE Within the Web Browser (Open Issue)">
<t>While there seems to be rough consensus that ICE<xref
target="RFC5245"></xref> should be the adopted as the recommendation for
NAT<xref target="RFC4787"></xref> traversal for RTC-Web applications,
currently there is an open issue as to what parts of ICE should be
implemented within RTC-Web capable web browsers.</t>
<t>To date there has been three proposals for the RTC-Web ICE
implementation.</t>
<t>The first proposal would place a full implementation of ICE within
the browser and expose native ICE APIs via JavaScript calls.</t>
<t>The second proposal would place a full implementation of STUN<xref
target="RFC3489"></xref> in the browser and expose native STUN APIs via
JavaScript calls. In the second proposal ICE would be implemented as a
JavaScript library that uses the browser’s native STUN APIs.</t>
<t>The third proposal is to defer the browser ICE implementation
requirements to the W3C WebRTC working group.</t>
<t>This section will be updated as the topic is vetted out on the
mailing list.</t>
<section title="Option 1: Full ICE in the Web Browser">
<t>This section proposes implementing full ICE in the web browser and
exposing native ICE APIs reasoning behind requiring RTC-Web web apps
to use a JavaScript library for ICE negotiation falls along two
primary assumptions.</t>
<section title="Issue 1: ICE Timing and Pacing Requirements">
<t>The ICE pacing requirements have a lower bound of 20 ms as stated
in <xref target="RFC5245"></xref>, section B.1., Pacing of STUN
Transactions. At the writing of this document it is unclear if the
resolution of modern JavaScript timers across the major operating
systems could meet the lower boundary requirements for ICE. It has
been suggested that the best way to determine if the ICE timing and
pacing requirements were actually feasible is to create browser
ready sample applications. The sample applications could be used to
prove or disprove the feasibility of ICE as a JavaScript
library.</t>
<t>To fairly evaluate a JavaScript ICE implementation the testing
environment should try to emulate a real-world usage scenario. The
following suggestions should be integrated into the test plan.</t>
<t><list style="symbols">
<t>The device and or computing environment. Areas to consider
here are the OS, use of virtualization, browser vendor, hardware
platform (notebook, desktop, tablet, netbook, smart phone, etc)
and network connectivity.</t>
<t>Testing performance under real-world web page conditions.
Real-world web pages often include inline advertisements. Web
pages with advertisements will include advertiser-bundled
JavaScripts,which can be quite large and take a long time to
execute. Long running JavaScripts scripts can prevent web
application timers from firing in correctly. Any feasibility
testing must cover the combination of JavaScript ICE with one or
more long running JavaScripts</t>
</list></t>
<t>A JavaScript ICE implementation should not be considered as a
viable recommendation of this draft until it two things happen.</t>
<t><list style="symbols">
<t>A working prototype is built - a working prototype would have
a browser with a STUN implementation and accompanying ICE
JavaScript library</t>
<t>Testing and proving the prototype is capable of handling the
ICE timing and pacing requirements within a real-world
environment</t>
</list></t>
<t></t>
</section>
<section title="Issue 2: Compatibility, Fixes and Update Rollout">
<t>It has been proposed that JavaScript ICE libraries would be
easier to manage with regards to compatibility and updates when
compared to ICE native within the web browser. While JavaScript
libraries would make it easy to add fixes and enhancements to an ICE
implementation this approach will not scale when it comes to
interoperability and rapid deployment. With ICE as a JavaScript
library, there can literally be a copy of the library on a per
website basis, given that there are over 250 million individual
websites on the internet, in addition to the millions of intranet
hosted sites, upgrading a JavaScript library will simply not scale
in a time friendly manner.</t>
<t>With ICE native within the browser, there are fewer than a dozen
implementations world wide that have to interoperate with each
other, which means that enhancements to ICE can be coordinated
between browser vendors. When it comes time to enhance or fix a
defect with the browser's native ICE implementation, updates to
browsers can be deployed, at scale, to hundreds of millions of users
in the span of a few weeks. The rapid updates have proven effective
and most if not all the major browser vendors have short term update
mechanisms.</t>
<t>Given that web browsers will be the dominant RTC-Web endpoint and
that a native implementation of ICE within the browser will
significantly narrow the complexities of ICE interoperability,
defect fixes and enhancements at scale it is RECOMMENDED that ICE be
implemented natively within all RTC-Web client applications.</t>
<t>A question may arise regarding the above recommendation if a
JavaScript ICE library could meet the ICE performance requirements.
While such a library may meet the ICE performance requirements,
until a deployment solution is proposed to propagate bug fixes and
enhancements to the JavaScript library at internet scale, a
JavaScript library approach would be an inferior recommendation
compared to the native in the browser approach.</t>
</section>
<section anchor="" title="Proposed Model">
<t>The model proposed here is that the web browser support a full
ICE implementation and expose APIs that to programmatically set up
an ICE session. With a full ICE implementation in the web browser, a
STUN implementation would be implicit and therefore STUN APIs could
also be exposed to give developers the flexibility of having a
native NAT traversal mechanism.</t>
</section>
</section>
<section title="Option 2: STUN in the Web Browser, ICE as JavaScript Library">
<t>This section discusses several drawbacks to including a full ICE
implementation in the browser and proposes a full STUN implementation
in the browser and ICE via a JavaScript library.</t>
<section anchor="sec-drawbacks" title="Issue 1: Hampers Innovation">
<t>One of the benefits of ICE is that it allows local implementation
flexibility in the way candidates are gathered, offered and
prioritized. However, once ICE is baked into the browser, it is no
longer possible for that innovation to take place - or at least, it
leaves the hands of the voice application providers. To date, there
has been variability in this aspect of implementation, with
different providers tuning it to tweak their needs and
deployments.</t>
</section>
<section title="Issue 2: Unnecessary Cost in some Cases">
<t>There is a broad array of use cases for VoIP. It is used for
everything from consumer Internet services (like Skype) to small
business phone systems. Though clearly global consumer Internet
services require the kind of traversal technology provided by full
ICE, it is not needed in other cases. One such use case is, in fact,
enterprise telephony, where users make calls within the confines of
their corporate network, and remote access is supported through VPN.
Today, VoIP endpoints in these environments do not generally use
ICE.</t>
<t>As such, if an enterprise communications application wanted to
utilize browser RTC, it would need to support ICE even though it was
not strictly required. Is there a penalty to support of ICE? The
enterprise would need to deploy STUN and TURN servers, which would
not actually be needed. ICE also typically increases call setup
delay (though the degree to which it does it is dependent on the
network conditions the users are in), those increases would be for
no benefit in the enterprise deployment scenario.</t>
</section>
<section title="Issue 3: Limits Adaptability">
<t>ICE was not the IETFs first attempt at techniques for firewall
and NAT traversal. Basic STUN <xref target="RFC3489"></xref> was
defined in 2003, and it solved the problem by attempting to
characterize NATs. It failed for a variety of reasons. However, one
of the key lessons of STUN was that its technique for classifying
NATs - breaking them into four different NAT varieties - proved
brittle. In reality, the market saw changes in the types of
implementations, and NATs appeared which met none of the
classifications. For this reason, ICE abandoned the classification
approach and instead moved towards a model of connectivity
checking.</t>
<t>As a consequence, ICE has greater reliability than pure STUN, but
its effectiveness in achieving direct p2p connections is still based
on some underlying assumptions around NAT types. Its design is most
effective for NATs whose behavior is endpoint-independent mapping,
and whose filtering policy is either endpoint-independent or
address-dependent <xref target="RFC4787"></xref>.</t>
<t>With the ongoing exhaustion of the IPv4 address space, we can
anticipate even further reliance on NAT and the likely appearance of
carrier NATs of differing varieties. This is likely to change the
nature of NAT behaviors seen in the real world. The right way to
deal with this is to adapt ICE's behavior, using differing
allocation techniques and assigning different priorities. For
example, ICE currently does not enable direct p2p connections in
cases where NATs have mapping policies which are endpoint dependent
but utilize sequential port allocation. If, despite the
recommendations of RFC4787, such NAT types become increasingly
prevalent, ICE's effectiveness will decline and more connections
will be relayed. With ICE literally baked into web browsers, it will
become harder to adapt its algorithms to work best under the
conditions of the modern Internet.</t>
</section>
<section title="Proposed Model">
<t>The model proposed here is that the browser itself support STUN
only. APIs are provided which allow for initiation of a STUN
transaction. The results of this transaction are then passed to the
browser application (notably, the reflexive address). The browser
API allows the browser application to set attribute/value pairs in
the message. Similarly, on the receive-side, APIs are defined for
allowing an application to register callbacks for receipt of a STUN
request. Those callbacks provide the application information on the
source IP and port, amongst other information.</t>
<t>For security purposes, the browser will refuse to send, or
accept, media to or from a peer to which a STUN transaction has not
completed successfully. This ensures that the browser cannot be used
as a DoS tool to launch a voice hammer attack.</t>
<t>What about TURN? In this model, TURN is mostly implemented on top
of the browsers STUN implementation. The Javascript code in the
browser can generate Allocate requests, and be informed of the
results. The only exception to this is that the browser has to be
told whether or not to encapsulate media in Send transactions, or to
use an allocated channel. The browser API provides a switch which
allows the application to tell the browser which encapsulation to
use for media.</t>
<t>In a server-mediated environment, TURN might also be unnecessary.
A call setup service can communicate directly with the relay service
to establish a transparent UDP tunnel through one or more relays,
the STUN connectivity checks may be sent through this tunnel, and no
TURN encapsulation support is needed in the browser. The
Javascript-initiated STUN connectivity tests may also be used to
authenticate the browser to the tunnel service.</t>
<t>With this model, there is now a great deal of flexibility in how
NAT traversal can be done. Some of the models which can now be
supported are:</t>
<t><list style="hanging">
<t hangText="ICE in JavaScript:">A full ICE implementation is
possible in JavaScript itself. Because the implementation
resides in JavaScript, it is trivially changed at any time.</t>
<t hangText="Server-Based ICE:">A full ICE implementation can
execute in the server, using remote-control commands to inform
the browser to send STUN transactions, and passing the results
from the browser back to the server. In essence - MGCP for
ICE.</t>
<t hangText="STUN-Only:">For deployments where the peer is
always publicly reachable from clients - such as enterprises or
PSTN termination services - the JavaScript can do a single STUN
transaction to create a permission in the browser, and then
proceed to send media.</t>
<t hangText="Non-ICE:">Protocols similar to ICE, but not
otherwise compliant, can also be implemented. Negotiation of
which NAT traversal mechanism is needed, is done by the
application outside of the browser.</t>
</list></t>
<t>This model addresses all of the concerns outlined in <xref
target="sec-drawbacks"></xref>. Now, if changes in NAT types occur
over time, new Javascript or server code can be deployed which uses
different prioritization, or even performs new allocation models.
For example, port-predictive allocations can be added in this model,
without upgrading the browser. Since the browser has the barest
minimum necessary for security and functional purposes, innovation
is possible to a greater degree. Finally, implementations can be
only as complex as is needed for the task at hand.</t>
</section>
</section>
<section title="Option 3: Defer to W3C WebRTC Working Group">
<t>This section proposes that the IETF defer the implementation of ICE
to the W3C WebRTC working group.</t>
<t>Given that RTC-Web is being designed to run on more than just web
browsers, the opinion here is that it should not be the role of this
working group to make a set of requirements for a specific RTC-Web
client application implementation.</t>
</section>
</section>
<section title="Negotiation Architecture">
<t>[WORK IN PROGRESS]</t>
<t>An example of this will be showing how a RTC-Web capable web browser
does signaling and negotiation to set up a DTLS [REF] connection using
ICE. Once the DTLS connection has been established, the RTC-Web client
application will use the secure channel for SIP signaling and media
transmission.</t>
<t>[TODO - add architecture diagram and content]</t>
</section>
<section title="Legacy VoIP Interoperability">
<t>There is no way to meet all the security requirements and maintain
comparability with all legacy VoIP equipment. This draft tries to
minimize the impedance mismatch. The requirements here would allow
interoperability with legacy VoIP equipment as long as that equipment
either directly supported, or was fronted by an SBC that supported ICE
or ICE-Lite.</t>
<t>Support for ICE-Lite has historically been lacking in VoIP equipment,
this is changing and ICE-Lite becoming increasingly prevalent,
particularly on devices designed to sit on the edge of a domain and
connect to remote user agents that may be behind NATs. Given the
increasing adoption of ICE-Lite, it could be conjectured that a
substantial fraction of VoIP equipment meets the RTC-WEB
interoperability list.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To guard against spoofing RTC-Web client applications are REQUIRED
to:</t>
<t><list style="symbols">
<t>Internally encapsulate the generation of STUN transaction IDs</t>
<t>Block read/write access to the generated STUN transaction IDs</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:20:27 |