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

Magnus Westerlund <> Wed, 02 September 2015 15:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87FFC1AD0C8; Wed, 2 Sep 2015 08:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J-Vdak0epAmk; Wed, 2 Sep 2015 08:28:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD1711B2BAC; Wed, 2 Sep 2015 08:28:16 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-6d-55e7158e9901
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6C.7A.17026.E8517E55; Wed, 2 Sep 2015 17:28:15 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 2 Sep 2015 17:28:14 +0200
To: David Mandelberg <>, "" <>, <>, <>, IESG <>
References: <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Wed, 2 Sep 2015 17:28:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjW6/6PNQgyflFh/v3WC1uLHnDrvF io+72C1m/JnIbPFh4UMWB1aPJUt+Mnl8nPiSxePL5c9sAcxRXDYpqTmZZalF+nYJXBm7V75k K7ijUbF+4hH2BsYHCl2MnBwSAiYSy6d8ZYSwxSQu3FvP1sXIxSEkcJRR4sXJJVDOMkaJucve MINUCQs4S9w5/pIFJCEisI1RYmv3QrB2IQEniePHtjGB2GwCFhI3fzSygdi8AtoS25dMBmtm EVCReLbqI1i9qECMRM+vDVA1ghInZz5hAbE5QRZ8vQ42hxlozsz55xkhbHmJ5q2zmSF2aUs0 NHWwTmAUmIWkfRaSlllIWhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzgg1t+6+5g XP3a8RCjAAejEg9vwoRnoUKsiWXFlbmHGKU5WJTEeVuYHoQKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYPTd+0NU+P5NMWkOweW2e26utTu6wedy5Amjb73shSaujhcWiOl3Sex9z81c2n0l 3Kz9466q/ZMqg7LnTf/LPMl8XfM0Qbu7M7Tk7odUPbf12nRae7XT+14XK7mjCdF88Vq61ee7 K6Y/9vCr9ji6NpSP/38UE8t2VZc9C87/N+Kpe3gyjeFIvxJLcUaioRZzUXEiAFyJLhZBAgAA
Archived-At: <>
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: Wed, 02 Sep 2015 15:28:23 -0000


Adding the WG.

Back from vacation. Thanks for the good review. See inline for response.

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.

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

> -----
> I also have a few nits:
> Abstract: The RTCP initialism is used without definition.
> Section 5.4: The SR initialism is used without definition.
> Section 6.4: I'd suggest changing "As for Paused State" to "As with
> Paused State". That sentence could also be split up for better readability.



Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: