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:47 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 1B3BAC14CE43 for <i2nsf@ietfa.amsl.com>; Thu, 1 Dec 2022 06:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.084
X-Spam-Level:
X-Spam-Status: No, score=-7.084 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_HI=-5, 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_BLOCKED=0.001, 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 O9RDydgHNjix for <i2nsf@ietfa.amsl.com>; Thu, 1 Dec 2022 06:47:47 -0800 (PST)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 CD4F7C14CE42 for <i2nsf@ietf.org>; Thu, 1 Dec 2022 06:47:47 -0800 (PST)
Received: by mail-pj1-x1030.google.com with SMTP id cm20so2076524pjb.1 for <i2nsf@ietf.org>; Thu, 01 Dec 2022 06:47:47 -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=0YBZxCWZG84mPNfL21cVEKBpVcPiMCIcuAJDrfgA4OU=; b=b/wD7Zl3nEEM9K6gyesQBd7dGCtQ1and4zDkEwr2y1bWc8LZQ/exp6j7W4v3JaFCZ8 Hjqf0vg5EmuwO5sm9YctHzxBrpFNGFvzvb4LvXR9TmNP7U8RiD2iAG15zqS/kJa6lAie iTveLbNNvQ/EmUhrWmvQom4l2Rdx0CJUJ2Knw3MZH9FhtoQInxzhsSKKkaIWo7SDOqi8 r60Z25QJ7/5mhY3oHXcu/n1CInX4sK+RPzsutYZzj940dUG+rfS4QLsiUEOCVUaQUr8P kCAAHoZ2onmZ2H7enNJXCWkZcSx5Ckgs12zzHo7gQ1HPmmSaxKcuh9CY3u31mwgjDg96 pmZQ==
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=0YBZxCWZG84mPNfL21cVEKBpVcPiMCIcuAJDrfgA4OU=; b=qKlfi1VG6YDDhFeZBY1c7dSNLTn8HOml7K0U+U0+2BmSewEZtvw55u12Ws+7QJaqPg f5vo5rTRikXC8FbGANlj4gf3ywh3ZtJ0MLDTX0cPlGPEfN2ay7b2vM6G9JoGFNwcXccJ YZvy3cIM8s0onkecwmjTP0i6dajHv/zpbqzwAeMXximHynZM9P/xwdtoJivelKIgCHLP XYjAGAyvCuZPwANPT/5fhF7CBT3gfQLKm3eZU6I6Q9rHrA94fWZ6p8aH9MG1AaHjNoaV hd3SVV+m1WHEXh6qkbKGmWT5hjHpFs5E31zPDpDaFJfP1qys5kY8h6MIIaruBZ6uA1L0 Z9LQ==
X-Gm-Message-State: ANoB5pml18Trl+fTBYwjF1luvh5LhCQ125rwrt1Xxe+2YoC5csajm/B1 c6awphHCPTuAwajDAQkvEgQLJg1QENDnLw60FUk=
X-Google-Smtp-Source: AA0mqf7Nwkhj1lGIjLQlvmvoihVe0pPkxAQZbvEovjmy6TRe8JE4L6qKi9UzSLJ8mj23WRfTGzYtw8Vbr5Ahsv0S7dk=
X-Received: by 2002:a17:902:ef44:b0:189:6793:644f with SMTP id e4-20020a170902ef4400b001896793644fmr31578524plx.38.1669906066894; Thu, 01 Dec 2022 06:47:46 -0800 (PST)
MIME-Version: 1.0
References: <BN2P110MB1107459FA89A847E027ADC17DC2E9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAPK2DexArzpzkJi2YTQzCRyMXgyOttNvNyY3EW=1OHSswRddRQ@mail.gmail.com> <CAPK2Dewz5bUT==1GvPhDSo42vGfVrBiB2cwbzLV38p44oYEH6g@mail.gmail.com> <BN2P110MB1107DB6FD3DC32CEACEA0356DC149@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB1107DB6FD3DC32CEACEA0356DC149@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 01 Dec 2022 23:47:10 +0900
Message-ID: <CAPK2DewYETUKyMvwh45w6GaVa2kqbNuiG4R41m74rxtLVK-5ZA@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="000000000000ecf39205eec54dc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/UteyZaEQrGhJxWYeBvxvwIGJahk>
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:47:50 -0000
Roman, I see. I hope these two drafts will be reviewed by the IESG by the end of this year. Thanks for your help. Best Regards, Paul On Thu, Dec 1, 2022 at 11:42 PM Roman Danyliw <rdd@cert.org> wrote: > Hi Paul, > > > > With the US Thanksgiving holiday last week and a full telechat this week I > have not yet had time to look at either this or the registration document. > > > > Regards, > > Roman > > > > *From:* I2nsf <i2nsf-bounces@ietf.org> *On Behalf Of * Mr. Jaehoon Paul > Jeong > *Sent:* Thursday, December 1, 2022 9:35 AM > *To:* Roman Danyliw <rdd@cert.org> > *Cc:* i2nsf@ietf.org; skku-iotlab-members < > skku-iotlab-members@googlegroups.com>; Patrick Lingga < > patricklink888@gmail.com>; Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-consumer-facing-interface-dm-23 > > > > 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