idnits 2.17.1 draft-muthu-behave-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 (March 4, 2012) is 4434 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: 'RFC4566' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Behave Muthu A M. Perumal 2 Internet-Draft D. Wing 3 Intended status: Standards Track R. Ram Mohan 4 Expires: September 5, 2012 Cisco Systems 5 H. Kaplan 6 Acme Packet 7 March 4, 2012 9 STUN Usage for Consent Freshness 10 draft-muthu-behave-consent-freshness-00 12 Abstract 14 This document describes a STUN usage that enables WebRTC 15 implementations to verify the peer consent for continuing to receive 16 traffic on a candidate pair ICE is using for a media component after 17 session establishment. Verification of peer consent is necessary to 18 ensure that a malicious JavaScript cannot use the browser as a 19 platform for launching attacks. This form of consent verification 20 also serves the purpose of refreshing NAT bindings. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Design Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. STUN Consent Method . . . . . . . . . . . . . . . . . . . . . . 4 61 6. STUN Consent Method Processing . . . . . . . . . . . . . . . . 5 62 6.1. Generating a Consent Request . . . . . . . . . . . . . . . 5 63 6.2. Receiving a Consent Request . . . . . . . . . . . . . . . . 5 64 6.3. Generating a Consent Response . . . . . . . . . . . . . . . 6 65 6.4. Receiving a Consent Response . . . . . . . . . . . . . . . 6 66 7. Performing Consent Freshness . . . . . . . . . . . . . . . . . 6 67 7.1. Generating Consent Freshness Request . . . . . . . . . . . 6 68 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Generating Consent Freshness Response . . . . . . . . . . . . . 7 72 10. SDP Extension for Consent Freshness . . . . . . . . . . . . . . 7 73 11. Interaction with Keepalives used for Refreshing NAT 74 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 12. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 77 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 78 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 79 16. Normative References . . . . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Consent verification is the mechanism using which WebRTC 85 implementations can verify the peer consent for receiving traffic on 86 candidate media transport addresses. This has two parts 88 1. Verifying peer consent for receiving traffic on candidate media 89 transport addresses at session establishment. 90 2. Verifying peer consent for continuing to receive traffic on 91 candidate media transport addresses after session establishment. 93 WebRTC implements are required to perform STUN connectivity checks at 94 session establishment as part of ICE procedures [RFC5245]. This 95 takes care of the first part of the consent verification described 96 above. 98 After session establishment ICE requires STUN Binding indications to 99 be used for refreshing NAT bindings for a candidate pair ICE is using 100 for a media component. Since a STUN Binding indication does not 101 evoke a response, it cannot be used for the second part of the 102 consent verification describes above. 104 This document defines a new STUN method, Consent and describes a STUN 105 usage based on STUN Consent request/response to enable verifying peer 106 consent for continuing to receive traffic on a candidate pair ICE is 107 using for a media component after session establishment. This usage 108 also serves the purpose of refreshing NAT bindings for that candidate 109 pair. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Definitions 119 Consent Freshness: It is the mechanism of verifying peer consent for 120 continuing to receive traffic on a candidate pair ICE is using for 121 a media component after ICE has concluded. This document uses 122 completion of session establishment synonymous with the conclusion 123 of ICE. 125 Transport Address: The combination of an IP address and port number 126 (such as a UDP or TCP port number). 128 4. Design Considerations 130 As described in the Introduction, STUN indications are not suitable 131 for performing consent freshness. Hence, performing consent 132 freshness requires the use of STUN request/response. 134 ICE requires the usage of message integrity with STUN using its 135 short-term credential mechanism. The need for this mechanism goes 136 beyond just security and is required for the correct operation of the 137 ICE connectivity check procedures; without message integrity the 138 connectivity checks can yield false positives, as described in 139 Appendix B section B.4 of the ICE specification. However, this 140 problem is not applicable for consent freshness, since consent 141 freshness is performed only after ICE concludes. 143 One of the reasons for ICE choosing STUN Binding indications for 144 keepalives is because Binding indication allows integrity to be 145 disabled, allowing for better performance. This is useful for large- 146 scale endpoints, such as PSTN gateways and SBCs as described in 147 Appendix B section B.10 of the ICE specification. 149 STUN requires the 96 bits transaction ID to be uniformly and randomly 150 chosen from the interval 0 .. 2**96-1, and be cryptographically 151 random. This is deemed sufficient for consent freshness from a 152 security perspective. 154 Considering these aspects, STUN request/response without the message 155 integrity and short/long-term credential mechanisms have been chosen 156 for consent freshness in this document. In addition, in order to 157 ensure that this STUN usage does not leave an existing ICE 158 implementation broken, this document chooses to define a new STUN 159 method, Consent to be used for consent freshness. 161 5. STUN Consent Method 163 The STUN message type field from the STUN specification [RFC5389] is 164 shown below 165 2 3 4 5 6 7 8 9 A B C D E F 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |M|M|M|M|M|C|M|M|M|C|M|M|M|M| 169 |b|a|9|8|7|1|6|5|4|0|3|2|1|0| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: Format of STUN Message Type Field 174 Here the bits in the message type field are shown as most significant 175 (Mb) through least significant (M0). C1 and C0 represent a 2-bit 176 encoding of the class. Mb through M0 represent a 12-bit encoding of 177 the method. The Consent method is encoded as 0b000000000010. 179 A Consent request has class=0b00 (request) and method=0b000000000010 180 (Consent) and is encoded into the first 16 bits of the STUN header as 181 0x0002. 183 A Consent success response has class=0b10 (success response) and 184 method=0b000000000010 (Consent) and is encoded into the first 16 bits 185 of the STUN header as 0x0102. 187 A Consent error response has class=0b11 (error response) and 188 method=0b000000000010 (Consent) and is encoded into the first 16 bits 189 of the STUN header as 0x0112. 191 A Consent indication has class=0b01 (indication) and 192 method=0b000000000010 (Consent) and is encoded into the first 16 bits 193 of the STUN header as 0x0012. 195 6. STUN Consent Method Processing 197 Processing of the STUN Consent method is similar to the processing of 198 the STUN Binding method except that the procedures pertaining to the 199 message integrity and short/long-term credential mechanisms are not 200 applicable. In particular, the USERNAME and MESSAGE-INTEGRITY 201 attributes are not included in a Consent request or response. 203 6.1. Generating a Consent Request 205 TBD 207 6.2. Receiving a Consent Request 209 TBD 211 6.3. Generating a Consent Response 213 TBD 215 6.4. Receiving a Consent Response 217 TBD 219 7. Performing Consent Freshness 221 The consent freshness described here is performed using STUN Consent 222 request/response after ICE concludes. The FINGERPRINT mechanism MUST 223 be used for consent freshness. 225 7.1. Generating Consent Freshness Request 227 A STUN agent generates a consent freshness request by constructing a 228 STUN Consent request. If there has been no STUN Consent request 229 generated on a candidate pair ICE is using for a media component for 230 Tc seconds, the agent MUST generate a consent freshness request. 232 If the transaction fails because all retransmissions of the request 233 time out or an ICMP error or a Consent failure received, then the 234 agent checks if Tm seconds have elapsed since the transaction began. 235 If Tm seconds have elapsed, then consent freshness is considered to 236 have failed in the direction from the agent to its peer. Otherwise, 237 the agent retries the Consent request after Tc seconds. 239 If the second transaction also fails, then the agent checks if Tm 240 seconds have elapsed since the first transaction began. If Tm 241 seconds have elapsed, then consent freshness is considered to have 242 failed in the direction from the agent to its peer. Otherwise, the 243 agent retries the Consent request again after Tc seconds. 245 If the third transaction also fails, then consent freshness is 246 considered to have failed in the direction from the agent to its 247 peer. 249 If consent freshness fails either because of Tm seconds elapsing or 250 the all retries exhausting, the agent MUST stop sending traffic on 251 that candidate pair. However, the agent MAY continue to receive 252 traffic from the peer. At this point, if a consent freshness 253 initiated from the peer succeeds, the agent MAY initiate a consent 254 freshness request. If this consent freshness request succeeds, the 255 agent MAY start sending traffic to the peer on this candidate pair. 257 Both Tc and Tm SHOULD be configurable. Tc SHOULD have a default of 258 15 seconds and MUST NOT be configured to less than 15 seconds. Tm 259 SHOULD have a default of 30 seconds. 261 8. Examples 263 The examples in this section show how consent freshness requests are 264 retried with Tc and Tm set to their default values. 266 8.1. Example 1 268 Suppose the consent freshness requests generated by an agent evoke an 269 ICM error almost immediately every time. Then the agent will retry 270 the requests at times 15 seconds and 30 seconds approximately before 271 concluding the consent freshness to have failed in the direction from 272 the agent to its peer. 274 8.2. Example 2 276 Suppose the STUN RTO (Retransmission TimeOut) is 500 ms. Then an 277 agent initiating consent freshness will retransmit the request at 500 278 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the agent 279 has not received a response after 39500 ms, the agent will consider 280 the transaction to have timed out, as described in section 7.2.1 of 281 the STUN specification. At this point, since Tm seconds have elapsed 282 since the transaction began, the agent will consider the consent 283 freshness to have failed in the direction from the agent to its peer. 285 9. Generating Consent Freshness Response 287 A STUN agent receiving a consent freshness request for a candidate 288 pair ICE is using for a media component MUST generate a STUN Consent 289 response. 291 10. SDP Extension for Consent Freshness 293 ICE provides the a=ice-options SDP attribute for defining new ICE 294 extensions in a backward compatible manner. This document defines a 295 new ICE extension "consent" to negotiate the consent freshness usage 296 described in this document. 298 An offerer that supports ICE and wishes to perform the consent 299 freshness as described in this document MUST include the a=ice- 300 options:consent session level SDP attribute in the SDP offer. 302 An answerer that agrees to perform consent freshness as described in 303 this document MUST include the a=ice-options:consent session level 304 SDP attribute in the SDP answer. 306 If the SDP offer does not contain the a=ice-options:consent session 307 level SDP attribute, the SDP answer MUST NOT contain the a=ice- 308 options:consent session level SDP attribute. 310 11. Interaction with Keepalives used for Refreshing NAT Bindings 312 An implementation that uses the consent freshness described in this 313 document has no need to also perform the keepalives described in ICE 314 [RFC5245] or RTP keepalive [RFC6263], as they both force recurring 315 messages to be sent over the UDP port used by RTP. Thus, an 316 implementation that uses the consent freshness described in this 317 document SHOULD NOT also do the keepalives described in ICE [RFC5245] 318 or RTP keepalives [RFC6263] for the UDP port used for RTP. 320 The RTCP port, if different from the RTP port, does not need consent 321 freshness (does it?) and continues to use the keepalives described in 322 ICE [RFC5245] or RTP keepalives [RFC6263] to refresh NAT bindings. 324 12. Open Items 326 1. This document describes a consent freshness mechanism for an ICE 327 usage. Is there a need for consent freshness even when ICE is 328 not used (certainly not for WebRTC where ICE is mandatory)? 329 2. If the RTCP port is different from the RTP port, does the RTCP 330 port need consent freshness? It looks unlikely given that RTCP 331 is typically rate limited. 333 13. Security Considerations 335 TBD 337 14. IANA Considerations 339 TBD 341 15. Acknowledgement 343 TBD 345 16. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 351 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 352 October 2008. 354 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 355 (ICE): A Protocol for Network Address Translator (NAT) 356 Traversal for Offer/Answer Protocols", RFC 5245, 357 April 2010. 359 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 360 Keeping Alive the NAT Mappings Associated with RTP / RTP 361 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 363 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 364 Description Protocol", RFC 4566, July 2006. 366 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 367 with Session Description Protocol (SDP)", RFC 3264, 368 June 2002. 370 Authors' Addresses 372 Muthu Arul Mozhi Perumal 373 Cisco Systems 374 Cessna Business Park 375 Sarjapur-Marathahalli Outer Ring Road 376 Bangalore, Karnataka 560103 377 India 379 Email: mperumal@cisco.com 381 Dan Wing 382 Cisco Systems 383 821 Alder Drive 384 Milpitas, California 95035 385 USA 387 Email: dwing@cisco.com 388 Ram Mohan R 389 Cisco Systems 390 Cessna Business Park 391 Sarjapur-Marathahalli Outer Ring Road 392 Bangalore, Karnataka 560103 393 India 395 Email: rmohanr@cisco.com 397 Hadriel Kaplan 398 Acme Packet 400 Email: hkaplan@acmepacket.com