Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 06 June 2019 03:01 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 EB4EA120043 for <i2nsf@ietfa.amsl.com>; Wed, 5 Jun 2019 20:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham 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 1pkGt88lIpzO for <i2nsf@ietfa.amsl.com>; Wed, 5 Jun 2019 20:01:50 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 88786120019 for <i2nsf@ietf.org>; Wed, 5 Jun 2019 20:01:49 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id m3so752909wrv.2 for <i2nsf@ietf.org>; Wed, 05 Jun 2019 20:01:49 -0700 (PDT)
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=fUN9kJqliQ27oI6Bjb9/tkLFyUhCczLfyFS9y6LN7sM=; b=VVTywLrfWhXKf1xTGitk9Z9H0J47ENxzJZ+4hVeoY9KNkgwgC0kaNedNgo1Wuupp69 pc+uaut8yWZ/GUBLKpDA6LbBj0bV67Z3yMYTV33+joW+79Saj09P6Bpoapw470V0uP8p YVunq9j4zBBwJZodXxJ1rLhiEHMSYJzZ1MofhxdBWT3+BrZK5wSIFr0Nijxr+ekwdn3G YNVXr3XODU4/WPuKxVaYNmqXi7P9nzBxkbB7qppcuD/S45vLW2zkCr7hxHFpHyLY5AvC 2bvVGw/ACB8WOSlrGsaDuV4mnXFRAwNhkGmJf5cbW7mut4YF1Lj/yQWGsx9FJXSDhzh5 HIhQ==
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=fUN9kJqliQ27oI6Bjb9/tkLFyUhCczLfyFS9y6LN7sM=; b=G6Mn5vk7HL3K/j5MI18O5NE/ZTLtye0RvMgyrePCsopr0PPu80FVh31COz2ncJsvdv s/qdAiMg8hi2l08/bmql+pNDt4tAaR80ixynLIAMSJwT9Ak8KMG9EJUKJ32bGDBLvwUc wnI9KXRMJvyeJh1sUV8ozS0Oz3GFRaca8U7omOcq80s1Cu0odXh6i7eQ+AnDqaBneed/ sHoHJyqjAqb55dgZ/CLsv9U8mPvVOJ79O52fJfdK+PkEzwoIfm+Y9D9CtzzD3RBDdvKo I17+AfZDAVg/jtPzXl/hoUWFi7Gp7NUR/UByR/p5RDi38B3HYfRckJil9R5Kxzk/fZ8d 6NQA==
X-Gm-Message-State: APjAAAXg2mb+NQW6g8y8T++U97eexP8tFl/4Ht5taMX/Tv82sK2zQqPP dMlPC011M0jXfmWJJtku/9rBfdz06Y7AXyxC9e0=
X-Google-Smtp-Source: APXvYqw0I6dmduXc52S6EURV76Kt+K6vy0olEeIVLWhZZz2FmokNioeqNPA2xcftobnyXxr2MewgEfct82B8KJHLQDk=
X-Received: by 2002:a5d:4a82:: with SMTP id o2mr10700643wrq.154.1559790107757; Wed, 05 Jun 2019 20:01:47 -0700 (PDT)
MIME-Version: 1.0
References: <359EC4B99E040048A7131E0F4E113AFC01B333BED6@marathon> <CAPK2Dex2p-mWQWUHCa3yCJZV6bSFsEX4zfpUrbDtyraPbHp92g@mail.gmail.com> <359EC4B99E040048A7131E0F4E113AFC01B3383932@marathon>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3383932@marathon>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 06 Jun 2019 12:01:09 +0900
Message-ID: <CAPK2Dez0e6ag3Q5EokDtiVLgnCOVBk7y+vG7i7rt0Ur2V1-=HQ@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, Yoav Nir <ynir.ietf@gmail.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "skku_secu-brain_all@googlegroups.com" <skku_secu-brain_all@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000004c12d9058a9eef03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/81COCqCdjepGyET-jfYhc5ox5uI>
Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
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: Thu, 06 Jun 2019 03:01:55 -0000
Hi Roman, I will review your comments during the weekend and answer them early next week. Thanks. Best Regards, Paul On Wed, Jun 5, 2019 at 7:35 AM Roman Danyliw <rdd@cert.org> wrote: > Hello Paul! > > Thank you for the extensive changes you have made. See follow-up > questions below. If you don't see a previous item listed, please consider > it resolved. > > Since your comments were made with a word attachment (no problem!), I'm > just responding to my own original thread. > > > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Mr. Jaehoon > Paul > > Jeong > > Sent: Thursday, May 02, 2019 5:13 AM > > To: Roman Danyliw <rdd@cert.org>; Linda Dunbar > > <linda.dunbar@huawei.com>; Yoav Nir <ynir.ietf@gmail.com> > > Cc: i2nsf@ietf.org; skku_secu-brain_all@googlegroups.com > > Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09 > > > > Hi Roman, Linda, and Yoav, > > I have reflected Roman's questions and comments in I2NSF Applicability > Draft > > (version 10). > > Here is the link of the revised draft: > > https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-10 > > > > I send you my revision letter that describes my answers and reflection > in the > > text. > > > > If you have questions and comments, please let me know. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Wed, Apr 17, 2019 at 9:23 PM Roman Danyliw <rdd@cert.org> wrote: > > Hi! > > > > I'm picking up where ekr left off > > (https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8 > > uo) with an AD review of draft-ietf-i2nsf-applicability-09. > > [snip] > > > (5) Section 1. Per "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", this sentence doesn't parse for me. > > > > Do you mean, "In the I2NSF framework, each NSF initially registers a > profile > > of its capabilities in the system"? If so, I think clarity of what > system (I think > > "I2NSF system") is being referenced is needed. > > Per -11, I’d recommend making the text even more concise. > > OLD: In the I2NSF framework, each NSF initially registers the profile of > its own capabilities into the Security Controller (i.e., network > operator management system [RFC8329]) in the I2NSF system via Registration > Interface [registration-inf-dm] so that each NSF can be selected and used > to enforce a given security policy from I2NSF User (i.e., network security > administrator). > > NEW: > In the I2NSF framework, each NSF initially registers the profile of its > own capabilities with the Security Controller (i.e., network operator > management system [RFC8329]) of the I2NSF system via the Registration > Interface [registration-inf-dm]. This registration enables an I2NSF User > (i.e., network security administrator) to select and use the NSF to enforce > a given security policy. > > > (6) Section 1. Per "In addition, the Security Controller ...", this > sentence > > introduces the concept of a Security Controller but doesn't define it. > Also, > > this seems like a level of detail not needed in the introduction. > > I appreciate all of the new text in -11, but I don't think we need all of > it. My concern is that some of it will unnecessarily duplicates text > already in Section 3 and [i2nsf-terminology]. The new text “(i.e., network > operator management system [RFC8329]).” sufficiently defines the > controller. The new text “Security Controller is defined as …” isn’t > needed. > > > (11) Section 3. Per "Note that an inside attacker at the DMS can > seriously > > weaken the I2NSF system ...", I concur with the assessment that a DMS can > > subvert the I2NSF system. Three related points: > > > > ** The boundary/scope of an I2NSF system wasn't clear to me. It > appears to > > me that an I2NSF system is security controller + NSFs. There are several > > interfaces defined for the controller and NSFs. Everything else (e.g., > DMS, > > I2NSF user) is outside the scope of the I2NSF system, correct? I draw > > attention to this distinction because identifying where this insider is > located > > needs to be clearer. > > > > ** If the DMS can provide the software package for the NSF, I'm not sure > > how the insider threat is mitigated. The attacker can already run a > software > > load of her choice on your network (that you have permitted). > > > > ** Per > > https://mailarchive.ietf.org/arch/msg/i2nsf/Xc92QkEPgRWC3FKuRvnaiNNFY2 > > o, I concur with ekr that the text needs to be clearer on what the DMS > can do > > to the I2NSF system. > > Despite the changes in -11, I still need help understanding the flow > between the security controller and DMS. Like ekr posed in the thread > above, I’m trying to understand how the software is loaded into the > production I2NSF system. > > As I understand it, we’re talking about a software update process > facilitated through a NETCONF interface via the Internet. Section 5 of > draft-hyun-i2nsf-registration-interface-dm says: > > 1) Security Controller first recognizes the set of capabilities > (i.e., NSF Profile) or the signature of a specific NSF required > or wasted in the current system. > > 2) Developer's Management System (DMS) matches the recognized > information to an NSF based on the information model definition. > > 3) Developer's Management System creates or eliminates NSFs matching > with the above information. > > 4) Security Controller can then add/remove the corresponding NSF > instance to/from its list of available NSF instances in the > system. > > To test my understanding, the user interface sends a high-level action to > the Security Controller (SC); the SC sends to the DMS what capabilities it > wants; the DMS returns back what NSF (modules/packages/code) it has that > meet these capabilities; the SC can then choose to download these NSF > (modules/package/code) from the DMS and provision these newly downloaded > NSF (modules/package/code) into the live system. Is this correct? > > How is the new code transported from the DMS to the SC? Is that in scope? > > > (12) Section 3, Per "On the other hand, an access to running (online) > NSFs > > should be allowed only to the Security Controller, not the DMS.", this > > sentence isn't clear to me. > > > > ** It doesn't parse so I don't know who is supposed to get what access -- > > specifically, "an access to running NSFs" > > > > ** "running (online) NSFs" is proposing an operational construct which > is also > > not clear to me. It that the equivalent of saying in production? If it > means > > production, is there a distinction being made between interacting with > the > > DMS during the time of provisioning and then after the fact? > > See comment in #13 about consolidating all threat mitigation in the > Security Considerations Section > > > (13) Section 3, Per "Also, the Security Controller can detect and prevent > > inside attacks by monitoring the activity of all the DMSs ... through > the I2NSF > > NSF monitoring capability", is the monitoring interface also capable of > > observing the DMS? I ask because the monitoring interface is described > in > > RFC8329 as part of I2NSF NSF-Facing Interface (Section 3.2).. The > Registration > > Interface description (Section 3.3 of RFC8329) makes no reference to any > > monitoring capability. > > Per the following new text: > > However, the Security Controller can detect and prevent inside attacks by > monitoring the activities of all the DMSs as well as the NSFs through the > I2NSF NSF monitoring functionality [nsf-monitoring-dm]. Through the NSF > monitoring, the Security Controller can monitor the activities and states > of NSFs, and then can make a diagnosis to see whether the NSFs are working > in normal conditions or in abnormal conditions including the insider > threat. Note that the monitoring of the DMSs is out of scope for I2NSF. > > This still confusing to me. The first sentence explicitly says that the > Security Controller can monitoring the activities of all the DMSs, but the > last sentence says monitoring the DMS is out of scope. > > As I understand it, the DMS is operated by a vendor outside of the > deployed enclave of the I2NSF system. Therefore, to me, this isn’t an > insider threat but a supply chain attack. Furthermore, “Note that an > inside attacker at the DMS can seriously weaken the I2NSF system's > security” is true. However, it’s more than an inside attack. An unwitting > DMS vendor could be compromised and their infrastructure could be coerced > into distributing modified NSF. > > I recommend moving all of this discussion about the insider threat/supply > chain attacks and possible mitigation with monitoring into the Security > Considerations. Additionally, RFC8329 Section 4 doesn’t seem to: > > ** distinguish between a malicious and compromised provider – the > mitigation would be different) > > ** a malicious/compromised DMS sending the wrong NSF (perhaps because the > attacker can’t modify the code but can alter what gets sent) > > ** general caution of not bringing your network down through automated > security action (using outside code) without prior testing > > > (15) Section 3. What it intentional to say that the Consumer interface > can be > > RESTCONF+YANG (with a reference); the NSF-Facing Interface is NETCONF > > (but YANG with no reference); and the registration interface is RESTCONF > > (no reference to YANG)? > > This comment resulted in a lot more text changes than anticipated. I was > intending to ask why certain interface mentioned the corresponding YANG > modules (and other did not). Given the new language, “The xxx interface > _can_ be implemented as an _XML file_ ...”, a few additional questions: > > ** why the references to XML (in the new language)? > ** why the use “can be implemented” (in the old and new language) because > the alternative to the specified data model isn’t clear. > > Is it simpler to say, “The xxx interface _is_ implemented with the xxx > interface YANG model [xxx-reference] using …{RESTCONF or NETCONF} which > befits ...”? > > It looks like you some language has changed relative to RESTCONF vs. > NETCONF. This is the new summary: > ** Consumer-Facing Interface = RESTCONF > ** NSF-Facing interface = NETCONF > ** Registration interface = NETCONF (was RESTCONF) > > I’d like to inquire about the consistency of this language with > [draft-ietf-i2nsf-nsf-facing-interface-dm]. It’s Section 7 says that > RESTCONF or NETCONF can both be used. > > > (18) Section 5. What is the purpose of including this section if there > is an > > entire draft (draft-hyun-i2nsf-nsf-triggered-steering) focused on the > topic? > > Thanks for the changes from [draft-hyun-i2nsf-nsf-triggered-steering] to > [RFC7665]. The followed edits more precisely use the reference (as having > it after the “I2NSF architecture” made it read to me that this was the > reference). > > Per Section 3, > s/ Also, the I2NSF framework can enforce multiple chained NSFs for the > low-level security policies by means of SFC techniques for the I2NSF > architecture [RFC7665]./ > The I2NSF framework can chain multiple NSFs to implement low-level > security policies with the SFC architecture [RFC7665]./ > > Per Section 4, > s/SFC technology can be utilized to support such packet forwarding in the > I2NSF framework [RFC7665]/ > The SFC architecture [RFC7665] can be utilized to support such packet > forwarding in the I2NSF framework/ > > > (19) Section 5, "To trigger an advanced security action in the I2NSF > > architecture, the current NSF appends a metadata describing the security > > capability required for the advanced action to the suspicious packet and > > sends the packet to the classifier." > > > > ** Editorial nit: s/NSF appends a metadata/NSF appends metadata/ > > ** What is the reference for this meta-data format? > > Thanks for the updated text. I recommend being more precise with the > following edit: > > OLD: > To trigger an advanced security action in the I2NSF architecture, the > current NSF appends metadata describing the security capability > required for the advanced action to the suspicious packet to the > network service header (NSH) of the packet [RFC8300]. > > NEW: > To trigger an advanced security action in the I2NSF architecture, the > current NSF appends metadata describing the security capability > required to the suspicious packet via a network service header (NSH) > [RFC8300]. > > > (20) Section 6. What is the role of the DMS is this scenario? Why does > the > > controller need to rely on [NFV MANO] if all information about the > > capabilities is already provided by the DMS? Since the SDN and other NSF > > operate using the same data model/interface, isn't the different between > an > > SDN and NSF opaque to the controller? I would have assumed that an SDN > is > > simply a specific type of NSF with particular capabilities. > > All my questions are addressed with the new text. Thanks. I’d recommend > looking at last few sentences of the new first and second paragraph of this > section. They appear to be saying a very similar thing. > > > (21) Section 6. "By taking advantage of this capability of SDN, it is > possible to > > optimize the process of security service enforcement in the I2NSF > system." > > The proposed optimization isn't evident from this text. > > Thanks. Check (20) because it appears this new language may introduce > more duplicate text. > > > (22) Section 6. "Especially, SDN forwarding elements enforce simple > packet > > filtering rules that can be translated into their packet forwarding > rules, > > whereas NSFs enforce NSF-related security rules requiring the security > > capabilities of the NSFs." > > > > ** I found the use of the word "Especially" confusing > > ** I am not sure what distinction is being made between the SDN > forwarding > > and NSF rules. > > Thanks. Check (20) because it appears this new language may introduce > more duplicate text. I think what you said for (21) obviates the need for > this new language. It’s now clear what you mean (based on your language for > (21)). > > > (23) Section 6, "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 wasn't sure what the "for this purpose" was referencing, what > > "purpose"? > > Editorial nit on the -11 edits. s/ For the tasks for security enforcement > (e.g., packet filtering)// > > > (27) Section 7. "Those NSFs are created or removed by a virtual network > > functions manager (VNFM) in the NFV architecture that performs the life- > > cycle management of VNFs. The Security Controller controls and monitors > > the configurations (e.g., function parameters and security policy rules) > of > > VNFs." > > > > Is the VNFM in scope for I2NSF? > > Thanks for the additional language about being out of scope. An editorial > nit in this revised text: > > s/Note that the life-cycle management of VNFs are out of scope for I2NSF./ > Note that the life-cycle management of VNFs is out of scope for I2NSF./ > > > If the Security Controller monitors/controls the VNFs, is it using [nsf- > > monitoring-dm] and [nsf-facing-inf-dm]? > > Thanks for the additional references. An editorial nit in the revised > text: > > s/via NSF-Facing Interface along with NSF monitoring capability > [nsf-facing-inf-dm][nsf-monitoring-dm]./ > via the NSF-Facing Interface along with the NSF monitoring capability > [nsf-facing-inf-dm][nsf-monitoring-dm]./ > > Regards, > Roman > > > Roman > > > > _______________________________________________ > > I2nsf mailing list > > I2nsf@ietf.org > > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > > > -- > > =========================== > > Mr. Jaehoon (Paul) Jeong, Ph.D. > > Associate Professor > > Department of Software > > Sungkyunkwan University > > Office: +82-31-299-4957 > > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: > > http://iotlab.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] AD Review: draft-ietf-i2nsf-applicability… Roman Danyliw
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Linda Dunbar
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Roman Danyliw
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Roman Danyliw
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Roman Danyliw
- Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicabi… Mr. Jaehoon Paul Jeong