Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 30 December 2020 16:10 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 C5CAD3A08D4; Wed, 30 Dec 2020 08:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.175
X-Spam-Level:
X-Spam-Status: No, score=0.175 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, HK_NAME_FM_MR_MRS=0.263, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20MeLPx9m6bK; Wed, 30 Dec 2020 08:10:19 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AA83A08AF; Wed, 30 Dec 2020 08:10:17 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id 23so38562208lfg.10; Wed, 30 Dec 2020 08:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azo0AxjD967Q15lkqh3P4ronsXTj+nDfAoUMQBvCcPo=; b=P4VpnntRCRB1oFCnoljHYyy+Ch4Nc0/hvBiAm9y0QV9Rq1UpU9PLESqAJM3tVt9Z1p FX+9i6vWoXyfbTQvseZAgITzHOsuMXgaj9c5I2wwNeSLdC263RoacGoEWF9bToIvhMtq WLWqhx+Rsm/QDLX7xwo0+cyZYP0Z2Pz7JnVfJkC6DVrIjEKhyNKCas0/07TaPsOqJUlD sErduCKBvYZlzokcfFIJ+28YYwHwoeUe0+e8MtYsxXaR6zMZZ8jN9HCl1s4islAdlgLg uqXiEgZCiUvMltaihv2fuCAHKUHnYwdSh0ZwTAFUtlLo6+OUFmE5CtUCC8AdbXvk8iL6 bBpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azo0AxjD967Q15lkqh3P4ronsXTj+nDfAoUMQBvCcPo=; b=GVHlU+HqqNiRmoPF4jLt4DzrhJ/71SBTxk5rPodTUwr7baJu9YAtpOLBHoR/S5xQV7 Jk7w0zwsvntNq5TByfhh4Cj7KDMtC8MnJ5KnrpVFDriXXYnpV1m6Dr377RQx5fAJlDMo fxqhdKujE8mwwZtAy4MvHAn7/cNJftFR7NqCR5oNI6Rxs6XpuEojF1x9pWXpyiBeu87z MlH3mum+3jSfBXMPVNWidDNgNkUZ0wAP0JD1pvQwgvpgiVhXFZEdqnE2naINjG6G7WEw N41+WrdJdNrOztmGF/WQgYRrNgdQcYySOAeg2uzz5vUncevC1HtSFbbcqnwRDRs+3N5b MzGQ==
X-Gm-Message-State: AOAM531l1cUlrLtWeK/Lf1HPq2jXYgnvId6Q67eJcFIZf6MC75pyHgvC zLAumTUXWtl/KnxzBTIVmzBgiHdv076NvLym7jo=
X-Google-Smtp-Source: ABdhPJw0brMuFZqoDRtbUdy9ougySHrBqjjuQBapGGcfkUlUHwxkBKJhDK3700vV7q/IFXrGrskHdGLj3tdiemSlkPM=
X-Received: by 2002:ac2:5c08:: with SMTP id r8mr23143158lfp.12.1609344614148; Wed, 30 Dec 2020 08:10:14 -0800 (PST)
MIME-Version: 1.0
References: <160083793582.31494.12459352773950908237@ietfa.amsl.com>
In-Reply-To: <160083793582.31494.12459352773950908237@ietfa.amsl.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 31 Dec 2020 01:09:37 +0900
Message-ID: <CAPK2Dey8t6oHWRmj5J=LxoLc2K__OvdO22HG350kSUTbBVCMAA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Éric Vyncke <evyncke@cisco.com>, Erik Kline <ek.ietf@gmail.com>, Barry Leiba <barryleiba@computer.org>, Alvaro Retana <aretana.ietf@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Murray Kucherawy <superuser@gmail.com>, Michael Scharf <michael.scharf@hs-esslingen.de>
Cc: The IESG <iesg@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/mixed; boundary="0000000000000c75f905b7b0be13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/hQP4Ms_FpzImoiFtt9F6sM21ebU>
Subject: Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 30 Dec 2020 16:10:26 -0000
Hi Benjamin, Éric, Erik, Murray, Barry, Alvaro, Magnus, and Michael, I have reflected your comments on the I2NSF Capability YANG Data Model Draft with the following revision: https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-14 I attach a revision letter to explain how I have addressed your comments on the revised draft. If you have further questions and comments, please let me know. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php> On Wed, Sep 23, 2020 at 2:12 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-i2nsf-capability-data-model-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There are many elements of the YANG module whose semantics seem > underspecified to me. I noted quite a few in the COMMENT section, and I > hope that those aspects of my comments are clear (as it would be > substantial effort to partition the comments and move the questions of > unclear semantics into the discuss section), but I am happy to assist in > the classification if needed. > > I think that the data nodes of this module as written are probably not > reflecting the intent -- it seems that the only elements of the 'nsf' > list are the string nsf-name; there is no "uses nsf-capabilities" stanza > to bring in the grouping that contains all the interesting parts. > Specifically, I do not see how the tree diagram reflects the current > module. > > I'm surprised to not see any discussion of privacy considerations -- > some of the features that we define capability indicators for are highly > sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE > audio to identify individuals, web filtering) that inherently require > access to individuals' private data. Not only should we note that > private information is made accessible in this manner, but we should > also reiterate that the nodes/entities given access to this data need to > be tightly secured and monitored, to prevent leakage or other > unauthorized disclosure of private data. > > I also think we need to mention that authentication and proper > authorization will be needed to register as an NSF providing these > capabilities. > > The examples do not seem to conform to the current module structure > (e.g., exact-fourth-layer-port-num and range-fourth-layer-port-num). > > I worry a little bit that even the structure of the tree risks "imposing > functional requirements or constraints" upon NSF developers (in the > words of the framework). How would, for example, SCTP capabilities be > indicated, let alone QUIC? (With an augmentation, clearly, but is that > undue burden?) While the classification into ingress/egress/log is > natural, it also may be found limiting; consider, for example, a setup > involving port mirroring -- is that an ingress action or egress? If > traffic is dropped as part of a different ingress filtering capability, > does it still get sent to the port mirror? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It's a little weird to have the data model be up for review when the > information model is still in AD Evaluation, but probably not > catastrophic. > > Section 1 > > As the industry becomes more sophisticated and network devices (e.g., > Internet of Things, Self-driving vehicles, and smartphone using Voice > over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a > > nit: missing verb for "network devices". > > registration interface [RFC8329]. With the capabilities of those > security devices maintained centrally, those security devices can be > > nit: I'd probably say that it's the knowledge of those capabilities or a > database of those capabilities that is maintained centrally. > > o Definition for condition capabilities of generic network security > functions. > > o Definition for condition capabilities of advanced network security > functions. > > [I'm not yet sure at this point that I understand the need for > distinguishing between generic and advanced network security functions > ... won't the boundary between those categories evolve over time?] > > Section 3 > > Framework. As shown in this figure, an NSF Developer's Management > System can register NSFs and the capabilities that the network > security device can support. To register NSFs in this way, the > > nit: s/device/devices/ > > That is, this Registration Interface uses the YANG module described > in this document to describe the capability of a network security > function that is registered with the Security Controller. With the > > nit: "capabilities" plural probably makes more sense in this context. > > capabilities of those network security devices maintained centrally, > > [similar comment about "maintained centrally" as above] > > Note that the NSF-Facing Interface [RFC8329] is used to configure the > security policy rules of the generic network security functions, and > The configuration of advanced security functions over the NSF-Facing > > nit: lowercase 'l' in "the". > > o If a network administrator wants to block malicious users for IPv6 > traffic, he sends a security policy rule to block the users to the > Network Operator Management System using the I2NSF User (i.e., web > application). > > I'm not entirely sure why only the IPv6 traffic of a malicious user > would be blocked. > > Also, nit/edtiorial-level, "using the I2NSF Consumer-Facing Interface" > would read more naturally to me than "using the I2NSF User". > > Section 4.1 > > The NSF capabilities in the tree include time capabilities, event > capabilities, condition capabilities, action capabilities, resolution > strategy capabilities, and default action capabilities. Those > > In Section 1 we had a similar list that used "general capabilities" > compared to "time capabilities" here. Is this distinction intentional? > (Given that the tree diagram and actual module use the "time" variant, > it's not entirely clear what the "general" variant would be...) > > repeated time like day, week, or month. See Section 3.4.6 > (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more > information about the time-based condition (e.g., time period) in the > capability algebra. > > Following the reference, it seems to just use time-based condition as an > example of an arbitrary condition -- I don't see any specific discussion > that mentions considerations specific to time-based conditions. > > event and system alarm. See Section 3.1 (Design Principles and ECA > Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more > information about the event in the ECA policy model. > > (side note) I followed the reference and was surprised that I couldn't > find any specific indication that an Event of '{}' evaluates to true (at > least, I assume it does). > > advanced network security functions. The condition capabilities of > generic network security functions are defined as IPv4 capability, > IPv6 capability, TCP capability, UDP capability, and ICMP capability. > The condition capabilities of advanced network security functions are > defined as anti-virus capability, anti-DDoS capability, Intrusion > Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE > capability. See Section 3.1 (Design Principles and ECA Policy Model > > At this point in the document I don't understand why VoIP and VoLTE are > fit to group together into a single capability. Is the condition clause > just looking at a phone number and not other aspects of the call? > > the ingress and egress actions. In addition, see Section 9.1 (Flow- > Based NSF Capability Characterization) for more information about > logging at NSFs. > > [this is section 9.1 of [I-D.ietf-i2nsf-capability] still, though the > additional discussion on logging is fairly minimal.] > > Section 5 > > In general there seems to be a lot of content in "reference" stanzas > that to my non-expert eye would have been more appropriate in the > "description" stanza. > > identity event { > description > "Base identity for I2NSF policy events."; > > I note that draft-ietf-i2nsf-capability uses the phrase "I2NSF Event", > "I2NSF Policy", and "I2NSF Policy Rule" but not "I2NSF policy event", > which makes me suspect that this is an editorial error. > (draft-ietf-i2nsf-nsf-monitoring-data-model doesn't use "I2NSF policy > event", either.) > > identity hardware-alarm { > base system-alarm-capability; > description > "Identity for hardware alarm"; > > How do I decide when to use hardware-alarm vs, e.g., memory-alarm or > cpu-alarm? > > identity condition { > description > "Base identity for policy conditions"; > } > > Similarly to for events, draft-ietf-i2nsf-capability seems to only use > "I2NSF Condition", not "I2NSF policy condition". In this case, the use > of "policy" does not feel as out of place to me as it did for events, > though. > > identity context-capability { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - The operating context of an NSF."; > } > > I don't see the "the operating context of an NSF" in the referenced > draft, and in fact "context" is not used as a technical term at all. > (Similarly for "identity access-control-list"'s "The context of an NSF".) > > identity application-layer-filter { > base context-capability; > description > "Identity for application-layer-filter condition capability"; > > This seems likely to be highly dependent on what exactly the application > layer is! I'm not sure that such a generic capability will be useful in > practice. > > identity user { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A user in an application of a policy rule > to be applied by an NSF. > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a user (e.g., the > corresponding IP address) in an NSF."; > > I'm fairly concerned about implying that it's safe and effective to use > an IP address to identify a user. While this works often enough that we > have stringent privacy considerations regarding storage/conveyance of IP > addresses in logs, in the context of automated network (security) > functions the risk of collatoral damage seems quite large. > > identity group { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A group (i.e., a set of users) in an > application of a policy rule to be applied by an NSF. > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a group (e.g., the > corresponding IP address) in an NSF."; > > An IP address can identify a group, too? > > identity geography { > base context-capability; > description > "Identity for geography condition capability"; > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A group (i.e., a set of users) in an > application of a policy rule to be applied by an NSF. > > I'm not sure what's going on here -- why are groups relevant for > geography? > > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a geographical location > i.e., geolocation (e.g., the corresponding IP address) in > an NSF. > > RFC 8519 doesn't itself talk about geographic location. > > RFC 8805: A Format for Self-Published IP Geolocation Feeds > - An IP address with geolocation information."; > > I question the utility of self-published geolocation information for the > application of (security) policy -- my understanding is that this > reference was intended to avoid (among other things) the issue where the > IETF meeting network gets geolocated to the location of the previous > IETF meeting for the first couple days of the week, which is a > convenience/performance application, not a security one. > > identity ipv4-capability { > base condition; > description > "Identity for IPv4 condition capability"; > > This identity is used as a base identity for other capabilities; is it > intended to also be used as a standalone capability? If not, I suggest > including "base" in the description. If so, please clarify what the > semantics are. > > identity ipv4-id { > base ipv4-capability; > description > "Identity for identification condition capability"; > > (side note) I'd suggest making some mention of "fragment" or > "fragmentation" here, in light of RFC 6864. > > identity ipv6-capability { > base condition; > description > "Identity for IPv6 condition capabilities"; > > [same as for ipv4-capability] > > identity exact-ipv6-flow-label { > [...] > reference > "RFC 8200: Internet Protocol, Version 6 (IPv6) > Specification - Flow Label"; > > RFC 6437 seems relevant as well. > (Similarly for range-ipv6-flow-label.) > > identity tcp-capability { > base condition; > description > "Identity for TCP condition capabilities"; > > [same as for ipv4-capability] > > identity exact-tcp-seq-num { > base tcp-capability; > description > "Identity for exact-match TCP sequence number condition > capability"; > > It's not entirely clear to me why there is need to match on the TCP > sequence number, which per RFC 6528 should be effectively random from > the vantage of a stateless NSF device. > > identity exact-tcp-ack-num { > base tcp-capability; > description > "Identity for exact-match TCP acknowledgement number condition > capability"; > > Likewise, the ack number should be effectively random to a stateless > NSF. > > identity udp-capability { > base condition; > description > "Identity for UDP condition capabilities"; > > [same as for ipv4-capability] > > identity icmp-capability { > base condition; > description > "Identity for ICMP condition capability"; > > [ditto] > > identity icmpv6-capability { > base condition; > description > "Identity for ICMPv6 condition capability"; > > [ditto] > > identity url-capability { > base condition; > description > "Identity for URL condition capability"; > > [ditto] > > identity pre-defined { > base url-capability; > description > "Identity for URL pre-defined condition capability"; > } > > identity user-defined { > base url-capability; > description > "Identity for URL user-defined condition capability"; > } > > With such sparse description and no reference, I have no idea what > functionality this is supposed to indicate. > > identity log-action-capability { > description > "Identity for log-action capability"; > > [same as for ipv4-capability] > > identity rule-log { > base log-action-capability; > description > "Identity for rule log log-action capability"; > } > > identity session-log { > base log-action-capability; > description > "Identity for session log log-action capability"; > } > > [same as for pre-defined/user-defined] > > identity egress-action-capability { > description > "Base identity for egress-action capability"; > > Why does egress-action-capability get described as a "base identity" but > ingress-action-capability and default-action-capability do not? > > identity tunnel-encapsulation { > base egress-action-capability; > description > "Identity for tunnel encapsulation action capability"; > > Given that there is more than one tunneling technology available (within > the IETF, even!), it's not really clear that this capability will be > useful. If a node that only does IPsec wants to talk to a node that > only does VXLAN, there's not going to be much tunneling going on. > > identity voip-volte-capability { > [...] > reference > "RFC 3261: SIP: Session Initiation Protocol > RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF VoIP/VoLTE security service > capability"; > > RFC 8329 doesn't talk about "voice" or "VoLTE" at all. > > identity exception-application { > [...] > reference > "RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF Anti-Virus Exception Application > capability"; > > RFC 8329 doesn't talk about "Anti-Virus Exception" at all (and it's not > a term I've encountered previously, so with no other reference I have > no idea what it's supposed to mean). > (Similarly for exception-signature.) > > identity voice-id { > base voip-volte-capability; > description > "Identity for advanced NSF VoIP/VoLTE Voice-ID capability. > This can be used for an extension point for VoIP/VoLTE > Voice-ID as an advanced NSF."; > > It sounds like this "voice-ID" is doing voiceprint analysis to identify > humans, which would have rather significant implications for the privacy > considerations of the system. > > reference > "RFC 3261: SIP: Session Initiation Protocol > RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF VoIP/VoLTE Security Service > capability"; > > [still no voice/VoLTE in 8329; I'm probably not going to catch all of > these] > > container generic-nsf-capabilities { > description > "Conditions capabilities. > If a network security function has the condition > capabilities, the network security function > supports rule execution according to conditions of > IPv4, IPv6, TCP, UDP, ICMP, ICMPv6, and payload."; > > nit: the "and" implies that an NSF has to support all of those if any > condition capability is present, which I don't think is the intent. > > description > "Default action capabilities. > A default action is used to execute I2NSF policy rules > when no rule matches a packet. The default action is > defined as pass, drop, alert, or mirror."; > > Does "alert" setill let the packet pass, or drop it? > > Section 7 > > "ietf-i2nsf-capability" is not a data node; it's the module name. (That > said, I don't really disagree with the assessment that all the nodes in > the module are sensitive, for the listed reasons.) > > Also, I believe it's conventionally assumed that nodes sensitive for > write are also sensitive for read, and don't need to be listed again. > > Section 8.1 > > RFCs 3444 and 8431 do not seem to be referenced anywhere in the document. > > RFCs 3849 and 5737 may not need to be normative (we use the reserved > addresses for documentation but the reader doesn't need to rely on that > per se). > > Appendix A.3 > > The figure lists only "user-defined" as an advanced capability but the > prose claims http and https inspection. > > Appendix A.5 > > We don't seem to use the address of the NSF anywhere, so there doesn't > seem to be need to state what its address is assumed to be. (This would > also render the RFC 5737 and RFC 3849 references unused.) > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >
- [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2… Benjamin Kaduk via Datatracker
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Linda Dunbar
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Benjamin Kaduk's Discuss on draft-iet… Mr. Jaehoon Paul Jeong