Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08

David Mandelberg <> Tue, 08 September 2015 22:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 84B791B3313 for <>; Tue, 8 Sep 2015 15:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a-IHhI6QxUXz for <>; Tue, 8 Sep 2015 15:01:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E4971B3327 for <>; Tue, 8 Sep 2015 15:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1441749664; bh=GV96YdB47kC3I2jgW3BRIL27nNTRbFv1HBBGxD9A56g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=GaXuGzoujC7pc/pEa3e4OClHtPCm2nFA9HvWCaaMnngD9VgeukhOn5vA6x9InTojBEI1UCnlo5YiPpKct9691P7whYnjmOCXGM+hVwreD+dT9F8Tj/YYBYML3OCq1qk4XOPQQux/KVj/0BiPYUJy5D54N+77Cx2HIrAolta/rSmqhrG512XdlkSxRSYGc7g0WUCEAKa50ltLAKwgvm/eAJxzJCwpEc69vSnvewwoiXa5SefmN5IkMI69H/5KzWhxncQQ2MRIeMcnrhAdAo+pUS5EMy3EBAD97haUJjqYIrdLtkIHYWsSouyYLNKOAbiVjawP/s1A9jLDYNsg4Brlig==
Received: from [] by with NNFMP; 08 Sep 2015 22:01:04 -0000
Received: from [] by with NNFMP; 08 Sep 2015 22:01:04 -0000
Received: from [] by with NNFMP; 08 Sep 2015 22:01:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: KRlcfQ0VM1mADaPypu2T5xkOqmaNdFnh7FohrAz7SMgdTld saYkQE..rdd.25aMOYfS6L8bl0wuNz677tc81mSHA6pnEtpBqtgC.aH2OQSt fiWGhVXaS3elOG8abWNoWUqNzOg3jAfsa39As6ZS9Ioa6IolPcv4HGKL5bPO jASi8dk9rOzz_yiZKaVk9Pd.4NsP3Iy408VUBoMK3HL_3180a8G7jlUdCDxI ZqVO5zC.lbcsIFg3KQhKOkylfJoyfrC_xdy5Ila8TF6m2GNyeFo_vFEGK2og 8_JxrBHUbd3OWXJj3yi7LVwsu.24Drh7Vqgg671AbttEvoB9U5K8dJI4terM O5wSOYob9Zq0opLlDkorkWHOqByutQFY4iWPhEn_gTtAAIqvd830yVJ9fym0 Kk8crgliMDnhC.NoltNuAaiADfIoUXJU1LkcJ58GeqfqTHZ3Lr5QDZ7Jsz.O jmeJMFQCW0n.P.z0YfJGnAC2JG6dwAimZt4giHg.rA1gLri0ISX_b9LdoZ5k 6Soy1IhwCRUyOufJLB88ik9w2kCzub.G5nZ2.kA--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from ( []) by (Postfix) with ESMTPSA id E19FB1C6095; Tue, 8 Sep 2015 18:01:01 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Sep 2015 18:01:01 -0400
From: David Mandelberg <>
To: Magnus Westerlund <>
In-Reply-To: <>
References: <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <>
Cc:,, IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Sep 2015 22:01:08 -0000

On 2015-09-02 11:28, Magnus Westerlund wrote:
> Den 2015-08-11 kl. 06:45, skrev David Mandelberg:
>> Hi,
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.
>> These comments were written primarily for the benefit of the 
>> security
>> area directors.  Document editors and WG chairs should treat these
>> comments just like any other last call comments.
>> I think this draft is Ready with issues, though the two issues are
>> relatively minor:
>> 1. The Security Considerations section talks about protecting 
>> against
>> injection of PAUSE requests:
>>     The way of protecting the RTP session from these injections is 
>> to
>>     perform source authentication combined with message integrity, 
>> to
>>     prevent other than intended session participants from sending 
>> these
>>     messages.
>> I think this paragraph should also mention replay protection, which 
>> is
>> needed if the 16-bit PauseID wraps around and the attacker has 
>> access to
>> old PAUSE requests.
> Yes, we should mention replay attacks. I note that due to that the
> current PauseID starts at 0 and increments by one, it takes some time
> until we wrap. And also then you might have to hold onto a lot of
> messages to be able to attempt a replay. But, clearly we should
> recommend replay protection at the outer security layer.
> I propose that we add the following sentence in the second paragraph
> prior to the last sentence:
> The security solution should provide replay protection, otherwise an
> attacker could for sessions that are long lived enough to wrap the
> PauseID replay old messages at the appropriate time to influence the
> media sender state.

Looks good to me.

>> 2. The next paragraph in Security Considerations talks about 
>> protecting
>> the multi-party use case against a single malicious participant by
>> individually authenticating participants. In addition to 
>> per-participant
>> authentication, I think there also needs to be a requirement for
>> attempted delivery of PAUSE requests to all participants. Without 
>> that
>> requirement, an attacker could cause the session to cycle through 
>> the
>> Playing, Pausing, and Paused states. To do that, the attacker would 
>> send
>> PAUSE requests only to the stream sender, instead of to the whole 
>> group.
>> Since no other participants receive the PAUSE request, they do not 
>> know
>> to send disapproving RESUMEs until after the stream sender has 
>> already
>> paused the stream. (I should note that I'm not particularly familiar
>> with multicast network operations. If it's infeasible for one
>> participant to send a message to another participant without the 
>> rest of
>> the group also receiving the message, then I apologize for bringing 
>> up a
>> non-issue.)
> Yes, you are correct that getting a malicious PAUSE message sent to
> multiple participants provides a mitigation in that the other
> participants can counter it. That I would expect to happen in
> multicast cases where anyone can send RTCP messages. It will fully
> depend on the multicast topology if an on-path attacker has any 
> chance
> of getting its messages delivered to the media stream endpoint and 
> not
> getting forwarded to other endpoints over the multicast tree.
> In the cases of the RTP middleboxes providing the multi-party
> functionality it will depend on the mode of operation of that
> middlebox. But, assuming the middlebox isn't compromised it will act
> on behalf of the whole session. It either works as multicast emulator
> and should forward it to everyone, or it will receive the request, 
> and
> only forward it if fits the rest of the session state.
> Proposed text for the end of Paragraph three:
>  An attacker that can send a PAUSE request without it reaching any
> other participant than the media sender can have its request being
> unopposed. This is mitigated in multi-party topologies that ensure
> that requests are seen by all or most of the RTP session 
> participants,
> enabling these participants to send RESUME. In topologies with
> middleboxes that consume and process PAUSE requests, the middlebox 
> can
> also mitigate such behavior as it will commonly not generate or
> forward a PAUSE message if it knows of another participant having use
> for the media stream.
> Comments on this?

This also looks good to me.

Thanks for addressing my concerns!

David Eric Mandelberg / dseomn