Hi!
I performed my AD review of draft-ietf-i2nsf-consumer-facing-interface-dm-23.
Thanks for the work on this information/data model. Below is my feedback:
** Section 1. Could a sentence or two here to explain what the Security
Controller, the recipient of the Consumer-Facing Interface, does with this
configuration information?
** Section 1. Since the architecture and reference model of RFC8329 is being
used, please provide bridging text to explain that "Security Controller" used
in this document is equivalent to a "Network Operator Management System" (used
in RFC8329).
** Section 1.
Assuming that vendors also provide the
front-end web applications to an I2NSF User, the Consumer-Facing
Interface is required because the web applications developed by each
vendor need to have a standard interface specifying the data types
used when the I2NSF User and Security Controller communicate with
each other using this interface.
...
The Consumer-Facing Interface would be built using a set of objects,
with each object capturing a unique set of information from Security
Administrator (i.e., I2NSF User [RFC8329])
I'd like to clear up ambiguity on who is an "I2NSF User"? Is it a "user" as in
a human? Is it vendor provided tooling which converts user input into this
standardized YANG module and sends it via the Consumer Interface to a
controller? Or is a "I2NSF User" both?
-- In this text there are references to "vendors ... provid[ing] the front-end
web applications to an I2NSF User", implying that "I2NSF User" is a human, and
the tooling to generate the YANG module is NOT part of the "I2NSF user"
-- This text also seems to equate a "Security Administrator", a human, to be
being the "I2NSF User".
-- Section 3.1 of RFC8329 gives examples of "I2NSF Consumers" (not "I2NSF
users") to be "video conference network management system", "enterprise network
administrator and management systems", and "IoT management system" which seems
to imply that it is both. Figure 1 above this text seems to depict a flow
between the I2NSF user directly to the Security Controller. Therefore, unless
a human is directly crafting YANG, there is likely some supporting technology
that is considered the "I2NSF user".
-- Section 6.1 of RFC8329 says "As a general principle, in the I2NSF
environment, users directly interact with the I2NSF Controller."
** Section 1.
These policies can easily be
translated by the Security Controller into low-level security
policies.
I'm not sure it makes sense to characterize the policy translation as "easy".
** Section 3. Editorial.
OLD
A Policy object represents a mechanism to express a Security Policy
by Security Administrator (i.e., I2NSF User) using Consumer-Facing
Interface toward Security Controller; the policy would be enforced on
an NSF.
NEW
A Policy object is a means to express a Security Policy set by a Security
Administrator (i.e., I2NSF User) with the Consumer-Facing Interface. It is
sent to the Security Controller which converts it into an NSF-specific
configuration via the NSF-facing interface for enforcement on the NSF.
** Section 3. Editorial.
OLD
The resolution strategy is described in [I-D.ietf-i2nsf-capability-data-model]
in detail.
NEW
The resolution strategy is described in Section 3.2 of
[I-D.ietf-i2nsf-capability-data-model].
** Section 3.
1) communication between two Endpoint Groups,
2) for preventing communication with externally or
internally identified threats, and 3) for implementing
business requirement such as controlling access to internal
or external resources for meeting regulatory compliance or
business objectives. An organization may restrict certain
communication between a set of user and applications for
example.
-- What is an "endpoint group"? It's explained later but not in this point in
the document. Please add a forward reference.
-- Per (3), isn't this entire interface about encoding "implementing business
requirements"?
** Section 3.
The threats may be from threat feeds obtained
from external sources or dynamically identified by using
specialty devices in the network.
I didn't see a mechanism in the text for this dynamic identification. The
definitely of threat sources later in the document seems to reinforce the idea
that this is externally sourced information.
** Section 3.
Rule conflict analysis
should be triggered by the monitoring service to perform an
exhaustive detection of anomalies among the configuration
rules installed into the security functions.
-- Does the "rule conflict analysis" happen on the Security Controller?
-- Please say more about the "monitoring service"
-- Please say more about "detecting anomalies". Is this more than "rule
conflict[s]"?
** Section 3.
A policy is a list of rules.
The text prior and Figure 2, just explained how a policy is much more than a
rule. Should it say, "A policy will contain a list of rules."
** Section 3.
A Policy Rule may be related segmentation,
threat mitigation or telemetry data collection from an NSF in the
network, ...
This sentence doesn't parse but I don't understand it enough to provide an
alternative.
** Section 3.
Event: This field includes the information to determine whether
the Rule Condition can be evaluated or not. See details in
Section 3.1.
What is the relationship between the Event and the rule Condition. Section 3.1
seems to provide means to specify which system events and alarms are
applicable, but it doesn't appear to have a dependency on the Condition and
seems to be describing if the entire Rule should trigger.
** Section 3.
This field contains all the checking conditions to apply
to the objective traffic.
Please restate to clarify "objective traffic" (vs. just traffic) and "checking
conditions".
** Section 3.1
The Rule could be activated based on a security event (i.e., system
event and system alarm).
This text states that that a "Rule _could_ be activated ...", suggesting that
there is an alternative way to activate it. Figure 4 doesn't seem to suggest
that. Should it read "The Rule is activated ..."?
** Section 3.2
This object represents Conditions that Security Administrator wants
to apply the checking on the traffic in order to determine whether
the set of actions in the Rule can be executed or not. The Condition
Sub-model consists of three different types of containers each
representing different cases, such as general firewall and DDoS-
mitigation cases, and a case when the condition is based on the
payload strings of packets.
-- The Condition model appears to have 8 different types of containers, not 3.
-- This sentence would benefit from editorial polish. Consider:
NEW
The Condition object describes the network traffic pattern or fields that must
be matched against the observed network traffic for the rule to trigger. The
fields used to express the required conditions to triggers the rule are
organized around the class of NSFs expected to be able to observe or compute
them.
** Section 3.2
Each containers have source and
destination-target to represent the source and destination for each
case.
This statement seems only accurate for "container firewall". For example
"container ddos" and "anti-virus" (and a few others) doesn't seem have a source
and destination.
** Section 3.2
This field represents the general firewall case,
where a security admin can set up firewall conditions using
the information present in this field.
What is a "general firewall case"? Is this equivalent to saying that that the
Security Administrator wants to describe network traffic with layer 3 or 4
header fields? Currently, the text is restating the name of the container as
the description.
** Section 3.2. Per the ddos and anti-virus cases, please re-write this text
to describe what each is doing. Currently, the text is restating the name of
the container. Specifically, "This field represents the "condition for <name
of container>, where a security amin can setup a <name of the container>
condition using the information presented in this field." Please also expand
security admin.
** Section 3. Per the payload case:
This field contains the payload string information.
This information is useful when security rule condition is
based on the string contents of incoming or outgoing
packets.
Recommend not using the term "string" since the data model says this is binary
and many payloads are likely to be that too.
** Section 3. Per the payload case:
The name referring to the payload-groups defined
and registered in the endpoint-groups.
This sentence doesn't parse.
** Section 3. Per the voice case:
. This information can be
used to filter a caller id or receiver id in order to
prevent any exploits (or attacks) of Voice over IP (VoIP)
or Voice over Cellular Network (VoCN).
No disagreement on the possibility describe here. However, isn't filter only
one of a number of actions that could be taken. Why call out "filter" here?
** Section 3. Per the context case:
This field provide extra information for the
condition for filtering the network traffic.
Please re-phrase this as the sentence doesn't parse.
** Section 3. Per the context case:
This field contains the information obtained
from threat-feeds (e.g., Palo-Alto, or RSA-netwitness).
-- Consider if you need to name the products as this might age the document in
the future. If so, please name them consistently. "Palo-Alto" is a company,
not a product, which doesn't hyphenate their name. "RSA-netwitness" is "RSA
Netwitness".
-- Additionally, why name these two vendors, instead of the three
products/tools actually mentioned in the data model?
** Section 3. Per the context case:
This information is useful when security rule condition is
based on the existing threat reports gathered by other
sources.
Shouldn't this read, "This field is used when the security ..."
** Section 3.3. Per Figure 6, it looks like specifying the both the primary
and secondary action could be empty. Is that intended?
** Section 4.
The Policy Endpoint Group is a very important part of building User-
Construct based policies.
What are "User-Construct based policies" as opposed to just "policies"?
** Section 4.
It is assumed that the information of Endpoint Groups (e.g., User-
group, Device-group, and Location-group) such as the IP address(es)
of each member in a group are stored in the I2NSF database available
to the Security Controller,
-- What is an "I2NSF database"? This is not an architectural entity described
in RFC8329.
-- What does it mean the "information of Endpoint Groups such as xxx are stored
in the I2NSF database ..."? Isn't this information that is being sent by the
I2NSF User to the Security Controller?
-- What is the interrelationship between user-group and the url-list? The
former lists IP addresses and the latter is list of URLs. Are those IP address
hosting those URLs? From the examples in Section 8, it looks like there is no
relationship between them, but that isn't stated here.
** Section 4.1. Can a "User Group" please be defined. The definition of "This
object represents a User-Group" just repeats the name. The description of the
field names suggests they are an address range for a "user in the user group".
Where does the user information come from? From the example in Section 8, it
appears that this field groups is a means to label an IP address block.
** Section 4.3.
This object represents a location group based on either tag or other
information.
What is the "tag" reference here?
** Section 4.3. Geo-ip-ipv4 and Geo-ip-ipv6 are citing RFC8805. My
understanding of that specification is that it provides a way to bind a
geographic name to an IP address. I don't see anything in the Location object
that ties a human readable geographic label to an IP address. Is the related
geography in the Name field?
** Section 4.4.
url: This field represents the new URL added by a user to the
URL database.
-- What is user is being referenced here?
-- What is a "URL database"?
** Section 5. Even with the detailed descriptions in Section 5.1. and 5.2, it
isn't clear what the relationship is between the information in the thread-feed
and the payload-content objections. Does the thread-feed describe the
malicious activity and the payload-content is a capture of what it looks like
on the wire?
** Section 5.
OLD
The threat prevention plays an important part in the overall security
posture by reducing the attack surfaces. This information could come
from various threat feeds (i.e., sources for obtaining the threat
information).
NEW
The Threat Prevention model describes information obtained from threat feeds
(i.e., sources for obtaining the threat
information).
** Section 5.1.
Description: This is the description of the threat feed. The
description should have the clear indication of the
security attack such as attack type (e.g., APT) and file
types used (e.g., executable malware).
Editorial. I found the naming convention a bit confusing. In my experience, a
thread feed is sometimes a list of indicators of compromise (IOC) tied to a
particular threat (e.g., one feed for a list of domains names or file hashes
tied to a given threat actors). Other times, it is a series of "objects"
(IOCs, descriptions, rules) which are a collection of malicious activity, not
necessarily related, which capture one publisher's aggregated view of what
threat to watch for. This description seems to assume it is only the former.
This would be worth explaining.
** Section 5.1 and Yang threat-prevention/description. The description needs
further specification.
Information model says:
Description: This is the description of the threat feed. The
description should have the clear indication of the
security attack such as attack type (e.g., APT) and file
types used (e.g., executable malware).
Yang says:
leaf description {
type string;
description
"This represents the descriptions of a threat-feed. The
description should include information, such as type,
threat, method, and file type. Structured Threat
Information Expression (STIX) can be used for
the description of a threat.";
reference
"STIX: Structured Threat Information Expression for the
description of a threat.";
}
-- It isn't clear how this field (description) can be a "clear indication"
without providing a structured format for each of the required fields. While
STIX is mentioned, it doesn't appear to be required.
-- If STIX is preferred or suggested, please be clear on which STIX objects
should be used. Is it STIX XML or JSON?
-- Please provide a reference to STIX
-- Is the intent to represent an XML blob in the string data type here? Is it
up to the implementer to recognize free form text vs. JSON vs. XML?
** Section 5.1.
Signatures: This field contains the threat signatures of malicious
programs or activities provided by the threat-feed. The
examples of signature types are "YARA", "SURICATA", and
"SNORT" [YARA][SURICATA][SNORT].
I'm confused by this description as I can't find where in this field the
"threat signatures of malicious programs" is represented. This field appears
to be conveying an enumerated type.
** Section 5.1.
"Signatures" should be
kept carefully in a secure manner. The secure keeping of
"Signatures" can be performed by Defense in Depth (DID)
[DID] or Distributed Ledger Technology (DLT) such as
Blockchain [Bitcoin]. The details of keeping "Signatures"
securely are out of scope in this document.
-- Per the caution of keeping signature in a "secure manner"? What additional
security properties or controls is that suggesting beyond everything else in
the data model? Put in another way, what's special here?
-- What does it mean to say that "signature can be performed ..." Given that
this is out of scope, I recommend just dropping the sentence.
** Section 5.1.
With the
obtained threat signatures, the I2NSF User can deliver them to the
Security Controller.
How are these signatures being delivered to the controller? Is it with this
Yang module?
** Section 5.1.
Note that signature-set in I2NSF Capability
[I-D.ietf-i2nsf-capability-data-model] is the setting of signatures,
which means the configuration of signatures for Intrusion Prevention
System (IPS). On the other hand, signature-type in Consumer-Facing
Interface is the type of signatures (e.g., YARA signatures, SNORT
signatures, and Suricata signatures).
-- Can the text "setting of the signatures" be rephrased, as I don't understand
what it means.
-- From this text it isn't clear what link is being drawn between the
capability model and this data model.
** Section 5.2.
This object represents a custom list created for the purpose of
defining an exception to threat feeds.
Can you please clarify, what is an "exception to the threat list"? Is that
something that is on the thread list but should be ignored?
** Section 5.2
This represents the description of how the payload
content is related to a security attack.
Is the referenced "security attack" the one described it the name field? Does
this imply additional requirements for the semantics of the name field?
** Section 5.2.
Content: This contains the payload contents, which are involed in a
security attack, such as strings.
-- Typo. s/involed/involved/
-- What are "strings" in the context of the payload contents? Do you mean
"strings" as in those dumped from a malware file? Readable text extracted from
a session stream?
** Section 6. Thanks for explaining the role of NACM. Is this guidance
specific to the I2NSF interface or a generic example of using NACM? Ask
because, I didn't see anything specific to I2NSF here. Was there a WG push to
include this non-I2NSF guidance? Section 11 already says that NACM can be used.
** Section 6.
Then, the
user can simply use an account of root or admin user for the access
control for the module of the I2NSF Consumer-Facing Interface
What is the origin of these users names?
** Section 7. Typo. s/provide the YANG data model of I2NSF/provide the YANG
data model of the I2NSF/
** Section 7.
The transformation of the
information model is performed so that this YANG data model can
facilitate the efficient delivery of the control or management
messages.
This statement doesn't seem right. Per RFC3444 cited in Section 1,
informational models "are protocol neutral". That is, they are not capable of
being interoperable without translation into a data mode. It isn't about
"efficient delivery". I recommend removing this sentence.
** Section 7.
With the YANG data model of I2NSF Consumer-Facing Interface, this
document suggests use cases
Are there use cases or examples? This is a bit pedantic, but to me this data
model suggests a lot more use cases than are described in Section 8.
** YANG. identity rate-limit. I appreciate that this identity is in other
I2NSF models. How does the Security Controller know what is the associate
rate-limit threshold is?
** YANG. identity signature-type. The references for signature-yara,
signature-snort and signature-suricata are all of the form "<tool name>: <tool
name> signatures are explained". There are not references.
** YANG. identity threat-feed-type. How is this used in this YANG module?
** YANG. identity device-type.
Note that the device type of either a source
or destination can be known with the help of DHCP
Fingerprinting and the interaction between an NSF and a DHCP
server.
This behavior seems out of scope for this module as it is prescribing NSF
behavior.
** Both of these comments are related to similar questions posed in the
information model:
-- YANG. grouping user-group. How is the alignment to users done? The model
appears to represent only a label (name) to describe an IP address range, with
the possibility of MAC addresses.
-- YANG. grouping device-group. Does the ip-address represent the services
hosted on the application port, or the outbound connection the ip-address-info
will be making?
** YANG. Per the fields under "rules":
-- Does the rule name need to be unique?
-- Would there be a desire to version at the per rule basis (e.g.,
Snort/Suricata's "rev:" rule option)?
** YANG. container range-port-number.
-- what are the semantics of both the start-port-number and end-pot-number
being empty?
-- If the start-port-number is set, but the end-port-number is not, does this
assume "[start-port-number,65555]? Same question situation for a set
end-port-number, but not start-port-number?
** YANG. container ddos.
-- leaf flow-rate-threshold. The associated unit of time is not specified. Is
it flows/per second?
-- RFC9244 is an entire YANG module on conveying DoS telemetry. Are there any
additional metrics worth adding here? Is there a way to reuse this feature
rich module?
** YANG. container anti-virus. This container not adequately specified.
"The type or name of the files to be excluded by the
antivirus. This can be used to keep the known
harmless files.
If the value starts with a regular expression (e.g.,
'*.exe'), the antivirus should interpret it as a
file pattern/type to be excluded.
If the value does not start with a dot (e.g.,
'example.exe'), the antivirus should interpret it as
a file name/path to be excluded.";
-- If regular expressions are permitted, please cite which flavor regex --
POSIX? PCRE?
-- "*.exe" is not a valid regular expression (in POSIX/PCRE) to evaluate a
filename that ends with a string ".exe".
-- Per the guidance, "if the value doesn't start with a dot (e.g.,
example.exe)", the cited example in the parenthesis doesn't appear to be
demonstrating what the text is describing. Also the format described in the
line above, "*.exe" also doesn't begin with a dot.
-- The text mentions that paths can also be included? Is that restricted to a
local filesystem. What are the expected path separators? Can protocol schemes
be uses (e.g., smb://myfiles/*.exe)
** YANG. container anti-virus. Specifying malicious files to block by hash
names seems common. Did the WG consider it?
** YANG. leaf-list source-id, destination-id, user-agent. What information is
this representing? The text says "The security policy rule according to a
<insert field name>."
** YANG. device-type/device
"The device attribute that can identify a device,
including the device type (i.e., router, switch,
pc, ios, or android) and the device's owner as
well.";
-- The list of device examples doesn't seem consistent with the defined ones
defined for "base device-type" (i.e., computer, mobile-phone, etc). For
example, there is not distinction made for mobile operating systems (IOS or
Android). Likewise, there is only network-infrastructure-device (not, router,
switch)
-- How does this field capture the device owner?
** YANG. url-group.
Is there a reason that the "leaf-list url" can't be of type "uri" instead of
"string"?
** YANG. list payload-content
-- Typo. s/Desecribe/Describe/
-- How should multiple instances of the "content" field be interpreted? Does
every instance of "content" need to be somewhere in the session stream,
regardless of order, or does order matter?
-- From where in the packet or stream is this payload considered? Is it
everything after the transport layer header?
** Section 8.1. Per Figure 19:
-- The descriptive text says this example is showing the registration of new
end-points, but the <name> says "security_policy_for_blocking_sns". Where is
the blocking behavior specified?
-- The values of the <url> are supposed to be URLs. What is specified here is
not a valid URL (there is not scheme)
-- What is the relationship is being expressed between the ip addresses in
<user-group> and those in <device-group>?
-- What is the relationship among the IP addresses in <user-group>,
<device-group> and the <url-group>?
Same questions for Figure 20. Thanks for providing both an IPv4 and IPv6
example.
** Section 8.3. Typo. s/coming from from/coming from/
** Section 8.3. Typo. s/seucurity/security/
** Section 8.3.
The Source is "malicious-id". This can be a single ID or a list
of IDs, depending on how the ID are stored in the database.
How would the "malicious-id" be registered? Would that be an IP address via a
<user-group>?
** Section 8.4.
The destination is set as "web_server01".
This destination is not reflected in Figure 23.
** Section 8.4. Typo. s/nsfs/NSFs/
** Section 8.4. Typo. s/secuiy/security/
** Section 8.4.
4. The Source is all sources which send abnormal amount of packets.
How would this 1000/pps would be calculated relative to "all sources which send
abnormal traffic"? I'm keying on the way in which a distinction would be made
that traffic is abnormal.
-- is there a per source IP counter to measure 1000/pps rate?
-- is there 1000/pps rate set for the destination and traffic is dropped after
regardless of the number of sources?
What normative text should be referenced to explain how these rates are
computed?
** Section 11. Editorial.
OLD
Writing to almost any element of this YANG
module would directly impact on the configuration of NSFs
NEW
Writing to almost any element of this YANG
module would directly impact the configuration of the NSFs implementing
the security policy.
** Section 11. Per "Writing to almost any element of this YANG module would
... impact the configuration of NSFs, e.g., ... rendering useless trained
statistics or artificial intelligence models", consider something weaker such
as s/rendering useless.../reducing the efficacy of statistics or artificial
models built on historical data./
** Idnits output said:
==[ annotated snip from idnits ]==
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
[Roman] Action: replace RFC793 with RFC9293.
** Downref: Normative reference to an Informational RFC: RFC 8329
[Roman] Action: RFC8329 doesn't need to be normative.
** Downref: Normative reference to an Informational RFC: RFC 8805
[Roman] Action: Check my comments on how RFC8805. If this draft stays, it will
be called out in IETF LC (and no action for the authors).
== Outdated reference: draft-ietf-tcpm-rfc793bis has been published as RFC
9293
[Roman] Action: replace with RFC9293.
-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-tcpm-rfc793bis'
[Roman] Action: replace with RFC9293.
==[ end snip ]==
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
