idnits 2.17.1 draft-ietf-rtcweb-stun-consent-freshness-02.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 (April 11, 2014) is 3669 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: October 13, 2014 T. Reddy 6 Cisco Systems 7 M. Thomson 8 Mozilla 9 April 11, 2014 11 STUN Usage for Consent Freshness 12 draft-ietf-rtcweb-stun-consent-freshness-02 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 October 13, 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 5. Connection Liveness . . . . . . . . . . . . . . . . . . . . . 4 62 6. DiffServ Treatment for Consent packets . . . . . . . . . . . 5 63 7. W3C API Implications . . . . . . . . . . . . . . . . . . . . 5 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 11.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 To prevent attacks on peers, RTP endpoints have to ensure the remote 75 peer wants to receive traffic. This is performed both when the 76 session is first established to the remote peer using ICE 77 connectivity checks, and periodically for the duration of the session 78 using the procedures defined in this document. 80 When a session is first established, WebRTC implementations are 81 required to perform STUN connectivity checks as part of ICE 82 [RFC5245]. That initial consent is not described further in this 83 document and it is assumed that ICE is being used for that initial 84 consent. 86 Related to consent is loss of connectivity ("liveness"). Many 87 applications want notification of connection loss to take appropriate 88 actions (e.g., alert the user, try switching to a different 89 interface). 91 This document describes a new STUN usage with a request and response 92 messages which verifies the remote peer's consent to receive traffic, 93 and can also detect loss of liveness. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 Consent: It is the mechanism of obtaining permission to send traffic 102 to a certain transport address. This is usually obtained via ICE. 104 Consent Freshness: Permission to continue sending traffic to a 105 certain transport address. This is performed by the procedure 106 described in this document. 108 Session Liveness: Detecting loss of connectivity to a certain 109 transport address. This is performed by the procedure described 110 in this document. 112 Transport Address: The remote peer's IP address and (UDP or TCP) 113 port number. 115 3. Design Considerations 117 Although ICE requires periodic keepalive traffic to keep NAT bindings 118 alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent 119 as STUN Indications which are send-and-forget, and do not evoke a 120 response. A response is necessary both for consent to continue 121 sending traffic, as well as to verify session liveness. Thus, we 122 need a request/response mechanism for consent freshness. ICE can be 123 used for that mechanism because ICE already requires ICE agents 124 continue listening for ICE messages, as described in section 10 of 125 [RFC5245]. 127 4. Solution Overview 129 A WebRTC browser performs a combined consent freshness and session 130 liveness test using STUN request/response as described below: 132 An endpoint MUST NOT send application data (in WebRTC this means RTP 133 or SCTP data) on an ICE-initiated connection unless the receiving 134 endpoint consents to receive the data. After a successful ICE 135 connectivity check on a particular transport address, subsequent 136 consent MUST be obtained following the procedure described in this 137 document. The consent expires after a fixed amount of time. 138 Explicit consent to send is indicated by: 140 1. Sending an ICE binding request to the remote peer's Transport 141 Address and receiving a matching and authenticated ICE binding 142 response from the inverted remote peer's Transport Address. 144 These ICE binding request/response are authenticated using the 145 same short- term credentials as the initial ICE exchange, but 146 using a new (fresh) transaction-id each time consent needs to be 147 refresh. Implementations MUST obtain fresh consent before their 148 existing consent expires. When obtaining fresh consent a STUN 149 connectivity check (or response) could be lost, and re- 150 transmissions MUST use the same STUN transaction-id, and re- 151 transmissions MUST NOT be sent more frequently than every 500ms 152 or the smoothed round-trip time (from previous consent freshness 153 checks or RTP round-trip time), whichever is less. For the 154 purposes of this document, receipt of an ICE response with the 155 matching transaction-id of its request with a valid MESSAGE- 156 INTEGRITY is considered an authenticated packet. 158 Consent expires after 15 seconds. That is, if an authenticated 159 packet (e.g., DTLS, SRTP, ICE) has not been received from the 160 inverted 5-tuple after 15 seconds, the application MUST cease 161 transmission on that 5-tuple. 163 Consent is ended immediately by receipt of a an authenticated message 164 that closes the connection (for instance, a TLS fatal alert). 166 Receipt of an unauthenticated end-of-session message (e.g., TCP FIN) 167 does not indicate loss of consent. Thus, an endpoint receiving an 168 unauthenticated end-of-session message SHOULD continue sending media 169 (over connectionless transport) or attempt to re-establish the 170 connection (over connection-oriented transport) until consent expires 171 or it receives an authenticated message revoking consent. 173 Although receiving authenticated packets is sufficient for consent, 174 it is still RECOMMENDED to send messages to keep NAT or firewall 175 bindings alive (see Section 10 of [RFC5245] and [RFC6263]). 177 To meet the security needs of consent, an implementation MUST ensure 178 that an application (e.g., Javascript application) is not able to 179 obtain or control STUN information relevant to consent, specifically 180 the ICE transaction-id MUST NOT be accessible to upper-level 181 applications. 183 5. Connection Liveness 185 A connection is considered "live" if packets are received from a 186 remote endpoint within an application-dependent period. An 187 application can request a notification when there are no packets 188 received for a certain period (configurable). 190 Similarly, if packets haven't been received within a certain period, 191 an application can request a consent check (heartbeat) be generated. 193 These two time intervals might be controlled by the same 194 configuration item. 196 Sending consent checks (heartbeats) at a high rate could allow a 197 malicious application to generate congestion, so applications MUST 198 NOT be able to send heartbeats faster than 1 per second. 200 6. DiffServ Treatment for Consent packets 202 It is RECOMMENDED that STUN consent checks use the same Diffserv 203 Codepoint markings as the media packets sent on that transport 204 address. This follows the recommendation of ICE connectivity check 205 described in section 7.1.2.4 of [RFC5245]. 207 Note: It is possible that different Diffserv Codepoints are used by 208 different media over the same transport address 209 [I-D.ietf-tsvwg-rtcweb-qos]. In that case, what should this document 210 recommend as the Codepoint for STUN consent packets ? 212 7. W3C API Implications 214 For the consent freshness and liveness test the W3C specification 215 should provide APIs as described below: 217 1. Ability for the browser to notify the JavaScript that a consent 218 freshness transaction has failed for a media stream and the 219 browser has stopped transmitting for that stream. 221 2. Ability for the JavaScript to start and stop liveness test and 222 set the liveness test interval. 224 3. Ability for the browser to notify the JavaScript that a liveness 225 test has failed for a media stream. 227 8. Security Considerations 229 This document describes a security mechanism. 231 The security considerations discussed in [RFC5245] should also be 232 taken into account. 234 SRTP is encrypted and authenticated with symmetric keys; that is, 235 both sender and receiver know the keys. With two party sessions, 236 receipt of an authenticated packet from the single remote party is a 237 strong assurance the packet came from that party. However, when a 238 session involves more than two parties, all of whom know each others 239 keys, any of those parties could have sent (or spoofed) the packet. 240 Such shared key distributions are possible with some MIKEY [RFC3830] 241 modes, Security Descriptions [RFC4568], and EKT 242 [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying 243 distributions, receipt of an authenticated SRTP packet is not 244 sufficient. 246 9. IANA Considerations 248 This document does not require any action from IANA. 250 10. Acknowledgement 252 Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus 253 Westerland, Cullen Jennings and Simon Perreault for their valuable 254 inputs and comments. 256 11. References 258 11.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 264 (ICE): A Protocol for Network Address Translator (NAT) 265 Traversal for Offer/Answer Protocols", RFC 5245, April 266 2010. 268 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 269 Keeping Alive the NAT Mappings Associated with RTP / RTP 270 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 272 11.2. Informative References 274 [I-D.ietf-avtcore-srtp-ekt] 275 McGrew, D. and D. Wing, "Encrypted Key Transport for 276 Secure RTP", draft-ietf-avtcore-srtp-ekt-02 (work in 277 progress), February 2014. 279 [I-D.ietf-tsvwg-rtcweb-qos] 280 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 281 other packet markings for RTCWeb QoS", draft-ietf-tsvwg- 282 rtcweb-qos-00 (work in progress), April 2014. 284 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 285 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 286 August 2004. 288 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 289 Description Protocol (SDP) Security Descriptions for Media 290 Streams", RFC 4568, July 2006. 292 Authors' Addresses 294 Muthu Arul Mozhi Perumal 295 Cisco Systems 296 Cessna Business Park 297 Sarjapur-Marathahalli Outer Ring Road 298 Bangalore, Karnataka 560103 299 India 301 Email: mperumal@cisco.com 303 Dan Wing 304 Cisco Systems 305 821 Alder Drive 306 Milpitas, California 95035 307 USA 309 Email: dwing@cisco.com 311 Ram Mohan Ravindranath 312 Cisco Systems 313 Cessna Business Park 314 Sarjapur-Marathahalli Outer Ring Road 315 Bangalore, Karnataka 560103 316 India 318 Email: rmohanr@cisco.com 320 Tirumaleswar Reddy 321 Cisco Systems 322 Cessna Business Park, Varthur Hobli 323 Sarjapur Marathalli Outer Ring Road 324 Bangalore, Karnataka 560103 325 India 327 Email: tireddy@cisco.com 328 Martin Thomson 329 Mozilla 330 Suite 300 331 650 Castro Street 332 Mountain View, California 94041 333 US 335 Email: martin.thomson@gmail.com