[secdir] SecDir review of draft-ietf-avt-rtp-uemclip-04

Magnus Nyström <magnus@rsa.com> Tue, 17 February 2009 07:36 UTC

Return-Path: <magnus@rsa.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFAA3A69A2; Mon, 16 Feb 2009 23:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuf8K-lma13B; Mon, 16 Feb 2009 23:36:20 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 543373A684F; Mon, 16 Feb 2009 23:36:20 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n1H7aRPA011186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 02:36:28 -0500 (EST)
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Tue, 17 Feb 2009 02:36:19 -0500
Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.10.43]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n1H7aDU6027885; Tue, 17 Feb 2009 02:36:16 -0500 (EST)
Received: from CORPUSMX50B.corp.emc.com ([128.221.62.39]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 02:36:15 -0500
Received: from W-JNISBETTEST-1 ([10.72.72.44]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 02:36:15 -0500
Date: Tue, 17 Feb 2009 08:36:44 +0100
From: Magnus Nyström <magnus@rsa.com>
To: iesg@ietf.org, secdir@ietf.org, hiwasaki.yusuke@lab.ntt.co.jp, ohmuro.hitoshi@lab.ntt.co.jp
In-Reply-To: <Pine.WNT.4.64.0812101529200.3888@W-JNISBETTEST-1.tablus.com>
Message-ID: <Pine.WNT.4.64.0902161338530.5224@W-JNISBETTEST-1.tablus.com>
References: <Pine.WNT.4.64.0805121031000.2612@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0811051802030.7640@W-JNISBETTEST-1.tablus.com> <Pine.WNT.4.64.0812101529200.3888@W-JNISBETTEST-1.tablus.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 17 Feb 2009 07:36:15.0229 (UTC) FILETIME=[69F9F2D0:01C990D2]
Cc: ron.even.tlv@gmail.com, secdir-secretary@ietf.org, tom.taylor@rogers.com
Subject: [secdir] SecDir review of draft-ietf-avt-rtp-uemclip-04
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: Tue, 17 Feb 2009 07:36:21 -0000

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.

Background
----------
This document describes the payload format of an enhanced speech codec of 
ITU-T G.711.

Comments
--------

The draft appears well written to me (it may benefit from an editorial 
review by a native English reader however). The Security Considerations 
section also appears adequate. One (possible) suggestion: The security 
consideration section notes the risk of memory attacks due to illegal 
layer indices etc. Maybe it could also be pointed out that decoders could 
be configured to reject layer indices etc. that are outside of some 
specified policy?

Other than that I have no additional comments on this document.

-- Magnus