Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Sat, 22 June 2019 09:41 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 2B43D120119 for <i2nsf@ietfa.amsl.com>; Sat, 22 Jun 2019 02:41:06 -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 sDmCu129MqzR for <i2nsf@ietfa.amsl.com>; Sat, 22 Jun 2019 02:41:01 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 8D2E3120026 for <i2nsf@ietf.org>; Sat, 22 Jun 2019 02:41:00 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id v19so8735493wmj.5 for <i2nsf@ietf.org>; Sat, 22 Jun 2019 02:41:00 -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=tUaY4pXrbhn0iNdxvC208TxTDmT9lN2v0FGqpO46KoM=; b=WYyEHKQ/GBSm2TH/2kFDTJJ27kUdTBb8NwUePidXEstMhSeIs/wqffG0/Df/oZajTy j3BAi0dxlqcNmPgf4FCT/gLsEA0Tx7IcQsm8OvGr9VO2S37K+aGqRQ+Ir/oqNRXZVBP3 cVXuAA8B4aHUon1C9yhf7GEOke1i6wsv2+FZQX1FOQ1fEz2gOi4J1NxDAItsLvB2QjHM whnx++SLCKrNsWldASHChhWYmHjiFiDwfNpT8/oVjL3lVVRcJnFoptrt8xkED+rmp7I8 uebfgUMdRJIyt+LpAxeAVk2bPPu9xwebzTBWtDorjlkVDxc18CBqSMKwYE6XCT+iUCTs 0vQg==
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=tUaY4pXrbhn0iNdxvC208TxTDmT9lN2v0FGqpO46KoM=; b=g/UWkLbwaJadbe9KPMGb2rUocL7i8kZMIeENP07n47VdqJn1cKTFa6L1yvDeHETEs7 g79POPeB+hjTX7SL/i+ioszMBHo6rR5gXvujWAi8hStHhdP8hHZqG5DrGemoHXFPDgNO sBx7IKZYd3go/5bZv4+eCVKyMBcAKQxYcY2+S86W2kIMEzOgGwGBKBSXGaw+iE+z45eT 2wjc86ZsMrn9ImRmcZQEI62hnAigTUVVL39KOajGpKVzp8eajswmes3Pqs4CbIKewXnE Y4YQpHpkUnRbIGICAiGhoKm3uZOZjEdSMXO8vn62FSCYddLQnYFLMNUb4Lqjk2vGM/e3 OXGA==
X-Gm-Message-State: APjAAAXC1yWwWTOtgaC/SVm5wjhwYUPWTFygcinRXl/zca76dw7H9uqm yFAnTcGrAkqGQH9fhYRoLXZt0qdrHOmGhBUx+F0=
X-Google-Smtp-Source: APXvYqyQ1NFEyqDXz3v7eRKdotynzmC2Dr9P4yAPSW0lbuFEDl1m4WzpKSmvGxmbJTW7mWwldf/rcPqzSeh4e2es6fs=
X-Received: by 2002:a1c:63d7:: with SMTP id x206mr7589963wmb.19.1561196458425; Sat, 22 Jun 2019 02:40:58 -0700 (PDT)
MIME-Version: 1.0
References: <359EC4B99E040048A7131E0F4E113AFC01B333BED6@marathon> <CAPK2Dex2p-mWQWUHCa3yCJZV6bSFsEX4zfpUrbDtyraPbHp92g@mail.gmail.com> <359EC4B99E040048A7131E0F4E113AFC01B3383932@marathon> <359EC4B99E040048A7131E0F4E113AFC01B33A0F15@marathon> <359EC4B99E040048A7131E0F4E113AFC01B33A1985@marathon> <CAPK2DexcE7uS5UcSne4_nQRv9W-+HbPE4QJyqgA5xVXD74WB7w@mail.gmail.com> <F95E231E-034E-4BA0-A4F1-BAADE8772135@cert.org>
In-Reply-To: <F95E231E-034E-4BA0-A4F1-BAADE8772135@cert.org>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Sat, 22 Jun 2019 18:45:59 +0900
Message-ID: <CAPK2DewWnGzmOv4m3jGVfX0PaGqupXg8syuFOdMzv3h6a5=LYw@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="000000000000544349058be6601b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/8pwsyOy_dIbPQ1zLsKT_A-YkcYU>
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: Sat, 22 Jun 2019 09:41:06 -0000
Roman, Thanks for your guidance.:-) Best Regards, Paul On Sat, Jun 22, 2019 at 5:09 PM Roman Danyliw <rdd@cert.org> wrote: > Hi Paul! > > Thanks for this revision and all of the iteration. I’ve advanced the > document to IETF LC. > > Roman > > On Jun 22, 2019, at 8:13 AM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Roman, > Thanks for your quick review. > > I have reflected your suggested text on #12 in Section 8 and > the mention about the lifecycle management from DMS in Section 3 > on the version -13: > https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-13 > > - New Text for Security Issues and Discussion on DMS in Section 8 > The role of the DMS is to provide an I2NSF system with the software > packages or images for NSF execution. The DMS must not access NSFs > in activated status. An inside attacker or a supply chain attacker > at the DMS can seriously weaken the I2NSF system's security. A > malicious DMS is relevant to an insider attack, and a compromised DMS > is relevant to a supply chain attack. A malicious (or compromised) > DMS could register an NSF of its choice in response to a capability > request by the Security Controller. As a result, a malicious DMS can > attack the I2NSF system by providing malicious NSFs with arbitrary > capabilities to include potentially controlling those NSFs in real > time. An unwitting DMS could be compromised and the infrastructure > of the DMS could be coerced into distributing modified NSFs as well. > > To deal with these types of threats, an I2NSF system should not use > NSFs from an untrusted DMS or without prior testing. The practices > by which these packages are downloaded and loaded into the system are > out of scope for I2NSF. > > I2NSF system operators should audit and monitor interactions with > DMSs. Additionally, the operators should monitor the running NSFs > through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as > part of the I2NSF NSF-Facing Interface. Note that the mechanics for > monitoring the DMSs are out of scope for I2NSF. > > - Mention about the Lifecycle Management from DMS in Section 3 > As shown in Figure 1, with a Developer's Management System (called > DMS), developers (or vendors) inform the Security Controller of the > capabilities of the NSFs through the Registration Interface > [registration-inf-dm] for registering (or deregistering) the > corresponding NSFs. Note that the lifecycle management of NSF code > from DMS (e.g., downloading of NSF modules and testing of NSF code) > is out of scope for I2NSF. > > Please let this draft go under the IESG submission. > > Thanks for your help. > > Best Regards, > Paul > > > On Sat, Jun 22, 2019 at 5:46 AM Roman Danyliw <rdd@cert.org> wrote: > >> Hello Paul! >> >> Thanks for the revised text and answering all of my questions. I have a >> few recommended text changes per items #12 below. All other items have >> been addressed. >> >> Thanks, >> Roman >> >> > From: Mr. Jaehoon Paul Jeong [mailto:jaehoon.paul@gmail.com] >> > Sent: Tuesday, June 18, 2019 5:15 AM >> > To: Roman Danyliw <rdd@cert.org> >> > Cc: Linda Dunbar <linda.dunbar@huawei.com>; Yoav Nir < >> ynir.ietf@gmail.com>; >> > i2nsf@ietf.org; skku_secu-brain_all@googlegroups.com; >> > Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> >> > Subject: Re: [I2nsf] AD Review: draft-ietf-i2nsf-applicability-09 >> > >> > Hi Roman, >> > I have addressed all of your comments again and submitted version -12: >> > https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-12 >> > >> > I attach my revision letter. >> > >> > Could you confirm that my addressing is good enough to move this >> > draft forward to the IESG submission? >> > >> > Thanks. >> > >> > Best Regards, >> > Paul >> > > -----Original Message----- >> > > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Roman >> Danyliw >> > > Sent: Tuesday, June 4, 2019 6:35 PM >> > > To: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>; 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 >> > > >> > > 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. >> >> Thanks for making the change. >> >> > > > (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. >> >> Thanks for making this change. >> >> > > > (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/Xc92QkEPgRWC3FKuRvnaiNNFY >> > > 2 >> > > > 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? >> >> Thanks for the new consolidated text in the Security Considerations >> section to address the above issues. Given variety of issues it covers, I >> recommend being more precise in what the DMS can do and what operators >> should do about it. I took a few editorial liberties in restructuring the >> text. See below. Does that make sense? >> >> ==[ start old ]== >> Note that an inside attacker (or supply chain attacker) at the DMS can >> seriously weaken the I2NSF system's security. Note that a malicious NSF >> provider (as a DMS) is relevant to an insider attack, and a compromised NSF >> provider is relevant to a supply chain attack. Also, note that a malicious >> (or compromised) DMS sending the wrong NSF may not modify the original code >> of the NSF but may alter the sent NSF as an instant. As a result, a >> malicious (or compromised) DMS can attack the Security Controller by >> providing the Security Controller with malicious (or compromised) NSFs, and >> controlling those NSFs in real time. Also, an unwitting DMS vendor could be >> compromised and their infrastructure could be coerced into distributing >> modified NSFs. To deal with these types of threats, the role of the DMS >> should be restricted to providing an I2NSF system with the software >> package/image for NSF execution, and the DMS should never be able to access >> NSFs in activated status for the I2NSF system's security. On the other >> hand, an access to active NSFs should be allowed only to the Security >> Controller, not the DMS during the provisioning time of those NSFs to the >> I2NSF system. However, note that an inside attacker (or supply chain >> attacker) can access the active NSFs, which are being executed as either >> VNFs or middleboxes in the I2NSF system, through a back door (i.e., an IP >> address and a port number that are known to the DMS to control an NSF). >> However, the Security Controller may detect and prevent those inside >> attacks (supply chain attacks) by monitoring the activities of all the DMSs >> as well as the NSFs through the I2NSF NSF Monitoring Interface >> [nsf-monitoring-dm] as part of the I2NSF NSF-Facing Interface. Through the >> NSF Monitoring Interface, 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 threats (or supply chain threats). Note that the >> monitoring of the DMSs is out of scope for I2NSF. However, as a general >> caution, a mitigation strategy for insider attacks or supply chain attacks >> is not to use an NSF without prior testing for an automated security action >> in the I2NSF system. >> ==[ end old ]== >> >> ==[ start new ]== >> The role of the DMS is to provide an I2NSF system with the software >> package or images for NSF execution. The DMS must not access NSFs in >> activated status. An inside attacker or a supply chain attacker at the >> DMS can seriously weaken the I2NSF system's security. A malicious DMS is >> relevant to an insider attack, and a compromised DMS is relevant to a >> supply chain attack. A malicious (or compromised) DMS could register an NSF >> of its choice in response to a capability requests by the Security >> Controller. As a result, a malicious DMS can attack the I2NSF system by >> providing a malicious NSFs with arbitrary capabilities to include >> potentially controlling those NSFs in real time. An unwitting DMS vendor >> could be compromised and their infrastructure could be coerced into >> distributing modified NSFs as well. >> >> To deal with these types of threats, an I2NSF system should not use NSFs >> from untrusted DMS or without prior testing. The practices by which these >> packages are downloaded and loaded into the system is out of scope for >> I2NSF. >> >> I2NSF system operators should audit and monitor interactions with DMSs. >> Additionally, the operator should monitor the running NSFs through the >> I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as part of the I2NSF >> NSF-Facing Interface. Note that the mechanics monitoring of the DMSs is out >> of scope for I2NSF. >> ==[ end new ]== >> >> The fact that lifecycle management of NSF code from DMS (e.g., >> downloading the modules, testing the code) is out of scope of I2NSF came up >> a few times in your revision letter (in response to my feedback and ekrs). >> You point out that it's noted much later in the text of Section 7. For >> clarity, I'd recommend adding such a short comment earlier in the text as >> well in the quick overview of the I2NSF Framework in Section 3 in the >> paragraph starting with "As shown in Figure 1, with a Developer's >> Management System ..." >> >> > > > (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? >> >> Thanks for making the change to address the concern. >> >> > > 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 >> > > > RESTCONF+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. >> >> Thanks for making this language consistent and the explanation in your >> revision letter. It addresses my concerns. >> >> > > > (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/ >> >> Thanks for the update. >> >> > > > (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]. >> >> Thanks for the update. >> >> > > > (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. >> >> Thanks for the update. >> >> > > > (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. >> >> Thanks for the update. >> >> > > > (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)). >> >> Thanks for the update. >> >> > > > (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)// >> >> Thanks for the update. >> >> > > > (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]./ >> >> Thanks for the update. >> >> > > 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 >> > > _______________________________________________ >> > > 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 > <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] 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