One document matched: draft-cbran-rtcweb-nat-01.txt
Differences from draft-cbran-rtcweb-nat-00.txt
Network Working Group C. Bran
Internet-Draft Cisco
Intended status: Standards Track M. Kaufman
Expires: March 9, 2012 Skype
C. Jennings
Cisco
J. Rosenberg
Skype
September 6, 2011
RTC-Web Network Address Translation
draft-cbran-rtcweb-nat-01
Abstract
This document outlines the network address translation (NAT)
mechanisms and requirements for RTC-Web client applications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Bran, et al. Expires March 9, 2012 [Page 1]
Internet-Draft Abbreviated-Title September 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Connection Management Requirements . . . . . . . . . . . . . . 3
4. ICE Within the Web Browser (Open Issue) . . . . . . . . . . . 4
4.1. Option 1: Full ICE in the Web Browser . . . . . . . . . . 4
4.1.1. Issue 1: ICE Timing and Pacing Requirements . . . . . 4
4.1.2. Issue 2: Compatibility, Fixes and Update Rollout . . . 5
4.1.3. Proposed Model . . . . . . . . . . . . . . . . . . . . 6
4.2. Option 2: STUN in the Web Browser, ICE as JavaScript
Library . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Issue 1: Hampers Innovation . . . . . . . . . . . . . 6
4.2.2. Issue 2: Unnecessary Cost in some Cases . . . . . . . 6
4.2.3. Issue 3: Limits Adaptability . . . . . . . . . . . . . 7
4.2.4. Proposed Model . . . . . . . . . . . . . . . . . . . . 8
4.3. Option 3: Defer to W3C WebRTC Working Group . . . . . . . 9
5. Negotiation Architecture . . . . . . . . . . . . . . . . . . . 9
6. Legacy VoIP Interoperability . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Bran, et al. Expires March 9, 2012 [Page 2]
Internet-Draft Abbreviated-Title September 2011
1. Introduction
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.
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:
[TODO put links to supporting drafts here]
2. Terminology
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 [RFC2119].
3. Connection Management Requirements
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 [RFC5245] or ICE-Lite Section 2.7 of
[RFC5245]. 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) [RFC3489] and Traversal Using Relays around NAT (TURN)
[RFC5766].
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 [RFC5245], ICE requires that both endpoints to support it in order
for ICE to be used on a call.
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
[RFC5245], applications that have a public IP address are REQUIRED to
support ICE-Lite and MAY fully support ICE. RTC-WEB client
Bran, et al. Expires March 9, 2012 [Page 3]
Internet-Draft Abbreviated-Title September 2011
applications that fully support ICE are REQUIRED to support
AGGRESSIVE NOMINATION, and MAY support REGULAR NOMINATION.
4. ICE Within the Web Browser (Open Issue)
While there seems to be rough consensus that ICE[RFC5245] should be
the adopted as the recommendation for NAT[RFC4787] 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.
To date there has been three proposals for the RTC-Web ICE
implementation.
The first proposal would place a full implementation of ICE within
the browser and expose native ICE APIs via JavaScript calls.
The second proposal would place a full implementation of
STUN[RFC3489] 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.
The third proposal is to defer the browser ICE implementation
requirements to the W3C WebRTC working group.
This section will be updated as the topic is vetted out on the
mailing list.
4.1. Option 1: Full ICE in the Web Browser
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.
4.1.1. Issue 1: ICE Timing and Pacing Requirements
The ICE pacing requirements have a lower bound of 20 ms as stated in
[RFC5245], 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.
To fairly evaluate a JavaScript ICE implementation the testing
Bran, et al. Expires March 9, 2012 [Page 4]
Internet-Draft Abbreviated-Title September 2011
environment should try to emulate a real-world usage scenario. The
following suggestions should be integrated into the test plan.
o 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.
o 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
A JavaScript ICE implementation should not be considered as a viable
recommendation of this draft until it two things happen.
o A working prototype is built - a working prototype would have a
browser with a STUN implementation and accompanying ICE JavaScript
library
o Testing and proving the prototype is capable of handling the ICE
timing and pacing requirements within a real-world environment
4.1.2. Issue 2: Compatibility, Fixes and Update Rollout
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.
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.
Bran, et al. Expires March 9, 2012 [Page 5]
Internet-Draft Abbreviated-Title September 2011
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.
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.
4.1.3. Proposed Model
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.
4.2. Option 2: STUN in the Web Browser, ICE as JavaScript Library
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.
4.2.1. Issue 1: Hampers Innovation
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.
4.2.2. Issue 2: Unnecessary Cost in some Cases
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.
Bran, et al. Expires March 9, 2012 [Page 6]
Internet-Draft Abbreviated-Title September 2011
Today, VoIP endpoints in these environments do not generally use ICE.
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.
4.2.3. Issue 3: Limits Adaptability
ICE was not the IETFs first attempt at techniques for firewall and
NAT traversal. Basic STUN [RFC3489] 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.
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 [RFC4787].
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.
Bran, et al. Expires March 9, 2012 [Page 7]
Internet-Draft Abbreviated-Title September 2011
4.2.4. Proposed Model
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.
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.
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.
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.
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:
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.
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.
Bran, et al. Expires March 9, 2012 [Page 8]
Internet-Draft Abbreviated-Title September 2011
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.
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.
This model addresses all of the concerns outlined in Section 4.2.1.
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.
4.3. Option 3: Defer to W3C WebRTC Working Group
This section proposes that the IETF defer the implementation of ICE
to the W3C WebRTC working group.
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.
5. Negotiation Architecture
[WORK IN PROGRESS]
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.
[TODO - add architecture diagram and content]
6. Legacy VoIP Interoperability
There is no way to meet all the security requirements and maintain
comparability with all legacy VoIP equipment. This draft tries to
Bran, et al. Expires March 9, 2012 [Page 9]
Internet-Draft Abbreviated-Title September 2011
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.
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.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
To guard against spoofing RTC-Web client applications are REQUIRED
to:
o Internally encapsulate the generation of STUN transaction IDs
o Block read/write access to the generated STUN transaction IDs
9. Acknowledgements
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.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
Bran, et al. Expires March 9, 2012 [Page 10]
Internet-Draft Abbreviated-Title September 2011
March 2003.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Authors' Addresses
Cary Bran
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 206 256-3502
Email: cbran@cisco.com
Matthew Kaufman
Skype
3210 Porter Drive
Palo Alto, California 94304
US
Phone: +1 831 440 8771
Email: matthew.kaufman@skype.net
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Bran, et al. Expires March 9, 2012 [Page 11]
Internet-Draft Abbreviated-Title September 2011
Jonathan Rosenberg
Skype
3210 Porter Drive
Palo Alto, California 94304
US
Email: jdrosen@skype.net
Bran, et al. Expires March 9, 2012 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:56 |