Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01

[Jeffrey Hutzelman <[e-mail]>]

On Fri, 2014-02-21 at 00:30 +0200, Varun Singh wrote:

> > probably needed that we're actually talking about the last block with
> > the same 'E' flag.  That is, a block arriving with E=0 and I=10
> > describes bytes discarded due to arriving late since the last block with
> > E=0, even if there was an intervening block with E=1.
> > 
> 
> It should be since the last RTCP report interval, if a report does not
> contain a bytes discarded block, the sender assumes that no
> bytes/packets are discarded, this behaviour is mentioned in 
> section 4.2.
> 
> Should this be explicitly mentioned before at the end of section 3?

OK; so it's not really since the last Bytes Discarded block at all, but
since the last report interval?  That makes sense, but contradicts the
third-to-last paragraph in section 3 (quoted below):

   If Interval Metric flag (I=11) is set, the value in the field
   indicates the number of RTP payload bytes discarded from the start of
   the session, if Interval Metric flag (I=01) is set, it indicates the
   number of bytes discarded since the last RTCP XR Byte Discarded Block
   was received.


In fact, a reference to RFC6792 may be appropriate at the point where
the I flag is first described.  Then the above can be rewritten...

"... If Interval Metric (I=10) is set, it indicates the number of bytes
discarded in the most recent reporting interval."

... or something like that.


> > 
> > For the most part, the security considerations section of this document
> > is fairly reasonable.  However, one issue I do not see discussed is that
> > senders relying on this information for tuning purposes may be tricked
> > by an attacker into undesirable behavior.  This may be one reason to
> 
> > apply appropriate integrity protection, but also suggests that senders
> > take the reported values with a grain of salt.
> > 
> 
> Proposal to add this:
> 
> The discarded bytes report is employed by the sender to perform 
> congestion control, typically, for calculating goodput. In these cases 
> an attacker MAY drive the endpoint to lower its sending rate and 
> under-utilised the link, therefore media senders should choose
> appropriate security measures to mitigate such attacks.
> 
> 
> Does the above text address you concern?

Pretty much.  Is it also possible that an attacker might get the sender
to _increase_ its sending rate, by reporting bytes discarded because
they arrived too late?  If so, that should be mentioned as well.

-- Jeff