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

"Laganier, Julien" <julienl@qualcomm.com> Fri, 22 October 2010 21:12 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 354C63A6965; Fri, 22 Oct 2010 14:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.519
X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id jKFBH+DjeKW8; Fri, 22 Oct 2010 14:12:27 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com []) by core3.amsl.com (Postfix) with ESMTP id 2E7533A696E; Fri, 22 Oct 2010 14:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287782046; x=1319318046; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@iet f.org"=20<iesg@ietf.org>|CC:=20"draft-ietf-avt-rtp-svc.al l@tools.ietf.org"=0D=0A=09<draft-ietf-avt-rtp-svc.all@too ls.ietf.org>|Date:=20Fri,=2022=20Oct=202010=2014:13:58=20 -0700|Subject:=20SECDIR=20Review=20of=20draft-ietf-avt-rt p-svc-23|Thread-Topic:=20SECDIR=20Review=20of=20draft-iet f-avt-rtp-svc-23|Thread-Index:=20ActyLgqaVpvgawTXTK6RBNcE 7V2G0A=3D=3D|Message-ID:=20<BF345F63074F8040B58C00A186FCA 57F29F6C36D44@NALASEXMB04.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=sBxl/vt5WRkMyhIFbE2t6QwdlMEavL0AMlsrKoqE44w=; b=mUYc5ss1B3OSYKrlqNekY+Ys//Rp55OqbG10PDubECJCQs5OpcVNxet7 vq4Fqz4Jf7ZEcYeHka5ngW3616dYUxLMqKRdBNZA4s1WE26rBIRvaKo8P sEmwzbwa/ryvRXfayRmJdSDlYqHD8dogaJrBhxFn+eIzrkjFk1T/Ymb9g 4=;
X-IronPort-AV: E=McAfee;i="5400,1158,6144"; a="58898238"
Received: from ironmsg04-l.qualcomm.com ([]) by wolverine02.qualcomm.com with ESMTP; 22 Oct 2010 14:14:05 -0700
X-IronPort-AV: E=Sophos;i="4.58,224,1286175600"; d="scan'208";a="26168856"
Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Oct 2010 14:14:05 -0700
Received: from nasanexhc05.na.qualcomm.com ( by nasanexhub04.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id; Fri, 22 Oct 2010 14:14:05 -0700
Received: from nalasexhub01.na.qualcomm.com ( by nasanexhc05.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id; Fri, 22 Oct 2010 14:14:05 -0700
Received: from NALASEXMB04.na.qualcomm.com ([]) by nalasexhub01.na.qualcomm.com ([]) with mapi; Fri, 22 Oct 2010 14:14:04 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Fri, 22 Oct 2010 14:13:58 -0700
Thread-Topic: SECDIR Review of draft-ietf-avt-rtp-svc-23
Thread-Index: ActyLgqaVpvgawTXTK6RBNcE7V2G0A==
Message-ID: <BF345F63074F8040B58C00A186FCA57F29F6C36D44@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-avt-rtp-svc.all@tools.ietf.org" <draft-ietf-avt-rtp-svc.all@tools.ietf.org>
Subject: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2010 21:12:29 -0000

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.