Re: [rtcweb] Security issue: consent refresh

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------