Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-consumer-facing-interface-dm-24
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Mon, 09 January 2023 20:32 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 51861C19E0FC for <i2nsf@ietfa.amsl.com>; Mon, 9 Jan 2023 12:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.086
X-Spam-Level:
X-Spam-Status: No, score=-0.086 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, URI_DOTEDU=1.999] autolearn=no 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 HrNctufsjKFm for <i2nsf@ietfa.amsl.com>; Mon, 9 Jan 2023 12:32:02 -0800 (PST)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 6E759C19E0F8 for <i2nsf@ietf.org>; Mon, 9 Jan 2023 12:32:02 -0800 (PST)
Received: by mail-pl1-x62b.google.com with SMTP id 17so10889836pll.0 for <i2nsf@ietf.org>; Mon, 09 Jan 2023 12:32:02 -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=77EvKCTjIJh+at0yq3gYrK5icLL8dHnySxEtFKJOKM8=; b=co1spDCYHeSjaU/AFyPUlVZOINsISXnJ6q5VFQcoWplhdKxvop70mhwqlNPBCrWI4Q 8xChNM+D6jvETdRUGVOnuA97nFrfbeZG24kujk6XboqWYcnnZ/4smPieAo18J3/op9nZ yuw/5d9HBLytGUH/xTCJ/ZFXa4+JtKimB2RQb++N9jDWT6Gwyy1FFGrRS656eNIOmI7X GbT/eF9BhKXtMKO1IAo5ncSPOBXkiEwcqrz8utb8uDp7j/RkytuPFuAJ3dv1M2KFywIN Iymoug+e/lP3hDMRIEuoQ3ea5MsMKfeh9Yh6ob3xKVNYUaoxjP5Jqxg/oxwEhJl+poiM BVyA==
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=77EvKCTjIJh+at0yq3gYrK5icLL8dHnySxEtFKJOKM8=; b=HLHxKNUil24MrL1/A/Jlr1Rah2CUvEX0ysGtw5fdb3PEe9MGA1Ojk6NAnUc7tHy4bM gWnr5gLvd27Nrwlhzie2bBvk7UVCeCmXbdkLjwbHZLmOYjfOWwwUsctnuCVKq1Tlpfzp euLZnSAEPln+teTqyCP8gmuOtRJoOgKkwnO3x9UWsBMX3jZ5sGyImZjGpYt7JfJtIEzl uhoY1IbmdnMfH/X8TWfRYW6B9gwRdHHKlvuS+kdrr3Q3XOLdQqe0sgJnUkFNDOxthjfK lwhncIpI8UQoCngwkrfSrTrQOqdWVrj1xHHvIt1qFDMoBOEqJM0G+KlKR07n+FmfqRXV Fgpg==
X-Gm-Message-State: AFqh2kpxVSIPqYSIcuhtpd+yciHFi2pKnyK54lxSvg3aMwuDU7DHsnnh Qa/it7Mk4wfGhJstPUk11vpTp1Y3R8lml71mJWkitqOKIf5FCw==
X-Google-Smtp-Source: AMrXdXu70VxTDyj3hX0N5W5EkIyVgQdgILinEUTOnTPZiL291v0Ff4AKLAOEJn3gPMZkMuEogP9U198rXPAIDhCK+AY=
X-Received: by 2002:a17:903:2442:b0:191:ffe7:5ed7 with SMTP id l2-20020a170903244200b00191ffe75ed7mr3975950pls.38.1673296321705; Mon, 09 Jan 2023 12:32:01 -0800 (PST)
MIME-Version: 1.0
References: <BN2P110MB110791C0BBA0EA630B6E4BDADCFE9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB110791C0BBA0EA630B6E4BDADCFE9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Mon, 09 Jan 2023 15:31:50 -0500
Message-ID: <CAPK2DezgovrCFy827EMcdRO5Q8rsGN+a6NFUeuU4z=OH7mnk7w@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>, Patrick Lingga <patricklink888@gmail.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dbfd1505f1daa8e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/0O8N_ZMbNCS_pj8CPYSgqs_ZgUs>
Subject: Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-consumer-facing-interface-dm-24
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: Mon, 09 Jan 2023 20:32:06 -0000
Hi Roman, Thanks for your review. Patrick and I will revise this CFI draft according to your 2nd review comments. Thanks. Best Regards, Paul 2023년 1월 9일 (월) 오전 11:16, Roman Danyliw <rdd@cert.org>님이 작성: > Hi! > > I performed an AD review on > draft-ietf-i2nsf-consumer-facing-interface-dm-23 ( > https://mailarchive.ietf.org/arch/msg/i2nsf/VHbdIrvHo5EjvcyQf5v9fjeVy1w/). > The authors produced at -24 in response. Thank you! > > To make it easier to track the remaining issues, I've created this new > thread. The following is feedback on the new text introduced in -24. > > ** Section 4.3. Location-group > > Thank you for the clarifying language in this section in -24. Per the > addition of the country, region and city fields please add normative > references for ISO3166-1 and ISO3166-2: > > [-23] 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? > > [-24] The YANG definition of "location-group" still cites RFC8805. With > the addition of the country, region and city fields, in what way is RFC8805 > still used? It seems like with the current fields there is a complete > mechanism to map human readable names to IP addresses (and then I don't see > a reliance on RFC8805); or all of these fields could be dropped in favor of > a single uri field that points to a RFC8805 file. Perhaps a hybrid would > be possible too. > > ** Section 5/Thread Feeds and IOC > > Thanks for the changes which resulted in "thread-feed-list/ioc" in -24. > > -- STIX, MISP and OpenIOC need to be normative references > > -- For [MISP] and [OpenIOC], if the best reference possible is in github, > please at least include a branch or tag. > > -- Conflict of interest as I am one of the document's co-author's: > _consider_ if you also want to include RFC8727 (JSON binding of IODEF). > > ** YANG. Per the fields under "rules": > > The revised text says: > > leaf name { > type string; > description > "This represents the name for a rule. The name must be > unique to represent different rules."; > } > > -- Should the "unique" constraint per Section 7.8.3 of RFC7950 be applied > here? > > -- Editorial. Is it that the "name must be unique to represent different > rules" or that "each rule name must be unique"? > > ** YANG. container anti-virus. > > [feedback for -24] > leaf-list exception-files { > type string; > description > "The type or name of the files to be excluded by the > antivirus. This can be used to keep the known > harmless files. Absolute paths are filenames/paths > to be excluded and relative ones are interpreted as > globs. Note that the file names can be hash names > to specify malicious files to block."; > reference > "GLOB: Linux Programmer's Manual - GLOB"; > > The above text is new in -24 to address feedback in -23. This new text > > -- The semantics of the "hash name" idea would benefit from further > specification. How does one know if one has a hash name as opposed to a > file name? How does one know which hash algorithm was used? Why are the > block values (i.e., the hash files) in the same leaf-list as those being > explicitly allowed (i.e., block values are being shared in an > "exception-file" list) > > -- [GLOB] needs to be a normative reference. Please also find a more > stable reference than https://man7.org/linux/man-pages/man7/glob.7.html > > > ** YANG. list payload-content > > Thanks for added the additional guidance on handling multiple content > fields and the support for depth and starting point. > > [-24] Both offset and distance limit themselves to a range of "0..65535". > If dealing with packet header information only, I can see this as being > adequate. I'm imagining a hypothetical multi-MB network stream. Should > there be flexibility to search past 65K? > > > ** Section 7.1 (was: Section 8.1). Per Figure 20: > > Thanks for the changes in -24 to address prior feedback on Figure 19 and > 20. > > [-24] The following text was added to Figure 20: > > <voice-group> > <name>malicious-id-v6</name> > <sip-id>sip:david@[2001:db8:2ef0::32b7]</sip-id> > </voice-group> > > > Use of the brackets around the IP address ("sip:david@[2001:db8:2ef0::32b7]") > is not a valid address. It should be "sip:david@2001:db8:2ef0::32b7". > > ** Section 7.4 (was: Section 8.4) > > [Per -24] > Thanks for explaining how the rates are computed. It appears that in this > section the following text was added: > > Note that tcpdump can be used to capture packets per host as source > [tcpdump]. tcpdump can limit capture to only packets related to a > specific host (e.g., source) by using the host filter. > > No disagreement on the capabilities of tcpdump. However, I'm having > trouble understanding the role it plays in the example. Is tcpdump being > invoked If so, how is that evident from the example? > > Thanks, > Roman > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
- [I2nsf] AD review follow-up on draft-ietf-i2nsf-c… Roman Danyliw
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Mr. Jaehoon Paul Jeong