Hi!
I'm picking up where ekr left off
(https://mailarchive.ietf.org/arch/msg/i2nsf/bVTGfSXR70UcFkwfkV4FsNHg8uo) 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,
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
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
