Skip to main content

Last Call Review of draft-ietf-avtext-sdes-hdr-ext-05
review-ietf-avtext-sdes-hdr-ext-05-secdir-lc-weiler-2016-04-21-00

Request Review of draft-ietf-avtext-sdes-hdr-ext
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-05-03
Requested 2016-03-10
Authors Magnus Westerlund , Bo Burman , Roni Even , Mo Zanaty
I-D last updated 2016-04-21
Completed reviews Genart Last Call review of -05 by Francis Dupont (diff)
Secdir Last Call review of -05 by Samuel Weiler (diff)
Opsdir Last Call review of -05 by Jouni Korhonen (diff)
Assignment Reviewer Samuel Weiler
State Completed
Request Last Call review on draft-ietf-avtext-sdes-hdr-ext by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has issues
Completed 2016-04-21
review-ietf-avtext-sdes-hdr-ext-05-secdir-lc-weiler-2016-04-21-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.







I am mostly satisfied with this document's security analysis.  I am 


worried that implementors will weasel their way around the "SHOULD"s, 


but the appropriate "SHOULD"s are in the doc.






The doc says "...there SHOULD be strong integrity protection and 


source authentication of the header extensions" -- I would like to 


also see specific citation(s).  (e.g. "Use X for integrity 


protection."  "Use X for authenticity.")






It would be nice to see some discussion of whether these headers 


increase the utility of RTP as a DOS vector - either by enabling a 


reflector attack or by triggering heavy computation on a receiving 


host.  I suspect that there's not much to see here, particularly if 


there really is integrity protection, but it would be nice to see the 


analysis.





Editorial comment:

For the RTP-naive reader, I suggest adding an early mention that SDES
is (normally) a special packet type within RTP.  Specifically: it
would be helpful for Section 1 to also say "RTP has a special packet
type for Source Description (SDES) items."