I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-15

Summary: Has 4 DISCUSSes. Needs 5 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2020-09-22 for -12)
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 (2020-09-22 for -12)
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.)

Erik Kline Discuss

Discuss (2020-09-22 for -12)
[ general ]

* At a high level, I'm slightly concerned about the state of the IP-geo
  aspects of this document.  It's not obvious to me what's desired (nor
  what may be achievable) here.

  [1] RFC 8805

  In section 5, there's a reference to 8805.  This document is an
  Independent Stream Editor's document, and not an IETF standard.  I don't
  know if that's technically disqualifying from being listed as a Normative
  reference or not.  Regardless, it certainly does not represent any formal
  industry consensus.

  [2] ipv4-geo-ip

  This references draft-ietf-i2nsf-capability, but I cannot find any
  discussion of IPv4 address geolocation in that document (admittedly I have
  not read it thoroughly).

  [3] ipv6-geo-ip

  I did not find an analogous geo-ip element for IPv6.  If there should be
  support for geolocation for one address family there should probably be
  support for the other.
Comment (2020-09-22 for -12)
[[ comments ]]

[ section 1 ]

* This document describes a YANG model outlining a few more I2NSF
  documents than just i2nsf-capability, including:

    - i2nsf-nsf-monitoring-data-model
    - i2nsf-sdn-ipsec-flow-protection

  Indeed, this is noted in section 5.  I think it could help the reader
  when they get to section 4.1 if some earlier section also noted the
  more complete list of references that section 5 does.

[ section 4.1 ]

* ICMPv6 is notable by its absence from the list in the paragraph describing
  the "condition capabilities of generic network security functions".

[ section 5 ]

* The meaning of ipv6-protocol is not immediately obvious, and may be
  redundant with ipv6-next-header (the actual name of the header field).

  Or rather, does ipv6-protocol here mean IPv6 itself (as in the value
  "6" or "true" meaning 'is capable of')?

  Or does this mean the first non-IPv6-extension-header next-header value?


[[ nits ]]

[ section 1 ]

* "As the industry becomes more sophisticated and network devices (...),"
  This is not a grammatically complete clause.  Maybe just something like:

  "...and network devices (...) continue to proliferate, ..."

  or something.

[ section 3 ]

* "at a Developer's Management Systems" ->
  "at a Developer's Management System"

* "managing the capabilities of NSFs in this document" ->
  "managing the capabilities of NSFs as described in this document"?

* "network administrator ..., he sends" ->
  "network administrator ..., they send"

* "sends that security policy rules" ->
  "sends that security policy rule"

* "This lets an I2NSF User not consider NSFs where the rule is applied."

  I found this confusing.  Does it mean to say something like
  "...where the rule is not applicable"?

Éric Vyncke Discuss

Discuss (2020-09-21 for -12)
Thank you for the work put into this document.

While I do appreciate that a data model (this document) is derived from an information model, I am concerned that the information model is an expired draft whereas I would expect the information model being published first. Else, what is the use of the information model ? What was the WG reasoning behind 'putting the cart before the horses' ? My concern is that by publishing the YANG model, there is nearly no way to change the information model anymore.

Please find below a couple of non-blocking COMMENT points but also a couple of blocking DISCUSS points around IPv6. They should be easy to resolve. I would hate to have NSF having basic IPv6 capabilities that cannot be configured by using the YANG model of this document.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.1 --
 
It is quite common to apply conditions based on the whole IPv6 extension header chain (i.e., presence of destination option header or wrong order of the extension headers). Why is there no such capabilities in this YANG module ? The only one is 'identity ipv6-next-header' that applies only to the first extension header.

What is the difference between 'identity ipv6-protocol' and 'identity ipv6-next-header' ? There is no 'protocol' field in the IPv6 header.

While fragmented IPv4 packets are part of the conditions ('identity ipv4-fragment-flags'), there is no equivalent in IPv6.
Comment (2020-09-21 for -12)
-- Section 4.1 --
May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even is SCTP is not heavily used).

Is there a real reason to have two related containers ? generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single one ?
     
Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, addresses are filtered/matched by using a prefix length and not a range (that is difficult to implement in hardware).

Is there a reason why ICMP(v6) codes are not part of the conditions ?

Magnus Westerlund Discuss

Discuss (2020-09-24 for -12)
I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack the semantics to understand if they do map to protocol values. 

This discuss is more a place holder to be aware that this document needs to re-reviewed after having addressed by transport people.

Roman Danyliw Yes

Deborah Brungard No Objection

Murray Kucherawy No Objection

Comment (2020-09-24 for -12)
I support Eric's DISCUSS position about the information model vs. data model publications.

The smashed-together list of references at the top of Section 5 could use some formatting.

I tripped over several of the editorial points Barry found.  Here's one more.  In Section 3:

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

Block malicious users "for" IPv6 traffic?  I don't understand.  Perhaps "block IPv6 traffic from malicious users"?

Barry Leiba No Objection

Comment (2020-09-18 for -12)
While most of these comments are editorial, some of them are dealing with text that's difficult to understand because of the editorial issues.  Please consider these:

— 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
   lot of problems described in [RFC8192].

This sentence seems a bit fractured.  What about network devices?  It looks like there’s something missing after the parenthetical.  Please re-work this sentence.

— Section 3 —

   This section provides as overview of how the YANG data model can be

Typo: “provides an overview”.

   The configuration of advanced security functions over the NSF-Facing
   Interface is used to configure the security policy rules of advanced
   network security functions (e.g., anti-virus and Distributed-Denial-
   of-Service (DDoS) attack mitigator), respectively, according to the
   capabilities of NSFs registered with the I2NSF Framework.

I don’t see what “respectively” refers to, as the sentence only talks about configuring one thing (“the security policy rules of advanced network security functions”).

Also, it seems odd to say “the configuration of … is used to configure …”.  Probably should fix that.


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

Please consider not making the network administrator male (“he”).


   o  When the Network Operator Management System receives the security
      policy rule, it automatically sends that security policy rules to
      appropriate NSFs

Change “rules” to singular “rule” to match the first half of the sentence.

— Section 7 —
You twice say “transport secure transport”, which should just be “secure transport”.

   o  ietf-i2nsf-capability: An attacker could alter the security
      capabilities associated with an NSF whereby disabling or enabling
      the evasion of security mitigations.

I don’t think “whereby” is the right word here, but I can’t figure out what you’re trying to say well enough to suggest what the right word is.  Maybe just “by”?  And I don’t know what it means to “disable the evasion of” something.  So this sentence needs some work, please.

   These are the subtrees and data
   nodes and their sensitivity/vulnerability:

Something’s missing here.  Maybe just “is”?  Maybe something else?

Alvaro Retana No Objection

Comment (2020-09-24 for -12)
The datatracker should indicate that this draft replaces draft-hares-i2nsf-capability-data-model.

I support the DISCUSS positions from Erik and Ben.

Alissa Cooper No Record

Martin Duke No Record

Warren Kumari No Record

Martin Vigoureux No Record

Robert Wilton No Record