Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-registration-interface-dm-00.txt

From: [email-masked]
Date: Sat, 20 Oct 2018 13:09:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions WG of the IETF.

        Title           : I2NSF Registration Interface Data Model
        Authors         : Sangwon Hyun
                          Jaehoon Paul Jeong
                          Taekyun Roh
                          Sarang Wi
                          Jung-Soo Park
	Filename        : draft-ietf-i2nsf-registration-interface-dm-00.txt
	Pages           : 23
	Date            : 2018-10-20

Abstract:
   This document defines an information model and a YANG data model for
   Interface to Network Security Functions (I2NSF) Registration
   Interface between Security Controller and Developer's Management
   System (DMS).  The objective of these information and data models is
   to support NSF search, instantiation and registration according to
   required security capabilities via I2NSF Registration Interface.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-00
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 21 Oct 2018 05:58:26 +0000

Hi,

I've gone through the new version of the Registration Interface mode draft, that does look much better and integrated to me now, and I have a few comments, most of them on the procedures described for using the interface and the connection of Controller and the DMS:

1) First of all, related to terminology: Why do you define the term "NSF Profile"? Why not refer to the "Profile" definition in the terminology document? By referring just to "Profile" I think you can freely use "NSF Profile" later on...

2) The actions described in section 4 seems to imply a direct and dynamic communication between Controller and DMS, when what I foresee is something similar to the onboarding mechanisms in current software-based networks: The DMS uses the registration interface to provide and update the capabilities of those NSFs provided to the Controller, and the Controller makes the appropriate selection once it receives a request from a client, instantiating them from the repository. But by no means a direct dialog between Controller and DMS should be assumed, nor I think we should specify a dynamic instantiation mechanism in this document.

3) The same happens with the process described in section 5. We should change this into a decoupled register-select-instantiate operation sequence. And, BTW, what do you mean by "a specific NSF required or *wasted* in the current system"? Wasted by whom and how?

4) Following this, the instantiation and deinstantaiation operations described in 5.1 should not be used. What is more, I'd say they are out of the scope of this document, and while mechanisms for instance management could be generally mentioned, they should not be described in detail here.

5) And a question on the access information described in section 5.3: should it not include a reference to the mechanisms to secure the access, like encryption, reference to certificates or key repositories, etc. I am not asking for storing credentials, but at least to let the Controller know that IPsec using certificates approved by a particular CA should be used, for example.

Be goode,

 --
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

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

On 20/10/2018, 22:10, "I2nsf on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Abstract:

    _______________________________________________
    I2nsf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/i2nsf

________________________________

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 22 Oct 2018 13:01:54 +0900

Hi Diego,
Here are my answers inline.

On Sun, Oct 21, 2018 at 2:58 PM Diego R. Lopez <[email-masked]>
wrote:

> Hi,
>
> I've gone through the new version of the Registration Interface mode
> draft, that does look much better and integrated to me now, and I have a
> few comments, most of them on the procedures described for using the
> interface and the connection of Controller and the DMS:
>
> 1) First of all, related to terminology: Why do you define the term "NSF
> Profile"? Why not refer to the "Profile" definition in the terminology
> document? By referring just to "Profile" I think you can freely use "NSF
> Profile" later on...
>
 => That's a good suggestion. We will refer to the definition of "Profile"
of the object of an NSF
      for the sake of "NSF Profile" in the revision -01.

>
> 2) The actions described in section 4 seems to imply a direct and dynamic
> communication between Controller and DMS, when what I foresee is something
> similar to the onboarding mechanisms in current software-based networks:
> The DMS uses the registration interface to provide and update the
> capabilities of those NSFs provided to the Controller, and the Controller
> makes the appropriate selection once it receives a request from a client,
> instantiating them from the repository. But by no means a direct dialog
> between Controller and DMS should be assumed, nor I think we should specify
> a dynamic instantiation mechanism in this document.
>
>  => In the IETF-103 Hackathon project for I2NSF in OpenStack-Based NFV,
DMS is implemented as an EM that has an interface (i.e., Ve-Vnfm Interface)
with VNF Manager.
    That is, the instantiation request from Security Controller to DMS will
be delivered to VNF Manager by DMS .
     We will clarify this text based on our implementation in the revision.

> 3) The same happens with the process described in section 5. We should
> change this into a decoupled register-select-instantiate operation
> sequence. And, BTW, what do you mean by "a specific NSF required or
> *wasted* in the current system"? Wasted by whom and how?
>
 => The wasted NSF is an NSF that is not used by any traffic flows, yet is
running as a VNF in the NFV environment. For the efficient resource
management, we need to
      deinstantiate such an NSF.

     The appendix of Registration Interface Information Model Draft below
clarifies the above my answers.
     Appendix A.  Lifecycle Management Mechanism in
draft-hyun-i2nsf-registration-interface-im-06

https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-06#page-12

     According to your comments, the the instantiation and deinstantiation
of an NSF will clarified in an Appendix rather than in a main section.

>
> 4) Following this, the instantiation and deinstantaiation operations
> described in 5.1 should not be used. What is more, I'd say they are out of
> the scope of this document, and while mechanisms for instance management
> could be generally mentioned, they should not be described in detail here.
>

 => Yes, as mentioned above, the instantiation and deinstantaiation
operations will be described in an Appendix in the revision.

>
> 5) And a question on the access information described in section 5.3:
> should it not include a reference to the mechanisms to secure the access,
> like encryption, reference to certificates or key repositories, etc. I am
> not asking for storing credentials, but at least to let the Controller know
> that IPsec using certificates approved by a particular CA should be used,
> for example.
>
>  => As explained in I2NSF-IPsec draft (
https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-06#page-6
),
      NSF Access Information contains the information to access an NSF in
the I2NSF network,  such asfollowings
      IPv4 address, IPv6 address, port number, and supported transport
protocol(s) rather than security information
      such IPsec session information. For secure access, we can use IPsec
for I2NSF in

https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-02

      We will add the text about secure access using IPsec along with the
above the I2NSF-IPsec draft in the revision.

      Thanks.

      Paul

> On 20/10/2018, 22:10, "I2nsf on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
> 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

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 23 Oct 2018 03:39:38 +0000

Hi Paul,

I think we agree in all aspects, but on the DMS concept and its connection with the Security Controller. In my view, a DMS will never be associated to VNFM (or anything else in the MANO stack) Let me try to illustrate this by means of the organizational roles involved: a SC would be typically run by a network provider or a its customer (Telefonica or, say, a bank Telefonica is providing network services), and a DMS would be typically run by a network equipment vendor (Huawei, Ericsson, F5…), and therefore it is quite unlikely the VNFM instances running in the network service providers are run by network equipment vendors.

In an NFV environment, the DMS requests through the registration interface will translate into events related with NSF onboarding. And the SC will use the registration interface to query the catalog of available NSFs and translate its decisions into requests to the MANO stack. So we could conclude the registration interface is the way for both the DMS and the SC interact with the NFV MANO stack, but by no means in an interactive, direct way. The shortcut you describe may be acceptable for demonstration purposes in a hackathon, but I do not see how this can match a real operational environment.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

On 21/10/2018, 23:01, "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

On Sun, Oct 21, 2018 at 2:58 PM Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

1) First of all, related to terminology: Why do you define the term "NSF Profile"? Why not refer to the "Profile" definition in the terminology document? By referring just to "Profile" I think you can freely use "NSF Profile" later on...
 => That's a good suggestion. We will refer to the definition of "Profile" of the object of an NSF
      for the sake of "NSF Profile" in the revision -01.

2) The actions described in section 4 seems to imply a direct and dynamic communication between Controller and DMS, when what I foresee is something similar to the onboarding mechanisms in current software-based networks: The DMS uses the registration interface to provide and update the capabilities of those NSFs provided to the Controller, and the Controller makes the appropriate selection once it receives a request from a client, instantiating them from the repository. But by no means a direct dialog between Controller and DMS should be assumed, nor I think we should specify a dynamic instantiation mechanism in this document.
 => In the IETF-103 Hackathon project for I2NSF in OpenStack-Based NFV, DMS is implemented as an EM that has an interface (i.e., Ve-Vnfm Interface) with VNF Manager.
    That is, the instantiation request from Security Controller to DMS will be delivered to VNF Manager by DMS .
     We will clarify this text based on our implementation in the revision.

3) The same happens with the process described in section 5. We should change this into a decoupled register-select-instantiate operation sequence. And, BTW, what do you mean by "a specific NSF required or *wasted* in the current system"? Wasted by whom and how?
 => The wasted NSF is an NSF that is not used by any traffic flows, yet is running as a VNF in the NFV environment. For the efficient resource management, we need to
      deinstantiate such an NSF.

     The appendix of Registration Interface Information Model Draft below clarifies the above my answers.
     Appendix A.  Lifecycle Management Mechanism in draft-hyun-i2nsf-registration-interface-im-06
     https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-06#page-12

     According to your comments, the the instantiation and deinstantiation of an NSF will clarified in an Appendix rather than in a main section.

 => Yes, as mentioned above, the instantiation and deinstantaiation operations will be described in an Appendix in the revision.

5) And a question on the access information described in section 5.3: should it not include a reference to the mechanisms to secure the access, like encryption, reference to certificates or key repositories, etc. I am not asking for storing credentials, but at least to let the Controller know that IPsec using certificates approved by a particular CA should be used, for example.
 => As explained in I2NSF-IPsec draft (https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-06#page-6),
      NSF Access Information contains the information to access an NSF in the I2NSF network,  such asfollowings
      IPv4 address, IPv6 address, port number, and supported transport protocol(s) rather than security information
      such IPsec session information. For secure access, we can use IPsec for I2NSF in
      https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-02

      We will add the text about secure access using IPsec along with the above the I2NSF-IPsec draft in the revision.

      Thanks.

      Paul

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

On 20/10/2018, 22:10, "I2nsf on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Abstract:

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

    _______________________________________________
    I2nsf mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/i2nsf

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
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 23 Oct 2018 12:50:45 +0900

Diego,
Thanks for your clarification comments.

My team will review your comments for the construction of I2NSF framework
in an NFV environment, and
then polish up the description of the registration interface between SC and
DMC along with the MANO stack
in the revision of the Registration Interface Data Model document.

Thanks.

Best Regards,
Paul

On Tue, Oct 23, 2018 at 12:39 PM Diego R. Lopez <
[email-masked]> wrote:

> Hi Paul,
>
>
>
> I think we agree in all aspects, but on the DMS concept and its connection
> with the Security Controller. In my view, a DMS will never be associated to
> VNFM (or anything else in the MANO stack) Let me try to illustrate this by
> means of the organizational roles involved: a SC would be typically run by
> a network provider or a its customer (Telefonica or, say, a bank Telefonica
> is providing network services), and a DMS would be typically run by a
> network equipment vendor (Huawei, Ericsson, F5…), and therefore it is quite
> unlikely the VNFM instances running in the network service providers are
> run by network equipment vendors.
>
>
>
> In an NFV environment, the DMS requests through the registration interface
> will translate into events related with NSF onboarding. And the SC will use
> the registration interface to query the catalog of available NSFs and
> translate its decisions into requests to the MANO stack. So we could
> conclude the registration interface is the way for both the DMS and the SC
> interact with the NFV MANO stack, but by no means in an interactive, direct
> way. The shortcut you describe may be acceptable for demonstration purposes
> in a hackathon, but I do not see how this can match a real operational
> environment.
>
>
>
> Be goode,
>
>
>
> --
>
> On 21/10/2018, 23:01, "Mr. Jaehoon Paul Jeong" <[email-masked]>
> wrote:
>
>
>
> Hi Diego,
>
> On Sun, Oct 21, 2018 at 2:58 PM Diego R. Lopez <
> [email-masked]> wrote:
>
> Hi,
>
>     That is, the instantiation request from Security Controller to DMS
> will be delivered to VNF Manager by DMS .
>
> ------------------------------
>