Re: [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes

정경훈 <> Thu, 13 January 2011 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C7D33A6B88 for <>; Thu, 13 Jan 2011 05:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.147
X-Spam-Level: *
X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nhz4Y+qsvUnu for <>; Thu, 13 Jan 2011 05:31:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2C5F13A6AAB for <>; Thu, 13 Jan 2011 05:31:54 -0800 (PST)
Received: from ( []) by (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <> for; Thu, 13 Jan 2011 22:33:39 +0900 (KST)
Received: from epv6spt1 ("port 21683"@[]) by (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <> for; Thu, 13 Jan 2011 22:33:39 +0900 (KST)
Message-id: <>
Date: Thu, 13 Jan 2011 13:33:39 +0000
From: 정경훈 <>
To: Stephen Farrell <>, "" <>, "" <>, "" <>
MIME-version: 1.0
X-MTR: 20110113131535653@kyunghun.jung
Msgkey: 20110113131535653@kyunghun.jung
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPHeader: ML
X-RootMTR: 20110113131535653@kyunghun.jung
MIME-version: 1.0
Content-type: text/html; charset="euc-kr"
Content-transfer-encoding: base64
X-Generator: Namo ActiveSquare 7
X-Mailman-Approved-At: Thu, 13 Jan 2011 07:21:34 -0800
Subject: Re: [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes
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: Thu, 13 Jan 2011 13:31:55 -0000

Samsung Enterprise Portal mySingle

Dear Mr. Stephen Farrell and IETF experts:


Thank you for your kind comments.


When we start this work in 2007 (finished in 3GPP and early implementations soon),

our key objective was to maximize the perceived quality of 4G mobile video telephony

at the low but most expensive bit-rate, perhaps second only to satellite in terms of cost.


Considering the strong security of IMS, over which the 4G handset using this attribute will be

deployed, we did not pay enough attention to areas you kindly mentioned. Apparantly, if the

image sizes accompanying "imageattr" are corrupted during negotiation, session setup can be

delayed or even dropped. We will reflect your advices into the draft soon.


Thank you again and many comments or corrections will be greatly welcomed.


Kyunghun Jung

Samsung Electronics Co., Ltd.


------- Original Message -------

Sender : Stephen Farrell<>

Date : 2011-01-13 20:52 (GMT+09:00)

Title : [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft defines a way to ask a sender to use different image
attributes using SDP.

The security considerations says that this doesn't change anything,
but I don't quite agree. A requestor could (accidentally or on
purpose) as for some very large image size or for some kind
of transformation that puts a lot of load on a transcoder, and
that could be part of some DoS attack. (I've actually seen this
bug triggered accidentally in a real system that did more or
less this.)

I'd suggest adding a paragraph to the security considerations
saying that implementations should be wary of this and could
include some sanity checking of inputs or could try to detect
cases where lots of resources are being used and then handle that
somehow. I don't know how that'd be best done, nor whether any
of that should use 2119 type language, but I assume the authors
can figure that out.