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

Jeffrey Hutzelman <> Thu, 20 February 2014 23:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3A681A0304; Thu, 20 Feb 2014 15:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rnz1g9-l_FZG; Thu, 20 Feb 2014 15:03:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 636031A0105; Thu, 20 Feb 2014 15:03:42 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id s1KN3Wms026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 18:03:33 -0500 (EST)
Message-ID: <>
From: Jeffrey Hutzelman <>
To: Varun Singh <>
Date: Thu, 20 Feb 2014 18:03:32 -0500
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on
Cc:,, The IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2014 23:03:46 -0000

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