Skip to main content

Last Call Review of draft-ietf-avtext-rtp-stream-pause-08

Request Review of draft-ietf-avtext-rtp-stream-pause
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-08-13
Requested 2015-08-06
Authors Bo Burman , Azam Akram , Roni Even , Magnus Westerlund
Draft last updated 2015-08-13
Completed reviews Genart Last Call review of -08 by Meral Shirazipour (diff)
Genart Telechat review of -08 by Meral Shirazipour (diff)
Secdir Last Call review of -08 by David Mandelberg (diff)
Opsdir Last Call review of -08 by Menachem Dodge (diff)
Assignment Reviewer David Mandelberg
State Completed
Review review-ietf-avtext-rtp-stream-pause-08-secdir-lc-mandelberg-2015-08-13
Reviewed revision 08 (document currently at 10)
Result Has Issues
Completed 2015-08-13

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

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.

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 



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 


David Eric Mandelberg / dseomn