Subject: Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 31 Dec 2020 01:09:37 +0900

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: [email-masked], [email-masked]
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 <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>