Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16

Stephen Farrell <> Mon, 25 October 2010 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E84E3A6A4A; Mon, 25 Oct 2010 07:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kHYykSfzMxxA; Mon, 25 Oct 2010 07:51:48 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by (Postfix) with ESMTP id 2D98A3A6A5B; Mon, 25 Oct 2010 07:51:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF9A3E409E; Mon, 25 Oct 2010 15:53:31 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288018410; bh=5teaBQ9WDg1Zky XIOtpZawGlxDo5BZ3tBI5HQZzsczs=; b=QWxeSOdLgo6R+/8Wzeri0hf+vTMMRp jR0yj7Q7BXLbK3CkUQr/1I+U7xoZJLSyWL17GDGvZRAFNY2LdZFiXVQ8uUlgIkTt xAvbh17rN69k88Jwp9c4IgwxL24hyNsdBLF7Dq1/b+5ynwsDsDVrRHpbqdpgDhgc zcxasW5ZdvvX/1GGklxUyctlphiy2fa8EKGio73L84Rqa17RBb5bX+UlU70lUjVE mbMRoREAmL9zj990XgO9TtzuNO9UFpfDj6vfgoBXVfO2Snv9c75xXcOJmCY+mLkO HBgoAFRlriR4s1SkxkAgvF2f+J+c9UsuBCaaH9Rr/htClyhKylqM0Yyw==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id cO-s+Oi6OR1C; Mon, 25 Oct 2010 15:53:30 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 3E95D3E409B; Mon, 25 Oct 2010 15:53:29 +0100 (IST)
Message-ID: <>
Date: Mon, 25 Oct 2010 15:53:27 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Oct 2010 14:51:50 -0000

On 25/10/10 15:04, Ali C. Begen (abegen) wrote:
> Hi Stephen,
> This time, hopefully a quick answer. 

Let's keep it up while we can:-)

>> The first is that this protocol is vulnerable to off-path DoS attacks
>> unless SRTP is used, and even where SRTP is used, additional (though
>> minor) constraints on how it is used are required to prevent
>> authorized receivers messing with one another.
> First of all, while RAMS could be favored more by the attackers due to the damage it can make, the same set of problems exist in any scenario where a feedback target (receiving feedback from multicast receivers) is supposed to act on them (doing retransmissions, or asking the actual media source to slow down, speed up, etc.).

Fair enough. I've no idea if this application is more likely
to be used as a potential DoS vector, compared to others with
the same issues.

> If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this.

Don't think that's needed myself, its more whether or not
SRTP is a real solution that'll be used, and as I say, I've
no idea about that.

>> The -16 version is clear enough (I think) about this, so my only
>> remaining question is whether or not SRTP, with the additional
>> constraints specified, is likely to be deployed or not.
> Well, I think we are only responsible to mention the problems and possible solutions. We cannot force vendors to implement everything from A to Z. The first deployment that RAMS has is the IPTV networks (for fast channel change). In such environments, the networks are managed and clients are deployed by the operator anyway. So, many of these concerns are not even relevant. I'd imagine they would not care much about SRTP.
> In other areas, SRTP could be needed, but will it be always used? It is not up to me.

Sure. But I guess there are other situations where RFCs say
e.g. "use s/mime" but we know that people just don't do that.

>> I have no idea myself, but if its unlikely to really be deployed,
>> then the vulnerability could probably easily be exploited which
>> would be bad and would lead me at least to wonder whether it would
>> be wiser to try to design this so that it is less vulnerable to
>> off-path attacks. (Assuming that such a solution exists of course.)
> I would not say it is very unlikely as SRTP exists today in many VoIP applications. So, the code is available. It is not rocket science, either. So, there is hope ;)

Right. And I assume that the AVT WG and the IESG might know
if that hope is likely to be realised.

To be clear, I'm not asking for a change to -16 here, I'm really
asking if -16's use of SRTP is likely to happen or not, and if
not, (which you guys may know), then whether that's considered
ok or not.

>> The second one relates to the additional SRTP constraints. The new
>> text says that the BRS needs to keep a list of receiver certs (which
>> seems unlikely) or else must ensure that all receivers are certified
>> by some "trusted" CA. I don't think that really works - if the
>> problem is that authorized receivers could DoS one another then I
>> don't see how this fixes that. Or am I missing something?
> Hit by your friends? E.g., the wife's set-top can attack the husband's set-top if her channel changes are getting slower. That is a tough problem to fix, though ;)

Well, hit by anyone else who can change a channel using
that BRS, which presumably is more than just my friends.

> I think this can be only solved if each unicast session is associated with the initial requestor's cert. So, only the messages with the right cert can cause changes in that session. Would that solve the problem?

I guess so, though that then depends on each receiver having
a key pair and cert, which is probably a deployment headache.
Is there no other way that this protocol could be hardened
against off-path DoS attempts? E.g. if messages contained a
nonce that had to be present in each subsequent message if
it was present in the first? Maybe the WG considered that
and rejected it, I don't know.


> -acbegen
>> S.
>> PS: The text quoted is from the response to my review of -15, I
>> guess it makes life easier to change the subject line to -16 for
>> this re-review but I might be wrong. If so, sorry;-)