Skip to main content

I2NSF Network Security Function-Facing Interface YANG Data Model

Note: This ballot was opened for revision 18 and is now closed.

Roman Danyliw
Erik Kline
No Objection
Comment (2022-02-12 for -21) Sent
[S5.1; nit]

* 2001:db8:0:1::0/120 should probably be 2001:db8:0:1::/120, which I think
  is more in keeping with RFC 5952 canonical string format.
Francesca Palombini
(was Discuss) No Objection
Comment (2022-03-24 for -23) Sent for earlier
Thank you for the work on this document.

Thank you for addressing my previous DISCUSS.

Murray Kucherawy
No Objection
Comment (2022-02-16 for -21) Sent
In Section 3, there's this:

   A default action is used to execute I2NSF policy rule when no rule
   matches a packet.  The default action is defined as pass, drop,
   reject, rate-limit, and mirror.  The default action can be extended
   according to specific vendor action features.  The default action is
   described in detail in [I-D.ietf-i2nsf-capability-data-model].

The second sentence is confusing.  It appears to say the default is all five of those, when I think it means to say is that the default is one of those.

Anywhere "http" or "https" appear as words in prose, but not as part of a URL or part of the YANG module, I believe they should be in all caps since they're acronyms.  See, for instance, the numerous instances of this in Section 5.

A very minor point: I suggest Section 6 be broken into two subsections, one per major action being requested.
Paul Wouters
No Objection
Comment (2022-04-19 for -25) Sent
Please do update the versioned draft's referenced to their latest version, and as the SecDir review suggested, why not use  RFC 9051 as the imaps reference.
Warren Kumari
No Objection
Comment (2022-02-08 for -20) Sent
Thank you to the authors and the WG for this document - it seems useful and complete.

Also, thank you to Joe for the OpsDir review, and to the authors for addressing his comments. 

Finally, I wanted to note that this was a really good Document Shepherd writeup, and was very helpful.
Zaheduzzaman Sarker
No Objection
Comment (2022-02-16 for -21) Sent
Thanks for working on this specification. Thanks to Yoshifumi Nishida for the TSVART review.

A bit of regrets that this specification does not include QUIC as transport protocol. A note in the specification regarding why it does not include QUIC would be nice.


  Duplicate https identity in section 4.1

     identity https-2 {
    base application-protocol;
      "The identity for Hypertext Transfer Protocol version 2
       (HTTP/2) over TLS.";
      "draft-ietf-httpbis-http2bis-07: HTTP/2";}
Éric Vyncke
(was Discuss) Abstain
Comment (2022-04-06 for -23) Sent
Thank you for the work put into this document and for acting on most of my comments on revision -21.

As written in a separate email, I am clearing my previous DISCUSS position but I am balloting ABSTAIN as the IPv6 support in this document is really too low. I understand that authors rely on the YANG modules of RFC 8519 which is clearly not enough for IPv6. 

About my own DISCUSS, the change to a "choice layer-3" is still a XOR: either IPv4 or IPv6 and this is not what security practitioners want to do as they do want congruent security policies. As we are kind of circling and not really reaching a final agreement, I will change my ballot from DISCUSS to ABSTAIN.

Special thanks to Linda Dunbar for the shepherd's write-up including the section about the WG consensus. 

Special thanks as well to Jean-Michel Combes for his INT directorate review.



# DISCUSS (only kept for archiving)

As noted in, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 3.3

Many security practitioners prefer to have a congruent condition part for IPv4 and IPv6, so, why having *TWO* conditions rather than one where the destination/source could be either IPv4 or IPv6. Separating the conditions can only make the authoring of policies more complex.

# COMMENTS (only kept for archiving)

## Abstract

The abstract mentions an information model but no reference is given. See also my comment on section 1

## Section 1
There is a mention of an information model in I-D.ietf-i2nsf-capability-data-model but as mentioned in my IESG ballot on that document, it does not contain any information model... Strongly suggest removing all mentions of 'information model' in the abstract and in this section.

## Section 3.3
Is the use of "ethernet" as a generic term for layer 2 appropriate ? Many layer-2 networks do not use Ethernet (so many IEEE standards...). Suggest to rename into "layer2".

Should other "ethernet" fields be used? Like the VLAN or CoS fields ?

If the IPv4 and IPv6 conditions are kept separated (see my DISCUSS above), then please rename the IPv6 "ttl" into "hop-limit" and "protocol" into "next-header".

More generally, and may be have I overlooked some previous explanations, is the cardinality of ethernet, ipv4, ipv6 the most suitable one ? Can't a condition have multiple IPv4 prefixes ?

## Section 4.1

Why is "session-aging-time" only a uint16 ? As its unit is "second", this represents roughly 18 hours and I am sure that some sessions are longer than 18 hours (I have many opened SSH sessions for days).

In "identity reject", when mentioning the ICMP type and code, please specify whether it is ICMPv4 or ICMPv6 ;-)

## Section 5.1

Thank you for the IPv6 example :-) Same comment as Erik Kline on the IPv6 address, may I also suggest to use a more sensible prefix length ? /60 should be more representative.
Alvaro Retana Former IESG member
No Objection
No Objection (2022-02-17 for -21) Sent
This document should be tagged as replacing draft-kim-i2nsf-nsf-facing-interface-data-model.
Martin Duke Former IESG member
No Objection
No Objection (2022-02-14 for -21) Sent
Thanks to Yoshi for the TSVART review, and the authors for both addressing his comments and switching to heavy reliance on RFC8519. I'm glad we're reusing YANG models instead of reinventing slightly different ones.

It appears the RFC8519 port model is inadequate because it doesn't support multiple ranges; would it better to update RFC8519 to include the construct here, or is there some different use case where port lists are needless complexity?
Martin Vigoureux Former IESG member
No Objection
No Objection (for -21) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (2022-02-17 for -21) Sent

Thanks for this document.  I have a few relatively minor comments:

3.2.  Event Clause
 - It looks like your tree diagram is reproduced twice?
 3.3.  Condition Clause
How do the conditions combine?  E.g., if I set both fields in ipv4 and ipv6 in the same rule?  Is the requirements that all fields set in the condition must match for the rule to be evaluated?  Perhaps this could be clarified here, and in the description of the condition container in the YANG module.
In terms of the YANG:

     identity priority-by-order {
       base priority-usage;
         "Identity for priority by order. This indicates the
          priority of a security policy rule follows the order of the
          configuration. The earlier the configuration is, the higher
          the priority is.";
Except for the base identities, where it helpful for the description to make it clear that it is a base identity, I don't think that you need text like "Identity for priority by order", although strictly is does no harm either.  I'll leave it to the authors to decide whether they change this, but if you do, then please consistently change it for all non base identities.

     identity disk-alarm {
       base system-alarm;
         "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 a threshold.";
         "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF
          Monitoring Interface YANG Data Model - System alarm for disk";
Would "storage-alarm" be a better generic name than disk-alarm?

     identity device-type {
         "Base identity for types of device. This identity is used for
          type of the device for the source or destination of a packet
          or traffic flow.";
          I2NSF Capability YANG Data Model";
I assume that in many cases, particular packet flows, then NSF would not be able to know what type of device it was?  I wasn't quite sure how this would work.

     identity redirection {
       base egress-action;
         "Identity for redirection. This action redirects the packet to
          another destination.";
Could the description clarify the difference between redirection and forwarding please?

5.  XML Configuration Examples of Low-Level Security Policy Rules

Should all the example rules have the same name?  Would they be expected to have different names?

Am I right in understanding that a rule in figure 6 (or 7) are combined with the rule in figure 8.  If so, what in the policy actually binds these together so that the NSFs know to work together?  Is it the common name that binds them all together?  If both v4 and v6 are handling by the same device then you can't have two list entries in the same list with the same key.