Last Call Review of draft-ietf-payload-vp8-08

Request Review of draft-ietf-payload-vp8
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-18
Requested 2013-06-07
Authors Patrik Westin, Henrik Lundin, Michael Glover, Justin Uberti, Frank Galligan
Draft last updated 2013-06-20
Completed reviews Genart Last Call review of -08 by Elwyn Davies (diff)
Genart Telechat review of -09 by Elwyn Davies (diff)
Genart Telechat review of -16 by Elwyn Davies (diff)
Genart Last Call review of -17 by Elwyn Davies
Secdir Last Call review of -08 by Brian Weis (diff)
Assignment Reviewer Brian Weis
State Completed
Review review-ietf-payload-vp8-08-secdir-lc-weis-2013-06-20
Reviewed rev. 08 (document currently at 17)
Review result Has Issues
Review completed: 2013-06-20


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.

This document describes an RTP payload specification applicable to the transmission of video streams encoded using the VP8 video codec defined in RFC 6386. It defines how the RTP header is used, and describes the format of a VP8 payload including sender and receiver semantics.

The Security Considerations document points to the Security Considerations of RFC 3550 (RTP), which seems appropriate since the codec fits entirely within the RTP framework. It does specifically call out protections that should be applied to the RTP packets, and notes that there a number of application-specific mechanisms that can provide those protections. I just have a couple minor comments/questions on this section.

1. Unless the SRTP recommendation in lower case was a WG consensus item I would suggest using upper-case RECOMMENDED to better convey the importance of protecting the RTP traffic.

2. The penultimate sentence makes a claim about the payload format being "unlikely to pose a denial-of-service threat due to the receipt of pathological data." I'm not sure what threat this is describing. If one is worried about a denial-of-service threat then the packet should be integrity protected and include a replay protection method (e.g., using SRTP). A non-key holder (e.g., man-in-the-middle) will not be able to create a correctly formed protected data packet so the denial-of-service properties of the data itself should be moot. Is there another threat here that I'm missing that makes this worth mentioning?