Re: [I2nsf] AD Review of draft-ietf-i2nsf-applicability-07

[Eric Rescorla <[e-mail]>]

Paul,

Thanks for your new version. Some responses below.


On Tue, Dec 25, 2018 at 6:42 AM Mr. Jaehoon Paul Jeong <
[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?



   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?



   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?

-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]> 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], [e-mail]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>