[I2nsf] Does my explanation help to address your concern? RE: Can the answer from Diego Lopez address your last concern of the text? FW: AD Review of draft-ietf-i2nsf-applicability-07

[Linda Dunbar <[e-mail]>]

Ekr,

Does my explanation help to address your concern?   Can you give us some advices on actions we can take to move this draft forward?

Greatly appreciated.

Thanks, Linda Dunbar

From: Linda Dunbar
Sent: Monday, January 14, 2019 10:11 AM
To: 'Eric Rescorla' <[e-mail]>
Cc: '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
Subject: RE: Can the answer from Diego Lopez address your last concern of the text? FW: AD Review of draft-ietf-i2nsf-applicability-07

Ekr,

The interface is for vendors to register their NSF (Network Security Function) capabilities, as shown in RFC 8329. This is a static process (in the multi-vendor PoC by ONF a few years ago, the registration process was an Excel file).

When a network operator have NSFs (physical or virtualized functions) from many different vendors, each vendor has to register (or inform) to the Network Operator Mgmt System about the NSFs it provides, so that the Network Operator can build a catalog of NSFs and instantiate the right NSFs at the right location to achieve workload bounded security.

The reason to call it “Developer’s Mgmt System” (instead of Vendor Mgmt System) is to allow NSFs developed by Open Source Community which is not a “Vendor” per se.


       +-------------------------------------------------------+
       |  I2NSF User (e.g., Overlay Network Mgmt, Enterprise   |
       |  Network Mgmt, another network domain's mgmt, etc.)   |
       +--------------------+----------------------------------+
                            |
                            |  I2NSF Consumer-Facing Interface
                            |
                            |              I2NSF
               +------------+---------+ Registration  +-------------+
               | Network Operator Mgmt|  Interface    | Developer's |
               |        System        | < --------- > | Mgmt System |
               +----------------+-----+               +-------------+
                                |
                                | I2NSF NSF-Facing Interface
                                |
           +---------------+----+------------+---------------+
           |               |                 |               |
       +---+---+       +---+---+         +---+---+       +---+---+
       | NSF-1 |  ...  | NSF-m |         | NSF-1 |  ...  | NSF-m |  ...
       +-------+       +-------+         +-------+       +-------+

        Developer Mgmt System A           Developer Mgmt System B

                      Figure 1: I2NSF Reference Model


Hope it helps. Please let us know if it is still confusing.
Since the information is already explained in the RFC 8329, should the authors simply add the reference? Instead of repeating the information?


Linda

From: Eric Rescorla [mailto:[e-mail]]
Sent: Monday, January 14, 2019 8:27 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: Re: Can the answer from Diego Lopez address your last concern of the text? FW: AD Review of draft-ietf-i2nsf-applicability-07



On Thu, Jan 10, 2019 at 9:14 AM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Ekr,

Do you think Diego Lopez’s explanation can address your last concern of “…What functions can the Developer perform on the system”?

Unfortunately, no. It's still not clear to me what the purpose of the developer interface is or what controls it gives the developers. Why would you need to dynamically inform the administrator of functions that ship with the device? I'm going to need a fairly precise description of the purpose and functions that are provided here. Can you point me to such a description?

-Ekr


What else can authors do to move this draft forward?

Thanks, Linda





From: Diego R. Lopez [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, January 02, 2019 6:19 PM
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>>
Cc: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Yoav Nir <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: AD Review of draft-ietf-i2nsf-applicability-07

Hi,

The registration interface is not intended to make any real-time change in the behavior of any NSF, and does not provide any management interface to the running NSFs. The registration interface is used to register the capabilities the function provides, so the Security Controller knows which capabilities are available and match them with the security policies. In the particular case of NFV-based NSFs, the onboarding process of the functions follows the requirements about code signing and attestation defined in the NFV Security specs, and this onboarding is orthogonal to I2NSF capability registration.

I am attaching a diagram we used in the discussions of the I2NSF framework in the hope it clarifies the idea.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

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

On 28/12/2018, 15:09, "Eric Rescorla" <[e-mail]<mailto:[e-mail]>> wrote:



On Thu, Dec 27, 2018 at 7:21 PM Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>> wrote:
Eric,
Let me answer your further questions below.

On Thu, Dec 27, 2018 at 11:59 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:


On Wed, Dec 26, 2018 at 6:42 PM Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric,
Here are my answers inlines below.

On Thu, Dec 27, 2018 at 3:44 AM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
Paul,

Thanks for your new version. Some responses below.


On Tue, Dec 25, 2018 at 6:42 AM Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric, Linda and Yoav,
I have reflected all the comments from Eric and submitted the revision -08 as follows:
https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-08

The changes are described in Appendix A of -08 document as follows:
-------------------------------------------------------------------------------------------------
Appendix A.  Changes from draft-ietf-i2nsf-applicability-07

   The following changes have been made from
   draft-ietf-i2nsf-applicability-07:

   o  This version has reflected all the comments from Eric Rescorla who
      is a Security Area Director as follows.

   o  In Section 1, Network Security Function (NFV) is defined in the
      viewpoint of the I2NSF framework.

   o  In Section 1, a user using the I2NSF User is clarified as a system
      administrator in the I2NSF framework.

   o  In Section 1, as the applicability of the I2NSF framework, four
      different scenarios are represented with a standard bulleted list.

   o  The standard document about ETSI-NFV is moved to Normative
      References.

   o  In Section 2, key terms (e.g., Network Function, Network Security
      Function, Network Functions Virtualization, and Servive Function
      Chaining) are internally defined along with the reference to open
      specifications.

   o  In Section 2, the definition of Firewall is corrected such that
      some suspicious packets are inspected by the firewall rather than
      every packet.

   o  In Section 3, for a Developer's Management System, the problem of
      an inside attacker is addressed, and a possible solution for the
      inside attacks is suggested through I2NSF NSF monitoring
      functionality.

I'm still pretty concerned about this. Standardizing a situation in which the
developer of your firewall has real-time management-level access to
that firewall seems extremely insecure, especially when that access is
authenticated via conventional credentials that are online as part of
the transaction (as opposed to software builds which can be signed
offline). This doesn't seem like a best practice. Why is it necessary?


 =>  The developer of a firewall does not have real-time management-level access
       even though its management system works the control plane as part of the I2NSF system.
       The developer's management system provides the Security Controller with
       the interface (i.e., Registration Interface) that is used to register the capability of
       the developer's security network function (i.e., firewall), to search an NSF for the required capability for a high-level security policy, and to help the lifecycle management
       of such an NSF for the Security Controller through an NFV interface (i.e., Ve-Vnfm interface) with the NFV's MANO.

I don't understand the distinction you are drawing here. Under what conditions can the developer modify the behavior of the I2NSF system? Can it do so at any time and without explicit action by the admin.

 =>  The developer means a security solution vendor (e.g., McAfee and Symantec) who provides the I2NSF system with security solutions,
       such as firewall, web filter, DPI, IDS/IPS, and DDoS-attack mitigator. Actually, the developer's management system
       cannot modify the behavior of the I2NSF system in run-time as long as the vendor doesn't have any backdoor to
       their developer's management system.
       This developer's management system facilitates the security service government by the Security Controller
       by providing the Security Controller with the Registration Interface for the capability registration and instantiation/de-instantiation
       of the image of a security service function.
       Thus, only the administrator can modify the behavior of the I2NSF system.

       Maybe,
       Diego Lopez can clarify my answer because he is the editor of RFC 8329 (Framework for Interface to Network Security Functions):
       https://tools.ietf.org/html/rfc832<https://tools.ietf.org/html/rfc8329>

Yeah, I'm not really following this. What functions can the Developer perform on the system.


   o  In Section 4, an XML file for the RESTCONF/YANG for the time-
      dependent web access control is pointed out with a reference to
      the Consumer-Facing Interface's data model
      [consumer-facing-inf-dm].

I didn't follow this change. The example you give of a high level security
policy is clearly freeform text and then you talk about XML. Is this just
example a summary of the semantics of something which would actually be an
XML file? Something else?

  => Even though the high-level security policy looks like a freeform text,  it is formatted
      in an XML according to the high-level security policy YANG model for the Consumer-Facing Interface.
      Yes, it is just an example of a summary of the semantics for such a high-level security policy,
      which is represented as an XML file.
      Here it an XML file for the web filter from the Consumer-Facing Interface Data Model document
      (https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02):

      You can see the XML file from
       https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-02#page-49

      <?xml version="1.1" encoding="UTF-8"?>
 <rpc message-id="4" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
  <edit-config>
   <target>
    <running/>
   </target>
    <config>
     <i2nsf-cf-interface-wf-req nc:operation="create">
         <policy-wf>
             <rule-wf>
                 <rule-wf-id>03</rule-wf-id>
                 <rule-wf-name>wf-policy-example</rule-wf-name>
                 <rule-wf-date>2018.10.26/14:03:17</rule-wf-date>
                 <event>
                     <event-id>04</event-id>
                     <event-name>wf</event-name>
                     <event-date>2018.10.26/14:03:17</event-date>
                     <event-type>wf</event-type>
                     <event-map-group>04</event-map-group>
                     <enable>True</enable>
                 </event>
                 <condition>
                     <condition-id>04</condition-id>
                     <source-ip>192.168.1.3</source-ip>
                     <destination-url>www.facebook.com<http://www.facebook.com></destination-url>
                     <time-information>
                         <begin-time>09:00</begin-time>
                         <end-time>18:00</end-time>
                     </time-information>
                     <match-direction>default</match-direction>
                     <exeption>00</exeption>
                 </condition>
                 <action>
                     <action-id>04</action-id>
                     <action-name>action-wf</action-name>
                     <action-date>2018.10.26/14:03:17</action-date>
                     <primary-action>REJECT</primary-action>
                     <secondary-action>LOG</secondary-action>
                 </action>
                 <precedence>none</precedence>
               <owner>
                 <owner-id>03</owner-id>
                 <name>i2nsf-admin</name>
               </owner>
             </rule-wf>
         </policy-wf>
     </i2nsf-cf-interface-wf-req>
    </config>
  </edit-config>
 </rpc>
  => In the above, source ip is used for the employees.
  Instead of the source ip, we can make and use "source group" for employees that can be translated
  into a set of IP addresses of the source group.

You need to make this clear, then. It would probably be easier to just show the XML and then provide the text summary.

  => Okay. I will include a simplified example XML code for web filter and provide the text summary as below.

   This service scenario assumes that an enterprise network
   administrator wants to control the staff members' access to a
   particular Internet service (e.g., Example.com) during business
   hours.  The following is an example high-level security policy rule
   for a web filter that the administrator requests: Block the staff members' access to Example.com from 9 AM to 6 PM.
   Here is an example XML code for this web filter:
<I2NSF>
    <name>block_website</name>
        <cond>
            <src>Staff_Member's_PC</src>
            <dest>Example.com</dest>
    <time-span-start>9:00AM</time-span-start>
            <time-span-end>-6:00PM</time-span-end>
        </cond>
        <action>block<action>
</I2NSF>

   The security policy name is "bloc_website" with the tag "name".
   The filtering condition has the source group "Staff_Member's_PC" with the tag "src",
   the destination website "Example.com" with the tag "dest",
   the filtering start time is the time "9:00AM" with the tag " time-span-start",
   and the filtering end time is the time "6:00PM" with the tag " time-span-end".
   The action is to "block" the packets satisfying the above condition,
   that is, to drop those packets

LGTM.




   o  In Section 6, the definitions of an SDN forwarding element and an
      NSF are clarified such that an SDN forwarding element is a switch
      running as either a hardware middle box or a software virtual
      switch, and an NSF is a virtual network function for a security
      service.

This wasn't clear to me either. Based on this text it would seem that
you could run an NSF on an SDN element, so it's not clear why they
are disjoint sets. Can you give me more information here?

 => An SDN switch can run as a virtual network function like an NSF, but the main functionality of the SDN switch is packet forwarding with a flow table along with simple filtering rules. More complicated security services can be done at dedicated NSFs. For example, there is the Open Virtual Switch (OVS) project for such a software-based SDN switch: https://www.openvswitch.org

Thus, the SDN switches and NSFs are logically disjoint sets though all of them  can run physically as virtual network functions.

I'm sorry, this still isn't clear, at least to me. How can I look at a given software element and determine whether it's an NSF or a virtualized SDN switch?

 => The distinction is logically done such that the NFV system having the I2NSF system categorizes some VNFs as NSFs for dedicated security services
      and some VNFs as virtualized SDN switches for packet switching and simple filtering rule enforcement.

     If there is an expert in the NFV, please let us know for further clarification.

I'm not following this either, so that would definitely help.

-Ekr


     Thanks.

     Best Regards,
     Paul


-Ekr

If you have further questions, please let me know.

Thanks.

Best Regards,
Paul

-Ekr


   o  In Section 6.3, a flow forwarding path management scheme in
      [AVANT-GUARD] is described in a self-contained way as follows.
      For DDoS-attack mitigation, the forwarding of traffic flows in
      switches can be dynamically configured such that malicious traffic
      flows are handled by the paths separated from normal traffic flows
      in order to minimize the impact of those malicious traffic on the
      the servers.  This flow path separation can be done by a flow
      forwarding path management scheme based on [AVANT-GUARD].

   o  Some typos are corrected such as "Interner -> Internet",
      "Registation -> Registration", "The low-level security rules for
      web filter checks -> The low-level security rules for web filter
      check", "fltering -> filtering", "illegal packets -> malicious
      packets", "manipulate rules -> configure rules", "managenent ->
      management", and "DDoS-attack mitigation operations -> DDoS-attack
      mitigation".
-------------------------------------------------------------------------------------------------

Thanks and Merry Christmas!

Best Regards,
Paul

On Fri, Dec 21, 2018 at 11:33 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3181


I found a number of typographical and grammar errors. Please give this
document a thorough read.

IMPORTANT
S 1.
>
>      Interface to Network Security Functions (I2NSF) defines a framework
>      and interfaces for interacting with Network Security Functions
>      (NSFs).  The I2NSF framework allows heterogeneous NSFs developed by
>      different security solution vendors to be used in the Network
>      Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing

Much of this document cannot be understood without reading ETSI-NFV,
so it has to be a normative reference. It also would be helpful to
provide a link.


S 2.
>      This document uses the terminology described in [RFC7149],
>      [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
>      [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology],
>      [consumer-facing-inf-im], [consumer-facing-inf-dm],
>      [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-dm], and
>      [nsf-triggered-steering].  In addition, the following terms are

Every term in this document needs to be understandable without
reference to closed specifications or internally defined. Please
ensure that this is so,


S 3.
>      used for the I2NSF NSF-Facing Interface.
>
>      The Registration Interface between the Security Controller and the
>      Developer's Management System can be implemented by RESTCONF
>      [RFC8040].  The data model defined in [registration-inf-dm] can be
>      used for the I2NSF Registration Interface.

What role does the Developer's Management System play in this? I think
this refers to the text above starting with "The developers (or
vendors)...". Is that correct?

Assuming I am correct, this seems like a potentially serious security
vulnerability in this design in that it potentially allows an inside
attacker at the developer to seriously weaken a system's security.
What protections exist to prevent this?


S 4.
>      administrator wants to control the staff members' access to a
>      particular Interner service (e.g., Example.com) during business
>      hours.  The following is an example high-level security policy rule
>      that the administrator requests: Block the staff members' access to
>      Example.com from 9 AM to 6 PM.  The administrator sends this high-
>      level security policy to the Security Controller, then the Security

The text above suggests that high-level policies are via
RESTCONF/YANG, but this is clearly freeform text.
COMMENTS
S 1.
>
>   1.  Introduction
>
>      Interface to Network Security Functions (I2NSF) defines a framework
>      and interfaces for interacting with Network Security Functions
>      (NSFs).  The I2NSF framework allows heterogeneous NSFs developed by

Please define "Network Security Functions" here.




S 1.
>      functions in the NFV platform.  In the I2NSF framework, each NSF
>      initially registers the profile of its own capabilities into the
>      system in order for themselves to be available in the system.  In
>      addition, the Security Controller is validated by the I2NSF Client
>      (also called I2NSF User) that the user is employing, so that the user
>      can request security services through the Security Controller.

In this case the user is the system administrator.


S 1.
>      [RFC7149] to provide different security functionality such as
>      firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and
>      Distributed Denial of Service (DDoS) attack mitigation; (iv) the use
>      of NFV as supporting technology.  The implementation of I2NSF in
>      these scenarios has allowed us to verify the applicability and
>      effectiveness of the I2NSF framework for a variety of use cases.

This would be easier to read with a standard bulleted list.


S 2.
>         network resources, which facilitates the design, delivery and
>         operation of network services in a dynamic and scalable manner
>         [ITU-T.Y.3300].
>
>      o  Firewall: A service function at the junction of two network
>         segments that inspects every packet that attempts to cross the

Nit: It might not inspect *every* packet.


S 4.
>
>   4.  Time-dependent Web Access Control Service
>
>      This service scenario assumes that an enterprise network
>      administrator wants to control the staff members' access to a
>      particular Interner service (e.g., Example.com) during business

Nit: "Internet"


S 4.
>      inspection capability is required to check whether the target URL of
>      a received packet is in the Example.com domain or not.
>
>      The Security Controller maintains the security capabilities of each
>      NSF running in the I2NSF system, which have been reported by the
>      Developer's Management System via the Registation interface.  Based

Nit: "Registration"


S 4.
>      currently using the network.  Based on the retrieved information, the
>      Security Controller generates low-level security rules to check
>      whether the source IP address of a received packet matches any one
>      being used by a staff member.  In addition, the low-level security
>      rules should be able to determine that a received packet is of HTTP
>      protocol.  The low-level security rules for web filter checks that

Nit: "rules"... "checks" disagree.


S 6.
>      translated into their packet forwarding rules, whereas NSFs enforce
>      NSF-related security rules requiring the security capabilities of the
>      NSFs.  For this purpose, the Security Controller instructs the SDN
>      Controller via NSF-Facing Interface so that SDN forwarding elements
>      can perform the required security services with flow tables under the
>      supervision of the SDN Controller.

I'm having some trouble understanding the difference here between NSFs
and SDN elements. They both seem to be software controlled network
elements. Is this just some continuum about CPU power?


S 6.
>      can perform the required security services with flow tables under the
>      supervision of the SDN Controller.
>
>      As an example, let us consider two different types of security rules:
>
>      Rule A is a simple packet fltering rule that checks only the IP

Nit: "filtering"


S 6.2.
>          packets that have the same call-id.
>
>      6.  The SDN Controller installs new rules (e.g., drop packets) into
>          underlying switches.
>
>      7.  The illegal packets are dropped by these switches.

"Illegal" is probably the wrong wrod here.


S 6.3.
>         is helpful to determine security policies for such a network.
>
>   6.3.  Attack Mitigation: Centralized DDoS-attack Mitigation System
>
>      A centralized DDoS-attack mitigation can manage each network resource
>      and manipulate rules to each switch through a common server for DDoS-

"manipulate rules to" is not grammatical.


S 6.3.
>
>      Servers are categorized into stateless servers (e.g., DNS servers)
>      and stateful servers (e.g., web servers).  For DDoS-attack
>      mitigation, traffic flows in switches are dynamically configured by
>      traffic flow forwarding path management according to the category of
>      servers [AVANT-GUARD].  Such a managenent should consider the load

1. This seems hard to understand without this reference, which is not
public.
2. "management"


S 6.3.
>      mitigation, traffic flows in switches are dynamically configured by
>      traffic flow forwarding path management according to the category of
>      servers [AVANT-GUARD].  Such a managenent should consider the load
>      balance among the switches for the defense against DDoS attacks.
>
>      The procedure of DDoS-attack mitigation operations in this system is

"procedure of... operations" is ungrammatical


--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail]<mailto:[e-mail]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>


--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>


--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

________________________________

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