Subject: Re: [rtcweb] Security issue: consent refresh

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Nov 2011 15:34:17 +0100

On 2011-10-31 14:22, Bernard Aboba wrote:

>> If there is a MitM physically on the path between the Browser and the
> peer, such a MitM can keep the RTP flowing even if we used RTCP,
>>because it could fake RTCP. (and such a MitM can keep TCP and SCTP
> going too, fwiw)
> 
> 
> [BA] Agree with Hadriel that forcing an IWF to "manufacture" RTCP is a
> bad idea, and that the focus should be on an off-path attacker.
> 
> Also agree that we need "continuing consent" and can't rely on a "source
> quench" approach which has proven unworkable in other
> contexts. There are situations where a receiver might have "gone away"
> for one reason or another, or where the receiver is being
> overwhelmed, where it might not have the ability or context to tell the
> sender to stop.  For example, if key state has been lost,
> putting out a secured "Bye" may not be possible.
> 

If we uses ICE initially then the implementation support for ICE
connectivity checks must exist in the interworking gateway. So I agree
that is likely the simplest, even if that code is going to be
continuously executed instead of only at startup for each session.

However, we still have a pretty big issue to figure out when it comes to
legacy devices and that is congestion/rate control. We are going to need
it, and I really wonder if we can make exceptions to this at all. And if
the legacy device don't implement even basic RTCP then this is a real
issue.

We added some text in the new version of WebRTC's usage of RTP document.
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

8.3.  Legacy Interop Limitations

   Congestion control interoperability with most type of legacy devices,
   even using an translator could be difficult.  There are numerous
   reasons for this:

   No RTCP Support:  There exist legacy implementations that does not
      even implement RTCP at all.  Thus no feedback at all is provided.

   RTP/AVP Minimal RTCP Interval of 5s:  RTP [RFC3550] under the RTP/AVP
      profile specifies a recommended minimal fixed interval of 5
      seconds.  Sending RTCP report blocks as seldom as 5 seconds makes
      it very difficult for a sender to use these reports and react to
      any congestion event.

   RTP/AVP Scaled Minimal Interval:  If a legacy device uses the scaled
      minimal RTCP compound interval, the "RECOMMENDED value for the
      reduced minimum in seconds is 360 divided by the session bandwidth
      in kilobits/second" ([RFC3550], section 6.2).  The minimal
      interval drops below a second, still several times the RTT in
      almost all paths in the Internet, when the session bandwidht
      becomes 360 kbps.  A session bandwidth of 1 Mbps still has a
      minimal interval of 360 ms.  Thus, with the exception for rather
      high bandwidth sessions, getting frequent enough RTCP Report
      Blocks to report on the order of the RTT is very difficult as long
      as the legacy device uses the RTP/AVP profile.

   RTP/AVPF Supporting Legacy Device:  If a legacy device supports RTP/
      AVPF, then that enables negotation of important parameters for
      frequent reporting, such as the "trr-int" parameter, and the
      possibility that the end-point supports some useful feedback
      format for congestion control purpose such as TMMBR [RFC5104].

   It has been suggested on the RTCWEB mailing list that if
   interoperating with really limited legacy devices an WebRTC end-point
   may not send more than 64 kbps of media streams, to avoid it causing
   massive congestion on most paths in the Internet when communicating
   with a legacy node not providing sufficient feedback for effective
   congestion control.  This warrants further discussion as there is
   clearly a number of link layers that don't even provide that amount
   of bit-rate consistently, and that assumes no competing traffic.

We need to discuss if there is a reasonable way to resolve this or if
this puts as strict or even stricter requirements then to support ICE.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randell Jesup <[email-masked]>
Date: Tue, 01 Nov 2011 13:52:28 -0400

>        even implement RTCP at all.  Thus no feedback at all is provided.

Typically these devices aren't using codecs that can be throttled, so 
lack of congestion control doesn't really matter here.  (G.711, G.729, 
etc).  In theory you could switch codecs to a 
supported-but-lower-bandwidth codec, of course, but there would be no 
way to tell them to switch.  Effectively you're talking to a non-CC 
device; it will work or it won't.  I've never seen a 2-way video 
endpoint that didn't support RTCP in some way (though some are broken in 
odd ways) - they might exist, but I haven't seen one.

>        it very difficult for a sender to use these reports and react to

Congestion control based on AVP RTCP reports is possible, but with a 
very slow convergence time and unclear fairness results.  It does "work" 
in practice if not over-stressed.  I used such algorithms in the past 
for interop with "standard" videophones and endpoints (while operating 
my device in AVPF mode).  Such algorithms are likely significantly 
unfair in practice, though they may be fair "on average".  Congestion 
control here is more useful as a way to provide adaptation to link 
bandwidth for a single application than to provide sharing of a link.

>        as the legacy device uses the RTP/AVP profile.

This is in most cases much better than AVP timings, though not good. 
"Typical" usages might yield 300-1500ms RTCP intervals (much better than 
5000ms avg.)

>        format for congestion control purpose such as TMMBR [RFC5104].

Even without TMMBR, a RR-based CC algorithm with a fairly fast reporting 
interval should be able to provide some level of fairness and quick 
response (though far worse delay control).

-- 
Randell Jesup
[email-masked]