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

[Linda Dunbar <[e-mail]>]

Diego,

Thank you very much for your explanation of the questions.

A few more questions.

The Trusted Computing Group has defined the Remote Attestation:

to enable a remote system to determine the level of trust in the integrity of platform of another system (attestator). The architecture for remote attestation consists of two major components: Integrity
measurement architecture and remote attestation protocol.

Are you trying to apply what being defined by TCG RA to  “Client <=> Controller” context?  Or is  the intent to identify the reasonable deployment scenarios, so that (lower cost) simplified procedures and protocols for remote attestation can be identified?    For example, if all requests to controller have to be carried by the TCP session initiated by the trusted controller,   remote attestation procedure can be simpler.

Your opinion?

Linda


From: DIEGO LOPEZ GARCIA [mailto:[e-mail]]
Sent: Friday, January 29, 2016 5:18 PM
To: Linda Dunbar
Cc: ANTONIO AGUSTIN PASTOR PERALES; [e-mail]
Subject: Re: Questions & suggstions to draft-pastor-i2nsf-vnsf-attestation-00

Hi Linda,

Thanks for your comments. We are working in a new version and will try to address them in it, but let me make a few remarks inlined below…


On 30 Jan 2016, at 24:07 , Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

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?

DRL> We will try to expand the document to cover of the threats that can addressed by trust assessment on the platform and the NSFs, so we’ll make a note on which ones are in that category.


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)

DRL> This is a good suggestion. We’ll follow it



 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 ?

DRL> The selection of the appropriate NSFs is supposed to happen before the attestation procedures are applied, so I’d say this draft addresses the situation of both cases 1 and 2. Anyway, I see interesting to explore your suggestion, especially in case 1, that would require a rather intelligent controller...



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?

DRL> The specification of Secure Boot yes, but I consider a reference to its applicability necessary...


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

DRL> The controller should measure the HW/SW on which the NSFs run, what we call the platform. We’ll try to make it clearer in the draft


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?

DRL> Indeed, and this is connected with the discussion on the selection of the vNSFs above. We’ll try to make it clear in the draft

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Tel:    [phone]
Mobile: [phone]
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição