[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3B1A0037; Thu, 20 Feb 2014 00:41:28 -0800 (PST)
Received: from [192.168.202.157] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (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 128.2.217.200
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
- [secdir] secdir review of draft-ietf-xrblock-rtcp… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-ietf-xrblock-… Varun Singh
- Re: [secdir] secdir review of draft-ietf-xrblock-… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-ietf-xrblock-… Varun Singh
- Re: [secdir] secdir review of draft-ietf-xrblock-… Jeffrey Hutzelman