Re: [I2nsf] AD Review of draft-ietf-i2nsf-consumer-facing-interface-dm-23
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 01 December 2022 14:35 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 97D79C14F6E7 for <i2nsf@ietfa.amsl.com>; Thu, 1 Dec 2022 06:35:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv3y_TmUpZr3 for <i2nsf@ietfa.amsl.com>; Thu, 1 Dec 2022 06:35:29 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FD0C14F718 for <i2nsf@ietf.org>; Thu, 1 Dec 2022 06:35:29 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id 82so1864256pgc.0 for <i2nsf@ietf.org>; Thu, 01 Dec 2022 06:35:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4DeozklfGvuFWqwXUvqv7rif6kxVhEbZV3mXtxTQWN4=; b=gLCoicfpEOLpHQSoG1T3DDPY6JT9kM/suKFFAftKwipGpBPOACO4w8K8lmPngihsId CDZP+R1NhGtuNlW+jcvAnNlsIWlZTn3p6AL15NZnEwpSxaEZUgoID30lcOloxnSlFaaq xBOADi9i9liZa19Kf+49+LHL2bnNZJRlQdA21WKmFmjWCeM98cUPmRMT1wgmayyGcnef YOyzeIG6bvKHRbiFGtn4Ea5F4WslNOcLGmaS9p6E9EoVqRvSlYhiOf7DkFa+QRG2KmBo WBLUy9E9XNcnrAO3P+w0kIVAq0ClxKTqxJrnOWyUj3sl2+eTlnM4pqyQ0MBWdygXc6lC LsFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4DeozklfGvuFWqwXUvqv7rif6kxVhEbZV3mXtxTQWN4=; b=JsRZEFoVvxV65jxHVkh3w7nDRmLRWxA/g0Vj00rEl/SOoHpmJl16MmNwkudVfB2I6i PnVVhsYltORXRWzwxZapSLhn7sVXq+txvTqzFD+ytE5uLYu/iKdW+h3XlqYJ3bz9h565 l3SIN8YnM5qAxzX8sw5T50bbHwZH/0enUQ3xa9RWMo3EWq5TA1hTXxGHUqbYx6AzRAYU k1/UJ/6iEW2Q3aQ8c0wmIVzGbgpVCMnlHyVBg1VqKhWlqsMvuVkU90iCkHGcadqSxgXe XcAh0/C+tq8Ok4YhFa4lhoEjV0aXZvxUPsd5a73LbK/kc5FVO4q5FfWVhGM9RoKtr/Gl xbjg==
X-Gm-Message-State: ANoB5pm7RtaJyMRPdrqBhbasszzIK5BcE5t9IoJmYbZ7r4c3woFs+PfE 2R2bJLzWuWkAFVaiAF7r1z2wrLwhXaZ5msHoqNw=
X-Google-Smtp-Source: AA0mqf6QjweicXepiuMBjGdXEOCC5x0y+BSr4PFGl8v1K5n7XWzed9HTJ5dF0PoS5T+OvC4Vvzlvw6Uae5MjvqCIIn8=
X-Received: by 2002:a63:902:0:b0:46e:9bb2:f0f7 with SMTP id 2-20020a630902000000b0046e9bb2f0f7mr42266257pgj.203.1669905327463; Thu, 01 Dec 2022 06:35:27 -0800 (PST)
MIME-Version: 1.0
References: <BN2P110MB1107459FA89A847E027ADC17DC2E9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAPK2DexArzpzkJi2YTQzCRyMXgyOttNvNyY3EW=1OHSswRddRQ@mail.gmail.com>
In-Reply-To: <CAPK2DexArzpzkJi2YTQzCRyMXgyOttNvNyY3EW=1OHSswRddRQ@mail.gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 01 Dec 2022 23:34:50 +0900
Message-ID: <CAPK2Dewz5bUT==1GvPhDSo42vGfVrBiB2cwbzLV38p44oYEH6g@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, Patrick Lingga <patricklink888@gmail.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000da234805eec521a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/9rkuXff0GBDTFFEueED3tHtTGLE>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-consumer-facing-interface-dm-23
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 01 Dec 2022 14:35:31 -0000
Hi Roman, If you are satisfied with this revision, could you put this Consumer-Facing Interface draft into the IESG telechat agenda? Thanks. Best Regards, Paul On Tue, Nov 8, 2022 at 5:45 PM Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Roman, > Here is the revision of Consumer-Facing Interface YANG Data Model: > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-24 > > Patrick and I have addressed all your comments. > I attach the revision letter. > > Thanks. > > Best Regards, > Paul > > On Mon, Oct 24, 2022 at 3:03 AM Roman Danyliw <rdd@cert.org> wrote: > >> 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 >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >> >
- [I2nsf] AD Review of draft-ietf-i2nsf-consumer-fa… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Roman Danyliw
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD Review of draft-ietf-i2nsf-consume… Mr. Jaehoon Paul Jeong