Skip to main content

Last Call Review of draft-ietf-avtext-rtp-stream-pause-08
review-ietf-avtext-rtp-stream-pause-08-secdir-lc-mandelberg-2015-08-13-00

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
review-ietf-avtext-rtp-stream-pause-08-secdir-lc-mandelberg-2015-08-13-00
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.






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




-----

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.




--
David Eric Mandelberg / dseomn


http://david.mandelberg.org/