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