Re: [I2nsf] [secdir] (updated) review of draft-ietf-i2nsf-capability-data-model-21

[Roman Danyliw <[e-mail]>]

Hi Paul!
(adding I2NSF and document alias like an official response to a directorate review)

Thanks for this review.  A response below and the authors/WG can correct me.

> -----Original Message-----
> From: secdir <[e-mail]> On Behalf Of Paul Wouters
> Sent: Monday, November 29, 2021 4:06 PM
> To: secdir <[e-mail]>
> Subject: [secdir] (updated) review of draft-ietf-i2nsf-capability-data-model-21
> 
> 
> Note to tools team: I was assigned draft-ietf-i2nsf-capability-data-model,
> although I had already reviewed the -16 version. I did a review now of the -21
> version but did not see a way within datatracker to update the review. So I
> opted to use the secdir mailing list for now.
> 
> Paul
> 
> 
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> The summary of the review is Has Issues
> 
> I have reviewed the document. I don't have any particular security concerns,
> and the Security Considerations section is fine. I do have some questions/issues
> from reading the document.
> 
> 
> I am a bit confused about this part:
> 
>          |  |  +--rw ipv4-capability*       identityref
>          |  |  +--rw ipv6-capability*       identityref
>          |  |  +--rw icmpv4-capability*     identityref
>          |  |  +--rw icmpv6-capability*     identityref
>          |  |  +--rw tcp-capability*        identityref
>          |  |  +--rw udp-capability*        identityref
> 
> There is an item for v4 and v6 support. Why is there a split of icmpv4 and
> icmpv6?
> Why isn't that done similarly to tcp and udp that don't have v4/v6 versions?

This modeling choice was made because ICMPv4 and ICMPv6 are not the same protocol.  TCP and UDP are the same protocol regardless of whether they are using IPv4 or v6.

> This term seems to be rather generic:
> 
>          |  |  +--rw url-capability*                    identityref
> 
> Perhaps what is meant is url-filtering-capability or url-protection-capability ?

I'll leave it up to the WG to decide if they want to scope it as such.

> It also seems rw advanced-nsf-capabilities is really either "rw protection-nsf-
> capabilities" or "rw filtering-nsf-capabilities" ? It seems "advanced" is a very
> generic term? It could be useful to allow for further non-filter/non-protective
> options, but it does seem right now this "advanced" category really means
> some kind of "client protection" category.

There is a history in the naming convention of advanced vs. generic-nsf-capabilities.  Advanced capabilities were initially extension points discussed in other documents.  After refinement, the work didn't evolve this way.  The WG has discussed and modified this convention, and arrived at roughly the explanation documented in Section 5.1:

==[ snip ]==
   In this
   document, two kinds of condition capabilities are used to classify
   different capabilities of NSFs such as generic-nsf-capabilities and
   advanced-nsf-capabilities.  First, the generic-nsf-capabilities
   define NSFs that operate on packet header for layer 2 (i.e., Ethernet
   capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4
   capability, and ICMPv6 capability.), and layer 4 (i.e., TCP
   capability, UDP capability, SCTP capability, and DCCP capability).
   Second, the advanced-nsf-capabilities define NSFs that operate on
   features different from the generic-nsf-capabilities, e.g., the
   payload, cross flow state, application layer, traffic statistics,
   network behavior, etc.  This document defines the advanced-nsf into
   two categories such as content-security-control and attack-
   mitigation-control.
==[ snip ]==


> Similarly, "rw target-capabilities" might be better descriped as "rw destination-
> capabilities"
> to avoid confusing about this being a "targetting system" or the client being
> "targetted".

I can see your point.  "target" is used in place of "destination" in a few places.  This seems editorial and I'd leave it up to the WG to decide.  

> I also find "rw action-capabilities" confusing. Isn't "anti-virus" and "anti-ddos"
> also an action capability ? Or should I read this as a condition of "anti-virus"
> kind activate an action capability (filter in, filter out, log). 

It's the latter.  Consider Example 5 of Section A.5 which depicts the interrelationship between <anti-ddos-capability> and the <action-capabilities>.

> It also seems the
> selector (eg "anti-virus") is coupled to an action (eg "block") so I'm a bit
> confused on why there is no capability link between these. Eg having "filtering"
> as a capability seems related to some conditionals, but perhaps not all. So I am
> not sure if the current model could describe that. Eg lets say there is a packet
> filter, not but no filter based on anti-virus but it can detect anti-virus. How
> would one know from these capabilities that anti-virus has "filter" and not only
> "log" ?

For your antivirus configuration there might be something like the following: 

<condition-capabilities>
   <advanced-nsf-capabilities>
   <anti-virus-capability>detect</anti-virus-capability>
...
<action-capabilities>
...
     <egress-action-capability>drop</ingress-action-capability>

> And "rw generic-nsf-capabilities" seems to be more like "rw transport-nsf-
> capabilities"

See explanation above on generic vs. advanced-capabilities

> There are many email contacts listed in Section 6. These will not stand the
> passing of time.
> Why are they needed? Should there be an IANA registry/contact instead ?

Not question this contact information will age.  However, it seems to be common convention to include all of the document authors in the YANG contact information.
 
> the identity targets include base target-device which only has a description
> field. So all these identity targets _only_ have a description. Is the presense of
> an empty identity entry enough to indicate this support, or is some kind of
> boolean field needed?

Thoughts from WG?

> identity flags is only about TCP. Should it be called tcp-flags (like tcp-options) ?
> Similar issue with identity total-length, verification-tag, identity chunk-type and
> service-code.

Seems like there should be consistency or an approach either way as to whether the protocol name is a prefix to a field name.  I'll leave it to the authors to decide on the approach.

> I see identity for pop3 and imap. Does that include pop3s and imaps (version of
> those protocols over TLS). If so, should it be clarified in the description text? If
> not, do we need seperate identity types for these?

I think the intent is for two identities: POP3+POP3S and IMAP+IMAPS, but I'll let the WG make the right change.

> I see identities for pass, drop, mirror and rate-limit, but not for reject (eg send
> an ICMP back)

Paul: Makes sense to me to add it in with your explanation.  
WG: What do you think?  I believe "reject" was in -05, but removed in -06 after the first AD review (https://mailarchive.ietf.org/arch/msg/i2nsf/Qkup2tKpVyAcelxy3QooLf7P1KI/) pointed out that all of these identities were undocumented.

> Security Considerations Section:
> 
>  	The lowest layer of RESTCONF protocol layers
>  	MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS
>  	[RFC7230][RFC8446] as a secure transport layer.
> 
> This excludes QUIC? Perhaps it is better to say use an encrypted and
> authenticated transport layer, such as TLS or QUIC using HTTPS.

This text is a derivative of the standard YANG boiler plate text included in most YANG document recently in recent years.  The working source is kept at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.  

> I am a little confused at Example 3. It shows:
> 
> It's only capability is "user-defined". It's only actions are "ingress/egree options
> that do pass/drop/mirror. Where does it state this is a web filter capability ?

It's a web-filter capability because of "<url-capability>".

"user-defined" is a specific type of URL-filter whose list is generated by the operator:

     identity user-defined {
       base url-filtering;
       description
         "Identity for user-defined URL Database condition capability.
          that allows a users manual addition of URLs for URL
          filtering.";
     }


> And does it really mean the web URI and content can be
> passed/dropped/mirrored? It feels like these pass/drop/mirror targets are for
> packets, not web-uri streams ?

The semantics are definitely reused from packet focused behavior.  For security mitigation devices that operate on streams pass/drop/mirror/log/etc are common actions though.
 
> And should these actions not be inside the capability <url-capability> ? 

The YANG module design is modeled on the premise that each part of the E-C-A rule is a separate top-level container per Section 3.1.  That certainly does remove flexibility but was a design choice.

> What if
> you define an NSF that has url-capability and a packet filter capability, how
> would one know the pass/mirror/drop targets are for the url-capability ot the
> packet filter capability ?
> 
> Maybe, one of the examples can include an NSF with multiple conditions and
> actions that don't fully overlap?

WG thoughts?

> NITS

[...]

Thanks.  Leaving to the authors.

Regards,
Roman