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

Varun Singh <varun@comnet.tkk.fi> Thu, 20 February 2014 23:26 UTC

Return-Path: <varun@comnet.tkk.fi>
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 684C01A0339; Thu, 20 Feb 2014 15:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dEmn64RUqf79; Thu, 20 Feb 2014 15:26:54 -0800 (PST)
Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FF1A0337; Thu, 20 Feb 2014 15:26:54 -0800 (PST)
Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AC8AC115314_3068F39B; Thu, 20 Feb 2014 23:26:49 +0000 (GMT)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 4596F1152EF_3068F39F; Thu, 20 Feb 2014 23:26:49 +0000 (GMT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 299DB1E0EA; Fri, 21 Feb 2014 01:26:49 +0200 (EET)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ZaaRxLGv3Iv; Fri, 21 Feb 2014 01:26:43 +0200 (EET)
Received: from [192.168.0.12] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 741541E021; Fri, 21 Feb 2014 01:26:43 +0200 (EET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Varun Singh <varun@comnet.tkk.fi>
In-Reply-To: <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu>
Date: Fri, 21 Feb 2014 01:26:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <05FF2E57-25CB-42AE-BC01-C46BB6AB17C7@comnet.tkk.fi>
References: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> <A11FD60C-02FA-4C6A-A037-F1970654D655@comnet.tkk.fi> <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wUqNhF7AO4l3hu-ZmjH-nUJw3OQ
Cc: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [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 23:26:57 -0000

Hi Jeff,

Comments inline.

On 21 Feb 2014, at 01:03, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

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

> "... If Interval Metric (I=10) is set, it indicates the number of bytes
> discarded in the most recent reporting interval."
> 
> ... or something like that.
> 

The most recent reporting interval works.

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

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 ?

> -- Jeff