Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23

[Stephan Wenger <[e-mail]>]

Hi all,

Julien, thanks for your thoughtful review.  After (rather loose)
coordination with my co-authors, here is our input.  In summary, the
editorial changes requested are fine with us and will be worked in
(chairs/Ads, please advise whether doing this during AUTH48 is ok).  As
for the non-editorial points, please see inline.


On 10.26.2010 03:52 , "Gonzalo Camarillo" <[e-mail]>
wrote:

>[...]
>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.

OK.  

>
>>   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.

This point is non-trivial, and I will answer it in separate email.  To
summarize, we adapted the (back since when highly contested) language from
RFC 3984 with modifications in video coding terminology only, and would
prefer not to reopen this issue.

>
>>   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?

We were thinking about "stream", and, yes, a clarification needs to be
added.

>
>>      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.

Will be removed.

>
>HTH,
>
>--julien
>