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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <
[e-mail]> wrote:

> 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.
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>