MMUSIC M. Thomson Internet-Draft Microsoft Intended status: Standards Track October 19, 2013 Expires: April 22, 2014 Using Interactive Connectivity Establishment (ICE) in Web Real-Time Communications (WebRTC) draft-thomson-mmusic-ice-webrtc-01 Abstract Interactive Connectivity Establishment (ICE) has been selected as the basis for establishing peer-to-peer UDP flows between Web Real-Time Communication (WebRTC) clients. Using an unmodified ICE implementation in this context enables the use of the web platform as a denial of service platform. The risks and complications arising from this choice are discussed. A modified algorithm for sending ICE connectivity checks from the web platform is described. Status of This Memo 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 April 22, 2014. Copyright Notice Copyright (c) 2013 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 Thomson Expires April 22, 2014 [Page 1] Internet-Draft ICE for WebRTC October 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. ICE in a Web Browser . . . . . . . . . . . . . . . . . . . . 4 2.1. Factors Influencing DoS Capacity . . . . . . . . . . . . 4 2.1.1. Pacing of Connectivity Checks . . . . . . . . . . . . 5 2.1.2. Retransmission of Connectivity Checks . . . . . . . . 5 2.1.3. Connectivity Check Size . . . . . . . . . . . . . . . 6 2.2. Denial of Service Magnitude . . . . . . . . . . . . . . . 6 3. Modified ICE Algorithm . . . . . . . . . . . . . . . . . . . 7 3.1. Trickled and Peer Reflexive Candidates . . . . . . . . . 9 3.2. Multiple ICE Agents . . . . . . . . . . . . . . . . . . . 10 3.2.1. Introducing Artificial Contention . . . . . . . . . . 11 3.2.2. Origin-First Round-Robin . . . . . . . . . . . . . . 11 3.2.3. Inter-Agent Candidate Pair Freezing . . . . . . . . . 11 3.2.4. Delayed ICE Agent Start . . . . . . . . . . . . . . . 12 4. Further Reducing the Impact of Attacks . . . . . . . . . . . 12 4.1. Bandwidth Rate Limiting . . . . . . . . . . . . . . . . . 12 4.2. Malicious Application Penalties . . . . . . . . . . . . . 13 4.3. Limited Concurrent Access to ICE . . . . . . . . . . . . 13 5. Negotiating Algorithm Use . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Defining Legitimate Uses of ICE . . . . . . . . . . 15 A.1. Candidate Pair Count . . . . . . . . . . . . . . . . . . 15 A.2. Connectivity Check Size . . . . . . . . . . . . . . . . . 16 A.3. Rate Calculations . . . . . . . . . . . . . . . . . . . . 16 A.4. Comparison: G.711 Audio . . . . . . . . . . . . . . . . . 16 A.5. Recommended Rate Limits . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction ICE [RFC5245] describes a process whereby peers establish a bi- directional UDP flow. This process has been adopted for use in Web Real-Time Communications (WebRTC) for establishing flows to and from web browsers ([I-D.ietf-rtcweb-overview]). Properties of ICE are also critical to the security of WebRTC (see Section 4.2.1 of [I-D.ietf-rtcweb-security]). Thomson Expires April 22, 2014 [Page 2] Internet-Draft ICE for WebRTC October 2013 The design of RFC 5245 does not fully consider the threat models enabled by the web environment. In particular, the following assumptions are not valid in a web context: o A one-time consent to communicate is sufficient, and revocation of consent is not necessary. o Signaling and control originates from actors that always operate in good faith. o Only one ICE processing context operates at the one time. Implementations of ICE that are technically compliant with the algorithm described in RFC 5245 potentially expose controls to web applications that can be exploited. In the web context, an attacker is able to provide code (usually JavaScript) that is executed by those hosts in a sandbox. The protections of the sandbox are critical, both for protecting the host running the sandbox, and for protecting the Internet as a whole from bad actors. The exposure of ICE features in the web browser could allow attackers to generate denial of service (DoS) traffic far in excess of the bandwidth needed to deploy the JavaScript. A small (1KB) file can potentially generate many megabytes of connectivity checks in a short period, representing an amplication factor far greater than other similar amplification attacks (for instance, DNS reflection attacks). Mounting this sort of DoS attack does not rely on anything other than inducing a host to download and execute JavaScript. This is generally very easy to accomplish, making it very easy to conscript large number of traffic sources. The issue regarding the one-time consent to communicate has already been identified as a serious problem for WebRTC. [I-D.muthu-behave-consent-freshness] describes a limit on the time that consent remains valid, requiring that communications consent be continuously refreshed. This document first describes the characteristics of ICE as they relate to the web and the way that these characteristics can be exploited. In order to address the issues arising from allowing web application to initiate and control ICE processing, a modified algorithm is described, plus additional measures that can be employed to reduce the amount of traffic an attacker can produce. Thomson Expires April 22, 2014 [Page 3] Internet-Draft ICE for WebRTC October 2013 1.1. Conventions and Terminology In cases where normative language needs to be emphasized, this document falls back on established shorthands for expressing interoperability requirements on implementations: the capitalized words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these is described in [RFC2119]. 2. ICE in a Web Browser A web browser provides an API that applications can use to instantiate and control an ICE agent. The web application is responsible for providing the ICE agent with signaling that it might need to operate successfully, as well as configuration information regarding TURN [RFC5766] or STUN [RFC5389] servers. In the web context, a browser treats the web application as being potentially hostile, providing access to features in a controlled fashion. Therefore, some of the information that an ICE agent might depend on in other contexts has to be regarded as potentially suspect when provided by a web application. 2.1. Factors Influencing DoS Capacity There are several parameters that affect the characteristics of DoS attacks that can be mounted using ICE. These include: o The number of candidate pairs that are created. An attacker can add extra remote candidates to inflate this number to tbe maximum supported. RFC 5245 recommends a default maximum of 100 candidate pairs. Reducing this limit directly reduces DoS potential, though it could affect success in some legitimate scenarios (see the calculations in Appendix A). o The time between consecutive connectivity checks. Pacing of checks is discussed at length in Section 2.1.1. o The total number and timing of retransmissions for each candidate pair. Section 2.1.2 discusses the implications of retransmissions. o The size of connectivity check packets. Size considerations are described in Section 2.1.3. o The number of ICE agents that can be operated concurrently. RFC 5245 does not consider scenarios like WebRTC where it is not only possible for there to be multiple agents. The web security model allows for cases where multiple agents can be created Thomson Expires April 22, 2014 [Page 4] Internet-Draft ICE for WebRTC October 2013 concurrently, often with a further restriction that a browser not leak information between agents. 2.1.1. Pacing of Connectivity Checks ICE [RFC5245] describes a scheme for pacing connectivity checks. There are two primary reasons that are cited: o Pacing the initial connectivity checks for a given candidate pair allows middleboxes sufficient time to establish bindings. Empirical evidence suggests that failing to allow at least 20 milliseconds between initial connectivity checks risks the bindings being dropped at some middleboxes. o Pacing limits the potential for connectivity checks to generate network congestion. Section 16.1 of [RFC5245] describes a formula for calculating the time between connectivity checks (Ta) that is based on the expected bandwidth of the real-time session that is being established. In the web context, information about the expected bandwidth used by the session comes from the web application. Since the web application has to be regarded as potentially malicious, information about expected media bandwidth cannot be used to determine the pacing of connectivity checks. A fixed minimum interval between connectivity checks becomes the primary mechanism for limiting the ability of web applications to generate packets that are potentially congestion inducing. Increasing the pacing interval directly reduces the amount of congestion that connectivity checks can generate, though this only reduces the peak bitrate that can be induced - the same amount of traffic is generated over a longer period. The cost of this is extended session setup times, where recent efforts have been focused on reducing this time. 2.1.2. Retransmission of Connectivity Checks The initial retransmission timer (RTO) can also be increased with similar effect to increasing the pacing timer. Furthermore, there is a strong desire to reduce the recommended value of the RTO in ICE from 500 milliseconds to values more reflective of common round trip times in well-connected locations, which might be as low as 50 milliseconds. More relevant is the total number of connectivity check retransmissions that an implementation attempts for each candidate pair. Each additional retransmission directly increases the duration Thomson Expires April 22, 2014 [Page 5] Internet-Draft ICE for WebRTC October 2013 and magnitude of a DoS attack. Following the exponential backoff recommended by RFC 5245 does extend the time between retransmissions, which could reduce the rate of connectivity checks after several retransmissions, but this depends on the initial retransmission time out (RTO). Reducing the number of retransmissions has the effect of reducing the probability of the check succeeding. The selection of a total retransmission count is a trade-off of success rates against the potential for abuse. 2.1.3. Connectivity Check Size As currently specified, an attacker is only able to influence the size of the USERNAME attribute. [RFC5389] restricts USERNAME to a maximum size of 512 octets; the Session Description Protocol (SDP) signaling described in [RFC5245] limits the size of the username fragment an attacker can set to 256 bytes. A browser could reduce its username fragment to as little as 4 bytes, limiting the overall size of the attribute to 261 bytes. A small username fragment does limit the collision resilience of the field, which is a property that is important for detecting other forms of attack (see Section 5.7.3 of [I-D.ietf-rtcweb-security-arch]). There is also the potential for new modifications to ICE that increase the packet size. For instance [I-D.martinsen-mmusic-malice] provides an attacker with direct control over the bytes that are included in connectivity checks. 2.2. Denial of Service Magnitude A malicious application is able to influence connectivity checking by altering the set of remote candidates and by changing the remote username fragment. The default maximum sizes for remote username fragment (256 bytes) and number of candidate pairs (100) described in RFC 5245 can be exploited by an attacker to increase the number and size of packets. Assuming an inter-check timer of the minimum of 20 milliseconds, plus a minimal 28 bytes of IPv4 and UDP overhead, this results in an attacker being able to induce approximately 144kbps for every ICE agent it is able to instantiate. This rate is significantly higher than the minimal rate of 20kbps that a typical compressed voice stream generates. By comparison, a G.711 audio stream, which cannot be rate limited in response to network congestion, but is generally regarded as safe to send to a willing target, generates about 74kbps. Thomson Expires April 22, 2014 [Page 6] Internet-Draft ICE for WebRTC October 2013 ICE does not allow for any congestion feedback (other than ECN [RFC3168]), so this rate could conceivably be sustained for some time, though after several seconds the time between retries increases, reducing the check rate unless the application is able to instantiate another ICE agent. Some existing ICE implementations could generate about 3 or more times the basic rate of connectivity checks over a short period. These implementations do not pace retransmission of connectivity checks, resulting in significantly higher connectivity check rates during early rounds of retransmission. These implementations are ignoring the advice on calculating a minimum RTO from Section 16.1 of [RFC5245]. However, the shorter RTO allows ICE to complete much faster, which is a significant advantage. Implementations that do not limit the number of ICE agents that can be instantiated, and subsequently fail to enforce rate limits globally create a further multiplicative factor on the basic rate. 3. Modified ICE Algorithm This section describes an algorithm that ensures proper global pacing of connectivity checks. This limits the ability of any single attacker to generate a high rate of connectivity checks. This only limits the peak data rate that results from connectivity checks, reducing the intensity of DoS attacks. Measures that reduce the overall duration of attacks are described in Section 4. The modified algorithm for ICE does not alter the way that candidate pairs are selected, prioritized, frozen or signaled. It only affects the generation of connectivity checks. This algorithm affects candidate pairs in either of the "Waiting" or "In-Progress" states only (see Section 5.7.4 of [RFC5245]). The ICE agent maintains two queues for candidate pairs. waiting queue: The first is a prioritized list of candidate pairs in the "Waiting" state. The waiting queue is simply a prioritized list of all the candidate pairs in the check list (see Section 5.7 of [RFC5245]) that are in the "Waiting" state. As candidate pairs enter the "Waiting" state, they are added to the waiting queue. As each candidate pair is added, it is prioritized relative to all the other candidate pairs in the waiting queue. Thomson Expires April 22, 2014 [Page 7] Internet-Draft ICE for WebRTC October 2013 check queue: The second is for outstanding connectivity checks. Each entry in this list represents a connectivity check for a given candidate pair. Each entry also includes a counter representing the number of connectivity checks that have been sent on this candidate pair. The ICE agent maintains two types of timer: a pacing timer and a retransmission timer. There is only one pacing timer, though there can be multiple retransmission timers running concurrently. The first candidate pair that arrives in the waiting queue starts the pacing timer. The pacing timer runs as long as there are items in any queue, ending if the timer expires when there are no entries in either queue. The pacing timer resumes if an entry is added to either queue and the timer is not already running. Each time the pacing timer expires, the ICE agent performs the following steps: 1. If there are items on the waiting queue, but no items on the check queue, the first candidate pair is taken from the waiting queue. a. The candidate pair transitions from "Waiting" to "In- Progress". b. A check counter is associted with the candidate pair, initialized with a zero value. c. The candidate pair is added to the check queue. This could result in a connectivity check being sent immediately if the check queue is currently empty. 2. If there are items in the check queue, the ICE agent removes the first item and performs a connectivity check on the identified candidate pair. a. The check counter associated with the candidate pair is incremented by one. b. Based on the value of the check counter, a retransmission timer is scheduled for the candidate pair. The retransmission timer is not scheduled if the check counter exceeds the maximum number of checks configured for the ICE agent. Thomson Expires April 22, 2014 [Page 8] Internet-Draft ICE for WebRTC October 2013 c. If the retransmission timer expires without the connectivity check succeeding, the candidate pair is returned to the end of the check queue along with the higher check counter. d. The retransmission timer is cancelled if the connectivity check succeeds. The process for handling successful checks in Section 7.1.3.2 of [RFC5245] is followed. 3. If no connectivity checks were sent, the pacing timer is stopped. An important characteristic of this algorithm is that it - as much as possible - prefers retransmission of connectivity checks over the initiation of new connectivity checks. This ensures that once an initial connectivity check has established any necessary middlebox bindings, subsequent retries are not delayed excessively, which could cause the binding to time out. However, the global pacing can cause the time between retransmission of connectivity checks to be extended as the check queue occasionally fills. Favoring retransmission over initial checks directly contradicts the guidance on RTO selection in Section 16.1 of [RFC5245]. This is necessary due to the delays induced by potential interactions between multiple ICE agents, which might otherwise cause retries to be significantly delayed. Improvements to candidate prioritization are expected to reduce the impact of this change. 3.1. Trickled and Peer Reflexive Candidates Trickled ICE candidates [I-D.ivov-mmusic-trickle-ice] generate candidate pairs after connectivity checking has commenced. In order to avoid trickled candidates negatively affecting the chances of a connectivity check succeeding, connectivity checks on newly appearing candidate pairs must be prioritized below any existing connectivity check. Trickled candidates are in many respects identical to peer reflexive candidates. Both arrive after the algorithm has commenced. In either case, as new candidates arrive (or are discovered), they are paired as normal (Section 5.7.1 of [RFC5245]), and - if appropriate - entered into the "Waiting" state. This causes the candidate pair to enter the waiting queue. Candidate pairs in the waiting queue are not ordered based on arrival time, they are ordered based on priority alone. Trickling regular candidates does introduce the potential for a mismatch in the ordering of candidate pairs between peers, since trickled candidates will appear in the sending side well before the Thomson Expires April 22, 2014 [Page 9] Internet-Draft ICE for WebRTC October 2013 receiving side can act upon them, resulting in the sending peer potentially commencing checks much earlier than the receiving peer. This is particularly important given the possibility that retransmissions of connectivity checks can block the progress of a candidate pair from the "Waiting" state into the "In-Progress" state, resulting in potentially large differences in the commencement time for any given candidate pair. A trickle ICE implementation MAY choose not to immediately enqueue local candidates as they are discovered to allow some time for trickle signaling to propagate in order to increase the probability that checks remain synchronized. 3.2. Multiple ICE Agents In a system that has potentially more than one ICE agent, it's important that connectivity checks from any given ICE agent cannot be blocked or starved by other ICE agents. It is also important that an attacker is unable to circumvent any limits by instantiating multiple ICE agents. To that end, a single pacing timer is maintained globally whenever multiple ICE agents are operated. Each time the pacing timer fires, the global context selects ICE agents in a round-robin fashion. In addition to ensuring a global rate limit, this selection method ensures that no single ICE agent is completely starved. In a shared context, ICE agents do not stop or start the pacing timer unless they are the first or last ICE agent to be active. The first ICE agent to commence checking starts the global timer, the last ICE agent to cancel the timer causes the global timer to be cancelled. At all other instances, "starting" the pacing timer for an ICE agent simply adds the ICE agent to the set of agents that can be selected; "stopping" the pacing timer removes the ICE agent from the set of ICE agents that are in consideration. A global pacing timer causes each individual ICE agent to execute checks more slowly than a lone ICE agent would. Where there are many candidate pairs to test, this could have a negative impact on the synchronization of checks between peers. Poor check synchronization can have a negative impact on success rates. Peers with asymmetric contention can have lower priority candidate pairs started on the less contended peer long before the contended peer is able to commence checking, which can result in those checks failing. Several measures are suggested for mitigating the impact of contention: artificial contention, origin-first distribution, inter- Thomson Expires April 22, 2014 [Page 10] Internet-Draft ICE for WebRTC October 2013 agent candidate pair freezing, and delayed start. However, it is important to note that similar artificial constraints have classically been quickly circumvented on the web if they have overly negative performance consequences. 3.2.1. Introducing Artificial Contention In cases where there is zero contention, artificial contention can be introduced to ensure a certain minimum effective pacing timer. In effect, this would increase the basic pacing timer from 20ms by a minimum multiple for any single ICE agent. Artificially contention would result in no checks being sent at all at different phases, spacing genuine connectivity checks. For instance, contention could be increased to a minimum of 3 ICE agents. Assuming a 20ms basic interval, the first ICE agent would be able to send connectivity checks every 60ms, as though it were contending with two other ICE agents. Adding another ICE agent would have no effect on this rate. It would only be if a fourth ICE agent were added that all ICE agents would be reduced to sending checks at 80ms intervals. This has the advantage of ensuring that a lightly contended client has the same rate of checking as a client with only a small number of ICE agents so that checks are more likely to be synchronized. 3.2.2. Origin-First Round-Robin In a system such as a browser, there are potentially competing interests sharing the same limited resources. In this type of context, each competing user - in the browser, this is an origin [RFC6454] - can first be selected using a round-robin or similar allocation scheme. Thus, as a first step, selection is performed from the set origins that have an active ICE agent. Once an origin is selected, agents are selected from within that origin. This ensures that no single origin can receive more than a proportional share of the access to connectivity checking. This is particularly important if multiple users (or origins) are each able to create multiple ICE agents. Selecting based on users first prevents a single origin from monopolizing access to connectivity checks. 3.2.3. Inter-Agent Candidate Pair Freezing Thomson Expires April 22, 2014 [Page 11] Internet-Draft ICE for WebRTC October 2013 In some cases, it might be necessary to instantiate multiple ICE agents from the same application, between the same two peers. An ICE agent MAY place candidate pairs in the "Frozen" state based on candidate pairs with the same foundation being "Waiting" or "In- Progress" on another ICE agent. This reduces the overall demand for connectivity checks without any significant negative effect on the chances that ICE succeeds. In the browser context, information about the success of connectivity checks cannot leak between different domains. This could allow information about activities on another tab to be leaked, violating the origin security model of the browser. Thus, any inter-agent freezing logic MUST be constrained to ICE agents that operate in the same origin. 3.2.4. Delayed ICE Agent Start In cases where there is high contention for access to connectivity checking, it might be preferable to delay the start of connectivity checks for an ICE agent rather than have the effective pacing timer increased. 4. Further Reducing the Impact of Attacks A global pacing timer allows a web application to determine whether another domain is currently establishing an ICE transport, simply by observing the pacing of connectivity checks that it requests. Section 3.2.1 describes a method that allows a limited number of ICE agents to operate without being detectable. The algorithm and the measures it describes are based on an assumption that ICE agents are created legitimately. Even with these measures, it's possible to generate a steady amount of bandwidth toward arbitrary hosts. The remainder of this section is dedicated to additional measures that might be employed to reduce the ability of malicious users to generate unwanted connectivity checks over time. 4.1. Bandwidth Rate Limiting A measure of the bandwidth generated by connectivity checks can be maintained, on both global and a per-origin basis. As this number increases, the browser can reduce the rate of connectivity checks. This reduction might either be gained by increasing the duration of the pacing timer or skipping occasional connectivity checks. Thomson Expires April 22, 2014 [Page 12] Internet-Draft ICE for WebRTC October 2013 Appendix A includes some simple calculations and recommendations on what might be appropriate limits to set on the bandwidth used by connectivity checks. 4.2. Malicious Application Penalties An attacker that only wishes to generate traffic is unlikely to provide valid candidates for two reasons: o a successful connectivity check is likely to cause the ICE agent to terminate further checking o serving connectivity checks requires the dedication of greater resources by the attacker A long sequence of unsuccessful connectivity checks is therefore a likely indicator for an attack. An ICE agent could choose to reduce the rate at which connectivity checks are generated for an application that has a large number of failed checks. Any measure that penalizes for unsuccessful checks will have to allow for some failures. Even legitimate uses of ICE can result in significant numbers of failed connectivity checks. For instance, an implementation that exclusively prioritizes IPv6 over IPv4 on a network with broken IPv6 will legitimately see a large number of failures. Similarly, if a remote peer is behind a NAT, prior to the commencement of checking by that peer all connectivity checks are likely to be discarded by the NAT. 4.3. Limited Concurrent Access to ICE Setting an absolute maximum on the number of ICE agents that can be instantiated could overly constrain legitimate applications that depend on having multiple active sessions. However, limiting concurrent access to active ICE agents by delaying the start of connectivity checking, as described in Section 3.2.4 might allow an implementation to reduce the ability of a single origin to generate unwanted connectivity checks. 5. Negotiating Algorithm Use The algorithm defined in Section 3 could cause some ICE agents to perform checks in a very different order to the order of an unmodified ICE agent. Failing to coordinate when checks occur reduces the probability that ICE is successful. TODO: Determine whether an ice-options token that enables negotiation of this algorithm is appropriate, or whether something more Thomson Expires April 22, 2014 [Page 13] Internet-Draft ICE for WebRTC October 2013 definitive is required, since an answerer could negotiate an ice- options token away. Note that WebRTC implementations probably won't be able to accept a session that does not use this algorithm. 6. Security Considerations This entire document is about security. 7. Acknowledgements The bulk of the algorithm described in this document came out of a discussion with Emil Ivov and Pal-Erik Martinsen. Eric Rescorla and Bernard Aboba provided some feedback regarding the DoS considerations and possible mitigations. 8. References 8.1. Normative References [I-D.ivov-mmusic-trickle-ice] Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ivov- mmusic-trickle-ice-01 (work in progress), March 2013. [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. 8.2. Informative References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-08 (work in progress), September 2013. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-07 (work in progress), July 2013. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-05 (work in progress), July 2013. Thomson Expires April 22, 2014 [Page 14] Internet-Draft ICE for WebRTC October 2013 [I-D.martinsen-mmusic-malice] Penno, R., Martinsen, P., Wing, D., and A. Zamfir, "Meta- data Attribute signaLling with ICE", draft-martinsen- mmusic-malice-00 (work in progress), July 2013. [I-D.muthu-behave-consent-freshness] Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage for Consent Freshness", draft-muthu-behave-consent- freshness-04 (work in progress), July 2013. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [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. [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011. Appendix A. Defining Legitimate Uses of ICE Limiting the bandwidth generated by connectivity checks depends on knowing how much ICE could use under normal circumstances. This ensures any absolute limit doesn't adversely affect a legitimate use of ICE. Any calculation should allow for slightly abnormal configurations that might generate higher than average data rates. Otherwise, an average might adversely affect legitimate users. The intent is to avoid having legitimate uses concerned with the limit. A.1. Candidate Pair Count Our sample legitimate user has 2 local network interfaces. This can result in as many as 14 candidates, 8 of them IPv4 plus 6 IPv6. Each interface has 1 IPv4 address, an IPv6 address, plus a link-local IPv6 address. Assuming a different public IPv4 NAT address for each interface and IP version (using either NAT4-4 or NAT6-4 as appropriate) other than the link local addresses, this adds another 4 addresses. In addition to this, two TURN servers might be contacted by either IPv4 or IPv6, providing 4 more addresses. Thomson Expires April 22, 2014 [Page 15] Internet-Draft ICE for WebRTC October 2013 Two peers with this configuration will generate 100 candidate pairs, since only IPv4 candidates are paired with IPv4 candidates. Assuming that all candidates are checked once before ICE completes on a second round of checks, there are in excess of 100 connectivity checks sent. Even at the fastest permitted pacing, this means that ICE completes in at least 2 seconds, plus the round trip time. A.2. Connectivity Check Size The STUN message used for a connectivity check can vary, but making some reasonable assumptions, it is likely to be 149 or 169 bytes on the wire (plus network layer encapsulation). This makes the following assumptions: IP Header: 20 bytes (IPv4) or 40 bytes (IPv6) with no extensions UDP Header: 8 bytes STUN Header: 20 bytes USE-CANDIDATE Attribute: 4 bytes CONTROLLED or CONTROLLING Attribute: 4 bytes PRIORITY Attribute: 4 bytes MESSAGE-INTEGRITY Attribute: 24 bytes FINGERPRINT Attribute: 8 bytes USER Attribute: 49 bytes carries two 20 character username fragments A.3. Rate Calculations Assuming a 150 byte connectivity check and a global pacing timer of 20ms, this produces 60kbps at peak (68kpbs for IPv6). For 100 candidate pairs, with at most 5 connectivity checks on each pair, this peak could be sustained for 10 seconds by a single ICE agent. The question is: is this a tolerable rate? A.4. Comparison: G.711 Audio G.711 audio is commonly used without any congestion feedback mechanisms in place - primarily because it is unflexible and unable Thomson Expires April 22, 2014 [Page 16] Internet-Draft ICE for WebRTC October 2013 to scale its network usage in response to congestion signals. The theory is that it might be acceptable to generate a similar amount of traffic without congestion controls. It should be immediately obvious that this theory has a major flaw. Even though the impact on the network might be similar, G.711 is not sent to an unwilling recipient, whereas no such guarantee can be made for connectivity checks. Assuming 80bit integrity on SRTP, no header extensions and no CSRCs, G.711 produces 84kbps. That would suggest that a single ICE agent with 20ms pacing might be tolerable, at least over short intervals. A.5. Recommended Rate Limits Enforcing a limit of 96kbps would allow for a substantial increase in the size of STUN connectivity check messages without affecting legitimate uses. Over a longer interval, this high rate is likely to be unnecessary. Even with 100 candidate pairs, ICE should complete in between 2 and 5 seconds, especially if candidate pairs are frozen across multiple ICE agents. Providing a lower limit over a 10 to 20 second interval should further limit the damage. Enforcing a longer term limit of 48 kilobytes (every 20 seconds or so) would allow for 6 seconds of continuous checking with the size described above, or 4 seconds of checking at the short term rate limit. Author's Address Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304 US Email: martin.thomson@skype.net Thomson Expires April 22, 2014 [Page 17]