Re: [video-codec] Secdir last call review of draft-ietf-netvc-requirements-09

Filippov Alexey <Alexey.Filippov@huawei.com> Wed, 29 May 2019 08:24 UTC

Return-Path: <Alexey.Filippov@huawei.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714612011C; Wed, 29 May 2019 01:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scCgoqnTtELP; Wed, 29 May 2019 01:24:30 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2A91200F9; Wed, 29 May 2019 01:24:30 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DA1F474E239E11457A1B; Wed, 29 May 2019 09:24:27 +0100 (IST)
Received: from fraeml706-chm.china.huawei.com (10.206.15.55) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 29 May 2019 09:24:27 +0100
Received: from fraeml705-chm.china.huawei.com (10.206.15.54) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 29 May 2019 10:24:27 +0200
Received: from fraeml705-chm.china.huawei.com ([10.206.112.183]) by fraeml705-chm.china.huawei.com ([10.206.112.183]) with mapi id 15.01.1713.004; Wed, 29 May 2019 10:24:27 +0200
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-netvc-requirements.all@ietf.org" <draft-ietf-netvc-requirements.all@ietf.org>, "video-codec@ietf.org" <video-codec@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Elena Alshina <elena.alshina@huawei.com>
Thread-Topic: Secdir last call review of draft-ietf-netvc-requirements-09
Thread-Index: AQHVFXvB/QOZDB7VaEmRwya5HDEc/qaBpN4Q
Date: Wed, 29 May 2019 08:24:27 +0000
Message-ID: <15bb8ab80acd410ba7e22809eb95e727@huawei.com>
References: <155906492120.25733.13337604572333992432@ietfa.amsl.com>
In-Reply-To: <155906492120.25733.13337604572333992432@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.198.51.251]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/video-codec/b988qHkAjdFe5u51Yw5MACWSAS0>
Subject: Re: [video-codec] Secdir last call review of draft-ietf-netvc-requirements-09
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 08:24:33 -0000

Dear Linda,

Thank you a lot for your comments and questions. Below, please, find my answers.
> why ?
In the case of software implementation, decoding a compressed stream can be a computationally intensive process that can require extensive data exchange between internal and external memory. So, if decoding should be performed in real time, this process can allocate too many computational resources (such as processor cores and memory that has limited bandwidth ) that are becoming unavailable for other tasks. This situation can lead to denial-of-services issues (such as media blackhole attack that is similar to packet drop attack, https://en.wikipedia.org/wiki/Packet_drop_attack). Thus, forging such streams that require too many computational resources for decoding can be considered a DoS attack. To address this security issue, computational resources should be allocated according to a codec level that in fact defines "the worst case of computational complexity, memory bandwidth, and physical memory size". It should guarantee that any picture can be decoded within a certain maximum time period for given computational resources.

--
Best regards,
Alexey Filippov

-----Original Message-----
From: Linda Dunbar via Datatracker [mailto:noreply@ietf.org] 
Sent: Tuesday, May 28, 2019 8:35 PM
To: secdir@ietf.org
Cc: draft-ietf-netvc-requirements.all@ietf.org; video-codec@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-netvc-requirements-09

Reviewer: Linda Dunbar
Review result: Has Nits

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.

This document describes the overview of internet Video codec applications and the corresponding requirements. However, it doesn't cover any security requirement.

Section 5 on Security Consideration description doesn't make sense to me. It stats that  not covering worst case of computational complexity/memory bandwidth can be considered as security vulnerability and lead to denial of services (DoS) in the case of attacks.

why ?

what are "the worst case of computational complexity/memory bandwidth"? why covering them can eliminate the "security vulnerability"?

Linda Dunbar