[I2nsf] Questions & suggstions to draft-pastor-i2nsf-vnsf-attestation-00

Linda Dunbar <linda.dunbar@huawei.com> Fri, 29 January 2016 23:07 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732651A911B for <i2nsf@ietfa.amsl.com>; Fri, 29 Jan 2016 15:07:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable
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 CKhYfT8hruc4 for <i2nsf@ietfa.amsl.com>; Fri, 29 Jan 2016 15:07:45 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F591A90A8 for <i2nsf@ietf.org>; Fri, 29 Jan 2016 15:07:44 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHR09998; Fri, 29 Jan 2016 23:07:41 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 Jan 2016 23:07:39 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Fri, 29 Jan 2016 15:07:34 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: ANTONIO AGUSTIN PASTOR PERALES <antonio.pastorperales@telefonica.com>, 'DIEGO LOPEZ GARCIA' <diego.r.lopez@telefonica.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Thread-Topic: Questions & suggstions to draft-pastor-i2nsf-vnsf-attestation-00
Thread-Index: AdFa6dZPY3cOkGxTRvK10yqlMgLXcg==
Date: Fri, 29 Jan 2016 23:07:34 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DE48CA@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.190]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DE48CAdfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56ABF0BE.01B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d872ca783f9cda250494becde630ac45
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/8b4KAZaIU_e7hnJfAcoKqCItiyk>
Subject: [I2nsf] Questions & suggstions to draft-pastor-i2nsf-vnsf-attestation-00
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 23:07:58 -0000

Antonio and Diego,

The draft-pastor-i2nsf-vnsf-attestation-00 has brought out very interesting security aspects of deploying I2NSF. Thank you very much.

Section 1 provides a very good threat analysis for I2NSF environment.  However, the solution (Section 5) only covers how "user" attest the "Controller". Do you plan to expand the draft to cover all the security threats documented in the Section 1?
I understand some of the issues described in the Section 1 is very difficult to solves. For example:
An authorized user may misuse assigned privileges to alter the network traffic processing of other users in the virtualization platform...


It is great to have those security threats documented. It would also be good to add a note when those issues are out of the scope of I2NSF.

Another example:
A user with physical access to the virtualization platform can modify the behavior of hardware components.
(my note: This issue is true to all virtualized functions. There is also data leakage across different VNFs instantiated on the same physical servers.  We should put a note that this is not something that IETF can address)


Architecturally, there are two ways that users  can use I2NSF:

1.     Users can specify the "Service Layer Policies/rules"  to the Security Controller. The Controller select the appropriate NSFs (virtual or physical) to enforce the "Service Policies" by passing down the "Capability Layer rules/policies".

2.     vNSFs are allocated to the Users. So the Users can send direct policies to its designated vNSFs via the Security Controller.


Your draft covers the Case 2 above very well. Can you add some description to the Case 1 ?

Some questions:

Section 4.1.3: Secure Boot is applicable to any Hypervisors that host multiple VMs. Should it be out of scope for I2NSF?

Section 5.2: Does the controller measure the User's hardware & software  components or measure its own HW&SW?

Section 5.3: Instantiation of vNSF to Container should be done by the lifecycle management of vNSF. The controller's job is only to pass policies. Is this your understanding too?


Thank you.

Linda