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

[Varun Singh <[e-mail]>]

Hi Jeff,

Comments inline.

On 21 Feb 2014, at 01:03, Jeffrey Hutzelman <[e-mail]> wrote:

> 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…
> 
Fixed.

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

The most recent reporting interval works.

> 
>>> 
>>> 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.
> 

Late could mean congestion and the receiver is skipping these packets. 
early may signify the jitter buffer is small and not capable of handling the packet 
(or perhaps a route change and packets are arriving out of order). I don’t think that 
in either case, the sender will increase the rate in response to a discard report. 

Or did I misunderstand ?

> -- Jeff