idnits 2.17.1 draft-ietf-rtcweb-stun-consent-freshness-03.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 (May 19, 2014) is 3629 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) == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-02 == Outdated reference: A later version (-18) exists of draft-ietf-tsvwg-rtcweb-qos-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Perumal 3 Internet-Draft D. Wing 4 Intended status: Standards Track R. Ravindranath 5 Expires: November 20, 2014 T. Reddy 6 Cisco Systems 7 M. Thomson 8 Mozilla 9 May 19, 2014 11 STUN Usage for Consent Freshness 12 draft-ietf-rtcweb-stun-consent-freshness-03 14 Abstract 16 To prevent sending excessive traffic to an endpoint, periodic consent 17 needs to be obtained from that remote endpoint. 19 This document describes a consent mechanism using a new STUN usage. 20 This same mechanism can also determine connection loss ("liveness") 21 with a remote peer. 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 November 20, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 3 62 4.2. Immediate Revocation of Consent . . . . . . . . . . . . . 4 63 5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 5 64 6. DiffServ Treatment for Consent packets . . . . . . . . . . . 5 65 7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 11.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Appendix A. Example Implementation . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 To prevent attacks on peers, RTP endpoints have to ensure the remote 78 peer wants to receive traffic. This is performed both when the 79 session is first established to the remote peer using ICE 80 connectivity checks, and periodically for the duration of the session 81 using the procedures defined in this document. 83 When a session is first established, WebRTC implementations are 84 required to perform STUN connectivity checks as part of ICE 85 [RFC5245]. That initial consent is not described further in this 86 document and it is assumed that ICE is being used for that initial 87 consent. 89 Related to consent is loss of connectivity ("liveness"). Many 90 applications want notification of connection loss to take appropriate 91 actions (e.g., alert the user, try switching to a different 92 interface). 94 This document describes a new STUN usage with a request and response 95 messages which verifies the remote peer's consent to receive traffic, 96 and can also detect loss of liveness. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 Consent: It is the mechanism of obtaining permission to send traffic 105 to a certain transport address. This is the initial consent to 106 send traffic, which is obtained by ICE or a TCP handshake. 108 Consent Freshness: Permission to continue sending traffic to a 109 certain transport address. This is performed by the procedure 110 described in this document. 112 Session Liveness: Detecting loss of connectivity to a certain 113 transport address. This is performed by the procedure described 114 in this document. 116 Transport Address: The remote peer's IP address and (UDP or TCP) 117 port number. 119 3. Design Considerations 121 Although ICE requires periodic keepalive traffic to keep NAT bindings 122 alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent 123 as STUN Indications which are send-and-forget, and do not evoke a 124 response. A response is necessary both for consent to continue 125 sending traffic, as well as to verify session liveness. Thus, we 126 need a request/response mechanism for consent freshness. ICE can be 127 used for that mechanism because ICE already requires ICE agents 128 continue listening for ICE messages, as described in section 10 of 129 [RFC5245]. 131 4. Solution Overview 133 There are two ways consent to send traffic is revoked: expiration of 134 consent and immediate revocation of consent, which are discussed in 135 the following sections. 137 4.1. Expiration of Consent 139 A WebRTC browser performs a combined consent freshness and session 140 liveness test using STUN request/response as described below: 142 An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, 143 DTLS) on an ICE-initiated connection unless the receiving endpoint 144 consents to receive the data. After a successful ICE connectivity 145 check on a particular transport address, subsequent consent MUST be 146 obtained following the procedure described in this document. The 147 consent expires after a fixed amount of time. 149 Explicit consent to send is indicated by sending an ICE binding 150 request to the remote peer's Transport Address and receiving a 151 matching and authenticated ICE binding response from the inverted 152 remote peer's Transport Address. These ICE binding requests and 153 responses are authenticated using the same short-term credentials as 154 the initial ICE exchange, but using a new (fresh) transaction-id each 155 time consent needs to be refreshed. Implementations MUST obtain 156 fresh consent before their existing consent expires. If an ICE 157 binding response is not received within 1.5 times the previous round 158 trip time, another ICE binding request is sent using the a new 159 (fresh) transaction-id (so that round-trip time can be calculated), 160 and re-transmissions MUST NOT be sent more frequently than every 161 500ms or the smoothed round-trip time (from previous consent 162 freshness checks or RTP round-trip time), whichever is less. For the 163 purposes of this document, receipt of an ICE response with the 164 matching transaction-id of its request with a valid MESSAGE-INTEGRITY 165 is considered a consent response. 167 The initial Consent to send traffic is obtained by ICE. Consent 168 expires after 30 seconds. That is, if a valid STUN binding response 169 corresponding to one of the STUN requests sent in the last 30 seconds 170 has not been received from the inverted 5-tuple, the endpoint MUST 171 cease transmission on that 5-tuple. 173 To meet the security needs of consent, an untrusted application 174 (e.g., JavaScript) MUST NOT be able to obtain or control the ICE 175 transaction-id, because that enables spoofing STUN responses, 176 falsifying consent 178 An endpoint that is only receiving application traffic (recvonly) 179 does not need to obtain consent which can slightly conserve its 180 resources. However, the endpoint needs to ensure its NAT or firewall 181 mappings persist which can be done using keepalive or other 182 techniques (see Section 10 of [RFC5245] and see [RFC6263]). If the 183 endpoint wants send application traffic, it needs to first obtain 184 consent if its consent expired. 186 4.2. Immediate Revocation of Consent 188 The previous section explained how consent expires due to a timeout. 189 In some cases it is useful to signal a connection is terminated, 190 rather than relying on a timeout. This is done by immediately 191 revoking consent. 193 Consent for sending traffic on the media or data channel is revoked 194 by receipt of a an authenticated message that closes the connection 195 (for instance, a TLS fatal alert). 197 Receipt of an unauthenticated message that closes a connection (e.g., 198 TCP FIN) does not indicate revocation of consent. Thus, an endpoint 199 receiving an unauthenticated end-of-session message SHOULD continue 200 sending media (over connectionless transport) or attempt to re- 201 establish the connection (over connection-oriented transport) until 202 consent expires or it receives an authenticated message revoking 203 consent. 205 5. Connection Liveness 207 A connection is considered "live" if packets are received from a 208 remote endpoint within an application-dependent period. An 209 application can request a notification when there are no packets 210 received for a certain period (configurable). 212 Similarly, if packets haven't been received within a certain period, 213 an application can request a consent check (heartbeat) be generated. 214 These two time intervals might be controlled by the same 215 configuration item. 217 Sending consent checks (heartbeats) at a high rate could allow a 218 malicious application to generate congestion, so applications MUST 219 NOT be able to send heartbeats faster than 1 per second. 221 6. DiffServ Treatment for Consent packets 223 It is RECOMMENDED that STUN consent checks use the same Diffserv 224 Codepoint markings as the media packets sent on that transport 225 address. This follows the recommendation of ICE connectivity check 226 described in section 7.1.2.4 of [RFC5245]. 228 Note: It is possible that different Diffserv Codepoints are used by 229 different media over the same transport address 230 [I-D.ietf-tsvwg-rtcweb-qos]. In that case, what should this document 231 recommend as the Codepoint for STUN consent packets ? 233 7. W3C API Implications 235 For the consent freshness and liveness test the W3C specification 236 should provide APIs as described below: 238 1. Ability for the browser to notify the JavaScript that a consent 239 freshness transaction has failed for a media stream and the 240 browser has stopped transmitting for that stream. 242 2. Ability for the JavaScript to start and stop liveness test and 243 set the liveness test interval. 245 3. Ability for the browser to notify the JavaScript that a liveness 246 test has failed for a media stream. 248 8. Security Considerations 250 This document describes a security mechanism. 252 The security considerations discussed in [RFC5245] should also be 253 taken into account. 255 SRTP is encrypted and authenticated with symmetric keys; that is, 256 both sender and receiver know the keys. With two party sessions, 257 receipt of an authenticated packet from the single remote party is a 258 strong assurance the packet came from that party. However, when a 259 session involves more than two parties, all of whom know each others 260 keys, any of those parties could have sent (or spoofed) the packet. 261 Such shared key distributions are possible with some MIKEY [RFC3830] 262 modes, Security Descriptions [RFC4568], and EKT 263 [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying 264 distributions, receipt of an authenticated SRTP packet is not 265 sufficient. 267 9. IANA Considerations 269 This document does not require any action from IANA. 271 10. Acknowledgement 273 Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus 274 Westerland, Cullen Jennings and Simon Perreault for their valuable 275 inputs and comments. 277 11. References 279 11.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 285 (ICE): A Protocol for Network Address Translator (NAT) 286 Traversal for Offer/Answer Protocols", RFC 5245, April 287 2010. 289 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 290 Keeping Alive the NAT Mappings Associated with RTP / RTP 291 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 293 11.2. Informative References 295 [I-D.ietf-avtcore-srtp-ekt] 296 McGrew, D. and D. Wing, "Encrypted Key Transport for 297 Secure RTP", draft-ietf-avtcore-srtp-ekt-02 (work in 298 progress), February 2014. 300 [I-D.ietf-tsvwg-rtcweb-qos] 301 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 302 other packet markings for RTCWeb QoS", draft-ietf-tsvwg- 303 rtcweb-qos-00 (work in progress), April 2014. 305 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 306 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 307 August 2004. 309 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 310 Description Protocol (SDP) Security Descriptions for Media 311 Streams", RFC 4568, July 2006. 313 Appendix A. Example Implementation 315 This section describes one possible implementation algorithm of 316 consent. This section is non-normative and provided for reference 317 only. 319 The solution uses three values: 321 1. A consent timer, Tc, whose value is set to 30 seconds. 323 2. A packet receipt timer, Tr, whose value is determined by the 324 application. Tr can be greater than 1 but less than 30 seconds 325 and has a default value of 5 seconds. 327 3. A consent timeout, Tf, which is how many seconds elapse without a 328 consent response before the browser ceases transmission of media. 329 Its value is be 30 seconds or less. 331 4. A retransmission Timer, Tret, whose value is determined by the 332 RTT of a given path. The duration of this timer is set to 1.5 333 times of (500 ms or the smoothened round-trip time (from previous 334 consent freshness checks or RTP round-trip time)), whichever is 335 less. 337 A WebRTC browser performs a combined consent freshness and session 338 liveness test using STUN request/response as described below: 340 Every Tc seconds, the WebRTC browser sends a STUN Binding Request to 341 the peer. The difference from ICE connectivity check is that there 342 is no exponential back off for retransmissions. 344 If a valid STUN Binding Response is received, the consent timer is 345 reset to the time of receiving the response and fires again Tc 346 seconds later. 348 If a valid STUN Binding Response is not received after Tret 349 milliseconds, the STUN Binding Request is retransmitted (with a new 350 Transaction ID). As long as a valid STUN Binding Response is not 351 received, this retransmission is repeated every Tret milliseconds 352 until Tf seconds have elapsed or a valid response is received. If no 353 valid response is received after Tf seconds, the WebRTC browser quits 354 transmitting traffic to this remote peer. The streams that are being 355 sent on a flow(5-tuple) for which a consent has failed will be 356 stopped. If the default value of Tf is 30 seconds then media 357 transmission will stop Consent (Tf) expires. 359 Authors' Addresses 361 Muthu Arul Mozhi Perumal 362 Cisco Systems 363 Cessna Business Park 364 Sarjapur-Marathahalli Outer Ring Road 365 Bangalore, Karnataka 560103 366 India 368 Email: mperumal@cisco.com 370 Dan Wing 371 Cisco Systems 372 821 Alder Drive 373 Milpitas, California 95035 374 USA 376 Email: dwing@cisco.com 377 Ram Mohan Ravindranath 378 Cisco Systems 379 Cessna Business Park 380 Sarjapur-Marathahalli Outer Ring Road 381 Bangalore, Karnataka 560103 382 India 384 Email: rmohanr@cisco.com 386 Tirumaleswar Reddy 387 Cisco Systems 388 Cessna Business Park, Varthur Hobli 389 Sarjapur Marathalli Outer Ring Road 390 Bangalore, Karnataka 560103 391 India 393 Email: tireddy@cisco.com 395 Martin Thomson 396 Mozilla 397 Suite 300 398 650 Castro Street 399 Mountain View, California 94041 400 US 402 Email: martin.thomson@gmail.com