STUN Usage for Consent Freshness and Session Liveness draft muthu behaveconsentfreshness01 Authors D Wing Muthu A M Perumal R Ram Mohan H Kaplan July 30 2012 IETF 84 Vancouver BC Canada ID: 548087
Download Presentation The PPT/PDF document "RTCWEB" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
RTCWEBSTUN Usage for Consent Freshness and Session Livenessdraft-muthu-behave-consent-freshness-01
Authors: D. Wing, Muthu A M. Perumal, R. Ram Mohan, H. Kaplan
July 30, 2012IETF-84 Vancouver, BC, Canada
draft-muthu-behave-consent-freshness-01
1Slide2
What is “Consent”Purpose of Consent: avoid denial of serviceConsentPermission to send trafficConsent freshness
Permission to continue sending trafficTraffic sender requests consent of the receiverdraft-muthu-behave-consent-freshness-01
2Slide3
Problem Description (1/3)draft-muthu-behave-consent-freshness-013Slide4
Our Approach to ConsentUse ICE Connectivity ChecksRTCWEB needs ICE anywayTransaction-ID protects from off-path attackersNo longer need ICE ‘indications’ for firewall and NAT keepalivesRFC6263Instead, keepalive using connectivity checksProvides both Consent and “Liveliness”
draft-muthu-behave-consent-freshness-014Slide5
Need WG Feedbackon several thingsConsent with authentication? When to stop sending after no consent?Consent frequency when sendingConsent frequency when not sending(liveliness / keepalive
)RTCPAPIsdraft-muthu-behave-consent-freshness-015Slide6
1. Consent with authenticationNeed WG feedbackAuthentication optionsSTUN Binding method with authentication (SHA-1
)Objection: CPU hit for PSTN gateway, SBC, mixerSTUN Binding method without authentication (no SHA-1)Objection: security is differentObjection: no longer compatible with normal ICE
draft-muthu-behave-consent-freshness-01
6Slide7
2. When to stop sendingNeed WG feedbackHow 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
7Slide8
3. Consent Frequency when SendingNeed WG feedbackHow frequently to request consent when actively sending?Every 5 seconds? Every minute? Every hour?
draft-muthu-behave-consent-freshness-01
8Slide9
4. Consent frequency when not sending (liveliness / keepalive)Need WG feedbackEvery 15 seconds as recommended by RFC6263Recommend using PCP to reduce frequency?draft-muthu-behave-consent-freshness-01
9Slide10
5. RTCPNeed WG feedbackGet consent for RTCP if on different port?
RTCP is typically rate limiteddraft-muthu-behave-consent-freshness-01
10Slide11
6. APIsNeed WG feedbackWhat APIs do we need?Consent transaction failedSet consent frequency (?)Others?
draft-muthu-behave-consent-freshness-01
11Slide12
WG Feedback: SummaryConsent with authentication? When to stop sending after no consent?Consent frequency when sendingConsent frequency when not sending(liveliness / keepalive)
RTCPAPIsdraft-muthu-behave-consent-freshness-0112Slide13
draft-muthu-behave-consent-freshnessInterest in Consent and Liveliness?Is document going in the proper direction?
draft-muthu-behave-consent-freshness-0113Slide14
Enddraft-muthu-behave-consent-freshness-0114Slide15
draft-muthu-behave-consent-freshness-0115Slide16
Problem Description (2/3)ICE connectivity checks verify consent only at session establishmentExisting ICE keepalives are one-way STUN “Indication”
Not confirmedNot authenticateddraft-muthu-behave-consent-freshness-0116Slide17
Problem Description (3/3)Related problem: Session livenessDetect connection failure after session establishmentOptimize consent freshness and liveness tests to avoid sending recurring messages
draft-muthu-behave-consent-freshness-0117Slide18
Design Considerations (1/8)STUN Binding RequestICE says MUST use short term authentication But SHA-1 impacts performance of aggregation equipment (e.g., PSTN gateways, mixers, SBCs
)STUN transaction IDUniformly and randomly chosen from the interval 0 .. 2^96-1Good enough for preventing off-path attacksMUST NOT be chosen or controlled by Javascript
draft-muthu-behave-consent-freshness-01
18Slide19
Design Considerations (3/8)Only obtain Consent when sending trafficReduces bandwidth usageConserves batteries
draft-muthu-behave-consent-freshness-01
19Slide20
Design Considerations (2/8)ICE requires an agent to be prepared to receive connectivity checks after ICE concludesSo, 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/RTP keepalive
draft-muthu-behave-consent-freshness-01
20