Last Call Review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
review-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01-secdir-lc-hutzelman-2014-02-27-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.


This document defines an RTCP extended report block for reporting the
number of RTP payload bytes discarded from a stream after being
received, due to packets arriving too early or too late.  I believe this
document is ready for publication, or nearly so.


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.

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


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.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA