Last Call Review of draft-ietf-avt-rtp-svc-

Request Review of draft-ietf-avt-rtp-svc
Requested rev. no specific revision (document currently at 27)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-10-22
Requested 2010-10-10
Other Reviews
Review State Completed
Reviewer Julien Laganier
Review review-ietf-avt-rtp-svc-secdir-lc-laganier-2010-10-24
Posted at
Draft last updated 2010-10-24
Review completed: 2010-10-24


I 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 format for Scalable Video Coding that is applicable to applications such as video streaming.

Disclaimer: I am not familiar with RTP applications, and even less with video coding. However, it appears that the security considerations MAY need more work:

> 8. Security Considerations
>   Section 9 of [I-D.ietf-avt-rtp-rfc3984bis] applies.  Additionally,
>   the following applies.

Suggest rewording: "The security considerations of the RTP Payload Format for H.264 Video specification [I-D.ietf-avt-rtp-rfc3984bis] applies."

Also, the reference is not listed in the {Normative, Informative} Reference Section.

>   Decoders MUST exercise caution with respect to the handling of
>   reserved NAL unit types and reserved SEI messages, particularly if
>   they contain active elements, and MUST restrict their domain of
>   applicability to the presentation containing the stream.  The safest
>   way is to simply discard these NAL units and SEI messages.

Maybe this is due to my ignorance about coding but I find this underspecified, notably given the presence of the MUST key word. How about spelling exactly what a decoder MUST do, as opposed to say "exercise caution". E.g., "Decoders MUST discard NAL units and SEI messages.", and then explain why, or point to [I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanation there.

>   When integrity protection is applied, care MUST be taken that the
>   stream being transported may be scalable; hence a receiver may be
>   able to access only part of the entire stream.

Hmm. If integrity protection is applied to the RTP packet, and not to the video content being encoded in a scalable manner, there shouldn't be a problem, right? So maybe you need to qualify the object to which integrity protection is applied in the statement above. Is it the RTP packet, or the stream?

>      Informative note: Other security aspects, including
>      confidentiality, authentication, and denial-of-service threat,
>      for SVC are similar as H.264/AVC, as discussed in Section 9 of
>      [I-D.ietf-avt-rtp-rfc3984bis].

This seems redundant with the first paragraph of the Security Considerations that already stated that Section 9 of [I-D.ietf-avt-rtp-rfc3984bis] applies.