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

Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 20 February 2014 08:41 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F268C1A003D; Thu, 20 Feb 2014 00:41:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ciXs7g3OUh8b; Thu, 20 Feb 2014 00:41:28 -0800 (PST)
Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu []) by ietfa.amsl.com (Postfix) with ESMTP id AAF3B1A0037; Thu, 20 Feb 2014 00:41:28 -0800 (PST)
Received: from [] (pool-108-39-146-104.pitbpa.fios.verizon.net []) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1K8fKMm000497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 03:41:22 -0500 (EST)
Message-ID: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org
Date: Thu, 20 Feb 2014 03:41:20 -0500
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/srodMaIE1hpj3VhNm444dg_zesc
Cc: jhutz@cmu.edu
Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2014 08:41:31 -0000

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+@cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA