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 <secdir-boun...@ietf.org> On Behalf Of Paul Wouters
> Sent: Monday, November 29, 2021 4:06 PM
> To: secdir <sec...@ietf.org>
> 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
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
