idnits 2.17.1 draft-ietf-rtcweb-stun-consent-freshness-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2013) is 3861 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Muthu. Perumal 3 Internet-Draft D. Wing 4 Intended status: Standards Track R. Ravindranath 5 Expires: March 24, 2014 T. Reddy 6 Cisco Systems 7 September 20, 2013 9 STUN Usage for Consent Freshness 10 draft-ietf-rtcweb-stun-consent-freshness-00 12 Abstract 14 Verification of peer consent before sending traffic is necessary in 15 WebRTC deployments to ensure that a malicious JavaScript cannot use 16 the browser as a platform for launching attacks. A related problem 17 is session liveness. WebRTC application may want to detect 18 connection failure and take appropriate action. 20 This document describes how a WebRTC browser can verify peer consent 21 to continue sending traffic and detect connection failure. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 61 5. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 62 6. Interaction with Keepalives used for Refreshing NAT Bindings 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 66 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 To prevent attacks on WebRTC peers, WebRTC browsers have to ensure 72 the remote peer wants to receive traffic. This is performed both 73 when the session is first established to the remote peer (using ICE 74 connectivity checks), and periodically for the duration of the 75 session (using the procedure defined in this document). 77 When a session is first established, WebRTC implementations are 78 required to perform STUN connectivity checks as part of ICE 79 [RFC5245]. That initial consent is not described further in this 80 document. 82 Related to consent is loss of connectivity ("liveness"). WebRTC 83 applications want notification of connection failure to take 84 appropriate actions (e.g., alert the user, try switching to a 85 different interface). 87 This document describes a new STUN usage with a request and response 88 which verifies the remote peer consents to receive traffic, and 89 detects loss of liveness. To meet the security needs of consent, the 90 JavaScript application has no control over the consent requests or 91 the requirement to receive a consent response. However, the 92 JavaScript does get notification of consent failure and loss of 93 connectivity. 95 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 Consent: It is the mechanism of obtaining permission from the peer 101 to send traffic on a candidate pair. 103 Consent Freshness: It is the mechanism of obtaining permission from 104 the peer to continue sending traffic on a nominated candidate pair 105 after ICE has concluded. 107 Session Liveness: It is the mechanism of detecting connectivity on a 108 nominated candidate pair after ICE has concluded. 110 Transport Address: The combination of an IP address and port number 111 (such as a UDP or TCP port number). 113 3. Design Considerations 115 Although ICE requires periodic keepalive traffic to be sent in order 116 to keep NAT bindings alive (Section 10 of [RFC5245], [RFC6263]), 117 those keepalives are send-and-forget, and do not evoke a response. A 118 response is necessary both for consent to continue sending traffic, 119 as well as to ensure connectivity. Thus, we need a request/response 120 mechanism. 122 Though ICE specifies STUN Binding indications to be used for 123 keepalives, it requires that an agent be prepared to receive 124 connectivity check as well. If a connectivity check is received, a 125 response is generated and there is no impact on ICE processing, as 126 described in section 10 of [RFC5245]. 128 The above considerations suggest that STUN Binding request/response 129 is most suitable for performing consent freshness. 131 4. Solution Overview 133 Consent freshness serves as a circuit breaker (so that if the path or 134 remote peer fails the WebRTC browser stops sending all traffic on 135 that remote peer), determining session liveness serves the purpose of 136 notifying the application of connectivity failure so that the 137 application can take appropriate action. 139 The solution uses three values: 141 1. A consent timer, Tc, whose value is determined by the browser. 142 This value MUST be 15 seconds. 144 2. A packet receipt timer, Tr, whose value is determined by the 145 application, but MUST NOT be shorter than 1 second or longer than 146 15 seconds, and SHOULD have a default value of 5 seconds. 148 3. A consent timeout, Tf, which is how many seconds elapse without a 149 consent response before the browser ceases transmission of media. 150 Its value MUST be 15 seconds or less, and the value 15 seconds is 151 RECOMMENDED. 153 A WebRTC browser performs a combined consent freshness and session 154 liveness test using STUN request/response as described below: 156 Every Tc seconds, the WebRTC browser sends a STUN Binding Request to 157 the peer. This request MUST use a new, cryptographically random 158 Transaction ID [RFC4086], and is formatted as for an ICE connectivity 159 check [RFC5245]. A valid STUN Binding Response is also formatted as 160 for an ICE connectivity check [RFC5245]. The STUN Binding Request 161 and STUN Binding Response are validated as for an ICE connectivity 162 check [RFC5245]. The difference from ICE connectivity check is that 163 there is no exponential back off for retransmissions. 165 If a valid STUN Binding Response is received, the consent timer is 166 reset and fires again Tc seconds later. 168 If a valid STUN Binding Response is not received after 500ms, the 169 STUN Binding Request is retransmitted (with the same Transaction ID 170 and all other fields). As long as a valid STUN Binding Response is 171 not received, this retransmission is repeated every 500ms until Tf 172 seconds have elapsed or a valid response is received. If no valid 173 response is received after Tf seconds, the WebRTC browser MUST quit 174 transmitting traffic to this remote peer. Considering the default 175 value of Tf=15 seconds, this means transmission will stop after 30 176 consent check packets have resulted in no response. 178 Liveness timer: If no packets have been received on the local port in 179 Tr seconds, the WebRTC browser MUST inform the JavaScript that 180 connectivity has been lost. The JavaScript application will use this 181 notification however it desires (e.g., cease transmitting to the 182 remote peer, provide a notification to the user, etc.). Note the 183 definition of a received packet is liberal, and includes an SRTP 184 packet that fails authentication, a STUN Binding Request with an 185 invalid USERNAME or PASSWORD, or any other packet. 187 5. W3C API Implications 189 For the consent freshness and liveness test the W3C specification 190 should provide APIs as described below: 192 1. Ability for the browser to notify the JavaScript that a consent 193 freshness transaction has failed for a media stream and the 194 browser has stopped transmitting for that stream. 196 2. Ability for the JavaScript to start and stop liveness test and 197 set the liveness test interval. 199 3. Ability for the browser to notify the JavaScript that a liveness 200 test has failed for a media stream. 202 6. Interaction with Keepalives used for Refreshing NAT Bindings 204 When not actively sending traffic on a nominated candidate pair, 205 performing consent freshness does not serve any purpose from a 206 security perspective. If consent freshness is not performed during 207 this period, the browser continues to performs the ICE keepalives 208 [RFC5245] or RTP keepalive [RFC6263] to refresh NAT bindings. 210 7. Security Considerations 212 Security considerations discussed in [RFC5245] are to be taken into 213 account. 215 The browser MUST use short-term credential to authenticate the STUN 216 messages used for Consent freshness, session liveness and perform 217 message integrity check on STUN binding request/response. 219 8. IANA Considerations 221 This document does not require any action from IANA. 223 9. Acknowledgement 225 Thanks to Eric Rescorla, Harald Alvestrand, Martin Thomson, Bernard 226 Aboba, Cullen Jennings and Simon Perreault for their valuable inputs 227 and comments. 229 10. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 235 Requirements for Security", BCP 106, RFC 4086, June 2005. 237 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 238 (ICE): A Protocol for Network Address Translator (NAT) 239 Traversal for Offer/Answer Protocols", RFC 5245, April 240 2010. 242 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 243 Keeping Alive the NAT Mappings Associated with RTP / RTP 244 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 246 Authors' Addresses 248 Muthu Arul Mozhi Perumal 249 Cisco Systems 250 Cessna Business Park 251 Sarjapur-Marathahalli Outer Ring Road 252 Bangalore, Karnataka 560103 253 India 255 Email: mperumal@cisco.com 257 Dan Wing 258 Cisco Systems 259 821 Alder Drive 260 Milpitas, California 95035 261 USA 263 Email: dwing@cisco.com 265 Ram Mohan Ravindranath 266 Cisco Systems 267 Cessna Business Park 268 Sarjapur-Marathahalli Outer Ring Road 269 Bangalore, Karnataka 560103 270 India 272 Email: rmohanr@cisco.com 273 Tirumaleswar Reddy 274 Cisco Systems 275 Cessna Business Park, Varthur Hobli 276 Sarjapur Marathalli Outer Ring Road 277 Bangalore, Karnataka 560103 278 India 280 Email: tireddy@cisco.com