idnits 2.17.1 draft-ietf-rtcweb-stun-consent-freshness-12.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 4, 2015) is 3279 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) == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on line 319, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 == Outdated reference: A later version (-18) exists of draft-ietf-tsvwg-rtcweb-qos-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Perumal 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Wing 5 Expires: November 5, 2015 R. Ravindranath 6 T. Reddy 7 Cisco Systems 8 M. Thomson 9 Mozilla 10 May 4, 2015 12 STUN Usage for Consent Freshness 13 draft-ietf-rtcweb-stun-consent-freshness-12 15 Abstract 17 To prevent sending excessive traffic to an endpoint, periodic consent 18 needs to be obtained from that remote endpoint. 20 This document describes a consent mechanism using a new Session 21 Traversal Utilities for NAT (STUN) usage. 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 5, 2015. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 3 62 4.2. Immediate Revocation of Consent . . . . . . . . . . . . . 5 63 5. DiffServ Treatment for Consent . . . . . . . . . . . . . . . 6 64 6. DTLS applicability . . . . . . . . . . . . . . . . . . . . . 6 65 7. API Recommendations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 11.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 To prevent attacks on peers, endpoints have to ensure the remote peer 77 is willing to receive traffic. This is performed both when the 78 session is first established to the remote peer using Interactive 79 Connectivity Establishment ICE [RFC5245] connectivity checks, and 80 periodically for the duration of the session using the procedures 81 defined in this document. 83 When a session is first established, ICE implementations obtain an 84 initial consent to send by performing STUN connectivity checks. This 85 document describes a new STUN usage with exchange of request and 86 response messages that verifies the remote peer's ongoing consent to 87 receive traffic. This consent expires after a period of time and 88 needs to be continually renewed, which ensures that consent can be 89 terminated. 91 This document defines what it takes to obtain, maintain, and lose 92 consent to send. Consent to send applies to a single 5-tuple. How 93 applications react to changes in consent is not described in this 94 document. 96 Consent is obtained only by full ICE implementations. An ICE-lite 97 implementation will not generate consent checks, but will just 98 respond to consent checks it receives. No changes are required to 99 ICE-lite implementations in order to respond to consent checks, as 100 they are processed as normal ICE connectivity checks. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 Consent: The mechanism of obtaining permission to send to a remote 109 transport address. Initial consent is obtained using ICE. 111 Consent Freshness: Maintaining and renewing consent over time. 113 Transport Address: The remote peer's IP address and UDP or TCP port 114 number. 116 3. Design Considerations 118 Although ICE requires periodic keepalive traffic to keep NAT bindings 119 alive (Section 10 of [RFC5245], [RFC6263]), those keepalives are sent 120 as STUN Indications which are send-and-forget, and do not evoke a 121 response. A response is necessary for consent to continue sending 122 traffic. Thus, we need a request/response mechanism for consent 123 freshness. ICE can be used for that mechanism because ICE 124 implementations are already required to continue listening for ICE 125 messages, as described in section 10 of [RFC5245]. If consent is 126 performed then there is no need to send keepalive messages. 128 4. Solution 130 There are two ways consent to send traffic is revoked: expiration of 131 consent and immediate revocation of consent, which are discussed in 132 the following sections. 134 4.1. Expiration of Consent 136 A full ICE implementation performs consent freshness test using STUN 137 request/response as described below: 139 An endpoint MUST NOT send data other than paced STUN connectivity 140 checks or responses toward any transport address unless the receiving 141 endpoint consents to receive data. That is, no application data 142 (e.g., RTP or DTLS) can be sent until consent is obtained. After a 143 successful ICE connectivity check on a particular transport address, 144 consent MUST be maintained following the procedure described in this 145 document. 147 Explicit consent to send is obtained and maintained by sending an 148 STUN binding request to the remote peer's transport address and 149 receiving a matching, authenticated, non-error STUN binding response 150 from the remote peer's transport address. These STUN binding 151 requests and responses are authenticated using the same short-term 152 credentials as the initial ICE exchange. 154 Note: Although TCP has its own consent mechanism (TCP 155 acknowledgements), consent is necessary over a TCP connection 156 because it could be translated to a UDP connection (e.g., 157 [RFC6062]). 159 Initial consent to send traffic is obtained using ICE. Consent 160 expires after 30 seconds. That is, if a valid STUN binding response 161 corresponding to any STUN request sent in the last 30 seconds has not 162 been received from the remote peer's transport address, the endpoint 163 MUST cease transmission on that 5-tuple. STUN consent responses 164 received after consent expiry do not re-establish consent, and may be 165 discarded or cause an ICMP error. 167 To prevent expiry of consent, a STUN binding request can be sent 168 periodically. To prevent synchronization of consent checks, each 169 interval MUST be randomized from between 0.8 and 1.2 times the basic 170 period. Implementations SHOULD set a default interval of 5 seconds, 171 resulting in a period between checks of 4 to 6 seconds. 173 Each STUN binding request for consent MUST use a new 174 cryptographically strong [RFC4086] STUN transaction ID. Each STUN 175 binding requests for consent is transmitted once only. Hence, the 176 sender cannot assume that it will receive a response for each consent 177 request, and a response might be for a previous request (rather than 178 for the most recently sent request). Consent expiration causes 179 immediate termination of all outstanding STUN consent transactions. 180 Each STUN transaction is maintained until one of the following 181 criteria is fulfilled: 183 o A STUN response associated with the transaction is received; or 185 o A STUN response associated to a newer transaction is received. 187 To meet the security needs of consent, an untrusted application 188 (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or 189 control the STUN transaction ID, because that enables spoofing of 190 STUN responses, falsifying consent. 192 To prevent attacks on the peer during ICE restart, an endpoint that 193 continues to send traffic on the previously validated candidate pair 194 during ICE restart MUST continue to perform consent freshness on that 195 candidate pair as described earlier. 197 While TCP affords some protection from off-path attackers ([RFC5961], 198 [RFC4953]), there is still a risk an attacker could cause a TCP 199 sender to send forever by spoofing ACKs. To prevent such an attack, 200 consent checks MUST be performed over all transport connections, 201 including TCP. In this way, an off-path attacker spoofing TCP 202 segments can not cause a TCP sender to send once the consent timer 203 expires (30 seconds). 205 An endpoint that is not sending any application data does not need to 206 maintain consent. However, failure to send could cause any NAT or 207 firewall mappings for the flow to expire. Furthermore, having one 208 peer unable to send is detrimental to many protocols. Absent better 209 information about the network, an endpoint SHOULD maintain consent if 210 there is any possibility that a flow might be needed again. 212 After consent is lost for any reason, the same ICE credentials MUST 213 NOT be used on the affected 5-tuple again. That means that a new 214 session, or an ICE restart, is needed to obtain consent to send. 216 4.2. Immediate Revocation of Consent 218 In some cases it is useful to signal that consent is terminated 219 rather than relying on a timeout. 221 Consent for sending application data is immediately revoked by 222 receipt of an authenticated message that closes the connection (e.g., 223 a TLS fatal alert) or receipt of a valid and authenticated STUN 224 response with error code Forbidden (403). Note however that consent 225 revocation messages can be lost on the network, so an endpoint could 226 resend these messages, or wait for consent to expire. 228 Receipt of an unauthenticated message that closes a connection (e.g., 229 TCP FIN) does not indicate revocation of consent. Thus, an endpoint 230 receiving an unauthenticated end-of-session message SHOULD continue 231 sending media (over connectionless transport) or attempt to re- 232 establish the connection (over connection-oriented transport) until 233 consent expires or it receives an authenticated message revoking 234 consent. 236 Note that an authenticated SRTCP BYE does not terminate consent; it 237 only indicates the associated SRTP source has quit. 239 5. DiffServ Treatment for Consent 241 It is RECOMMENDED that STUN consent checks use the same Diffserv 242 Codepoint markings as the ICE connectivity checks described in 243 Section 7.1.2.4 of [RFC5245] for a given 5-tuple. 245 Note: It is possible that different Diffserv Codepoints are used by 246 different media over the same transport address 247 [I-D.ietf-tsvwg-rtcweb-qos]. Such a case is outside the scope of 248 this document. 250 6. DTLS applicability 252 The DTLS applicability is identical to what is described in 253 Section 4.2 of [RFC7350]. 255 7. API Recommendations 257 The W3C specification [W3C-WEBRTC] may provide an API hook that 258 generates an event when consent has expired for a given 5-tuple, 259 meaning that transmission of data has ceased. This could indicate 260 what application data is affected, such as media or data channels. 262 8. Security Considerations 264 This document describes a security mechanism. 266 The security considerations discussed in [RFC5245] should also be 267 taken into account. 269 SRTP is encrypted and authenticated with symmetric keys; that is, 270 both sender and receiver know the keys. With two party sessions, 271 receipt of an authenticated packet from the single remote party is a 272 strong assurance the packet came from that party. However, when a 273 session involves more than two parties, all of whom know each others 274 keys, any of those parties could have sent (or spoofed) the packet. 275 Such shared key distributions are possible with some MIKEY [RFC3830] 276 modes, Security Descriptions [RFC4568], and EKT 277 [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying 278 distributions, receipt of an authenticated SRTP packet is not 279 sufficient to verify consent. 281 9. IANA Considerations 283 This document does not require any action from IANA. 285 10. Acknowledgement 287 Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus 288 Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul 289 Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan 290 Banavi and Christian Groves for their valuable inputs and comments. 291 Thanks to Christer Holmberg for doing a through review. 293 11. References 295 11.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 301 Requirements for Security", BCP 106, RFC 4086, June 2005. 303 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 304 (ICE): A Protocol for Network Address Translator (NAT) 305 Traversal for Offer/Answer Protocols", RFC 5245, April 306 2010. 308 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 309 Keeping Alive the NAT Mappings Associated with RTP / RTP 310 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 312 11.2. Informative References 314 [I-D.ietf-avtcore-srtp-ekt] 315 Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key 316 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03 317 (work in progress), October 2014. 319 [I-D.ietf-rtcweb-overview] 320 Alvestrand, H., "Overview: Real Time Protocols for 321 Browser-based Applications", draft-ietf-rtcweb-overview-13 322 (work in progress), November 2014. 324 [I-D.ietf-tsvwg-rtcweb-qos] 325 Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. 326 Polk, "DSCP and other packet markings for RTCWeb QoS", 327 draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), 328 November 2014. 330 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 331 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 332 August 2004. 334 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 335 Description Protocol (SDP) Security Descriptions for Media 336 Streams", RFC 4568, July 2006. 338 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 339 4953, July 2007. 341 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 342 Robustness to Blind In-Window Attacks", RFC 5961, August 343 2010. 345 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 346 around NAT (TURN) Extensions for TCP Allocations", RFC 347 6062, November 2010. 349 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 350 Layer Security (DTLS) as Transport for Session Traversal 351 Utilities for NAT (STUN)", RFC 7350, August 2014. 353 [W3C-WEBRTC] 354 Bergkvist, A., Burnett, D., Narayanan, A., and C. 355 Jennings, "WebRTC 1.0: Real-time Communication Between 356 Browsers", february 2015. 358 Authors' Addresses 360 Muthu Arul Mozhi Perumal 361 Ericsson 362 Ferns Icon 363 Doddanekundi, Mahadevapura 364 Bangalore, Karnataka 560037 365 India 367 Email: muthu.arul@gmail.com 369 Dan Wing 370 Cisco Systems 371 821 Alder Drive 372 Milpitas, California 95035 373 USA 375 Email: dwing@cisco.com 376 Ram Mohan Ravindranath 377 Cisco Systems 378 Cessna Business Park 379 Sarjapur-Marathahalli Outer Ring Road 380 Bangalore, Karnataka 560103 381 India 383 Email: rmohanr@cisco.com 385 Tirumaleswar Reddy 386 Cisco Systems 387 Cessna Business Park, Varthur Hobli 388 Sarjapur Marathalli Outer Ring Road 389 Bangalore, Karnataka 560103 390 India 392 Email: tireddy@cisco.com 394 Martin Thomson 395 Mozilla 396 Suite 300 397 650 Castro Street 398 Mountain View, California 94041 399 US 401 Email: martin.thomson@gmail.com