Ben,
Thank you very much for the detailed comments.
As a co-chair, I just want to address your comments on "“not see any discussion
of privacy considerations”. The draft authors will address your detailed
comments & suggestions on the document.
There are suite of Data Models from I2NSF WG. All of them are branch out from
the I2NSF Framework RFC8329. The Security and privacy description from RFC
8329 are applicable to all of them. RFC8329 states that
The mechanisms adopted within the
solution space must include proper secure communication channels that
are carefully specified for carrying the controlling and monitoring
information between the NSFs and their management entity or entities.
The Section 4 of RFC 8329 specifies the Threats Associated with Externally
Provided NSFs.
Therefore, the WG doesn’t think it is necessary to repeat in every Data Model
draft of the Security and Privacy described in the I2NSF framework RFC8329.
Best Regards,
Linda Dunbar
-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email protected]>
Sent: Wednesday, September 23, 2020 12:12 AM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; Linda Dunbar <[email protected]>; [email protected]
Subject: Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12:
(with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2nsf-capability-data-model-12: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3D&reserved=0
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
There are many elements of the YANG module whose semantics seem underspecified
to me. I noted quite a few in the COMMENT section, and I hope that those
aspects of my comments are clear (as it would be substantial effort to
partition the comments and move the questions of unclear semantics into the
discuss section), but I am happy to assist in the classification if needed.
I think that the data nodes of this module as written are probably not
reflecting the intent -- it seems that the only elements of the 'nsf'
list are the string nsf-name; there is no "uses nsf-capabilities" stanza to
bring in the grouping that contains all the interesting parts.
Specifically, I do not see how the tree diagram reflects the current module.
I'm surprised to not see any discussion of privacy considerations -- some of
the features that we define capability indicators for are highly sensitive
and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify
individuals, web filtering) that inherently require access to individuals'
private data. Not only should we note that private information is made
accessible in this manner, but we should also reiterate that the nodes/entities
given access to this data need to be tightly secured and monitored, to prevent
leakage or other unauthorized disclosure of private data.
I also think we need to mention that authentication and proper authorization
will be needed to register as an NSF providing these capabilities.
The examples do not seem to conform to the current module structure (e.g.,
exact-fourth-layer-port-num and range-fourth-layer-port-num).
I worry a little bit that even the structure of the tree risks "imposing
functional requirements or constraints" upon NSF developers (in the words of
the framework). How would, for example, SCTP capabilities be indicated, let
alone QUIC? (With an augmentation, clearly, but is that undue burden?) While
the classification into ingress/egress/log is natural, it also may be found
limiting; consider, for example, a setup involving port mirroring -- is that an
ingress action or egress? If traffic is dropped as part of a different ingress
filtering capability, does it still get sent to the port mirror?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
It's a little weird to have the data model be up for review when the
information model is still in AD Evaluation, but probably not catastrophic.
Section 1
As the industry becomes more sophisticated and network devices (e.g.,
Internet of Things, Self-driving vehicles, and smartphone using Voice
over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a
nit: missing verb for "network devices".
registration interface [RFC8329]. With the capabilities of those
security devices maintained centrally, those security devices can be
nit: I'd probably say that it's the knowledge of those capabilities or a
database of those capabilities that is maintained centrally.
o Definition for condition capabilities of generic network security
functions.
o Definition for condition capabilities of advanced network security
functions.
[I'm not yet sure at this point that I understand the need for distinguishing
between generic and advanced network security functions ... won't the boundary
between those categories evolve over time?]
Section 3
Framework. As shown in this figure, an NSF Developer's Management
System can register NSFs and the capabilities that the network
security device can support. To register NSFs in this way, the
nit: s/device/devices/
That is, this Registration Interface uses the YANG module described
in this document to describe the capability of a network security
function that is registered with the Security Controller. With the
nit: "capabilities" plural probably makes more sense in this context.
capabilities of those network security devices maintained centrally,
[similar comment about "maintained centrally" as above]
Note that the NSF-Facing Interface [RFC8329] is used to configure the
security policy rules of the generic network security functions, and
The configuration of advanced security functions over the NSF-Facing
nit: lowercase 'l' in "the".
o If a network administrator wants to block malicious users for IPv6
traffic, he sends a security policy rule to block the users to the
Network Operator Management System using the I2NSF User (i.e., web
application).
I'm not entirely sure why only the IPv6 traffic of a malicious user would be
blocked.
Also, nit/edtiorial-level, "using the I2NSF Consumer-Facing Interface"
would read more naturally to me than "using the I2NSF User".
Section 4.1
The NSF capabilities in the tree include time capabilities, event
capabilities, condition capabilities, action capabilities, resolution
strategy capabilities, and default action capabilities. Those
In Section 1 we had a similar list that used "general capabilities"
compared to "time capabilities" here. Is this distinction intentional?
(Given that the tree diagram and actual module use the "time" variant, it's not
entirely clear what the "general" variant would be...)
repeated time like day, week, or month. See Section 3.4.6
(Capability Algebra) in [I-D.ietf-i2nsf-capability] for more
information about the time-based condition (e.g., time period) in the
capability algebra.
Following the reference, it seems to just use time-based condition as an
example of an arbitrary condition -- I don't see any specific discussion that
mentions considerations specific to time-based conditions.
event and system alarm. See Section 3.1 (Design Principles and ECA
Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more
information about the event in the ECA policy model.
(side note) I followed the reference and was surprised that I couldn't find any
specific indication that an Event of '{}' evaluates to true (at least, I assume
it does).
advanced network security functions. The condition capabilities of
generic network security functions are defined as IPv4 capability,
IPv6 capability, TCP capability, UDP capability, and ICMP capability.
The condition capabilities of advanced network security functions are
defined as anti-virus capability, anti-DDoS capability, Intrusion
Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE
capability. See Section 3.1 (Design Principles and ECA Policy Model
At this point in the document I don't understand why VoIP and VoLTE are fit to
group together into a single capability. Is the condition clause just looking
at a phone number and not other aspects of the call?
the ingress and egress actions. In addition, see Section 9.1 (Flow-
Based NSF Capability Characterization) for more information about
logging at NSFs.
[this is section 9.1 of [I-D.ietf-i2nsf-capability] still, though the
additional discussion on logging is fairly minimal.]
Section 5
In general there seems to be a lot of content in "reference" stanzas that to my
non-expert eye would have been more appropriate in the "description" stanza.
identity event {
description
"Base identity for I2NSF policy events.";
I note that draft-ietf-i2nsf-capability uses the phrase "I2NSF Event", "I2NSF
Policy", and "I2NSF Policy Rule" but not "I2NSF policy event", which makes me
suspect that this is an editorial error.
(draft-ietf-i2nsf-nsf-monitoring-data-model doesn't use "I2NSF policy event",
either.)
identity hardware-alarm {
base system-alarm-capability;
description
"Identity for hardware alarm";
How do I decide when to use hardware-alarm vs, e.g., memory-alarm or cpu-alarm?
identity condition {
description
"Base identity for policy conditions";
}
Similarly to for events, draft-ietf-i2nsf-capability seems to only use "I2NSF
Condition", not "I2NSF policy condition". In this case, the use of "policy"
does not feel as out of place to me as it did for events, though.
identity context-capability {
[...]
reference
"draft-ietf-i2nsf-capability-05: Information Model of NSFs
Capabilities - The operating context of an NSF.";
}
I don't see the "the operating context of an NSF" in the referenced draft, and
in fact "context" is not used as a technical term at all.
(Similarly for "identity access-control-list"'s "The context of an NSF".)
identity application-layer-filter {
base context-capability;
description
"Identity for application-layer-filter condition capability";
This seems likely to be highly dependent on what exactly the application layer
is! I'm not sure that such a generic capability will be useful in practice.
identity user {
[...]
reference
"draft-ietf-i2nsf-capability-05: Information Model of NSFs
Capabilities - A user in an application of a policy rule
to be applied by an NSF.
RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a user (e.g., the
corresponding IP address) in an NSF.";
I'm fairly concerned about implying that it's safe and effective to use an IP
address to identify a user. While this works often enough that we have
stringent privacy considerations regarding storage/conveyance of IP addresses
in logs, in the context of automated network (security) functions the risk of
collatoral damage seems quite large.
identity group {
[...]
reference
"draft-ietf-i2nsf-capability-05: Information Model of NSFs
Capabilities - A group (i.e., a set of users) in an
application of a policy rule to be applied by an NSF.
RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a group (e.g., the
corresponding IP address) in an NSF.";
An IP address can identify a group, too?
identity geography {
base context-capability;
description
"Identity for geography condition capability";
reference
"draft-ietf-i2nsf-capability-05: Information Model of NSFs
Capabilities - A group (i.e., a set of users) in an
application of a policy rule to be applied by an NSF.
I'm not sure what's going on here -- why are groups relevant for geography?
RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a geographical location
i.e., geolocation (e.g., the corresponding IP address) in
an NSF.
RFC 8519 doesn't itself talk about geographic location.
RFC 8805: A Format for Self-Published IP Geolocation Feeds
- An IP address with geolocation information.";
I question the utility of self-published geolocation information for the
application of (security) policy -- my understanding is that this reference was
intended to avoid (among other things) the issue where the IETF meeting network
gets geolocated to the location of the previous IETF meeting for the first
couple days of the week, which is a convenience/performance application, not a
security one.
identity ipv4-capability {
base condition;
description
"Identity for IPv4 condition capability";
This identity is used as a base identity for other capabilities; is it intended
to also be used as a standalone capability? If not, I suggest including "base"
in the description. If so, please clarify what the semantics are.
identity ipv4-id {
base ipv4-capability;
description
"Identity for identification condition capability";
(side note) I'd suggest making some mention of "fragment" or "fragmentation"
here, in light of RFC 6864.
identity ipv6-capability {
base condition;
description
"Identity for IPv6 condition capabilities";
[same as for ipv4-capability]
identity exact-ipv6-flow-label {
[...]
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Flow Label";
RFC 6437 seems relevant as well.
(Similarly for range-ipv6-flow-label.)
identity tcp-capability {
base condition;
description
"Identity for TCP condition capabilities";
[same as for ipv4-capability]
identity exact-tcp-seq-num {
base tcp-capability;
description
"Identity for exact-match TCP sequence number condition
capability";
It's not entirely clear to me why there is need to match on the TCP sequence
number, which per RFC 6528 should be effectively random from the vantage of a
stateless NSF device.
identity exact-tcp-ack-num {
base tcp-capability;
description
"Identity for exact-match TCP acknowledgement number condition
capability";
Likewise, the ack number should be effectively random to a stateless NSF.
identity udp-capability {
base condition;
description
"Identity for UDP condition capabilities";
[same as for ipv4-capability]
identity icmp-capability {
base condition;
description
"Identity for ICMP condition capability";
[ditto]
identity icmpv6-capability {
base condition;
description
"Identity for ICMPv6 condition capability";
[ditto]
identity url-capability {
base condition;
description
"Identity for URL condition capability";
[ditto]
identity pre-defined {
base url-capability;
description
"Identity for URL pre-defined condition capability";
}
identity user-defined {
base url-capability;
description
"Identity for URL user-defined condition capability";
}
With such sparse description and no reference, I have no idea what
functionality this is supposed to indicate.
identity log-action-capability {
description
"Identity for log-action capability";
[same as for ipv4-capability]
identity rule-log {
base log-action-capability;
description
"Identity for rule log log-action capability";
}
identity session-log {
base log-action-capability;
description
"Identity for session log log-action capability";
}
[same as for pre-defined/user-defined]
identity egress-action-capability {
description
"Base identity for egress-action capability";
Why does egress-action-capability get described as a "base identity" but
ingress-action-capability and default-action-capability do not?
identity tunnel-encapsulation {
base egress-action-capability;
description
"Identity for tunnel encapsulation action capability";
Given that there is more than one tunneling technology available (within the
IETF, even!), it's not really clear that this capability will be useful. If a
node that only does IPsec wants to talk to a node that only does VXLAN, there's
not going to be much tunneling going on.
identity voip-volte-capability {
[...]
reference
"RFC 3261: SIP: Session Initiation Protocol
RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF VoIP/VoLTE security service
capability";
RFC 8329 doesn't talk about "voice" or "VoLTE" at all.
identity exception-application {
[...]
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-Virus Exception Application
capability";
RFC 8329 doesn't talk about "Anti-Virus Exception" at all (and it's not a term
I've encountered previously, so with no other reference I have no idea what
it's supposed to mean).
(Similarly for exception-signature.)
identity voice-id {
base voip-volte-capability;
description
"Identity for advanced NSF VoIP/VoLTE Voice-ID capability.
This can be used for an extension point for VoIP/VoLTE
Voice-ID as an advanced NSF.";
It sounds like this "voice-ID" is doing voiceprint analysis to identify humans,
which would have rather significant implications for the privacy considerations
of the system.
reference
"RFC 3261: SIP: Session Initiation Protocol
RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF VoIP/VoLTE Security Service
capability";
[still no voice/VoLTE in 8329; I'm probably not going to catch all of these]
container generic-nsf-capabilities {
description
"Conditions capabilities.
If a network security function has the condition
capabilities, the network security function
supports rule execution according to conditions of
IPv4, IPv6, TCP, UDP, ICMP, ICMPv6, and payload.";
nit: the "and" implies that an NSF has to support all of those if any condition
capability is present, which I don't think is the intent.
description
"Default action capabilities.
A default action is used to execute I2NSF policy rules
when no rule matches a packet. The default action is
defined as pass, drop, alert, or mirror.";
Does "alert" setill let the packet pass, or drop it?
Section 7
"ietf-i2nsf-capability" is not a data node; it's the module name. (That said,
I don't really disagree with the assessment that all the nodes in the module
are sensitive, for the listed reasons.)
Also, I believe it's conventionally assumed that nodes sensitive for write are
also sensitive for read, and don't need to be listed again.
Section 8.1
RFCs 3444 and 8431 do not seem to be referenced anywhere in the document.
RFCs 3849 and 5737 may not need to be normative (we use the reserved addresses
for documentation but the reader doesn't need to rely on that per se).
Appendix A.3
The figure lists only "user-defined" as an advanced capability but the prose
claims http and https inspection.
Appendix A.5
We don't seem to use the address of the NSF anywhere, so there doesn't seem to
be need to state what its address is assumed to be. (This would also render
the RFC 5737 and RFC 3849 references unused.)
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
