idnits 2.17.1 draft-muthu-behave-consent-freshness-01.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 (July 16, 2012) is 4273 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 339, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 342, 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: January 17, 2013 Cisco Systems 5 H. Kaplan 6 Acme Packet 7 July 16, 2012 9 STUN Usage for Consent Freshness and Session Liveness 10 draft-muthu-behave-consent-freshness-01 12 Abstract 14 Verification of peer consent is necessary in WebRTC deployments to 15 ensure that a malicious JavaScript cannot use the browser as a 16 platform for launching attacks. A related problem is session 17 liveness. WebRTC applications may want to detect connection failure 18 and take appropriate actions. This document describes a STUN usage 19 that enables a WebRTC browser to perform the following on a candidate 20 pair ICE is using for a media component after session establishment: 22 1. Verify the peer consent for continuing to receive traffic. 23 2. Dectect connection failure. 25 This also serves the purpose of refreshing NAT bindings. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 17, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Design Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. STUN Consent Method . . . . . . . . . . . . . . . . . . . . . . 5 67 7. STUN Consent Method Processing . . . . . . . . . . . . . . . . 6 68 7.1. Generating a Consent Request . . . . . . . . . . . . . . . 6 69 7.2. Receiving a Consent Request . . . . . . . . . . . . . . . . 6 70 7.3. Generating a Consent Response . . . . . . . . . . . . . . . 7 71 7.4. Receiving a Consent Response . . . . . . . . . . . . . . . 7 72 8. Performing Consent Freshness . . . . . . . . . . . . . . . . . 7 73 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10. Generating Consent Freshness Response . . . . . . . . . . . . . 7 75 11. SDP Extension for Consent Freshness . . . . . . . . . . . . . . 7 76 12. Interaction with Keepalives used for Refreshing NAT 77 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 13. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 81 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 82 17. Normative References . . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 Consent verification is the mechanism using which WebRTC 88 implementations can verify the peer consent for receiving traffic on 89 candidate media transport addresses. This has two parts 91 1. Verifying peer consent for receiving traffic on candidate media 92 transport addresses at session establishment. 93 2. Verifying peer consent for continuing to receive traffic on 94 candidate media transport addresses after session establishment. 96 WebRTC implements are required to perform STUN connectivity checks at 97 session establishment as part of ICE procedures [RFC5245]. This 98 takes care of the first part of the consent verification described 99 above. 101 After session establishment ICE requires STUN Binding indications to 102 be used for refreshing NAT bindings for a candidate pair ICE is using 103 for a media component. Since a STUN Binding indication does not 104 evoke a response, it cannot be used for the second part of the 105 consent verification describes above. 107 A related problem is session liveness. WebRTC applications may want 108 to detect connection failure on candidate media transport addresses 109 after session establishment and take appropriate actions. Again, the 110 STUN Binding indications in ICE sent after session establishment 111 cannot be used for determining session liveness. 113 This document describes a STUN usage based on STUN request/response 114 that enables a WebRTC browser to perform the following on a candidate 115 pair ICE is using for a media component after session establishment: 117 1. Verify the peer consent for continuing to receive traffic. 118 2. Dectect connection failure. 120 This also serves the purpose of refreshing NAT bindings. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Definitions 129 Consent Freshness: It is the mechanism of verifying peer consent for 130 continuing to receive traffic on a candidate pair ICE is using for 131 a media component after ICE has concluded. This document uses 132 completion of session establishment synonymous with the conclusion 133 of ICE. 135 Session Liveness: It is the mechanism of detecting connectivity on a 136 candidate pair ICE is using for a media component after ICE has 137 concluded. 139 Transport Address: The combination of an IP address and port number 140 (such as a UDP or TCP port number). 142 4. Solution Overview 144 The solution uses two timers: 145 1. A consent timer Tc whose value is determined by the browser. 146 2. A packet receipt timer whose value is determined by the 147 application. 149 A WebRTC browser performs a combined consent freshness and session 150 liveness test using STUN resuest/respose as described below: 152 o Starts a consent timer Tc (no less than 15 sec). 153 o Starts a packet receipt timer Tr (no less than 500 msec); 154 application configurable. 155 o When either timer expires it starts a STUN transaction. 156 o When the STUN transaction succeeds, it re-starts both timers. 157 o When the STUN transaction fails 158 * If the transaction was started by timer Tc, it stops sending 159 traffic on that candidate pair. 160 * Else, it notifies the application of the failure and continues. 161 o It resets timer Tr on receiving any packet from the other side. 163 While consent freshness serves as a circuit breaker (if there is a 164 failure the WebRTC browser stops sending all traffic on that 165 candidate pair), determining session liveness serves the purpose of 166 notifying the application of connectivity failure so that the 167 application can take appropriate action. 169 5. Design Considerations 171 As described earlier in this document, STUN indications are not 172 suitable for performing consent freshness. Hence, performing consent 173 freshness requires the use of STUN request/response. 175 ICE requires the usage of message integrity with STUN using its 176 short-term credential mechanism. The need for this mechanism goes 177 beyond just security and is required for the correct operation of the 178 ICE connectivity check procedures; without message integrity the 179 connectivity checks can yield false positives, as described in 180 Appendix B section B.4 of RFC5245. However, this problem is not 181 applicable for consent freshness, since consent freshness is 182 performed only after ICE concludes. 184 One of the reasons for ICE choosing STUN Binding indications for 185 keepalives is because Binding indication allows integrity to be 186 disabled, allowing for better performance. This is useful for large- 187 scale endpoints, such as PSTN gateways and SBCs as described in 188 Appendix B section B.10 of RFC5245 190 STUN requires the 96 bits transaction ID to be uniformly and randomly 191 chosen from the interval 0 .. 2**96-1, and be cryptographically 192 random. This is good enough security against an off-path attacker. 194 Though ICE specifies STUN Binding indications to be used for 195 keepalives, it requires that an agent be prepared to receive 196 connectivity check as well. If a connectivity check is received, a 197 response is generated, but there is no impact on ICE processing, as 198 described in section 10 of RFC5245. 200 Reusing STUN Binding request/response allows browsers to interoperate 201 with existing ICE implementations; even ICE-lite implementations. 202 This is considered very important. 204 Conclusion: Considering all the above, there seems to be a rough 205 consensus in the RTCWEB WG for reusing the STUN Binding request/ 206 response for determining consent freshness and session liveness. The 207 current thought is that the cost of the SHA-1 computation is not a 208 good enough justification for the pain a new method would cause with 209 existing IEC implementations. 211 6. STUN Consent Method 213 The STUN message type field from the STUN specification [RFC5389] is 214 shown below 215 2 3 4 5 6 7 8 9 A B C D E F 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |M|M|M|M|M|C|M|M|M|C|M|M|M|M| 219 |b|a|9|8|7|1|6|5|4|0|3|2|1|0| 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: Format of STUN Message Type Field 224 Here the bits in the message type field are shown as most significant 225 (Mb) through least significant (M0). C1 and C0 represent a 2-bit 226 encoding of the class. Mb through M0 represent a 12-bit encoding of 227 the method. The Consent method is encoded as 0b000000000010. 229 A Consent request has class=0b00 (request) and method=0b000000000010 230 (Consent) and is encoded into the first 16 bits of the STUN header as 231 0x0002. 233 A Consent success response has class=0b10 (success response) and 234 method=0b000000000010 (Consent) and is encoded into the first 16 bits 235 of the STUN header as 0x0102. 237 A Consent error response has class=0b11 (error response) and 238 method=0b000000000010 (Consent) and is encoded into the first 16 bits 239 of the STUN header as 0x0112. 241 A Consent indication has class=0b01 (indication) and 242 method=0b000000000010 (Consent) and is encoded into the first 16 bits 243 of the STUN header as 0x0012. 245 7. STUN Consent Method Processing 247 Processing of the STUN Consent method is similar to the processing of 248 the STUN Binding method except that the procedures pertaining to the 249 message integrity and short/long-term credential mechanisms are not 250 applicable. In particular, the USERNAME and MESSAGE-INTEGRITY 251 attributes are not included in a Consent request or response. 253 7.1. Generating a Consent Request 255 TBD 257 7.2. Receiving a Consent Request 259 TBD 261 7.3. Generating a Consent Response 263 TBD 265 7.4. Receiving a Consent Response 267 TBD 269 8. Performing Consent Freshness 271 TBD 273 9. Examples 275 TBD 277 10. Generating Consent Freshness Response 279 A STUN agent receiving a consent freshness request for a candidate 280 pair ICE is using for a media component MUST generate a STUN Consent 281 response. 283 11. SDP Extension for Consent Freshness 285 TBD 287 12. Interaction with Keepalives used for Refreshing NAT Bindings 289 An implementation that performs the procedures described in this 290 document has no need to also perform the keepalives described in ICE 291 [RFC5245] or RTP keepalive [RFC6263], as they both force recurring 292 messages to be sent over the UDP port used by RTP. Thus, an 293 implementation that performs the procedures described in this 294 document SHOULD NOT also do the keepalives described in ICE [RFC5245] 295 or RTP keepalives [RFC6263] for the UDP port used for RTP. 297 13. Open Items 299 1. Should STUN Binding request/response be reused for determining 300 consent freshness and session liveness, considering 301 interoperability with existing ICE and ICE-lite implementation 302 even at the cost of the incurred SHA-1 computation? 304 2. If the RTCP port is different from the RTP port, does RTCP need 305 consent freshness and session liveness tests? 307 14. Security Considerations 309 TBD 311 15. IANA Considerations 313 TBD 315 16. Acknowledgement 317 Thanks to Eric Rescorla, Harald Alvestrand, Martin Thomson, Bernard 318 Aboba, Cullen Jennings and Simon Perreault for their valuable inputs 319 and comments 321 17. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 327 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 328 October 2008. 330 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 331 (ICE): A Protocol for Network Address Translator (NAT) 332 Traversal for Offer/Answer Protocols", RFC 5245, 333 April 2010. 335 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 336 Keeping Alive the NAT Mappings Associated with RTP / RTP 337 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 339 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 340 Description Protocol", RFC 4566, July 2006. 342 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 343 with Session Description Protocol (SDP)", RFC 3264, 344 June 2002. 346 Authors' Addresses 348 Muthu Arul Mozhi Perumal 349 Cisco Systems 350 Cessna Business Park 351 Sarjapur-Marathahalli Outer Ring Road 352 Bangalore, Karnataka 560103 353 India 355 Email: mperumal@cisco.com 357 Dan Wing 358 Cisco Systems 359 821 Alder Drive 360 Milpitas, California 95035 361 USA 363 Email: dwing@cisco.com 365 Ram Mohan R 366 Cisco Systems 367 Cessna Business Park 368 Sarjapur-Marathahalli Outer Ring Road 369 Bangalore, Karnataka 560103 370 India 372 Email: rmohanr@cisco.com 374 Hadriel Kaplan 375 Acme Packet 377 Email: hkaplan@acmepacket.com