Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt

Harald Alvestrand <harald@alvestrand.no> Tue, 06 March 2012 09:51 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7616721F8722 for <avt@ietfa.amsl.com>; Tue, 6 Mar 2012 01:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.527
X-Spam-Level:
X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCnsXJuEfm8i for <avt@ietfa.amsl.com>; Tue, 6 Mar 2012 01:51:51 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72E21F871B for <avt@ietf.org>; Tue, 6 Mar 2012 01:51:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6088939E107; Tue, 6 Mar 2012 10:51:50 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL1sQf2o745y; Tue, 6 Mar 2012 10:51:49 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CE1E839E090; Tue, 6 Mar 2012 10:51:49 +0100 (CET)
Message-ID: <4F55DE35.6060104@alvestrand.no>
Date: Tue, 06 Mar 2012 10:51:49 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Varun Singh <vsingh.ietf@gmail.com>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no> <CAEbPqry_wqrj0AHL9cjtYbiDc3xwL_fUoAVg8U91Lo9rkMrFrA@mail.gmail.com>
In-Reply-To: <CAEbPqry_wqrj0AHL9cjtYbiDc3xwL_fUoAVg8U91Lo9rkMrFrA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Colin Perkins <csp@csperkins.org>, "avt@ietf.org WG" <avt@ietf.org>, rtp-congestion@alvestrand.no
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 09:51:52 -0000

On 03/06/2012 10:21 AM, Varun Singh wrote:
> Hi Harald,
>
> comments inline
>
> On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand<harald@alvestrand.no>  wrote:
>
> [snip!]
Thanks for the quick response!

[snip]
>> Security considerations (missing section): For an end node that implements
>> this specification, an active attacker can cut the transmission by faking
>> two RTCP packets that get accepted instead of the recipient's RTCP packets.
>> This may be worthy of a note, and pointer to appropriate defenses.
> This is a valid attack. However, if we consider no early-feedback (the
> draft currently only follows RFC3550 timing rules) then the attacker's
> second fake report may be ignored by the sender because it is too
> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>
>
> Example:
> SR               |                          |
>          |                      I
>        ----------------------------------------------------------------------------------------------------------->
> time
> RR   |                   F          |              F          |
>     F              F      |
>
> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
> report). So, instead of waiting for 3 RTCP reports to arrive the
> sender MUST wait two RTCP intervals?
Yes, I think stating that the sender waits two RTCP intervals before 
drawing a conclusion is a reasonable defense against this version of the 
attack.

Another interesting version is what happens if the attacker bumps up the 
"highest sequence number received" - the security considerations may 
want to say that RRs with a "highest sequence number received" larger 
than the highest sequence number sent MAY be part of an attack, so 
SHOULD be disregarded.

But of course, using SRTP on the RTCP channel is also an option for the 
defender; that allows the receiver to detect that the replays are 
replays, and discard them for that reason.