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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Feb 2014 03:41:20 -0500

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) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: Varun Singh <[email-masked]>
Date: Fri, 21 Feb 2014 00:30:49 +0200

Hi Jeffery,

Thank you for reviewing the document, comments inline.

Cheers,
Varun

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

[snip!]
> appears to be a typo, but should be corrected.

Yes, it is a typo. Fixed.

> Byte Discarded block was _sent_.  Further, some clarification is

Should be “sent”. Fixed.

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

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Feb 2014 18:03:32 -0500

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

> 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

---

From: Varun Singh <[email-masked]>
Date: Fri, 21 Feb 2014 01:26:41 +0200

Hi Jeff,

Comments inline.

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

> the I flag is first described.  Then the above can be rewritten…
> 
Fixed.

> ... or something like that.

The most recent reporting interval works.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Feb 2014 18:38:10 -0500

> in either case, the sender will increase the rate in response to a discard report. 

Nope; that's where I was going, and your explanation makes sense to me.
In which case, the text you proposed seems fine to me.

-- Jeff