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>