| Network Working Group | C. Bran |
| Internet-Draft | Cisco |
| Intended status: Standards Track | M.K. Kaufman |
| Expires: March 11, 2012 | Skype |
| C. Jennings | |
| Cisco | |
| J.R. Rosenberg | |
| Skype | |
| September 08, 2011 |
RTC-Web Network Address Translation
draft-cbran-rtcweb-nat-01
This document outlines the network address translation (NAT) mechanisms and requirements for RTC-Web client applications.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 11, 2012.
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 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.
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.
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]
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].
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 applications that fully support ICE are REQUIRED to support AGGRESSIVE NOMINATION, and MAY support REGULAR NOMINATION.
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.
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.
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 environment should try to emulate a real-world usage scenario. The following suggestions should be integrated into the test plan.
A JavaScript ICE implementation should not be considered as a viable recommendation of this draft until it two things happen.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
[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]
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.
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.
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:
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5245] | Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. |
| [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, March 2003. |
| [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. |
| [RFC4787] | Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. |