Re: [I2nsf] Closing the WGLC for draft-ietf-i2nsf-capability-data-model-16

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Tom,
I will try to analyze your new comments and address them in the revision.

Linda,
Let me address Tom's comments on the revision before submitting this NSF
capability draft to the IESG.

Thanks.

Best Regards,
Paul

2021년 4월 28일 (수) 오후 8:45, tom petch <[e-mail]>님이 작성:

> From: Linda Dunbar <[e-mail]>
> 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 <[e-mail]>
> Sent: Tuesday, April 27, 2021 10:44 AM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Subject: Re: [I2nsf] Closing the WGLC for
> draft-ietf-i2nsf-capability-data-model-16
>
> From: I2nsf <[e-mail]> on behalf of Linda Dunbar <
> [e-mail]>
> 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: [e-mail]
> 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&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416364721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=gTCjj1AgX850nVjMqwhSUYpi261P%2FIEPVEDlzY%2FuVs8%3D&amp;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&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=CwsgBrh%2FRpLX2x5TP%2BplrmO1ckr3VO4F56TN21h5LOM%3D&amp;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&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2db646bb15a843e2627508d909934590%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637551350416374715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RDAu7tXiFbH1WtgyJo2KL1idgWJ3s6pwQjVvJ60TLM8%3D&amp;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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>