[I2nsf] Editors have addressed all your comments to draft-ietf-i2nsf-applicability-09 , can you move it forward to IESG?

[Linda Dunbar <[e-mail]>]

Roman,

The editors have all your comments to draft-ietf-i2nsf-applicability-09,
they have uploaded the revised version (draft-ietf-i2nsf-applicability-11).

 the attached documents highlight their changes to address your comments.

can you move it forward to IESG?

Thank you very much
Linda Dunbar



*From:* Mr. Jaehoon Paul Jeong <[e-mail]>
*Sent:* Sunday, May 26, 2019 8:00 PM
*To:* Roman Danyliw <[e-mail]>
*Cc:* Yoav Nir <[e-mail]>; Jaehoon (Paul) Jeong <
[e-mail]>; [e-mail];
[e-mail]
*Subject:* Re: your comments to draft-ietf-i2nsf-applicability-09 have all
been addressed, can you move it forward to IESG?



Hi Roman,

Could you review my revision and share your review with us in the i2nsf
mailing list?



As you may know, the progress of our I2NSF Applicability draft is so
delayed after the WGLC.



I hope we can make a fast progress



Thanks.



Best Regards,

Paul



2019년 5월 17일 (금) 오전 12:23, Linda Dunbar <[e-mail]>님이 작성:

Roman,



Thank you very much for the comments to draft-ietf-i2nsf-applicability-09.

The draft authors have addressed them in the
draft-ietf-i2nsf-applicability-11. Please see the attached letter on their
changes to each of your comment.



Can you move the draft forward to IESG?



Thank you very much.



Linda & Yoav



*From:* Mr. Jaehoon Paul Jeong [mailto:[e-mail]]
*Sent:* Thursday, May 02, 2019 4:13 AM
*To:* Roman Danyliw <[e-mail]>; Linda Dunbar <[e-mail]>;
Yoav Nir <[e-mail]>
*Cc:* [e-mail]; [e-mail]
*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
<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-i2nsf-applicability-10&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539390558&sdata=fNWPkqJu6vWczL25A34FIRZ9bn%2FZX%2Ba6jqNU2GvsxVk%3D&reserved=0>




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 <[e-mail]> wrote:

Hi!

I'm picking up where ekr left off (
https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8uo
<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fi2nsf%2FbVTGfSXR70UcFkwfkV4FsNHg8uo&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539400552&sdata=lfeRnF5W3n%2BKZiE5Qg%2BUVbcKwDPNsZsLykcdWGQ5sSk%3D&reserved=0>)
with an AD review of draft-ietf-i2nsf-applicability-09.

(1) Section 1.  Please do not expand NSF again the second sentence.  The
acronym NSF was defined in the first sentence.

(2) Global Typo - s/funcional/functional/

(3) Section 1.  I had difficulty understanding the sentence:

"Note that Network Security Function (NSF)  is defined as a
   funcional  block  for a security service within an I2NSF framework that
   has well-defined I2NSF NSF-facing interface and other external
   interfaces and well-defined functional behavior [NFV-Terminology]."

** I'm not clear on what a functional block is and [NFV-Terminology]
doesn't define it (although it does define other things also using this
terminology)

** Why is this NSF definition different than the one provided in RFC8329 -
"Network Security Functions (NSFs) are packet-processing engines that
inspect and optionally modify packets traversing networks, either directly
or in the context of sessions to which the packet is associated" or
RFC8192, "An NSF is a function that is used to ensure integrity,
confidentiality, or availability of network communication; to detect
unwanted network activity; or to block, or at least mitigate, the effects
of unwanted activity."

**Why use the [NVF-Terminology] citation?  It does not appear to have an
entry for NSF in the terms/definitions.

(4) Section 1.  Per "The I2NSF framework allows ... by utilizing the
capabilities of such products and the virtualization of security functions
in the NFV platform", I don't understand what the second clause ("by
utilizing ...") is adding.  It seems to simply restate  that the products
have capabilities and will be virtualized (which is implicit in the NFV).

(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.

(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.

(7) Section 2,

This document uses the terminology described in [RFC7665], [RFC7149],
   [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
   [ITU-T.X.1252], [ITU-T.X.800], [NFV-Terminology], [RFC8329],
   [i2nsf-terminology], [consumer-facing-inf-dm], [i2nsf-nsf-cap-im],
   [nsf-facing-inf-dm], [registration-inf-dm], and
   [nsf-triggered-steering ].

This sentence has 15 references covering hundreds of pages as having the
relevant terminology.  Are all of them needed?  That's seems like a lot
background reading.

(8) Figure 1.  I found it confusing that this Figure 1 diagram didn't use
the same names as Figure 1 of [RFC8329].  Specifically, why did the
"Network Operator Management System" get renamed a "Security Controller"?

(9) Section 3.  Recommend the following editorial change since none of the
third paragraph has anything to do with the NSF-Facing Interface:

OLD: Finally, the Security Controller sends the generated low-level
security policies to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm].

NEW: Finally, the Security Controller sends the generated low-level
security policies to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm] via the
NSF Facing Interface.

DROP:  The Security Controller requests NSFs to perform low-level security
services via the NSF-Facing Interface.


(10) Section 3.  Per the final sentence of paragraph 2, why is
[i2nsf-nsf-cap-im] appropriate?  Doesn't the Security Controller use only
the YANG module from [nsf-facing-inf-dm]?

(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/Xc92QkEPgRWC3FKuRvnaiNNFY2o
<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fi2nsf%2FXc92QkEPgRWC3FKuRvnaiNNFY2o&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539400552&sdata=RuQAtjrDt%2BsS1ICnjJh1itqbMRAAPpL0ftoibjBJJVw%3D&reserved=0>,
I concur with ekr that the text needs to be clearer on what the DMS can do
to the I2NSF 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?

(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.

(14) Section 3, I'm not clear on what is MTI or the alternatives.  The text
says "The Consumer-Facing Interface ... can be implemented ... by
[consumer-facing-inf-dm]" and "the NSF facing interface ... can be
implemented using NETCONF ... [with] ... the data model defined in
[nsf-facing-inf-dm]".  Why can?  If not with those references then with
what?

(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)?

(16) Section 4.  I found the term "an example XML code" vague given that
this document is supposed to be an applicability statement highlighting
I2NSF.  To what schema does this XML conform?  Is this a notional example
or a complete instance?  On what interface would this have been sent?

(17) Section 4.  Grammatical Nit.

s/it is assumed that an NSF of firewall/
/it is assumed than a firewall NSF/

s/NSF of web filter/
/web filter NSF/

(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?

(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?

(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.

(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.

(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.

(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"?

(24) Section 6.  Editorial Nit.

OLD:
"The following subsections introduce three use cases for cloud-based
security services: (i) firewall system, (ii) deep packet inspection system,
and (iii) attack mitigation system.  [RFC8192]"

NEW:
The following subsections introduce three use cases from [RFC8192] for
cloud-based security services: (i) firewall system, (ii) deep packet
inspection system, and (iii) attack mitigation system."

(25) Section 6.1 - 6.3.  It wasn't evident to me why these sections were in
the document.  The described procedures and benefits didn't read as being
I2NSF specific and appear to primarily describe what's happening in the SDN
(and not using the defined I2NSF interfaces).

(26) Section 6.3, Typo. s/the the/the/

(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?

If the Security Controller monitors/controls the VNFs, is it using
[nsf-monitoring-dm] and [nsf-facing-inf-dm]?

Roman

_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf
<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539410549&sdata=Yv40HJnxj9LEt0Z3p2DgPe2njwxGYA0clXSeVOV0rP0%3D&reserved=0>




-- 

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpslab.skku.edu%2Fpeople-jaehoon-jeong.php&data=02%7C01%7Cldunbar%40futurewei.com%7C176e649a0712434048a708d6e23ec320%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636945156539410549&sdata=BXO3w6E%2FSKZ13p5ohj%2FpboZK8wse0xZlIOxO38MSYF8%3D&reserved=0>