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

[Varun Singh <[e-mail]>]

Hi Jeffery,

Thank you for reviewing the document, comments inline.

Cheers,
Varun

On 20 Feb 2014, at 10:41, Jeffrey Hutzelman <[e-mail]> wrote:

[snip!]
> The Interval Metric (I) flag is described inconsistently with regard to
> the permissible values.  The description of this flag indicates that
> only I=10 (Interval Duration) or I=11 (Cumulative Duration) are
> permitted, and that I=01 (Sampled Metric) is specifically prohibited.
> However, when discussing the meaning of the byte count, the meaning is
> described for I=11 and I=01 cases, rather than I=11 and I=10.  This
> appears to be a typo, but should be corrected.
> 

Yes, it is a typo. Fixed.

> Also, in the Interval Duration case, the byte count is described as
> being the number of bytes discarded "since the last RTCP XR Byte
> Discarded Block was received".  In fact, since these blocks may be lost
> in transit, the sender of this report (the RTP receiver) cannot know
> which reports were received, and the interval is in fact since the last
> Byte Discarded block was _sent_.  Further, some clarification is

Should be “sent”. Fixed.

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

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

> -- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
>   Carnegie Mellon University - Pittsburgh, PA