Subject: [I2nsf] Review of draft-pastor-i2nsf-usecases-00

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 05:18:26 -0500

Antonio and Diego: 

Thank you for a well-written draft which presents a clear view of the vNSF
device.  This use case provides a clear case for defining the following: 

.         architecture of a vNSF,  

.         OAM interface for security (Function based API),  

.         an intent-based customer API for the vNSF (service based API),   

.         mechanisms for validation of availability provenance, and correct
execution,  integrity of the NSF, and Isolation,

.         Policy that would be accessed by the OAM, and 

.         Security functions (traffic inspection, traffic manipulation, and
impersonation) that could be selected as capabiltie4s of these functions. 

This use case creates a clear use case for the work.  However, I have a few
questions listed below:  

Questions: 

1) Do you think the OAM Function based interface for security can be built
on top of existing protocols? 

 I2RS is taking the approach of specifying extensions to existing protocols
and working on information models and yang data models. Do you think this
approach would satisfy your use case?  

Let me provide a bit of expansion on what I2RS is doing.  

.         I2RS WG in its specification of the dynamic interface to the
routing/switching systems is specifying requirements for the dynamic
protocol.  The I2RS has already suggested expanding the netconf/restconf
protocol with additional features for publication/subscription and
traceability.  More additions are in the process of being specified. 

.         I2RS is defining protocol independent modules and allowing
protocol specific modules. 

Do you think an expansion of I2RS plus vNSF Yang Modules would work for the
OAM Function interface? Or do you see a combination of the SACM interface
plus an I2RS interface would work?  Or something entirely different.   

2)  Are you considering a push model for the security and firewall
parameters (Radius, etc).  Or a pull based model based on an identity
requested? 

3) How do you compare the vNSF to the broker function in the I2RS work 

3) Do you think the Service layer can be Intent Based?  

Sue Hares

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 4 Feb 2015 12:24:37 +0000

Hi Sue,

Some attempts to reply to your questions inline below...

On 3 Feb 2015, at 11:18 , Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
1) Do you think the OAM Function based interface for security can be built on top of existing protocols?
 I2RS is taking the approach of specifying extensions to existing protocols and working on information models and yang data models. Do you think this approach would satisfy your use case?
Let me provide a bit of expansion on what I2RS is doing.
*         I2RS WG in its specification of the dynamic interface to the routing/switching systems is specifying requirements for the dynamic protocol.  The I2RS has already suggested expanding the netconf/restconf protocol with additional features for publication/subscription and traceability.  More additions are in the process of being specified.

*         I2RS is defining protocol independent modules and allowing protocol specific modules.
Do you think an expansion of I2RS plus vNSF Yang Modules would work for the OAM Function interface? Or do you see a combination of the SACM interface plus an I2RS interface would work?  Or something entirely different.
For the OAM functionality I believe that an expansion of I2RS and the appropriate YANG modules would be enough. But we must not forget the other essential element when dealing with security services: trust. There is a need of establishing a trusted link between the user and the provider platform and services. This not only include the establishment of a secure connection, but the attestation procedures so the user can be sure (to an appropriate level of assurance) the right services are being provided on the right platform.
2)  Are you considering a push model for the security and firewall parameters (Radius, etc).  Or a pull based model based on an identity requested?
We are considering both models, depending on who acts at the capability layer. When the provider defines a set of NFs or provision them to be available for a set of users, I think a RADIUS or similar mechanism to access a provider-wide data repository would be the most efficient way. For fine tuning, personalization and direct management, a direct request-response mechanism should be applied.
3) How do you compare the vNSF to the broker function in the I2RS work
I assume you refer here to what has been called the controller, that would have an equivalent function to what I understand an I2RS broker does. In fact, I think calling it a broker in this context would help in clarifying its role. The term controller is too overloaded recently, and this component could play a (brokering) role when dealing with trust establishment, at least for levels of assurance below "paranoid" ones.
3) Do you think the Service layer can be Intent Based?
Definitely yes. We are involved in a project related to I2NSF goals, and what is called the high-level policy there is very much in line with intent. There a couple of aspects to refine, as these high-level policies allow some imperative definitions, but I think this is the direction to go.

Be goode,

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

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