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