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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 14:41:10 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2nsf-capability-data-model-25: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle 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:
----------------------------------------------------------------------

The overall structure of this data model seems useful and well described.
I also think that the identified "core" set of capabilities to include in
this YANG module is a good starting set that will have broad applicability
(while still allowing extensibility as needed via standard YANG
mechanisms).  However, I'd like to have a discussion about whether the
individual capabilities are identified and described with sufficient
precision so that actual implementations will have identical expctations
of semantics and thereby achieve interoperability.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with more precision, but I may be working
under flawed assumptions of the usage scenario.

Consider the resolution strategies as an example.  "First Matching" and
"Last Matching" are pretty straightforward, but where can I find a precise
specification of "Prioritized Matching Rule with Errors" or "Prioritized
Matching Rule with No Errors"?  I don't think I can find one in this
document, and I don't see any references given that would settle the
question either.

Similarly, if an NSF indicates the "routing-header" capability, what
specifically does that mean?  IPv6 routing headers are managed in an IANA
registry and this registry is seeing some recent activity, with SRH being
registered in 2020 and two CRH variants given temporary registrations in
2021.  Is it required to support all defined routing headers in order to
claim this capability?  Is that all headers defined at the time of this
writing, or at the time the claim is being made, or some other definition
of "all"?  Is it required to support deprecated routing header types like
source route ("RH0") and Nimrod?  If it suffices to only support any
single routing header type, then this is no longer an unambiguous
description of the feature.

As a couple more examples that I called out in my COMMENT section below,
support for HTTP will likely vary across major version of HTTP, and the
"transformation" capability for egress action seems under-defined as well
-- would a NSF claim this capability if it can perform a single type of
transformation?  What happens if the user wanted a different type of
transformation?

It is probably most prudent to have a general discussion about what level
of detail/precision we are expecting to include in this document, and only
then go and modify the corresponding parts of the document to be
compatible with that expectation.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for expanding the security and privacy considerations sections in
response to my earlier review; it's much improved.

It seems to me that knowing the capabilities of a given NSF is necessary
but not sufficient in order to plan out a successful deployment that
utilizes those capabilities.  In particular, knowledge of where the NSF
lies in the (physical or virtual) network topology, or the ability to
adjust the topology as needed (as might be done in SDN or with a
service-function chaning architecture) is also necessary in order to know
which flows could actually be processed by a given NSF.  While the
specifics of the interaction with network topology are probably out of
scope for a data model for NSF capabilities, it still seems like we should
mention that there is a need to make this integration, which would ideally
be accompanied by a reference to a document that meets that need.  Right
now the word "topology" appears in this document only once, in the
security considerations section (as part of a statement that does not seem
to be supported by the rest of the document, no less).

Section 1

   *  Definition for resolution strategy capabilities of network
      security functions.

I didn't see discussion of the need for resolution strategies in the
framework (maybe I missed it), so we might want to have a bit of
exposition on how the need for it arises due to the other elements of the
framework and deployment reality.  Some of that content is already present
down in §3.2, but there doesn't seem to be an introductory remark that
this is extending past what the framework envisioned.

Section 3.1

   *  Automation: The system MUST have the ability to auto-discover,
      auto-negotiate, and auto-update its security capabilities (i.e.,
      without human intervention).  These features are especially useful

I assume that "auto-update" here is in the sense of "keep the central
database of NSF capabilities current" rather than "go fetch and apply
software patches".  If my assumption is correct, then we might refer to
its "capability registration", admittedly at the cost of the alliterative
"auto-"s.

   of capabilities that other I2NSF Components can use.  These
   capabilities MUST have their access control restricted by a policy;
   this is out of scope for this document.  [...]

Is the mechanics of the access control, the policy about which components
are granted which access, or both, what is out of scope?

                                            The set of capabilities
   provided by a given set of NSFs unambiguously defines the security
   services offered by the set of NSFs used.  [...]

This is probably more of a soapbox rant than an actionable comment, but
"unambiguously defines" is a very high bar.  If there is any kind of
vendor differentiation or quality-of-implementation differences, there may
be attributes not captured by the set of capabilities that still affect
the security services on offer.

   Technically, the "Policy Rule" is really a container that aggregates
   the above three clauses, as well as metadata, which describe the
   characteristics and behaviors of a capability (or an NSF).

Almost nit-like, but up here since it actually affects meaning: if the
thing that describes the characteristics and behaviors of a capability/NSF
is the metadata, then remove the comma after "metadata".

   Aggregating metadata enables a business logic to be used to prescribe
   a behavior.  For example, suppose a particular ECA Policy Rule
   contains three actions (A1, A2, and A3, in that order).  Action A2
   has a priority of 10; actions A1 and A3 have no priority specified.

This is the first time we've mentioned "priority"; it is not a good way to
introduce the topic.  In fact, this paragraph is the only place that the
word "priority" appears in the document (though "prioritized" does appear
in §5.1 and in the YANG model ... with no further description of how to
fulfil them).
Also, is the concept of being able to aggregate multiple pieces of
metadata the importent point here, or just the ability to associate
metadata with a policy at all?  I might rephrase slightly to use
"associate" in that case.

Section 3.2

   There is no conflict between the two policy rules R1 and R2, since
   the actions are different.  [...]

I don't think the actions just being "different" is enough to meet the
definition.  Is the intent to say that they act on different *objects*, or
that somehow they act on the same object "in the same way"?

   *  Resolution Strategies: They can be used to specify how to resolve
      conflicts that occur between the actions of the same or different
      policy rules that are matched and contained in this particular
      NSF;

I'm kind of curious how a conflict would arise between the actions of "the
same policy rule".  Isn't that just a badly written rule?
(There is similar text in §5, if any change is made here.)

Section 4

   Controller.  As described in [RFC8192], with the usage of
   Registration Interface and the YANG module in this document, the NSFs
   manufactured by multiple vendors can be managed together by the
   Security Controller in a centralized way and be updated dynamically
   by each vendor as the NSF has software or hardware updates.

As above, please clarify what is being updated in the scenario being
referred to (i.e., software on the device vs the registration information
at the security controller).

                           v                 I2NSF
         +-----------------+------------+  Registration +-------------+
         | Network Operator Mgmt System |   Interface   | Developer's |
         | (i.e., Security Controller)  |<------------->| Mgmt System |
         +-----------------+------------+               +-------------+
                           ^                                New NSF
                           |                          Cap = {FW, WF}
             I2NSF         |                          E = {}
      NSF-Facing Interface |                          C = {IPv4, IPv6}
                           |                          A = {Allow, Deny}

I still think it would be useful to have some prose indicating that the "E
= {}" means that the event boolean will always evaluate to true.

Section 6

     identity system-event {
       [...]
     identity system-alarm {
       [...]
     identity time {
       [...]
     identity device-type {
       [...]
     identity geographic-location {
       [...]
     identity directional {

All of these identities are used as base identities for other identities.
Are any of them intended to also be used directly as their own identifier?
If not, then I think the description should use the phrase "base
identity".

     identity device-type {
       description
         "Identity for device type condition capability. The capability
          for matching the destination device type.";

Why is the destination device given the unqualified name "device-type"?
Why would the source device type not also be of interest?

     identity fragment-flags {
       base ipv4;
       description
         "Identity for IPv4 fragment flags condition capability";

I'm not aware of "fragment flags" being a common jargon to refer to the
'flags' field of the IPv4 header.

     identity routing-header {
       base ipv6;
       description
         "Identity for IPv6 routing header condition
         capability";

The semantics of this identity (and several adjacent ones, really) seem
rather under-defined.  Does this mean that my NSF can recognize that there
is a RH present?  Or is the NSF expected to do some further parsing on it?
Which types of RH would the NSF be required to be able to parse if it
indicates this capability?  What if new RH types are allocated in the
future?

     identity sctp {
       base transport-protocol;
       description
         "Identity for SCTP condition capabilities";
       [...]
     identity dccp {
       base transport-protocol;
       description
         "Identity for DCCP condition capabilities";

The TCP and UTP identities said they were "base identity" for the
respective condition capabilities.  Why are SCTP and DCCP different in
this regard?

     identity options {
       base tcp;
       description
         "Identity for TCP options condition capability";

Similarly to the routing-header, what am I signifying if I claim this
capability?  TCP options are maintained in an IANA registry, so attempting
to claim support for all options is an open-ended task.

     identity length {
       base tcp;
       base udp;
       description
         "Identity for matching TCP or UDP length condition capability.

Why is SCTP (DATA) chunk length not applicable here?  (I don't actually
know if DCCP has something analogous.)

     identity http {
       base application-protocol;
       description
         "The identity for Hypertext Transfer Protocol.";
       reference
         "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message
          Syntax and Routing
          RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics
          and Content";

This seems highly problematic.  HTTP/1.x, HTTP/2, and HTTP/3 are
completely different protocols and a device that can parse one should not
be expected to be able to parse any of the others.  Trying to conglomerate
support for "http" conditions in this manner seems doomed to result in
failure.

     identity pop3 {
       base application-protocol;
       description
         "The identity for Post Office Protocol 3. This includes
          POP3 over TLS";
       [...]
     identity imap {
       base application-protocol;
       description
         "The identity for Internet Message Access Protocol. This
          includes IMAP over TLS";

Why are pop3 and imap different from http, which gets distinct identities
for http-not-s and https?

     identity transformation {
       base egress-action;
       description
         "Identity for transformation action capability";

Keeping with the theme, "transformation" is a very generic capability.  In
some cases the nature of the transformations that are or are not possible
will be very important to the user, but in this model an NSF has to either
claim the "transformation" capability or not claim it, leaving no room for
the subtleties that will be very important for actual deployments.

     identity fmr {
       base resolution-strategy;
       description
         "Identity for First Matching Rule (FMR) resolution
          strategy capability";
     [...]
     identity lmr {
       base resolution-strategy;
       description
         "Identity for Last Matching Rule (LMR) resolution
          strategy capability";
     [...]
     identity pmr {
       base resolution-strategy;
       description
         "Identity for Prioritized Matching Rule (PMR) resolution
          strategy capability";
     [...]
     identity pmre {
       base resolution-strategy;
       description
         "Identity for Prioritized Matching Rule with Errors (PMRE)
          resolution strategy capability";
     [...]
     identity pmrn {
       base resolution-strategy;
       description
         "Identity for Prioritized Matching Rule with No Errors (PMRN)
          resolution strategy capability";

Where are the details of these resolution strategies specified?  "first
match" and "last match" are perhaps self-explanatory, but I am confident
that just relying on the string "Prioritized Matching Rule with No Errors
(PMRN)" with no reference or further explanation will result in divergent
implementation.

Section 9

   *  list nsf: The leak of this node to an attacker could reveal the
      specific configuration of security controls to an attacker.  An
      attacker can craft an attack path that avoids observation or
      mitigations; one may reveal topology information to inform
      additional targets or enable lateral movement; one enables the
      construction of an attack path that avoids observation or
      mitigations; one provides an indication that the operator has
      discovered the attack.

I don't understand what the "one" in the different clauses here refers to.
Is it supposed to be "one node" in the YANG tree?  But I don't remember
seeing specific nodes that provide these abilities if read access is
obtained by an attacker; could we name the specific nodes if that's the
case?

Also, separately, I don't think any of the nodes in *this* module provide
topology information.  My understanding is that topolgoy information would
have to come from a different source (likely a separate YANG module
implemented by the same system) and could be combined with the information
from this model in order to perform the indicated attacks.

   Some of the capability indicators (i.e., identities) defined in this
   document are highly sensitive and/or privileged operations that
   inherently require access to individuals' private data.  These are
   subtrees and data nodes that are considered privacy sensitive:
   [...]

I think that url-filtering-capability should also be listed here.
Perhaps NEW:
% * url-filtering-capability: URLs themselves often contain sensitive
%   information [CAPABILITY-URLS], and access to URLs typically comes
%   hand-in-hand with access to request and response content, which is
%   also often sensitive.
%
% [CAPABILITY-URLS]: https://www.w3.org/2001/tag/doc/capability-urls/

Section 10.2

I'm not sure what methodology was used to classify references as normative
vs informative.  E.g., RFC 6691 is cited in the same way that RFC 7323
is, but RFC 7323 is classified as normative and RFC 6691 is classified as
informative.  For reference, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
, the classification should be made solely on how the reference is used in
the document, with no dependence on the status or source of the
referred-to document.
For concreteness, I suggest that the classification of RFCs 2818 and 6691,
and [I-D.ietf-i2nsf-nsf-facing-interface-dm] and
[I-D.ietf-i2nsf-registration-interface-dm] be revisited.

   [OODMP]    "https://www.oodesign.com/mediator-pattern.html".

   [OODOP]    "https://www.oodesign.com/mediator-pattern.html".

   [OODSRP]   "https://www.oodesign.com/mediator-pattern.html".

I think the latter two were intended to point to
https://www.oodesign.com/observer-pattern.html and
https://www.oodesign.com/single-responsibility-principle.html
respectively.

NITS

Section 2

   This document follows the guidelines of [RFC8407], uses the common
   YANG types defined in [RFC6991], and adopts the Network Management
   Datastore Architecture (NMDA).  The meaning of the symbols in tree

Please reference RFC 8342 for NMDA.

Section 3

   This CapIM includes enabling a security controller in an I2NSF
   framework [RFC8329] to properly identify and manage NSFs, and allow
   NSFs to properly declare their functionality through a Developer's
   Management System (DMS) [RFC8329], so that they can be used in the
   correct way.

I think there's a word or two missing between "includes" and "enabling"
(perhaps "mechanisms for" or "provision for"?) -- the information model
itself does not include an element "enabling a controller to ...", rather,
the existince of the model (and other things build on it) enables the
controller to do these things.  Alternately, drop "includes" and go with
"this CapIM enables [...]".

Section 3.1

   *  Advertisement: Registration Interface
      [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to

"The Registration Interface"

   *  Execution: NSF-Facing Interface
      [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring

Likewise here, add "The".

      set of Message Exchange Patterns [Hohpe].  Registration Interface
      [I-D.ietf-i2nsf-registration-interface-dm] can register the

"The" here as well.

      capabilities of NSFs with the security controller from the request
      of Developer's Management System providing NSFs and the
      corresponding security capabilities.  Also, this interface can

Something seems awry here but I can't pick out the intended meaning so as
to suggest a fix.  Is the idea that the Developer's Management System
instigates a request and as a result of that request the list of relevant
NSFs and their respective security capabilities become available at the
security controller?  If so, a comma before "providing" would help, as
would some more description like "providing a list of available ... at the
security controller".

      whether it needs to invoke scaling or not.  NSF Monitoring
      Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe

"The NSF Monitoring Interface"

   or stored separately in a vendor's local repository.  In either case,
   Registration Interface can facilitate this update process to

"the Registration Interface"

   Developer's Management System to let the security controller update
   its repository for NSFs and their security capabilities.

I think we want s/to Developer's Management System to let/so the
Developer's Management System can let/

Section 4

   *  If a network administrator wants to block IPv4 or IPv6 packets
      from malicious users, the network administrator sends a security
      policy rule to block the users to the Network Operator Management
      System (i.e., Security Controller) using the I2NSF Consumer-Facing
      Interface.

The ordering of the clauses seems wrong here.  I think we want to say that
the network admin sends a security policy rule to the security controller,
and that rule says to block the users in question.  So we might consider
NEW:
% If a network administrator wants to block IPv4 or IPv6 packets
% from malicious users, the network administrator sends a security policy
% rule to the Network Operator Management System (i.e., Security Controller)
% using the I2NSF Consumer-Facing Interface, directing the system to block
% the users in question.

Section 5.1

   The context capabilities provide extra information for the condition.
   The given context conditions are application filter, target, user
   condition, and geographic location.  The application filter
   capability is capability in matching the packet based on the
   application protocol, such as HTTP, HTTPS, FTP, etc.  The device type
   capability is capability in matching the type of the destination
   devices, such as PC, IoT, Network Infrastructure devices, etc.  The
   user condition is capability in matching the users of the network by
   mapping each user ID to an IP address.  Users can be combined into
   one group.  The geographic location capability is capability in
   matching the geographical location of a source or destination of a
   packet.

A couple points.

The construction of "the <X> capability is capability in <Y>" is not
grammatical; it would be better as something like "the <X> capability is
the capability for" (other variants are possible that change the
conjugation of the following verb) (multiple instances).

The sentence about "users can be combined into one group" is potentially
confusing.  Is there only ever one group possible?  If there can be
multiple concurrent groupings defined, then something like "users can be
combined into groups" would be more accurate.

                                                               In
   addition, see Section 9.1 (Flow-Based NSF Capability
   Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in
   [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about
   logging at NSFs.

s/7.5/6.5/ (at least as of the -12 of the referenced draft)

Section 6

     identity system-event {
       base event;
       description
         "Identity for system event. System event (called alert) is

I suggest adding "sometimes" or "also" at the start of the parenthetical.

       description
         "Identity for CPU alarm. CPU is the Central Processing Unit
          that executes basic operations of the system. A cpu-alarm
          is emitted when the CPU usage is exceeding the threshold.";
       [...]
       description
         "Identity for disk alarm. Disk is the hardware to store
          information for a long period, i.e., Hard Disk and Solid-State
          Drive. A disk-alarm is emitted when the disk usage is
          exceeding the threshold.";

s/the threshold/a threshold/.  There is no one single definite threshold
that always applies; the threshold in question is either going to be
independently configurable or will vary across systems/implementations.

     identity voip-volte-phone {
       base device-type;
       description
         "Identity for voip-volte-phone";

I think we want "VOIP or VoLTE phone"; there isn't really a single
combined VOIP/VoLTE phone as a concept (even if modern premium smartphones
do offer seamless wifi/LTE calling).

Section 9

   *  list nsf: An attacker could alter the security capabilities
      associated with an NSF by disabling or enabling the functionality
      of the security capabilities of the NSF.

I'd suggest
NEW:
%  *  list nsf: An attacker could alter the security capabilities
%     associated with an NSF in the database maintained by the security
%     controller.  Such changes could result in security functionality
%     going unused due to the controller not having a record of it, and
%     could also result in falsely claiming security capabilities that the
%     controller would then attempt to use but would not actually be
%     provided.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 11 Feb 2022 01:42:07 +0900

Hi Benjamin,
Here is the revised draft reflecting your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-26

I attach the revision letter to explain how the revision
is done by Patrick and me for your comments.

[Review by Benjamin Kaduk and Response by Authors] starts from page 1 in
the revision letter.

Thanks for your valuable comments and help.

Best Regards,
Paul

On Thu, Feb 3, 2022 at 7:41 AM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>