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

"Ali C. Begen (abegen)" <> Tue, 19 October 2010 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 029B03A688D; Tue, 19 Oct 2010 08:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hi55WqM5vEyl; Tue, 19 Oct 2010 08:17:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF2383A6870; Tue, 19 Oct 2010 08:17:12 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAP5TvUyrR7Hu/2dsb2JhbAChZ3GjL5xfhUoEhFWJAA
X-IronPort-AV: E=Sophos;i="4.57,350,1283731200"; d="scan'208";a="203142312"
Received: from ([]) by with ESMTP; 19 Oct 2010 15:18:41 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id o9JFIfI2019855; Tue, 19 Oct 2010 15:18:41 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 08:18:41 -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: Tue, 19 Oct 2010 08:18:40 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15
Thread-Index: Actj5XZ6siccECGjQDmrr42uZdjsgwLSyiBg
References: <>
From: "Ali C. Begen (abegen)" <>
To: Stephen Farrell <>,,
X-OriginalArrivalTime: 19 Oct 2010 15:18:41.0561 (UTC) FILETIME=[E9A5F890:01CB6FA0]
X-Mailman-Approved-At: Wed, 20 Oct 2010 07:45:29 -0700
Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15
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: Tue, 19 Oct 2010 15:17:16 -0000

Sorry for not responding to this email earlier. I thought I did. Thanks to Robert for reminding me.


We tried to address all the issues mentioned below in the latest version. I will respond line by line below.

> -----Original Message-----
> From: Stephen Farrell []
> Sent: Monday, October 04, 2010 12:59 PM
> To:;
> Cc:;
> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15
> #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.

Yes, things may go wrong if an attacker sends RAMS control messages on behalf of others or an attacker modifies others' messages. We ack this problem and provide some solutions to deal with it.
> 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?)

The SDP should be only accepted from reliable sources. So, authentication and integrity checks are recommended. This applies to any application using SDP.
> - P17 says that the BRS may reject the RAMS-R request. Are there
> security reasons that might cause rejection? If so, what?

Not really. The rejection reasons are mostly related to the ones already listed in section 7.3.1.
> - 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?

We need to have this since the SSRC that is known by the RTP_Rx may have changed and it has to trust to the server for the most up-to-date SSRC. Note that here we assume the server side (BRS) is not compromised. If it is, it does not matter. It can send junk data w/o changing the SSRC.
> - 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.)

First of all, supporting the updated messages is an optional feature, which is highly discouraged anyway (due to various other reasons). In case, an implementation supports it, the security considerations are not much different. Section 10 makes some proposals to deal with this (e.g., source address validation, SRTP, policing, etc.).
> - Could I send a fake RTCP BYE pretending to be from some RTP_Rx in
> order to DoS that client?

You can but you need to know the CNAME (which is possible). However, if RTCP messages are authenticated and source address is validated, you will fail.
> - 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)

Yeah, we added a text for it. The server should pay attention to what the client mentioned in that field. In any case, that is an upper limit and the server can transmit at much slower pace if it wants to.
> - 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?

Yes, we added text about this as well. The server can naturally reject the decision anyway if it computes that the client is better off by joining the mcast immediately (rather than first receiving the burst and then joining). The client then can join and build up a buffer as long as it wants to.
> - 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.

Yes, see the new text in section 10.

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

This really depends on how SDP is distributed. It could be HTTP(S), RTSP or something else. 
> - 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.)

Well, in managed networks such as IPTV networks, servers and clients are known by the system admin, configured properly, etc. so one may not need to implement SRTP. In non-managed environments, SRTP is a good tool and if they want protection, they better use it. 
> - p43 says RAMS itself brings no new attacks, but surely it does create
> some new off-path DoS potential, if messages could be guessed?

And we tried to explain these *new* attacks in Section 10.
> - p43: what does "consider the security of such SRTP key sharing mean?"
> I think this spec should say.

We revised that part. See the new text to see whether it works.
> 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.)

Rephrased this part.
> - 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
> general:-)

The response codes have their own scopes. A client may not be authorized for any RAMS operation, or maybe RAMS is not enabled only for that stream. We explicitly say this now in the text.
> - 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?

For some reason, we did not wanna use 2119 language here (I don't recall it now). But, the idea is that it is really up to the server whether to use the updated request or ignore it.
> - 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?

Why do we need to say any 2119 language here. The server is not expecting a RAMS-T for them, but the client could still send one.
> - 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?

Sure it does since it is an RTP seqnum and all rtp seqnum rules apply to it as well.
> - 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
> received?

Wrapping rules are known in general I think since nobody has asked before what they were :) and MSN is usually 0, but if it keeps increasing, after it has reached the max value, it will naturally wrap around (which is very unlikely to happen).
> - p38: saying support for rfc5576 "can also be needed" seems vague.
> Better to specifically say when its needed.

Expanded the text to say when it would be needed.

Thanks much for the careful review.

> Regards,
> Stephen.