From: Linda Dunbar <linda.dun...@futurewei.com>
Sent: 27 April 2021 16:49
Tom,
Can you please provide the concrete suggestions to the authors on the changes
you like to see?
This is the second time of the WGLC for the draft. It would be very helpful to
hear your suggestions during the WGLC window.
Thank you very much
<tp>
Linda,
Sorry about the timing but here goes;
Not Ready IMHO
This is one of six I2NSF I-D with YANG modules and there is a lot of
overlap between them but the functionality offered, the approach taken,
the structuring, the terminology used, varies between them which is
likely to create confusion (and errors) in the user. This I-D is mostly
a list of some 200 YANG identity which then appear in a YANG list to
show what is supported and by implication what is not. (I have
extracted the identity and list them at the end of this e-mail since
much of what I say is clearer when the list is visible in its entirety).
There are similar but different lists of YANG identity in
draft-ietf-i2nsf-customer-facing, draft-ietf-i2nsf-nsf-facing,
draft-ietf-i2nsf-nsf capability.
I find the choice of identifiers here poor. Some have the
suffix -capability, others do not. Given the context in which the
module uses them e.g leaf-list sctp-capability, then I find that suffix
largely redundant. Ditto the suffix -action in the list of anti-ddos.
Most identifier are multi-element e.g.
identity prefix-ipv6-address-flow-direction
and the element order means that they will collate with all the prefix,
range, exact together while ipv6-next-header will be somewhere
different. A user likely needs all the ipv4 together, all the ipv6 etc so the
identifier should be
identity ipv6-address-prefix-flow-direction
so that all the ipv6, sctp, udp etc are together. With YANG, as with
many languages, the distinction between exact and range is moot; exact
is usually modelled with a range with 'start' equal to 'end' so you
could almost assume that both variants are supported and it is certainly
the least important aspect of the identifier so should come last in the
identifier if it is included at all (I would not).
Functionally there are fewer protocols than other I2NSF I-D; http only
appears as a potential flood while draft-ietf-i2nsf-consumer-facing has
ssh, ftp, http, pop3, nat etc and draft-ietf-i2nsf-nsf-facing has ospf,
l2tp, eigrp, skip etc. Are these not some of these capabilities?
YANG allows multiple identity to be derived from a common base which
makes it possible easily to e.g. reference just ip4, or ipv4 and ipv6,
or all such protocols. Not here. ipv4-capability is derived from
'identity condition' along with many other quite different capabilities
such as
identity context-capability {
which renders that YANG capability(!) of little use.
draft-nsf-monitoring by contrast derives tcp, udp, icmp from a common
base of ipv4 or ipv6, both of which are in turn derived from 'identity
ip' which is derived from 'protocol-type' OK I disagree about the
suffiix -type but the structure there is what other IETF YANG modules
widely use and I think right. In this I-D there is no concept of
protocol - the identity for protocol are all derived from 'identity
condition' (along with much else, unrelated concepts IMHO)
identity icmp-capability and identity icmpv6-capability are likewise
both derived from 'identity conditoin' when I would expect them to have
a common icmp base given how much overlap there is between icmp for v4
and icmp for v6 and a likely need to refer the two combined.
I-D nsf-monitoring is quite different here, deriving icmp from a base of
either ipv4 or ipv6, while deriving icmpv4 from ipv4 and icmpv6 from
ipv6. I think that approach much superior both in the choice of
identifiers, icmpv4 and icmpv6 as opposed to icmp and icmpv6, and in
allowing a simple reference to icmp in all its forms along with ipv4 or ipv6
specific when needed.
This I-D models identity ipv4-tos-dscp and identity
ipv6-traffic-class-dscp/identity exact-ipv6-flow-label; nsf-facing has
choices such as minimize-cost, maximize-reliability derived from a
choice of either identity type-of-service or identity traffic-class
which seems to be more in line with current thinking.
With alarms, this I-D is more in line with others but with different
terminology, here it is memory-alarm, cpu-alarm, disk-alarm,
hardware-alarm, interface-alarm. I-D nsf-facing is the same but I-D
nsf-monitoring has mem-usage-alarm, cpu-usage-alarm, disk-usage-alarm,
hw-failure-alarm, ifnet-state-alarm. Not wrong but confusingly
different.
This I-D has context-capability e.g. user, geography, ACL which I
struggle to relate to the other I-D. (In passing, I would have thought ACL a
sine
qua none for any I2NSF work).
This I-D derives identity rule-log, identity session-log from
log-action-capability. nsf-facing is the same but comsumer-facing has
identity log, identity syslog, identity session-log derived from
secondary-action;
Here ingress-action/egress-action/default-action are a common base for
identity pass, identity drop, identity alert, identity mirror while I-D
consumer-facing has primary-action as a base for identities pass, drop,
alert, rate-limit, mirror and I-D nsf-facing has pass, drop, reject,
alert, mirror.
resolution-strategy-capability is the base for identity fmr, identity
lmr, identity pmr, identity pmre, identity pmrn and this is the same as
I-D nsf-facing(!)
This I-D uses advanced-nsf-capability as the base for
anti-virus-capability, anti-ddos-capability, ips-capability,
voip-volte-capability. I-D consumer-facing has security-event-type as a
base for ddos, spyware, trojan, ransomware while I-D nsf-facing uses
content-security-control as a base for firewall, antivirus, ips, ids,
url-filtering, voip-volte, mail-filtering, file-blocking, pkt-capture,
application-control and then I-D nsf-monitoring has nsf-attack-type as
a base for botnet-attack-type and virus-type, and virus-type is then
the base for trojan, worm, macro. Here, antivirus is the base for
identity detect and identity allow-list which for me is a completely
different set of concepts.
Returning to ddos, here the I-D diverge widely. This I-D
has 10 derived identity, with the only appearance of http in the I-D but
which it separates from https; likewise it splits icmp-flood from icmpv6
flood (without a common icmp base) and dns-request from dns-reply, again
the only appearance of the dns protocol and, again, with no common base.
I-D nsf-monitoring uses a base of flood type from which it derives 14
identity adding syn-ack, fin-rst, tcp-con. It keeps the dns-request,
dns-reply but gives a choice of icmp, icmpv4, icmpv6 but does not derive
the last two from the first. (What is meant by 'icmp'? beware, it all
depends on the author, could be v4 could be v4 and v6, you cannot tell).
I-D nsf-facing is quite close to I-D nsf-monitoring for ddos but uses a
base of attack-mitigation-control; joins http and https in identity
http-and-https-flood, splits dns into dns and dns-amp rather than query
and reply, adds oversized-icmp (icmp-... please) and then tacks on
ip-sweep, port-scanning, ping-of-death, teardrop, tracert which may be
attacks but are not ddos and would seem to make no appearance in this
capabilities I-D.
This I-D uses voip-volte-capability as a base for voip-volte-call-id and
identity user-agent. I-D nsf-facing derives identity voip-volte from
content-security-control (not a concept I see in the capabilities I-D)
while draft-ietf-i2nsf-registration-interface-dm would appear to expect
there to be an identity 'voice-id'.
No one I-D on its own is wrong and every I-D has parts that I think just right
- it is just when they are put together
it all gets confusing. What I lack is an underlying information
model which separates out the different concepts and gives them
identifiers for these YANG I-D to use both in nomenclature and it going into
more detail. A monitoring I-D may specify more detailed flood prevention e.g
but I should be able to refer it back to a capability in this I-D. RFC8329 is
not that model.
I append below the list of identity I have extracted from the
capabilities I-D. I think that seeing just the list of identifiers
highlights the challenges a user will have. I have similar lists for
customer-facing, nsf-facing, nsf-monitoring. In YANG the 'base' is
specified after the 'identity' statement. For the purposes of this
review I find it clearer to place the 'base' first and then list the
identity derived from that the base. The order of the identity
statements is the same as in the I-D
Tom Petch
/*
* Identities draft-ietf-i2nsf-capability-data-model-16
*/
base event;
identity system-event-capability {
identity system-alarm-capability {
base system-event-capability;
identity access-violation {
identity configuration-change {
base system-alarm-capability;
identity memory-alarm {
identity cpu-alarm {
identity disk-alarm {
identity hardware-alarm {
identity interface-alarm {
base condition;
identity context-capability {
base context-capability;
identity access-control-list {
identity application-layer-filter {
identity target {
identity user {
identity group {
identity geography {
base directional-capability;
identity unidirectional {
identity bidirectional {
base condition;
identity ipv4-capability {
base ipv4-capability;
identity exact-ipv4-header-length {
identity range-ipv4-header-length {
identity ipv4-tos-dscp {
identity exact-ipv4-total-length {
identity range-ipv4-total-length {
identity ipv4-id {
identity ipv4-fragment-flags {
identity exact-ipv4-fragment-offset {
identity range-ipv4-fragment-offset {
identity exact-ipv4-ttl {
identity range-ipv4-ttl {
identity ipv4-protocol {
identity prefix-ipv4-address-flow-direction {
identity prefix-ipv4-address {
identity prefix-ipv4-src-address {
identity prefix-ipv4-dst-address {
identity range-ipv4-address-flow-direction {
identity range-ipv4-address {
identity range-ipv4-src-address {
identity range-ipv4-dst-address {
identity ipv4-ip-opts {
identity ipv4-geo-ip {
base condition;
identity ipv6-capability {
base ipv6-capability;
identity ipv6-traffic-class-dscp {
identity exact-ipv6-flow-label {
identity range-ipv6-flow-label {
identity exact-ipv6-payload-length {
identity range-ipv6-payload-length {
identity ipv6-next-header {
identity exact-ipv6-hop-limit {
identity range-ipv6-hop-limit {
identity prefix-ipv6-address-flow-direction {
identity prefix-ipv6-address {
identity prefix-ipv6-src-address {
identity prefix-ipv6-dst-address {
identity range-ipv6-address-flow-direction {
identity range-ipv6-address {
identity range-ipv6-src-address {
identity range-ipv6-dst-address {
identity ipv6-header-order {
identity ipv6-options {
identity ipv6-hop-by-hop {
identity ipv6-routing-header {
identity ipv6-fragment-header {
identity ipv6-destination-options {
identity ipv6-geo-ip {
base condition;
identity tcp-capability {
base tcp-capability;
identity exact-tcp-port-num-flow-direction {
identity exact-tcp-port-num {
identity exact-tcp-src-port-num {
identity exact-tcp-dst-port-num {
identity range-tcp-port-num-flow-direction {
identity range-tcp-port-num {
identity range-tcp-src-port-num {
identity range-tcp-dst-port-num {
identity tcp-flags {
identity tcp-options {
base condition;
identity udp-capability {
base udp-capability;
identity exact-udp-port-num-flow-direction {
identity exact-udp-port-num {
identity exact-udp-src-port-num {
identity exact-udp-dst-port-num {
identity range-udp-port-num-flow-direction {
identity range-udp-port-num {
identity range-udp-src-port-num {
identity range-udp-dst-port-num {
identity exact-udp-total-length {
identity range-udp-total-length {
base sctp-capability; [**yes really]
identity exact-sctp-port-num-flow-direction {
identity exact-sctp-port-num {
identity exact-sctp-src-port-num {
identity exact-sctp-dst-port-num {
identity range-sctp-port-num-flow-direction {
identity range-sctp-port-num {
identity range-sctp-src-port-num {
identity range-sctp-dst-port-num {
identity sctp-verification-tag {
identity sctp-chunk-type {
base dccp-capability;
identity exact-dccp-port-num-flow-direction {
identity exact-dccp-port-num {
identity exact-dccp-src-port-num {
identity exact-dccp-dst-port-num {
identity range-dccp-port-num-flow-direction {
identity range-dccp-port-num {
identity range-dccp-src-port-num {
identity range-dccp-dst-port-num {
identity dccp-service-code {
base condition;
identity icmp-capability {
base icmp-capability;
identity icmp-type {
identity icmp-code {
base condition;
identity icmpv6-capability {
base icmpv6-capability;
identity icmpv6-type {
identity icmpv6-code {
base condition;
identity url-capability {
base url-capability;
identity pre-defined {
identity user-defined {
base log-action-capability;
identity rule-log {
identity session-log {
base ingress-action-capability;
base egress-action-capability;
base default-action-capability;
identity pass {
identity drop {
identity alert {
identity mirror {
base egress-action-capability;
identity invoke-signaling {
identity forwarding {
identity redirection {
base resolution-strategy-capability;
identity fmr {
identity lmr {
identity pmr {
identity pmre {
identity pmrn {
base advanced-nsf-capability;
identity anti-virus-capability {
identity anti-ddos-capability {
identity ips-capability {
identity voip-volte-capability {
base anti-virus-capability;
identity detect {
identity allow-list {
base anti-ddos-capability;
identity syn-flood-action {
identity udp-flood-action {
identity http-flood-action {
identity https-flood-action {
identity dns-request-flood-action {
identity dns-reply-flood-action {
identity icmp-flood-action {
identity icmpv6-flood-action {
identity sip-flood-action {
identity detect-mode {
identity baseline-learning {
base ips-capability;
identity signature-set {
identity ips-exception-signature {
base voip-volte-capability;
identity voip-volte-call-id {
identity user-agent {
base ipsec-capability;
identity ike {
identity ikeless {
Linda
-----Original Message-----
From: tom petch <ie...@btconnect.com>
Sent: Tuesday, April 27, 2021 10:44 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; i2nsf@ietf.org
Subject: Re: [I2nsf] Closing the WGLC for
draft-ietf-i2nsf-capability-data-model-16
From: I2nsf <i2nsf-boun...@ietf.org> on behalf of Linda Dunbar
<linda.dun...@futurewei.com>
Sent: 27 April 2021 16:06
I2NSF WG,
As expected, there is no issue with the second time WGLC for
draft-ietf-i2nsf-capability-data-model.
<tp>
Sigh, I did not know there was a Last Call in progress, I did not see that on
the datatracker:-( I spent last week going round in circles trying to dovetail
the five I2NSF YANG modules and this morning finally decided that it could not
be done.
The general concern I have is that there are a number of YANG modules that are
doing the same thing in different ways, with different terminology, different
technology, which is going to give the user heartache IMHO
Today I read RFC8329 hoping that it would give one clear set of right
terminology but it does not help much; thus s.9.2 therein is rather vague with
question marks in places. The various YANG modules are clearly in the same
ballpark as the RFC but perhaps not on the same base e.g. the RFC has pass,
deny, mirror while this I-D has pass, drop, alert, mirror and differences like
that are repeated many times. In places, that may be by design but in others I
believe that it is not I will post some more concrete examples on Wednesday.
I will seek to use 'capability' as the base, the refer4ence, and point out
where the other four diverge
I would say that sdn-ipsec gets it right but I also note that the IESG made in
excess of 150 changes to the I-D before approving it which I think on the one
hand was necessary but on the other hand seems a profligate use of AD time.
More could have been done beforehand IMHO.
Tom Petch
This email is to confirm that the WGLC for the
draft-ietf-i2nsf-capability-data-model-16 is completed. We will move this draft
to IESG.
Thank you very much for the work.
Best Regards,
Linda Dunbar
From: Linda Dunbar
Sent: Tuesday, March 30, 2021 4:37 PM
To: i2nsf@ietf.org
Subject: WGLC for draft-ietf-i2nsf-capability-data-model-16
Hello Working Group,
When I2NSF WG closed the WGLC for draft-ietf-i2nsf-capability-data-model in
Dec 2019
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fi2nsf%2F%3Fq%3Ddraft-ietf-i2nsf-capability-data-model%26f_from%3DLinda%2520Dunbar&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416364721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=gTCjj1AgX850nVjMqwhSUYpi261P%2FIEPVEDlzY%2FuVs8%3D&reserved=0
), there was a formative reference to draft-ietf-i2nsf-capability-05 which was
stale.
After the review, IESG decided to throw the draft back to I2NSF WG and
requested the WG to reach the consensus to sunset the
draft-ietf-i2nsf-capability-05. The WG finally reached the consensus in Oct
2020
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fi2nsf%2F%3Fq%3Ddraft-ietf-i2nsf-capability-data-model%26f_from%3DLinda%2520Dunbar&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=CwsgBrh%2FRpLX2x5TP%2BplrmO1ckr3VO4F56TN21h5LOM%3D&reserved=0)
Many thanks to the authors to merge all the relevant content from
draft-ietf-i2nsf-capability-05 and addressed all the comments from YANG Doctor
review and
This email starts a two-weeks Working Group Last Call on
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RDAu7tXiFbH1WtgyJo2KL1idgWJ3s6pwQjVvJ60TLM8%3D&reserved=0
This poll runs until April 13, 2021.
We are also polling for knowledge of any undisclosed IPR that applies to this
Document, to ensure that IPR has been disclosed in compliance with IETF IPR
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document, please
respond to this email and indicate whether or not you are aware of any relevant
undisclosed IPR. The Document won't progress without answers from all the
Authors and Contributors.
If you are not listed as an Author or a Contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.
Thank you.
Linda & Yoav
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
