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

Stephan Wenger <> Tue, 02 November 2010 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56F103A687F; Tue, 2 Nov 2010 07:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y2kyAIa7gOPr; Tue, 2 Nov 2010 07:12:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F70F3A68D6; Tue, 2 Nov 2010 07:12:45 -0700 (PDT)
Received: from [] (unverified []) by (SurgeMail 3.9e) with ESMTP id 11732-1743317 for multiple; Tue, 02 Nov 2010 15:11:40 +0100
User-Agent: Microsoft-MacOutlook/
Date: Tue, 02 Nov 2010 10:07:13 -0400
From: Stephan Wenger <>
To: Gonzalo Camarillo <>,,,,
Message-ID: <>
Thread-Topic: SECDIR Review of draft-ietf-avt-rtp-svc-23
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Ye-Kui Wang <>, Alex Eleftheriadis <>, Thomas Schierl <>,, "" <>
Subject: Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Nov 2010 14:12:49 -0000

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

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

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

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