Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?)

[Magnus Westerlund <[e-mail]>]

On 2014-03-26 02:20, Ram Mohan R (rmohanr) wrote:

> Currently there is no section that talks about this. One of the comments
> given by Magnus some time back on this draft asks about scope of consent.
> We (the authors of draft-ietf-stun-consent-freshness) were discussing
> among ourselves on whether there is a need to have any text for
> fate-sharing connections. We don¹t see a real need to have any
> recommendation in this draft but wanted to bring this topic to mailer to
> see if any one else have any different opinion.
> 
> As you said it is completely up to the application what to do if consent
> fails. There may be many possibilities- For example for a single media
> stream when RTP and RTCP are sent over different addresses (no mux used),
> then if consent fails for one of the components, an application may choose
> to cease that stream. There may be also cases where consent may fail for
> audio but pass for video. Again it is up to the application (JavaScript)
> to take a decision on what to do.

I do think RTP MUST be fate shared with its RTCP. Because revoking
consent for RTCP should not be a way of turning off congestion control.
Thus, no RTCP should mean no RTP either as you get no feedback on how it
behaves.
> 
> Since it is application that always decide, I am ok to just leave it and
> not have any text in this document
> 

>From a security point of view, what is important is that one can't treat
consent on one transport flow (5-tuple) to mean consent to send on any
other. Because then an attacker could create a session where he receives
the low-bitrate audio and consent to the media there and direct the
video to a target for the attack, where no consent is received.

But, I am personally mostly fine with saying nothing that a failure to
retain consent on one RTP session or data channel's transport flows, may
or may not mean that the transmission should be killed on another RTP
session or data channel, where consent has not yet failed.

One question is if one doesn't fate share all transport flows within the
peer connection if one should trigger a consent check when the failure
happens on some other transport flow? That way one can minimize the
delay of discovering revoked consent or path failure on all transport
flows.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------