[secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 04 October 2010 16:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id DA9773A6D7B; Mon, 4 Oct 2010 09:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.801
X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id b2s7mJplI-VL; Mon, 4 Oct 2010 09:58:05 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 1E8A53A6ED0; Mon, 4 Oct 2010 09:57:58 -0700 (PDT)
Received: from localhost (localhost []) by hermes.scss.tcd.ie (Postfix) with ESMTP id 40C333E40F4; Mon, 4 Oct 2010 17:58:53 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1286211532; bh=cHsGZOymHPq5NdWI5eygUwWS 9AYSzlFr27LPUcIrHvU=; b=wtjvR9PsZCxmJxzvsyG9CITdHCodj2M7Z4SrpHgH 9Ru96pCeMSTS3xPLHEzmI8INN47ypb2LrZaqh9lb03xwkqqnjc5FuwXrlu12cA8F U0u6gGtfX5soSjiqivBbQre2NFkysU/xwKJAdNdk7kYXhNZfoiqQkAyQhApb96e5 m2GY2ackRz+pvxu1wKfVOnIniWyxCNFO/IYm2G3tfdE/46LZjoHhtqOcz8RxSwBj 9HBJaBp6VwYYHgNMXT1FdQjNJyk2J83BEzP4IXMIdIw4FJJSLqrEEV1UdIj6C5aJ SlKzE4jPPuPTL+LLDMXtT08hJxTwhnthrEt6bjOjphc+cQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([]) by localhost (scss.tcd.ie []) (amavisd-new, port 10027) with ESMTP id wFyOwBvi0Xqb; Mon, 4 Oct 2010 17:58:52 +0100 (IST)
Received: from [] (stephen-samy.dsg.cs.tcd.ie []) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DE6A13E40F0; Mon, 4 Oct 2010 17:58:50 +0100 (IST)
Message-ID: <4CAA07C8.4030806@cs.tcd.ie>
Date: Mon, 04 Oct 2010 17:58:48 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: avt-chairs@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15
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, 04 Oct 2010 16:58:08 -0000

#include <secdir-review-boilerplate.h>

This document defines a way for multicast receivers (e.g. IPTV clients)
to rapidly acquire the reference information required to make sense of
the session data. Reference information is usually only sent
periodically within the session, so this document defines how to setup
a new unicast session with a server that transmits the reference
information to the client on request so as a result the client doesn't
have to wait so long.

Overall, I'm a bit concerned that this might create new DoS exploit
potential, but I could be wrong (don't know enough about multicast) and
I see there has been a separate thread on ietf-discuss that had some
mention of that. (I've not read that thread in detail.) If an off-path
attacker could insert RAMS-* messages with values that are likely
to result in things happening then that, I think, would be quite bad,
but I'm not quite sure.

Detailed security-related issues/questions:

- How does the client know that it has the right FT/BRS? (Does it
always get that from SDP?) What would happen if it has a bogus FT/BRS?
(Is that likely?)

- P17 says that the BRS may reject the RAMS-R request. Are there
security reasons that might cause rejection? If so, what?

- P18 says that the BRS can replace the SSRC from the RAMS-R with
something else. Wouldn't that allow a bad BRS to redirect an RTP_Rx to
some dodgy stream, instead of the one requested? Should the RTP_Rx
react to that somehow?

- How are updated RAMS-R and RAMS-I related to originals? Is there a
way to insert these (maybe from off-path?) If there is, could a fake
RAMS-I mount a DoS on the RTP-Rx? (E.g. by supplying crap information.)

- Could I send a fake RTCP BYE pretending to be from some RTP_Rx in
order to DoS that client?

- Could I send a RAMS-R requesting a very high bitrate for a burst as
a way to DoS someone local to the (claimed) source of the RAMS-R? (The
max is 2^64 I guess)

- p31: the Min RAMS buffer fill requirement seems to allow RTP-Rx to
request almost 50 days (2^32ms) of content in the unicast burst.  That
seems too much, from the p-o-v of potential DoS exploits. Maybe say
that the BRS SHOULD impose some limit as part of DoS mitigation?

- p35: the earliest join time is also a 32 bit millisecond counter.
Should the RTP_Rx also have some kind of sanity check if asked to wait
days? Same comment wrt burst duration.

- p42: Saying "adequate" security measures are "RECOMMENDED" to protect
SDP description, without saying what they might be, is very vague.
What's an implementer supposed to do?

- p43 mentions SRTP as a SHOULD. How widely is that deployed and does
it make sense for this use-case? I think that should be clear. (If SRTP
isn't really used, or if its not going to be used here, then its not a
real countermeasure.)

- p43 says RAMS itself brings no new attacks, but surely it does create
some new off-path DoS potential, if messages could be guessed?

- p43: what does "consider the security of such SRTP key sharing mean?"
I think this spec should say.

Nits/Non-security things:

- p8: CNAME is used without being defined.

- p15: AVPF is used before being defined/expanded.

- p18: Saying "If the RTP_Rx will issue a ..." seems confusing. Would
that be clear to an implementer? In other words ought the spec say
SHOULD somewhere here? (In which case, it'd also presumably say when
its ok not to follow the SHOULD.)

- p19: This says that if the BRS has given a 504 etc. reject, then the
RTP_Rx MUST NOT retry. Does that mean just for this stream or for any
stream? Its not clear to me if the "MUST NOT" is scoped to one "channel
change" button press, or many, and if many, how that'd ever be reset,
though that might be my ignorance of the use-case and multicast in

- p20 says the BRS "can" use the updated RAMS-R - that's not 2119
language, so I assume you mean "MAY" and the intent is to allow
implementers to handle updated RAMS-R in whatever way suits best, given
their internal state when the update arrives?

- p21 says "there is no need" to send RAMS-T for rejected stuff.  Maybe
that'd be better as a MUST NOT or SHOULD NOT?

- p21: the mix of SHALL and MUST looks odd, I at least, would prefer
just MUSTs.

- p21, typo s/and started/and has started/

- p21, OSN-minus-one as a signal for the BRS to stop - can that OSN
wrap around?

- p34: what are "the regular wrapping rules" for MSN and how does
that work with an 8 bit field that is only zero when a new RAMS-R is

- p38: saying support for rfc5576 "can also be needed" seems vague.
Better to specifically say when its needed.