1 / 20

July 30, 2012 IETF -84 Vancouver, BC, Canada

RTCWEB STUN Usage for Consent Freshness and Session Liveness draft- muthu -behave-consent-freshness-01. July 30, 2012 IETF -84 Vancouver, BC, Canada. Authors: D. Wing, Muthu A M. Perumal, R. Ram Mohan, H. Kaplan. What is “Consent”. Purpose of Consent: avoid denial of service Consent

bozica
Télécharger la présentation

July 30, 2012 IETF -84 Vancouver, BC, Canada

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RTCWEBSTUN Usage for Consent Freshness and Session Livenessdraft-muthu-behave-consent-freshness-01 July 30, 2012 IETF-84 Vancouver, BC, Canada Authors: D. Wing, Muthu A M. Perumal, R. Ram Mohan, H. Kaplan draft-muthu-behave-consent-freshness-01

  2. What is “Consent” • Purpose of Consent: avoid denial of service • Consent • Permission to send traffic • Consent freshness • Permission to continue sending traffic • Traffic sender requests consent of the receiver draft-muthu-behave-consent-freshness-01

  3. Problem Description (1/3) draft-muthu-behave-consent-freshness-01

  4. Our Approach to Consent • Use ICE Connectivity Checks • RTCWEB needs ICE anyway • Transaction-ID protects from off-path attackers • No longer need ICE ‘indications’ for firewall and NAT keepalives • RFC6263 • Instead, keepalive using connectivity checks • Provides both Consent and “Liveliness” draft-muthu-behave-consent-freshness-01

  5. Need WG Feedbackon several things • Consent with authentication? • When to stop sending after no consent? • Consent frequency when sending • Consent frequency when not sending • (liveliness / keepalive) • RTCP • APIs draft-muthu-behave-consent-freshness-01

  6. 1. Consent with authentication Need WG feedback Authentication options • STUN Binding method with authentication (SHA-1) • Objection: CPU hit for PSTN gateway, SBC, mixer • STUN Binding method without authentication (no SHA-1) • Objection: security is different • Objection: no longer compatible with normal ICE draft-muthu-behave-consent-freshness-01

  7. 2. When to stop sending Need WG feedback How long to wait for the consent response before stop sending ? • 39.5 seconds using STUN defaults • Based on fixed seconds? • Based on fixed packets per second? • Based on fixed bandwidth? • Based on 3x, 4x previous STUN round-trip time? draft-muthu-behave-consent-freshness-01

  8. 3. Consent Frequency when Sending Need WG feedback How frequently to request consent when actively sending? Every 5 seconds? Every minute? Every hour? draft-muthu-behave-consent-freshness-01

  9. 4. Consent frequency when not sending (liveliness / keepalive) • Need WG feedback • Every 15 seconds • as recommended by RFC6263 • Recommend using PCP to reduce frequency? draft-muthu-behave-consent-freshness-01

  10. 5. RTCP Need WG feedback Get consent for RTCP if on different port? • RTCP is typically rate limited draft-muthu-behave-consent-freshness-01

  11. 6. APIs Need WG feedback What APIs do we need? • Consent transaction failed • Set consent frequency (?) • Others? draft-muthu-behave-consent-freshness-01

  12. WG Feedback: Summary • Consent with authentication? • When to stop sending after no consent? • Consent frequency when sending • Consent frequency when not sending • (liveliness / keepalive) • RTCP • APIs draft-muthu-behave-consent-freshness-01

  13. draft-muthu-behave-consent-freshness • Interest in Consent and Liveliness? • Is document going in the proper direction? draft-muthu-behave-consent-freshness-01

  14. End draft-muthu-behave-consent-freshness-01

  15. draft-muthu-behave-consent-freshness-01

  16. Problem Description (2/3) • ICE connectivity checks verify consent only at session establishment • Existing ICE keepalives are one-way • STUN “Indication” • Not confirmed • Not authenticated draft-muthu-behave-consent-freshness-01

  17. Problem Description (3/3) • Related problem: Session liveness • Detect connection failure after session establishment • Optimize consent freshness and liveness tests to avoid sending recurring messages draft-muthu-behave-consent-freshness-01

  18. Design Considerations (1/8) • STUN Binding Request • ICE says MUST use short term authentication • But SHA-1 impacts performance of aggregation equipment (e.g., PSTN gateways, mixers, SBCs) • STUN transaction ID • Uniformly and randomly chosen from the interval 0 .. 2^96-1 • Good enough for preventing off-path attacks • MUST NOT be chosen or controlled by Javascript draft-muthu-behave-consent-freshness-01

  19. Design Considerations (3/8) • Only obtain Consent when sending traffic • Reduces bandwidth usage • Conserves batteries draft-muthu-behave-consent-freshness-01

  20. Design Considerations (2/8) • ICE requires an agent to be prepared to receive connectivity checks after ICE concludes • So, let’s do ICE connectivity checks for ‘Consent’ • Reusing STUN Binding method allows to interoperate with existing ICE/ICE-lite implementations • No need to also perform ICE/RTPkeepalive draft-muthu-behave-consent-freshness-01

More Related