Subject: Re: [I2nsf] I2NSF Scope discussion

From: Yoav Nir <[email-masked]>
Date: Sun, 1 Feb 2015 11:29:30 +0200

Hi, Linda.

I’ll preface my comments with the disclaimer that although I work for a firewall/IPS company, I work mostly in IPsec and SSL VPNs.

Having said that, unlike routing, switching and IPsec VPNs, firewalls and IPS are a dynamic field, with capabilities varying wildly among vendors and changing fast. There is also no “standardized” terminology for these capabilities, so filtering out “inappropriate” content or blocking emails with “phishing” or “spam” could mean different things to different vendors, and different things to different administrators.

Splitting the interface as proposed below alleviates some of that concern, and I think the proposed work is a goal worth pursuing, but it does place a great deal of responsibility on the controller. It will have to translate the “no spam” requirement to whatever capabilities the security devices advertise. All anti-spam configurations for example are a balancing act between type I and type II errors. It is going to be challenging for the same intent (and presumably tolerance of type I errors) to be translated correctly to different devices.

Again, this is not something that should discourage us from trying. It is just something to be careful about.

Yoav

> On Jan 29, 2015, at 4:43 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Over the email discussion on the I2NSF list, it becomes clear that there are two distinct interfaces for I2NSF:
> -          Capability or Functional Oriented interface between Controller and Devices (or devices’ adaptor), which focuses more on the functional security policies for the functions listed above.
> -          Service Oriented interface between Applications/Users and the Controller, which is more intent description for service requests, monitor, reports, etc.
>  
> It is envisioned that clients of the I2NSF include security administrators, management systems, applications (or its controller), or security functions that detect suspicious threat triggering more vigorous security resources.
>  
> http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-00 <http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-00> provides a concrete set of content going through the functional interface: 
>  
>                                            +---------+
>                                            |Src/dest |
>                                          +-> address |
>                                          | |  scope  |
>                                          | +---------+
>                                          |
>                                          | +---------+
>                                          +->  User   |
>               +--------+                 | +---------+
>               |        |                 |
>            +-->  Rule  |    +---------+  | +---------+
>            |  |        |  +-> Objects +--+-> Service |
>            |  +--------+  | +---------+  | +---------+
>            |              |              |
>            |      *       |              | +-----------+
>            |      *       |              +->Application|
>            |      *       |              | +-----------+
>            |              |              |
> +-------+  |  +--------+  |              | +----------+
> |       |  |  |        |  |              +-> Schedule |
> |Policy +--+-->  Rule  +--+              | +----------+
> |       |  |  |        |  |              |
> +-------+  |  +--------+  |              |            +---------+
>            |              |              |   *      +->Antivirus|
>            |      *       |              +-> *      | +---------+
>            |      *       |                  *      |
>            |      *       |                         | +---------+
>            |              |                         +->  IPS    |
>            |              |                         | +---------+
>            |  +--------+  |                         |
>            |  |        |  |                         | +----------+
>            +-->  Rule  |  |                         +->  URL     |
>               |        |  |                         | | Filtering|
>               +--------+  |               +-------+ | +----------+
>                           |             +->Permit +-+
>                           | +---------+ | +-------+ | +----------+
>                           +-> Actions +-+           +->   File   |
>                             +---------+ | +-------+ | | Blocking |
>                                         +-> Deny  | | +----------+
>                                           +-------+ |
>                                                     | +----------+
>                                                     | |   Data   |
>                                                     +-> Filtering|
>                                                     | +----------+
>                                                     |
>                                                     | +------------+
>                                                     | | Application|
>                                                     +->   control  |
>                                                     | +------------+
>                                                     |
>                                                     |   *
>                                                     +-> *
>                                                         *
> Figure 1 The overall Information Model for I2NSF Capability Interface
>  
> For the Functional/Capability Interface, I2NSF deliverables should include:
> •       Develop a comprehensive set of informational Models for the functions listed above with regard to different aspects of OAM (Operations/Administration/Maintenance) including polices requests, monitoring, reports, fault/consistency management, etc. 
> •       Develop the corresponding Data Models, e.g. YANG model.
> •       Compare with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc” (e.g. PCP, Radius, etc)
> •       Specify the secure mechanisms to carry the content identified by the informational models. E.g. TLS to carry the information.
> •       Authentication and registration mechanism
> E.g. who is legitimate to issue security policies or monitor reports over the Functional Interface. 
>  
> For the Service Layer Interface, I2NSF deliverables should include:
> •       Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS
> •       Develop comprehensive set of “TARGETs” for the Security Intent
> –       e.g. Security Target in Data Centers network, in Access Network, in Wide Area network, etc
> –      Develop informational model for “Users”, “Roles”, “Permissions”
> •       Develop the corresponding Data Models, e.g. YANG model.
> •       Compare with existing IETF protocols for “Roles”, “Users”, “Permissions”, etc.
>  
> In addition, the I2NSF working group will
> •        Document a high-level architecture that will describe the functional building blocks for the dynamic negotiation of security service parameters, the dynamic and subsequent allocation of network security resources and the operation of such resources, including means to assess that what has been allocated complies with what has been negotiated.
> •       Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And
> •        Analyze candidate protocols that may carry the information to be exchanged through the various interfaces.
>  
> Any more suggestions? 
>  
> Cheers, 
>  
> Linda Dunbar
> _______________________________________________
> I2nsf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>

---

From: Zongning <[email-masked]>
Date: Mon, 2 Feb 2015 00:58:04 +0000

Hi, Linda,

Generally speaking I support the proposed work of I2NSF, especially from the perspective of motivation and value of this work to users of security functions.
However, I am a little bit conservative to the proposed deliverables – current scope covers too many work items and many of them are very general work.
I’d suggest to start from the bottom. For example, start with gap analysis to existing IETF protocols (e.g. PCP, Radius, etc), based on one or two typical use cases for I2NSF. This is mainly to drive the further discussion of information models.

Thanks.

-Ning

发件人: I2nsf [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2015年1月29日 10:44
收件人: [email-masked]
抄送: Romascanu, Dan (Dan); [email-masked]
主题: [I2nsf] I2NSF Scope discussion

http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-00 provides a concrete set of content going through the functional interface:

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

For the Functional/Capability Interface, I2NSF deliverables should include:
*       Develop a comprehensive set of informational Models for the functions listed above with regard to different aspects of OAM (Operations/Administration/Maintenance) including polices requests, monitoring, reports, fault/consistency management, etc.
*       Develop the corresponding Data Models, e.g. YANG model.
*       Compare with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc” (e.g. PCP, Radius, etc)
*       Specify the secure mechanisms to carry the content identified by the informational models. E.g. TLS to carry the information.
*       Authentication and registration mechanism
E.g. who is legitimate to issue security policies or monitor reports over the Functional Interface.

For the Service Layer Interface, I2NSF deliverables should include:
*       Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS
*       Develop comprehensive set of “TARGETs” for the Security Intent
–       e.g. Security Target in Data Centers network, in Access Network, in Wide Area network, etc
–      Develop informational model for “Users”, “Roles”, “Permissions”
*       Develop the corresponding Data Models, e.g. YANG model.
*       Compare with existing IETF protocols for “Roles”, “Users”, “Permissions”, etc.

In addition, the I2NSF working group will
*        Document a high-level architecture that will describe the functional building blocks for the dynamic negotiation of security service parameters, the dynamic and subsequent allocation of network security resources and the operation of such resources, including means to assess that what has been allocated complies with what has been negotiated.
*       Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And
*        Analyze candidate protocols that may carry the information to be exchanged through the various interfaces.

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 2 Feb 2015 08:21:39 +0000

Hi Linda,
Thanks for your good summary.
I think this scope description is comprehensive and covers all the key works we identify till now. I support the proposed works and will contribute my efforts.

I have the other suggestions as follows:

1.       We need a terminology draft to describe clearly what is the exact mean of some key terminologies (e.g., intent-driven, service, capability, etc) used in our works;

2.       We need to put more efforts on the gap analysis work, which is the basis and guidance to our further work.

Thanks!

B.R.
Frank

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, January 29, 2015 10:44 AM
To: [email-masked]
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: [I2nsf] I2NSF Scope discussion

-          Capability or Functional Oriented interface between Controller and Devices (or devices' adaptor), which focuses more on the functional security policies for the functions listed above.

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

*    Compare with existing IETF protocols for "OBJECTs, ACTIONs, FILTERING, etc" (e.g. PCP, Radius, etc)

For the Service Layer Interface, I2NSF deliverables should include:
*    Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS
*    Develop comprehensive set of "TARGETs" for the Security Intent
-    e.g. Security Target in Data Centers network, in Access Network, in Wide Area network, etc
-   Develop informational model for "Users", "Roles", "Permissions"
*    Develop the corresponding Data Models, e.g. YANG model.
*    Compare with existing IETF protocols for "Roles", "Users", "Permissions", etc.

Any more suggestions?

Cheers,

Linda Dunbar

---

From: Shaibal Chakrabarty <[email-masked]>
Date: Mon, 2 Feb 2015 09:08:13 -0600

Linda:

Thank you for your efforts and in iteratively clarifying the requirements.
This is a very good start for a much larger domain of interfaces to network
security functions.

with best regards, shaibal

On Wed, Jan 28, 2015 at 8:43 PM, Linda Dunbar <[email-masked]>
wrote:

> -          Capability or Functional Oriented interface between Controller
> and Devices (or devices’ adaptor), which focuses more on the functional
> security policies for the functions listed above.
>
> -          Service Oriented interface between Applications/Users and the
> Controller, which is more intent description for service requests, monitor,
> reports, etc.
>
>
>
> It is envisioned that clients of the I2NSF include security
> administrators, management systems, applications (or its controller), or
> security functions that detect suspicious threat triggering more vigorous
> security resources.
>
>
>
>
> http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-00
> provides a concrete set of content going through the functional interface:
>
>
>
>                                            +---------+
>
>                                            |Src/dest |
>
>                                          +-> address |
>
>                                          | |  scope  |
>
>                                          | +---------+
>
>                                          |
>
>                                          | +---------+
>
>                                          +->  User   |
>
>               +--------+                 | +---------+
>
>               |        |                 |
>
> •       Develop a comprehensive set of informational Models for the
> functions listed above with regard to different aspects of OAM
> (Operations/Administration/Maintenance) including polices requests,
> monitoring, reports, fault/consistency management, etc.
>
> •       Specify the secure mechanisms to carry the content identified by
> the informational models. E.g. TLS to carry the information.
>
> •       Develop a Role Based Access Control to express the Security
> Intent by Applications/Administrators/OSS
>
> •        Document a high-level architecture that will describe the
> functional building blocks for the dynamic negotiation of security service
> parameters, the dynamic and subsequent allocation of network security
> resources and the operation of such resources, including means to assess
> that what has been allocated complies with what has been negotiated.
>
> •       Document small and well-scoped use cases to constrain the scope
> of the work and achieve sufficient focus for the working group to deliver
> successful outcomes. And
>
> •        Analyze candidate protocols that may carry the information to be
> exchanged through the various interfaces.
>
>
>
> Any more suggestions?
>
>
>
> Cheers,
>
>
>
> Linda Dunbar
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 2 Feb 2015 11:15:40 -0500

+ support

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 28 January 2015 9:43 PM
To: [email-masked]
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: [I2nsf] I2NSF Scope discussion

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 2 Feb 2015 19:51:44 +0000

Hi Linda and Frank,

[Apologies on two fronts: (1) the is probably a bit long for most people's tastes in e-mail and (2) I had to compose it during the course of many "distractions" over multiple hours, so it might not flow as smoothly as I would have liked.]

I am reviewing the "service" and "capability" interface drafts and the same diagram reproduced in Linda's e-mail below appears in both of them. I would like to clarify just two terminological elements at this level to better focus future discussion:

- What is the category label for the set of boxes in the bottom/right-most portion of the diagram (i.e., "Antivirus" through "Application Control")?

   --- I would note that, from the  service provider/operator perspective in the context of NFV, most of these boxes would seem to refer to "functions" that could be implemented as VNFs, i.e., as "software appliances" running over NFV Infrastructure, replacing hardware device running over specialized hardware/firmware/OS.

   --- However, from the consumer/subscriber/customer perspective, these would be seen as "services" (e.g., AV-as-a-Service, FW-as-a-Service, etc.), and (for the most part) agnostic wrt implementation mechanisms (VNF or hardware; standards-based or proprietary).

   --- And note that for NFV, multiple VNFs can be "chained" into a service function path to form a composite service from the consumer/subscriber/customer perspective who would again (generally) be agnostic wrt the individual services underlying the composite.

- Now, that diagram also contains a "higher-level" box called "Service" (and note that it is at the same logical level as "Application"). How does this "Service" relate to the perspective outlined above? (And "It does not, because..." can be, of course, a perfectly valid answer!)

   --- Note that the "capability interface" document helpfully provides a definition for "Service", to wit:
        "o Service: A service is an application identified by a protocol type and port number. It can be a service or a group of services.
          NSF matches the service traffics based on the protocol types and port numbers and applies the security actions to them;"

   --- First, this is a very specific and low-level definition of "service" (PPSM); fitting this definition into the broader context outlined above is difficult...?

   --- Second, note the "is an application" part of the definition. Then note the definition of "Application" given in the same I-D:
        "o Application: An application is a computer program for a specific task or purpose, and multiple applications constitute an application group.
          It provides a finer granularity than service in matching traffic. Even if different applications have the same service, they still can be distinguished
          by analyzing the data packets and comparing the signatures of each application...."

   --- In common usage (esp. from the consumer/subscriber/customer perspective), I am not certain that "applications" are seen as more finely granular than "services". And much of the NFV world is using this diagram (or something similar) which I have pulled from Open Networking Foundation, Software-Defined Networking: The New Norm for Networks, April 13, 2012, p. 7, for the high-level positioning of these constructs:

I think (based upon what I have read and considered thus far) that the two interfaces that I2NSF needs to be concerned with, relative to your diagram below, are:

   - An interface from the "Policy" component (probably via an "Applications" component positioned per the ONF diagram above) to the (possibly composite) "Service" component; and
   - an interface from the "Service" component to the capabilities of the individual security-related VNFs

This pair of interfaces is very close to the two you outline below, but not quite the same. An issue of the first (of my pair) is the intersection with SUPA and/or IBNemo, etc...? An issue with the second is should I2NSF push more specialized capability policies to the VNFs or should it translate from service operations to VNF capability commands or such...?

But the key issues I really wanted to raise here is about the terminology: (1) ensuring that we have a consistent usage internally and (2) ensuring that our usage is consistent with the broader NFV/SDN de facto usage.

Avanti,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 28, 2015 9:44 PM
To: [email-masked]
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: [I2nsf] I2NSF Scope discussion

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 3 Feb 2015 03:43:39 +0000

Hi Bob,
Indeed a long email~~  But a very valuable input for this group!

By carefully reading this email, I also agree that we have some key issues needed to be addressed:

1.       What is the clear distinction between "application" and "service" in our work scope? Can we consider "application" as the finer granularity than "service"?

2.       Service function chain is another type of security service instance that we need to consider in the scope;

3.       The first interface, service interface, as you mentioned, should provide an application-agnostic interface to negotiate all the common security services. I think we need to describe the clear boundary from SUPA, IBNemo, I2RS, etc in the gap analysis draft. The second interface, capability interface, my personal preference is a NSF-agnostic interface. All these design principles are based on the goal to simplify the network controller by unifying its NBI and SBI, and support as many as possible types of applications and NSFs.

B.R.
Frank

From: Natale, Bob [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 3:52 AM
To: Linda Dunbar; Xialiang (Frank)
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: RE: [I2nsf] I2NSF Scope discussion

Hi Linda and Frank,

Avanti,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 28, 2015 9:44 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Romascanu, Dan (Dan); [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] I2NSF Scope discussion

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 3 Feb 2015 06:09:05 +0000

Thanks for the feedback, Frank ... here are some follow-ups for consideration:

- Wrt your #1, second question: My preferred answer is "No, Applications should not be considered as finer granularity than Services" ... only because it will be more beneficial globally to adopt the emerging "generally accepted" industry perspective (e.g., the ONF diagram I included below) "Applications" are consumers of "[Network] Services".

[Note that I am fully aware that in the SOA domain it is not uncommon to consider "Applications" (esp. legacy apps) as a valid capability packaging option for "Services" ... this is part of the reason why I recommend against using the term "service-oriented" in our work ... it just carries too many SOA implications that are not necessary at this level.]

- Wrt your #2: I agree.  More specifically, security operations relative to Service Function Paths (SFP) would be a valid SFC-specific use case for I2NSF.

- Wrt your #3, I agree with everything you say there, but would emphatically add one point - it's not just the "clear boundary" that is important to identify ... the "common overlap" (or whatever the right term might be) is also important and identifying that is also a good start on identifying the clear boundaries. Again, I think this identification of commonality among all of these initiatives should be on Area-level responsibility but the absence of that does not negate the need to do it at the individual initiative level, IMHO.

[Btw, I realize that I have been expressing a lot of (informed?) judgments (some might legitimately call them "opinions") with a high degree of _apparent_ certitude in my postings ... but that is not really the case ... I am in learning mode here as much as or probably more than most of the people on these lists ... and I never fear or take umbrage at learning that I got something wrong. Lastly (one more "biographical" note), for several decades now I have focused on solution architecture in the operational domain as opposed to technical implementation activities ... so feel free to calibrate my input accordingly.]

Avanti,
BobN

From: Xialiang (Frank) [mailto:[email-masked]]
Sent: Monday, February 02, 2015 10:44 PM
To: Natale, Bob; Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: RE: [I2nsf] I2NSF Scope discussion

Hi Bob,

B.R.
Frank

Cc: [email-masked]<mailto:[email-masked]>; Romascanu, Dan (Dan); [email-masked]<mailto:[email-masked]>

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 3 Feb 2015 06:52:07 +0000

Bob,
SFC-specific use case should be in scope of I2NSF. But, considering its complexity, my question is: should we put this work in the second phase of I2NSF? We need to have a decision in the beginning. And we should consider how to support this use case in the future when we start to design the architecture and information/data model, etc.

In addition, agree with you about the importance of terminologies and gap analysis with other technologies!

B.R.
Frank

From: Natale, Bob [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 2:09 PM
To: Xialiang (Frank); Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: RE: [I2nsf] I2NSF Scope discussion

Avanti,
BobN

Hi Bob,

B.R.
Frank

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 3 Feb 2015 06:59:51 +0000

Hi Frank,

Yes, I think putting the SFC/SFP use case off to a future phase would be a good idea and I agree that it would probably fall on the more complex end of the spectrum .. I just wanted to highlight the probable need for it.

Avanti,
BobN

Sent: Tuesday, February 03, 2015 1:52 AM

Bob,

B.R.
Frank

Avanti,
BobN

Hi Bob,

B.R.
Frank

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 07:38:20 -0500

Frank, Bob, and Linda:

It is good to refine the definition of what you mean by the application and
service. You will need to compare that with what I2RS, SFC, and other groups
consider a service. 

I2RS protocol independent topology and SFC are investigating managing
services, but this may not be what draft-pastor-i2rs-access-usecases-00 or
draft-zarny-insf-data-center-use-cases-00. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Monday, February 02, 2015 10:44 PM
To: Natale, Bob; Linda Dunbar
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [I2nsf] I2NSF Scope discussion

Hi Bob,

By carefully reading this email, I also agree that we have some key issues
needed to be addressed:

1.       What is the clear distinction between "application" and "service"
in our work scope? Can we consider "application" as the finer granularity
than "service"? 

2.       Service function chain is another type of security service instance
that we need to consider in the scope;

3.       The first interface, service interface, as you mentioned, should
provide an application-agnostic interface to negotiate all the common
security services. I think we need to describe the clear boundary from SUPA,
IBNemo, I2RS, etc in the gap analysis draft. The second interface,
capability interface, my personal preference is a NSF-agnostic interface.
All these design principles are based on the goal to simplify the network
controller by unifying its NBI and SBI, and support as many as possible
types of applications and NSFs.

B.R.

Frank

Hi Linda and Frank,

[Apologies on two fronts: (1) the is probably a bit long for most people's
tastes in e-mail and (2) I had to compose it during the course of many
"distractions" over multiple hours, so it might not flow as smoothly as I
would have liked.]

I am reviewing the "service" and "capability" interface drafts and the same
diagram reproduced in Linda's e-mail below appears in both of them. I would
like to clarify just two terminological elements at this level to better
focus future discussion:

- What is the category label for the set of boxes in the bottom/right-most
portion of the diagram (i.e., "Antivirus" through "Application Control")?

   --- I would note that, from the  service provider/operator perspective in
the context of NFV, most of these boxes would seem to refer to "functions"
that could be implemented as VNFs, i.e., as "software appliances" running
over NFV Infrastructure, replacing hardware device running over specialized
hardware/firmware/OS.

   --- However, from the consumer/subscriber/customer perspective, these
would be seen as "services" (e.g., AV-as-a-Service, FW-as-a-Service, etc.),
and (for the most part) agnostic wrt implementation mechanisms (VNF or
hardware; standards-based or proprietary).

   --- And note that for NFV, multiple VNFs can be "chained" into a service
function path to form a composite service from the
consumer/subscriber/customer perspective who would again (generally) be
agnostic wrt the individual services underlying the composite.

- Now, that diagram also contains a "higher-level" box called "Service" (and
note that it is at the same logical level as "Application"). How does this
"Service" relate to the perspective outlined above? (And "It does not,
because." can be, of course, a perfectly valid answer!)

   --- Note that the "capability interface" document helpfully provides a
definition for "Service", to wit:

        "o Service: A service is an application identified by a protocol
type and port number. It can be a service or a group of services.

          NSF matches the service traffics based on the protocol types and
port numbers and applies the security actions to them;"

   --- First, this is a very specific and low-level definition of "service"
(PPSM); fitting this definition into the broader context outlined above is
difficult.?

   --- Second, note the "is an application" part of the definition. Then
note the definition of "Application" given in the same I-D:

        "o Application: An application is a computer program for a specific
task or purpose, and multiple applications constitute an application group.

          It provides a finer granularity than service in matching traffic.
Even if different applications have the same service, they still can be
distinguished

          by analyzing the data packets and comparing the signatures of each
application.."

   --- In common usage (esp. from the consumer/subscriber/customer
perspective), I am not certain that "applications" are seen as more finely
granular than "services". And much of the NFV world is using this diagram
(or something similar) which I have pulled from Open Networking Foundation,
Software-Defined Networking: The New Norm for Networks, April 13, 2012, p.
7, for the high-level positioning of these constructs:

I think (based upon what I have read and considered thus far) that the two
interfaces that I2NSF needs to be concerned with, relative to your diagram
below, are:

   - An interface from the "Policy" component (probably via an
"Applications" component positioned per the ONF diagram above) to the
(possibly composite) "Service" component; and

   - an interface from the "Service" component to the capabilities of the
individual security-related VNFs

This pair of interfaces is very close to the two you outline below, but not
quite the same. An issue of the first (of my pair) is the intersection with
SUPA and/or IBNemo, etc.? An issue with the second is should I2NSF push more
specialized capability policies to the VNFs or should it translate from
service operations to VNF capability commands or such.?

But the key issues I really wanted to raise here is about the terminology:
(1) ensuring that we have a consistent usage internally and (2) ensuring
that our usage is consistent with the broader NFV/SDN de facto usage.

Avanti,

BobN

Over the email discussion on the I2NSF list, it becomes clear that there are
two distinct interfaces for I2NSF: 

-          Capability or Functional Oriented interface between Controller
and Devices (or devices' adaptor), which focuses more on the functional
security policies for the functions listed above. 

It is envisioned that clients of the I2NSF include security administrators,
management systems, applications (or its controller), or security functions
that detect suspicious threat triggering more vigorous security resources.

http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-
00 provides a concrete set of content going through the functional
interface: 

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

.       Develop a comprehensive set of informational Models for the
functions listed above with regard to different aspects of OAM
(Operations/Administration/Maintenance) including polices requests,
monitoring, reports, fault/consistency management, etc. 

.       Develop the corresponding Data Models, e.g. YANG model. 

.       Compare with existing IETF protocols for "OBJECTs, ACTIONs,
FILTERING, etc" (e.g. PCP, Radius, etc) 

.       Specify the secure mechanisms to carry the content identified by the
informational models. E.g. TLS to carry the information. 

.       Authentication and registration mechanism

E.g. who is legitimate to issue security policies or monitor reports over
the Functional Interface.  

.       Develop a Role Based Access Control to express the Security Intent
by Applications/Administrators/OSS

.       Develop comprehensive set of "TARGETs" for the Security Intent

-       e.g. Security Target in Data Centers network, in Access Network, in
Wide Area network, etc

.       Develop the corresponding Data Models, e.g. YANG model. 

.       Compare with existing IETF protocols for "Roles", "Users",
"Permissions", etc. 

.        Document a high-level architecture that will describe the

.       Document small and well-scoped use cases to constrain the scope of
the work and achieve sufficient focus for the working group to deliver
successful outcomes. And

.        Analyze candidate protocols that may carry the information to be
exchanged through the various interfaces. 

Any more suggestions? 

Cheers, 

Linda Dunbar

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 07:40:42 -0500

Frank and Bob, and Linda: 

I forgot to mention on this thread that there an i2RS use case draft.  It
would be good to review the I2RS use case draft for the overlapping cases: 

 <http://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/> 
draft-ietf-i2rs-usecase-reqs-summary-00

Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 7:38 AM
To: 'Xialiang (Frank)'; 'Natale, Bob'; 'Linda Dunbar'
Cc: [email-masked]'; 'Romascanu, Dan (Dan)'; [email-masked]'
Subject: RE: [I2nsf] I2NSF Scope discussion

Frank, Bob, and Linda:

Sue 

Hi Bob,

 

B.R.

Frank

Hi Linda and Frank,

 

Avanti,

BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions? 

Cheers, 

Linda Dunbar

---

From: John Strassner <[email-masked]>
Date: Tue, 3 Feb 2015 20:43:31 +0000

Hi Linda,

One of the most important differences between an information model and a data model is that an information model emphasizes relationships between objects, whereas most data models (1) can only express a limited form of relationship, and 2) may not even contain such information.

As a consequence, Fig 1 in the capability interface draft confuses me. Does the "+->" symbol mean "contains" ( it appears to when I look at Policy +-> Rule, or Rule +-> Action), but then the analogy breaks down. For example, Actions do not "contain" permit or deny; rather, permit and deny are types of actions that can be taken.

A more general question is, are the boxes in Figure 1 supposed to be objects or entities? I hope not...

A couple of additional points:

For the Functional/Capability Interface, I2NSF deliverables should include:
*       Develop a comprehensive set of informational Models for the functions listed above with regard to different aspects of OAM (Operations/Administration/Maintenance) including polices requests, monitoring, reports, fault/consistency management, etc.
<js> We should never, ever, ever have multiple information models. The information model should be consensual, and provide THE definition for a modeled object (e.g., class, attribute, relationship, constraint). </js>
*       Develop the corresponding Data Models, e.g. YANG model.
*       Compare with existing IETF protocols for "OBJECTs, ACTIONs, FILTERING, etc" (e.g. PCP, Radius, etc)
<js>  Yang is a data model, not a protocol. Do you mean compare Netconf with existing IETF protocols? Or simply to find a protocol that could be used with Yang? </js>
*       Specify the secure mechanisms to carry the content identified by the informational models. E.g. TLS to carry the information.
*       Authentication and registration mechanism
E.g. who is legitimate to issue security policies or monitor reports over the Functional Interface.
<js>  I think you need authentication and authorization, as a minimum </js>

For the Service Layer Interface, I2NSF deliverables should include:
*       Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS
<js>  I will modify this to be more generic. For now, we could say PBAC (Policy Based Access Control) </js>
*       Develop comprehensive set of "TARGETs" for the Security Intent
-       e.g. Security Target in Data Centers network, in Access Network, in Wide Area network, etc
<js>  Typically (e.g., in deontic logic), a target is a set of managed entities. So this part is fine. My issue is with the next line... </js>
-      Develop informational model for "Users", "Roles", "Permissions"
<js>  There are two problems. First, none of these are "targets" in the classic sense. These are all objects that are used by an access control system (e.g., RBAC in this case) to determine what operations are permitted to be executed on which objects by which users. Second, what is missing from this list is a way to convey the intent. </js>
*       Develop the corresponding Data Models, e.g. YANG model.
*       Compare with existing IETF protocols for "Roles", "Users", "Permissions", etc.

...

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, January 28, 2015 6:44 PM
To: [email-masked]
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: [I2nsf] I2NSF Scope discussion

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: John Strassner <[email-masked]>
Date: Tue, 3 Feb 2015 22:04:17 +0000

Hi Bob,

Let me take a shot at some of your very good observations.
#1 - if it looks like a duck...
- What is the category label for the set of boxes in the bottom/right-most portion of the diagram (i.e., "Antivirus" through "Application Control")?...
<js> In ZOOM, we called these things NetworkFunctions. A NetworkFunction is a type of FunctionalBlock (from basic systems theory; see SysML) that defines a set of inputs, a set of outputs, has a state, and has a transfer function. The "packaging" of the NetworkFunction can be as a part of a hardware device (PNF) or as a virtualized function (PNF). It can produce and consume Resources and Services. We use the composite pattern, and define the notion of sets and graphs, so service chains are also supported.

We did this for a number of reasons, the primary of which was to try to model what it does and not be concerned with calling it an Application or not. </js>

- Now, that diagram also contains a "higher-level" box called "Service" (and note that it is at the same logical level as "Application"). How does this "Service" relate to the perspective outlined above?
<js> See above. In ZOOM, a Service is a type of ManagedResource. So is a NetworkFunction. The two are peers, and NetworkFunctions can be used to describe a Service. </js>

   --- Note that the "capability interface" document helpfully provides a definition for "Service", to wit:
        "o Service: A service is an application identified by a protocol type and port number. It can be a service or a group of services.
...
<js> I'm uncomfortable with this definition. But this is a long discussion. Suffice it to say that 1) this only works for network services (e.g., when I invoke spell check in Microsoft Word, from the end user's point-of-view, spell check provides a service, but what are its protocol and port number? :), and 2) I'll propose a new one, more closely aligned with ZOOM. </js>

<talk about the definition of an application in the above draft>
   --- In common usage (esp. from the consumer/subscriber/customer perspective), I am not certain that "applications" are seen as more finely granular than "services". And much of the NFV world is using this diagram (or something similar) which I have pulled from Open Networking Foundation, Software-Defined Networking: The New Norm for Networks, April 13, 2012, p. 7, for the high-level positioning of these constructs:
<js> I agree with Bob. In DEN-ng, an application is a managed object that can produce and consume Resources and/or Services. As such, it is definitely NOT more granular than a Service, especially since there are different types of Services (e.g., CustomerFacingService (like a VPN) and ResourceFacingServices (like OSPF forwarding within a VPN). I would note that the concepts I have stated can be mapped into the ONF diagram. </js>

What is needed...
   - An interface from the "Policy" component (probably via an "Applications" component positioned per the ONF diagram above) to the (possibly composite) "Service" component; and
   - an interface from the "Service" component to the capabilities of the individual security-related VNFs
<js> Agreed, with a tad more detail:

*         Resources to be managed express what they can do as Capabilities

*         Capabilities are mapped via NetworkFunctions to Services

*         PolicyRules live in a PolicyManagementSystem, which contains basic functions as described in, for example, PBAC

*         The PolicyManagementSystem client is the entity that uses a DSL to express its intent

*         The output of the PolicyManagementSystem client goes to the PolicyManagementSystem, where things like conflict detection and remediation, as well as translating intent to a form that can be consumed by a device, happen

*         The output of the PolicyManagementSystem is then used to manage the device

o   The only way for the PolicyManagementSystem to correlate the capabilities of the device to a (much more abstract definition of a) Service is through the information model

o   Given this, the PolicyManagementSystem has one interface to the Service and one to the Device
</js>

This pair of interfaces is very close to the two you outline below, but not quite the same.
<js> Agreed; will try and address this in the draft updates <js>

An issue of the first (of my pair) is the intersection with SUPA and/or IBNemo, etc...?
<js> I'm not sure I understand SUPA anymore. It seems to be much less about policy and much more about configuring services using Yang. I do not think that at this time, NEMO has overlap - see my earlier note. </js>

An issue with the second is should I2NSF push more specialized capability policies to the VNFs or should it translate from service operations to VNF capability commands or such...?
<js> Why can't it do both? Practically speaking, there is no standard OSS interface to communicate with, so this is somewhat of a moot point. However, if we have a good information model, then the PolicyManagementSystem should be able to look at an incoming rule and refine it. </js>

<js> Agreed </js>

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: I2nsf [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, February 02, 2015 11:52 AM
To: Linda Dunbar; Xialiang (Frank)
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [I2nsf] I2NSF Scope discussion

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 4 Feb 2015 06:50:59 +0000

Hi John,

I fully agree with all of your observations and clarifications below, with one "issue":
JS: "...a Service is a type of ManagedResource. So is a NetworkFunction. The two are peers, and NetworkFunctions can be used to describe a Service."

I agree that "Service" and "Network Function" (whether implemented as PNF or VNF) are "peers" (which I interpret as two sides (views) of the same coin) ... this (along with your other comments below) really calls into question the diagram in the two drafts as it currently stands, or so it seems to me.

Lastly (and irrespective of the recent threads on this list to date), I would like to see as much coordination with ZOOM as makes sense ... and will start doing my part in that respect to (as much as "day job" commitments allow).

Avanti,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, February 03, 2015 5:04 PM
To: Natale, Bob; John Strassner; Linda Dunbar; Xialiang (Frank)
Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [I2nsf] I2NSF Scope discussion

Hi Bob,

What is needed...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

|       |  |  |        |  |              |

           |              |              |   *      +->Antivirus|

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

                          |             +->Permit +-+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *

Any more suggestions?

Cheers,

Linda Dunbar

---

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

Hi,

In my view, a "Service" and a "Network Function" are peers, but the former exposes its management interface to consumers (end users, or even third parties performing a composition to build more complex services), and the latter exposes its interfaces to providers. In summary users manage services, providers manage NFs.

Be goode,

On 4 Feb 2015, at 07:50 , Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

I fully agree with all of your observations and clarifications below, with one “issue”:
JS: “…a Service is a type of ManagedResource. So is a NetworkFunction. The two are peers, and NetworkFunctions can be used to describe a Service.”

I agree that “Service” and “Network Function” (whether implemented as PNF or VNF) are “peers” (which I interpret as two sides (views) of the same coin) … this (along with your other comments below) really calls into question the diagram in the two drafts as it currently stands, or so it seems to me.

Lastly (and irrespective of the recent threads on this list to date), I would like to see as much coordination with ZOOM as makes sense … and will start doing my part in that respect to (as much as “day job” commitments allow).

Avanti,
BobN

Hi Bob,

Let me take a shot at some of your very good observations.
#1 – if it looks like a duck…
- What is the category label for the set of boxes in the bottom/right-most portion of the diagram (i.e., “Antivirus” through “Application Control”)?...
<js> In ZOOM, we called these things NetworkFunctions. A NetworkFunction is a type of FunctionalBlock (from basic systems theory; see SysML) that defines a set of inputs, a set of outputs, has a state, and has a transfer function. The “packaging” of the NetworkFunction can be as a part of a hardware device (PNF) or as a virtualized function (PNF). It can produce and consume Resources and Services. We use the composite pattern, and define the notion of sets and graphs, so service chains are also supported.

- Now, that diagram also contains a “higher-level” box called “Service” (and note that it is at the same logical level as “Application”). How does this “Service” relate to the perspective outlined above?
<js> See above. In ZOOM, a Service is a type of ManagedResource. So is a NetworkFunction. The two are peers, and NetworkFunctions can be used to describe a Service. </js>

   --- Note that the “capability interface” document helpfully provides a definition for “Service”, to wit:
        “o Service: A service is an application identified by a protocol type and port number. It can be a service or a group of services.
…
<js> I’m uncomfortable with this definition. But this is a long discussion. Suffice it to say that 1) this only works for network services (e.g., when I invoke spell check in Microsoft Word, from the end user’s point-of-view, spell check provides a service, but what are its protocol and port number? :), and 2) I’ll propose a new one, more closely aligned with ZOOM. </js>

<talk about the definition of an application in the above draft>
   --- In common usage (esp. from the consumer/subscriber/customer perspective), I am not certain that “applications” are seen as more finely granular than “services”. And much of the NFV world is using this diagram (or something similar) which I have pulled from Open Networking Foundation, Software-Defined Networking: The New Norm for Networks, April 13, 2012, p. 7, for the high-level positioning of these constructs:
<js> I agree with Bob. In DEN-ng, an application is a managed object that can produce and consume Resources and/or Services. As such, it is definitely NOT more granular than a Service, especially since there are different types of Services (e.g., CustomerFacingService (like a VPN) and ResourceFacingServices (like OSPF forwarding within a VPN). I would note that the concepts I have stated can be mapped into the ONF diagram. </js>

What is needed…
   - An interface from the “Policy” component (probably via an “Applications” component positioned per the ONF diagram above) to the (possibly composite) “Service” component; and
   - an interface from the “Service” component to the capabilities of the individual security-related VNFs
<js> Agreed, with a tad more detail:
•       Resources to be managed express what they can do as Capabilities
•       Capabilities are mapped via NetworkFunctions to Services
•       PolicyRules live in a PolicyManagementSystem, which contains basic functions as described in, for example, PBAC
•       The PolicyManagementSystem client is the entity that uses a DSL to express its intent
•       The output of the PolicyManagementSystem client goes to the PolicyManagementSystem, where things like conflict detection and remediation, as well as translating intent to a form that can be consumed by a device, happen
•       The output of the PolicyManagementSystem is then used to manage the device
o   The only way for the PolicyManagementSystem to correlate the capabilities of the device to a (much more abstract definition of a) Service is through the information model
o   Given this, the PolicyManagementSystem has one interface to the Service and one to the Device
</js>

An issue of the first (of my pair) is the intersection with SUPA and/or IBNemo, etc…?
<js> I’m not sure I understand SUPA anymore. It seems to be much less about policy and much more about configuring services using Yang. I do not think that at this time, NEMO has overlap – see my earlier note. </js>

An issue with the second is should I2NSF push more specialized capability policies to the VNFs or should it translate from service operations to VNF capability commands or such…?
<js> Why can’t it do both? Practically speaking, there is no standard OSS interface to communicate with, so this is somewhat of a moot point. However, if we have a good information model, then the PolicyManagementSystem should be able to look at an incoming rule and refine it. </js>

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Hi Linda and Frank,

[Apologies on two fronts: (1) the is probably a bit long for most people’s tastes in e-mail and (2) I had to compose it during the course of many “distractions” over multiple hours, so it might not flow as smoothly as I would have liked.]

I am reviewing the “service” and “capability” interface drafts and the same diagram reproduced in Linda’s e-mail below appears in both of them. I would like to clarify just two terminological elements at this level to better focus future discussion:

- What is the category label for the set of boxes in the bottom/right-most portion of the diagram (i.e., “Antivirus” through “Application Control”)?

   --- I would note that, from the  service provider/operator perspective in the context of NFV, most of these boxes would seem to refer to “functions” that could be implemented as VNFs, i.e., as “software appliances” running over NFV Infrastructure, replacing hardware device running over specialized hardware/firmware/OS.

   --- However, from the consumer/subscriber/customer perspective, these would be seen as “services” (e.g., AV-as-a-Service, FW-as-a-Service, etc.), and (for the most part) agnostic wrt implementation mechanisms (VNF or hardware; standards-based or proprietary).

   --- And note that for NFV, multiple VNFs can be “chained” into a service function path to form a composite service from the consumer/subscriber/customer perspective who would again (generally) be agnostic wrt the individual services underlying the composite.

- Now, that diagram also contains a “higher-level” box called “Service” (and note that it is at the same logical level as “Application”). How does this “Service” relate to the perspective outlined above? (And “It does not, because…” can be, of course, a perfectly valid answer!)

   --- Note that the “capability interface” document helpfully provides a definition for “Service”, to wit:
        “o Service: A service is an application identified by a protocol type and port number. It can be a service or a group of services.
          NSF matches the service traffics based on the protocol types and port numbers and applies the security actions to them;”

   --- First, this is a very specific and low-level definition of “service” (PPSM); fitting this definition into the broader context outlined above is difficult…?

   --- Second, note the “is an application” part of the definition. Then note the definition of “Application” given in the same I-D:
        “o Application: An application is a computer program for a specific task or purpose, and multiple applications constitute an application group.
          It provides a finer granularity than service in matching traffic. Even if different applications have the same service, they still can be distinguished
          by analyzing the data packets and comparing the signatures of each application….”

   --- In common usage (esp. from the consumer/subscriber/customer perspective), I am not certain that “applications” are seen as more finely granular than “services”. And much of the NFV world is using this diagram (or something similar) which I have pulled from Open Networking Foundation, Software-Defined Networking: The New Norm for Networks, April 13, 2012, p. 7, for the high-level positioning of these constructs:

   - An interface from the “Policy” component (probably via an “Applications” component positioned per the ONF diagram above) to the (possibly composite) “Service” component; and
   - an interface from the “Service” component to the capabilities of the individual security-related VNFs

This pair of interfaces is very close to the two you outline below, but not quite the same. An issue of the first (of my pair) is the intersection with SUPA and/or IBNemo, etc…? An issue with the second is should I2NSF push more specialized capability policies to the VNFs or should it translate from service operations to VNF capability commands or such…?

Avanti,
BobN

                                           +---------+
                                           |Src/dest |
                                         +-> address |
                                         | |  scope  |
                                         | +---------+
                                         |
                                         | +---------+
                                         +->  User   |
              +--------+                 | +---------+
              |        |                 |

Any more suggestions?

Cheers,

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

--
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

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 4 Feb 2015 13:18:31 +0000

Very nicely put, Diego. +1.

Avanti,
BobN

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 3:26 AM
To: Natale, Bob
Cc: John Strassner; Linda Dunbar; Xialiang (Frank); [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [I2nsf] I2NSF Scope discussion

Hi,

Be goode,

Hi John,

Avanti,
BobN

Hi Bob,

What is needed...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+
                                           |Src/dest |
                                         +-> address |
                                         | |  scope  |
                                         | +---------+
                                         |
                                         | +---------+
                                         +->  User   |
              +--------+                 | +---------+
              |        |                 |

Any more suggestions?

Cheers,

Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

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

---

From: John Strassner <[email-masked]>
Date: Thu, 5 Feb 2015 18:38:44 +0000

Yes, this is exactly what I meant, only clearer. :)

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Natale, Bob [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 5:19 AM
To: DIEGO LOPEZ GARCIA
Cc: John Strassner; Linda Dunbar; Xialiang (Frank); [email-masked]; Romascanu, Dan (Dan); [email-masked]
Subject: RE: [I2nsf] I2NSF Scope discussion

Avanti,
BobN

Hi,

Be goode,

Hi John,

Avanti,
BobN

Hi Bob,

What is needed...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Hi Linda and Frank,

Avanti,
BobN

                                           +---------+
                                           |Src/dest |
                                         +-> address |
                                         | |  scope  |
                                         | +---------+
                                         |
                                         | +---------+
                                         +->  User   |
              +--------+                 | +---------+
              |        |                 |

Any more suggestions?

Cheers,

Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D