Skip to main content

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

Request Review of draft-ietf-payload-vp8
Requested revision 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
I-D last updated 2013-06-20
Completed reviews Genart Last Call review of -08 by Elwyn B. Davies (diff)
Genart Telechat review of -09 by Elwyn B. Davies (diff)
Genart Telechat review of -16 by Elwyn B. Davies (diff)
Genart Last Call review of -17 by Elwyn B. Davies
Secdir Last Call review of -08 by Brian Weis (diff)
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-payload-vp8 by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 17)
Result Has issues
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

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?