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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Sep 2015 17:28:13 +0200

Hi,

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

Incorporated.

Cheers

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: [email-masked]
----------------------------------------------------------------------

---

From: David Mandelberg <[email-masked]>
Date: Tue, 08 Sep 2015 18:01:01 -0400

> PauseID replay old messages at the appropriate time to influence the

Looks good to me.

> 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.
>
> 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.
>
> unopposed. This is mitigated in multi-party topologies that ensure
> that requests are seen by all or most of the RTP session 
> participants,
> 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
http://david.mandelberg.org/