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

"Ali C. Begen (abegen)" <abegen@cisco.com> Mon, 25 October 2010 14:02 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC793A6A27; Mon, 25 Oct 2010 07:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.564
X-Spam-Level:
X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwJSiOL+Pn3p; Mon, 25 Oct 2010 07:02:37 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 289E13A683F; Mon, 25 Oct 2010 07:02:37 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALcqxUyrR7Hu/2dsb2JhbAChXXGfV5wPhUgEhFSJBQ
X-IronPort-AV: E=Sophos;i="4.58,236,1286150400"; d="scan'208";a="609407497"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2010 14:04:22 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9PE4Mwp002403; Mon, 25 Oct 2010 14:04:22 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 07:04:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Oct 2010 07:04:41 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D81691E@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4CC58A1C.5020704@cs.tcd.ie>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
Thread-Index: Act0S1C4aWcJ9m28QlS73LG6fWkIAwAAGpPQ
References: <4CAA07C8.4030806@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> <4CC58A1C.5020704@cs.tcd.ie>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
X-OriginalArrivalTime: 25 Oct 2010 14:04:21.0948 (UTC) FILETIME=[85FD87C0:01CB744D]
X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700
Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org, avt-chairs@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 25 Oct 2010 14:02:39 -0000

Hi Stephen,

This time, hopefully a quick answer. 

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Monday, October 25, 2010 3:46 PM
> To: Ali C. Begen (abegen)
> Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org; sec-ads@ietf.org; secdir@ietf.org; avt-chairs@ietf.org
> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
> 
> 
> Hi Ali,
> 
> On 19/10/10 16:18, Ali C. Begen (abegen) wrote:
> > Sorry for not responding to this email earlier.
> 
> Me too:-)
> 
> draft-ietf-avt-rapid-acquisition-for-rtp-16 seems to me to do a good
> job of addressing my comments on -15, except, perhaps, for two.

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

If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this.
 
> 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.
 
> 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 ;)
 
> 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 ;)

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?

-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;-)