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

Varun Singh <> Thu, 20 February 2014 22:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF3A61A0324; Thu, 20 Feb 2014 14:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wYoSGROpgRh7; Thu, 20 Feb 2014 14:31:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B0E881A0328; Thu, 20 Feb 2014 14:30:59 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 72B6827114A_306821FB; Thu, 20 Feb 2014 22:30:55 +0000 (GMT)
Received: from ( []) by (Sophos Email Appliance) with ESMTP id 3B1E4271147_306821FF; Thu, 20 Feb 2014 22:30:55 +0000 (GMT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 1AB4F1E021; Fri, 21 Feb 2014 00:30:55 +0200 (EET)
X-Virus-Scanned: by amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 4jNPoWeJEVo7; Fri, 21 Feb 2014 00:30:49 +0200 (EET)
Received: from [] ( []) by (Postfix) with ESMTPSA id B1B7B1E0EA; Fri, 21 Feb 2014 00:30:49 +0200 (EET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Varun Singh <>
In-Reply-To: <>
Date: Fri, 21 Feb 2014 00:30:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Jeffrey Hutzelman <>
X-Mailer: Apple Mail (2.1827)
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 22:31:04 -0000

Hi Jeffery,

Thank you for reviewing the document, comments inline.


On 20 Feb 2014, at 10:41, Jeffrey Hutzelman <> wrote:

> 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) <>
>   Carnegie Mellon University - Pittsburgh, PA