Re: [I2nsf] AD Review of draft-ietf-i2nsf-applicability-07
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Fri, 28 December 2018 15:08 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3C126BED for <i2nsf@ietfa.amsl.com>; Fri, 28 Dec 2018 07:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAhcCETjoKK7 for <i2nsf@ietfa.amsl.com>; Fri, 28 Dec 2018 07:08:22 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51089126C01 for <i2nsf@ietf.org>; Fri, 28 Dec 2018 07:08:22 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id w18so28680388ite.1 for <i2nsf@ietf.org>; Fri, 28 Dec 2018 07:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lNYy0p0qjSJi2m+6PBIxvgcJGwl6TS/6/qHFj5dm8ps=; b=hRJqohrCFCQB1Do1craupKeVz3T01D5MtVRQK9dXVvxkAzAwGktKCbmUyVknAX73Zb ohlV5dV4Puw74mvOK/a2QMop6gBK7WCIyGL5b0cx7XZ6DrNwKOP8PT6q5Y8Bakozrw6B yPz20J5v+9uU2PKyNHaOmt+PCOdCynhkpOHDuhOe/3jk0RKbZuf0jOa4ad0YeAVKo/Ox b9qylnG9mF6rPjPpcxHzIeB9acisV0p3iClX+MFXDxiBxucv3fcsg/txOz2IhB8Bi9/p ZyBzniNy1Uo8qsHxoq4GuQ/113haQr1x/36ALwsfeHCbCGtNx7Y/C23D4SG8+UDcCB5X VxkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lNYy0p0qjSJi2m+6PBIxvgcJGwl6TS/6/qHFj5dm8ps=; b=n5hvbeZ4S3/b1MRKIADH+jk7wnR7sj1wCIGrRVCusPwSlEG850peabh4bHQUqpXY2e uvjHJLBtJh2YiWhQgBIpwqH4IUn3EoWDIPT+k4avnZk38uVjvUwhdCZZJAd63nl97l9r 3n/K7D9vHZ0nImR1ThIF8Oh2bD2zxFknICVSgY7PktLdFZe2b4gdrf/l2UrsHA5mWeFu 4BZU+GotYkKbrMJN3aMjM+lr2G8MPPbtOHr0Zy3DN5BmnzxmLtVew6p9TPw4MS2sejJt LyMwrdcajznNW2KcyDYY9k9kgcYk/wr578zK8K+zNYKncf3GA5hY3MnpHFbCoRItiV1m psTw==
X-Gm-Message-State: AJcUukcXF4XzST1CmzBXpI056wswDN3FqejnD6hSj4m69vO9fnoxwixX oe1iD9dIfsjJMzYNwxvzKVIMbiK8hj+tgfOZcnI=
X-Google-Smtp-Source: ALg8bN4C1DnBjFlKHe8lr6n9WGNzkNm2zef2IKDV97RGjK5d+chyzpRvIdQNI+VJqTHG60JCmhghXcN74gRUygr8oPo=
X-Received: by 2002:a24:2914:: with SMTP id p20mr9352056itp.156.1546009701364; Fri, 28 Dec 2018 07:08:21 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBOjhEpw4gNDRgJD=FCWy1Wrirz_EsJefJjDHpp5mVe1fw@mail.gmail.com> <CAPK2DewE2vbjAr41xErxnjmxK2CTmK2h9fXFTBSFCigpNj9XPQ@mail.gmail.com> <CABcZeBNZhqTawAFcj9p01ig-tE=XaFm5yCXuGJQFiqoOGgNZxA@mail.gmail.com> <CAPK2Dex7hbKC3Cpq2Jy+UXr7YFqgjGUGvzNiSYMix7M5qQhx=w@mail.gmail.com> <CABcZeBMyRGZ5QEwxLQRkcrkz665vWgOFPv+dwAuF5HSg1=B6eA@mail.gmail.com> <CAPK2Deyn1=vVShbq=hMRmvQ1=G5_Yew8pYgqQC=Vh-dG9d2Wrg@mail.gmail.com> <CABcZeBPd2B5QB0-+eJ5z77rACvTLTTpZRrRKBrCAZHdBCFurGw@mail.gmail.com>
In-Reply-To: <CABcZeBPd2B5QB0-+eJ5z77rACvTLTTpZRrRKBrCAZHdBCFurGw@mail.gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Sat, 29 Dec 2018 00:08:09 +0900
Message-ID: <CAPK2DexxmGj1YWW8=WdLEx32eVmGhoSehZFA20gjNgALMSQVMA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Susan Hares <shares@ndzh.com>, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>, Sangwon Hyun <swhyun77@gmail.com>, Tae-Jin Ahn <taejin.ahn@kt.com>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, Yoav Nir <ynir.ietf@gmail.com>, i2nsf@ietf.org, skku_secu-brain_all@googlegroups.com, Jaehoon Jeong <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000011c114057e166f54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/UOIxhT7GyHEpU8Bm4S0HrtbK-WQ>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-applicability-07
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Dec 2018 15:08:26 -0000
Susan, Diego, Sangwon, and Taejin, Could you clarify my explanation for Eric as coauthors? Thanks. Best Regards, Paul 2018년 12월 28일 (금) 오후 11:09에 Eric Rescorla <ekr@rtfm.com>님이 작성: > > > On Thu, Dec 27, 2018 at 7:21 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Eric, >> Let me answer your further questions below. >> >> On Thu, Dec 27, 2018 at 11:59 PM Eric Rescorla <ekr@rtfm.com> wrote: >> >>> >>> >>> On Wed, Dec 26, 2018 at 6:42 PM Mr. Jaehoon Paul Jeong < >>> jaehoon.paul@gmail.com> wrote: >>> >>>> Hi Eric, >>>> Here are my answers inlines below. >>>> >>>> On Thu, Dec 27, 2018 at 3:44 AM Eric Rescorla <ekr@rtfm.com> wrote: >>>> >>>>> Paul, >>>>> >>>>> Thanks for your new version. Some responses below. >>>>> >>>>> >>>>> On Tue, Dec 25, 2018 at 6:42 AM Mr. Jaehoon Paul Jeong < >>>>> jaehoon.paul@gmail.com> 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 >>>> </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 <ekr@rtfm.com> 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: +82-31-299-4957 >>>>>> Email: jaehoon.paul@gmail.com >>>>>> 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: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> 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: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> <http://cpslab.skku.edu/people-jaehoon-jeong.php> >> >
- [I2nsf] Fwd: AD Review of draft-ietf-i2nsf-applic… Eric Rescorla
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Eric Rescorla
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Eric Rescorla
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Eric Rescorla
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Diego R. Lopez
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-applica… Mr. Jaehoon Paul Jeong