Last Call Review of draft-ietf-payload-rtp-ancillary-06
review-ietf-payload-rtp-ancillary-06-secdir-lc-emery-2016-11-10-00
Request | Review of | draft-ietf-payload-rtp-ancillary |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-11-03 | |
Requested | 2016-10-27 | |
Authors | Thomas Edwards | |
I-D last updated | 2016-11-10 | |
Completed reviews |
Genart Last Call review of -06
by Christer Holmberg
(diff)
Secdir Last Call review of -06 by Shawn M Emery (diff) Opsdir Last Call review of -06 by Nevil Brownlee (diff) Genart Last Call review of -10 by Christer Holmberg (diff) |
|
Assignment | Reviewer | Shawn M Emery |
State | Completed | |
Request | Last Call review on draft-ietf-payload-rtp-ancillary by Security Area Directorate Assigned | |
Reviewed revision | 06 (document currently at 14) | |
Result | Has nits | |
Completed | 2016-11-10 |
review-ietf-payload-rtp-ancillary-06-secdir-lc-emery-2016-11-10-00
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 draft specifies a Real-time Transport Protocol (RTP) payload format for ancillary data; including time code, Closed Captioning, and Active Format Description (AFD). The security considerations section does exist and refers to the base protocol specification of RTP and any profile utilized for consideration. The section continues that RTP does not require a single media solution, referencing RFC 7202, and references RFC 7201 for various mechanisms to secure RTP. I agree with this assertion. The section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data. I'm OK with this assertion, except for the integrity check using Checksum_Word. The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check. General comments: None. Editorial comments: Abstract: Does RTP and SMPTE need to be expanded first? Abstract: Is SMPTE ST 291-1 a normative reference? s/an SDI/a SDI/ Shawn. --