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

[Linda Dunbar <[e-mail]>]

Ben,

Thank you very much for the detailed comments.

As a co-chair, I just want to address your comments on "“not see any discussion of privacy considerations”.  The draft authors will address your detailed comments & suggestions on the document.

There are suite of Data Models from I2NSF WG. All of them are branch out from the I2NSF Framework RFC8329.  The Security and privacy description from RFC 8329 are applicable to all of them. RFC8329 states that
      The mechanisms adopted within the
      solution space must include proper secure communication channels that
      are carefully specified for carrying the controlling and monitoring
      information between the NSFs and their management entity or entities.

The Section 4 of RFC 8329 specifies the Threats Associated with Externally Provided NSFs.

Therefore, the WG doesn’t think it is necessary to repeat in every Data Model draft of the Security and Privacy described in the I2NSF framework RFC8329.

Best Regards,

Linda Dunbar


-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]>
Sent: Wednesday, September 23, 2020 12:12 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Linda Dunbar <[e-mail]>; [e-mail]
Subject: Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&amp;sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&amp;sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3D&amp;reserved=0



----------------------------------------------------------------------
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.)