Re: [I2nsf] IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm

[Linda Dunbar]

Tom,

Consumer facing Interface commands don't need to differentiate v4 or v6.
For example Kubernetes Cluster Scoped Network Policies use Cluster names, not 
even the IP addresses:  
https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/edit#slide=id.g401c104a3c_0_0

Comments and replies are inserted below:


-Original Message-
From: t petch 
Sent: Friday, April 1, 2022 6:08 AM
To: Linda Dunbar ; Roman Danyliw ; 
i2nsf@ietf.org
Cc: Patrick Lingga ; Mr. Jaehoon Paul Jeong 

Subject: Re: IETF 113 session in comparing 
draft-ietf-i2nsf-consumer-facing-interface-dm & 
draft-ietf-i2nsf-nsf-facing-interface-dm

On 28/03/2022 18:23, Linda Dunbar wrote:
> Tom,
>
> As Sue Hares said:
>
>   "The first stage of a yang model is joyous. You decide what goes in.   The
>   second of getting a prototype yang model  implementation is hard work.  The
>   third stage of getting the model approved in the IETF environment is
>   frustrating and painful.During the second and third stage, most WGs have
>   trouble keeping up the energy - since it is all about the small details of
>   Yang."
>
> All the I2NSF YANG models are at their third stage, with small changes, which 
> is difficult for non-editors to keep up.
> Can you review Paul and his team revisions before they upload revision?

Linda

I continue to see capability as the core I-D which the other I-D are then based 
on and I still see an outstanding DISCUSS against it.  I am unclear whether or 
not capability -26 (or -29 AFAICT) addresses Ben's point, that the meaning of a 
capability is not sufficiently defined in a way that will bring 
interoperability.
[Linda] Agree with you that capability should be the base that other I-D can 
references. But for attributes that unique to a specific interface, they should 
be specified in their corresponding I-D.


As an example, capability specifies icmpv4 and icmpv6 and then uses these two, 
along with DCCP, as base for identity type. consumer-facing has a single 
icmp-message, no differentiation between icmpv4 and icmpv6, and derives from it 
echo and echo-reply, each of which is for both
icmpv4 and icmpv6.
[Linda] Consumer facing Interface commands should be allowed to use more 
abstract name. Doesn't need to nail down to v4 or v6. It is the security 
Controller's job to translate to the corresponding icmpv4 or icmpv6 depending 
on the security function supports ipv4 or IPv6.

If a simple box supports icmpv4 only and echo/echo-reply only, what capability 
does that constitute? (How does a user know that DCCP is not supported?).
[Linda] At the consumer interface level, users might not need to know if DCCP 
is supported or now. Not sure why users need to know if DCCP is supported or 
not?


With hindsight, Ben's question is so obvious I wonder how I did not see it.  I 
think that it applies to much of capability (e.g. http, as another AD 
suggested).  I believe that the question can be addressed by text, as opposed 
to revamping the model (such as by taking the identity structure to a finer 
level of detail) but I am not the one with a DISCUSS - it is up to the IESG to 
be satisfied by whatever resolution is proposed.  Perhaps they will be 
satisfied with capability-26 but it is now for them to say.
[Linda] I hope authors can address the AD's concern.

Thank you very much for helping shaping the data model. Really appreciate your 
help.
Linda


Tom Petch



>
>   Thank you very much for your continued support to improve the YANG models.
>
> Linda
>
> -Original Message-
> From: t petch mailto:ie...@btconnect.com>>
> Sent: Friday, March 25, 2022 12:10 PM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; Roman Danyliw
> mailto:r...@cert.org>>; i2nsf@ietf.org
> Cc: Patrick Lingga 
> mailto:patricklink...@gmail.com>>; Mr. Jaehoon Paul 
> Jeong
> mailto:jaehoon.p...@gmail.com>>
> Subject: Re: IETF 113 session in comparing
> draft-ietf-i2nsf-consumer-facing-interface-dm &
> draft-ietf-i2nsf-nsf-facing-interface-dm
>
> On 25/03/2022 14:39, Linda Dunbar wrote:
>> Tom,
>>
>> At IETF 113 I2NSF session, we had a good discussion of the comparison of 
>> draft-ietf-i2nsf-consumer-facing-interface-dm & 
>> draft-ietf-i2nsf-nsf-facing-interface-dm, from Top Level YANG Tree, Event, 
>> Condition and Action.
>>
>> Here is the summary:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
>> a
>> tracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-i2nsf-compa
>> r
>> ison-of-consumer-facing-and-nsf-facing-data-models-00data=04%7C0
>> 1
>> %7Clinda.dunbar%40futurewei.com%7Cb8b83f05fa904d406b2008da0e824533%7C
>> 0
>> fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637838249925611459%7CUnknow
>> n
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>> J
>> XVCI6Mn0%3D%7C3000sdata=PpLBu4%2FqvNKaNfjTmtBZQlL6%2B3zjHcx815DA
>> 3
>> IqzG74%3Dreserved=0
>>
>> Since you didn't join the discussion, can you please look over the 
>> 

Re: [I2nsf] Request for Review of I2NSF NSF-Facing Interface YANG Data Model Draft

[Alexey Melnikov]

Hi Paul,

On 21/03/2022 12:36, Mr. Jaehoon Paul Jeong wrote:
Hi Alexey, Jean-Michel, Erik, Martin, Éric, Francesca, Robert, Murray, 
and Zaheduzzaman,

Here is the revised draft of I2NSF NSF-Facing Interface YANG Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-22

I attach the revision letter to explain how Patrick and I have 
reflected your comments.
In the 1st page of the revision letter, there is an index table to 
mark the start page

of the comments and responses for each reviewer.
If each of you is satisfied with the revision, please let us know and 
update the status of your stance on this draft.


You pretty much addressed all of my comments. One of your changes has 
improved existing text, but it is still not quite clear enough:


 leaf-list exception-files {
   type string;
   description
 "The type or name of the files to be excluded by the
  antivirus. This can be used to keep the known
  harmless files.
  If the value starts with a regular expression (e.g.,
  '*.exe'), the antivirus should interpret it as a
  file pattern/type to be excluded.
  If the value does not start with a dot (e.g.,
  'example.exe'), the antivirus should interpret it as
  a file name/path to be excluded.";
 }
   }

I think the above raises a question of what is a regular expression? Adding a 
specific reference would help, as there are variety of syntaxes used for 
regular expressions.

Best Regards,

Alexey
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm

[t petch]

On 28/03/2022 18:23, Linda Dunbar wrote:

Tom,

As Sue Hares said:

  "The first stage of a yang model is joyous. You decide what goes in.   The
  second of getting a prototype yang model  implementation is hard work.  The
  third stage of getting the model approved in the IETF environment is
  frustrating and painful.During the second and third stage, most WGs have
  trouble keeping up the energy - since it is all about the small details of
  Yang."

All the I2NSF YANG models are at their third stage, with small changes, which 
is difficult for non-editors to keep up.
Can you review Paul and his team revisions before they upload revision?


Linda

I continue to see capability as the core I-D which the other I-D are 
then based on and I still see an outstanding DISCUSS against it.  I am 
unclear whether or not capability -26 (or -29 AFAICT) addresses Ben's 
point, that the meaning of a capability is not sufficiently defined in a 
way that will bring interoperability.


As an example, capability specifies icmpv4 and icmpv6 and then uses 
these two, along with DCCP, as base for identity type. consumer-facing 
has a single icmp-message, no differentiation between icmpv4 and icmpv6, 
and derives from it echo and echo-reply, each of which is for both 
icmpv4 and icmpv6.


If a simple box supports icmpv4 only and echo/echo-reply only, what 
capability does that constitute? (How does a user know that DCCP is not 
supported?).


With hindsight, Ben's question is so obvious I wonder how I did not see 
it.  I think that it applies to much of capability (e.g. http, as 
another AD suggested).  I believe that the question can be addressed by 
text, as opposed to revamping the model (such as by taking the identity 
structure to a finer level of detail) but I am not the one with a 
DISCUSS - it is up to the IESG to be satisfied by whatever resolution is 
proposed.  Perhaps they will be satisfied with capability-26 but it is 
now for them to say.


Tom Petch





  Thank you very much for your continued support to improve the YANG models.

Linda

-Original Message-
From: t petch 
Sent: Friday, March 25, 2022 12:10 PM
To: Linda Dunbar ; Roman Danyliw ; 
i2nsf@ietf.org
Cc: Patrick Lingga ; Mr. Jaehoon Paul Jeong 

Subject: Re: IETF 113 session in comparing 
draft-ietf-i2nsf-consumer-facing-interface-dm & 
draft-ietf-i2nsf-nsf-facing-interface-dm

On 25/03/2022 14:39, Linda Dunbar wrote:

Tom,

At IETF 113 I2NSF session, we had a good discussion of the comparison of 
draft-ietf-i2nsf-consumer-facing-interface-dm & 
draft-ietf-i2nsf-nsf-facing-interface-dm, from Top Level YANG Tree, Event, 
Condition and Action.

Here is the summary:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
tracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-i2nsf-compar
ison-of-consumer-facing-and-nsf-facing-data-models-00data=04%7C01
%7Clinda.dunbar%40futurewei.com%7Cb8b83f05fa904d406b2008da0e824533%7C0
fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637838249925611459%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
XVCI6Mn0%3D%7C3000sdata=PpLBu4%2FqvNKaNfjTmtBZQlL6%2B3zjHcx815DA3
IqzG74%3Dreserved=0

Since you didn't join the discussion, can you please look over the comparison 
and see if they are any issues?


Linda

I did look at the slides when they arrived.

What I deduced some time ago, and see that the current charter specifies, is 
that it is the Capability Layer that has primacy, that 'Only simple Service 
Layer policies that are modelled as closely as possible on the Capability Layer 
are within scope.'  It is then a question not of how close Consumer Facing and 
Network Facing are (and yes, they are close) but how close each is to 
Capability.  I note that since I reviewed capability-26 there have been three 
new versions of that and that the IESG have yet to confirm that the DISCUSS on 
capability have been resolved; and while -29 has a change log - good - it only 
gives the changes from -28 (best practice IMHO is have a change log going back 
to the -00 that precedes adoption) so I have to look at
-27 to see what it changed and -28 to see what it changed (and no, I do not 
want a .pdf giving OLD and NEW; a statement that e.g. references to
RFC4960 have been replaced with references to rfc4960bis I find much quicker to 
deal with).

So, when the IESG are satisfied with capability I will look at the current 
version and the others that have come out in-between and then look at the other 
I-D after that; and yes, the I-D will likely be in the RFC Editor Queue by 
then:-(.

IN passing, a comment that others have made and which I would endorse is that 
the authors seem unfamiliar with the usage of 'i.e.' and 'e.g.'
which in places changes the technical meaning.  I suspect that that will still 
be the case in the most recent I-D.

Tom Petch


Thank you very much,

Linda Dunbar

-Original Message-
From: t petch mailto:ie...@btconnect.com>>
Sent: Monday, March 21, 2022 

Re: [I2nsf] What does "not subscribe to the basic tenet of 'reference not replicate'" mean? FW: Request for Comments, Interest and Support in I2NSF Re-Chartering

[Mr. Jaehoon Paul Jeong]

Hi Tom,
I see your point.
A common YANG module approach can be done
after the set of the current five I2NSF YANG I-Ds
are published as RFCs and they are augmented to
accommodate new protocols such as QUIC and HTTP/3.

Linda,
Could you submit the I-Ds of Consumer-Facing Interface and Registration
Interface to the IESG?

We will be able to accommodate Tom's common YANG module approach in the 2nd
phase of our I2NSF WG.

Thanks.

Best Regards,
Paul

2022년 4월 1일 (금) 오후 7:46, t petch 님이 작성:

> On 30/03/2022 10:47, Mr. Jaehoon Paul Jeong wrote:
> > Hi Linda and Tom,
> > I think we can handle the replication problem that may cause the
> > inconsistent description of each identity
> > that is used by Capability, NSF-Facing Interface, and Consumer-Facing
> > Interface YANG data models by
> > referencing the Capability data model as the base of I2NSF's data models
> as
> > follows.
> > ---
> > Capability data model:
> >
> >identity reject {
> >  base ingress-action;
> >  base egress-action;
> >  base default-action;
> >  description
> >"The reject action denies a packet to go through the NSF
> > entering or exiting the internal network and sends a response
> > back to the source. The response depends on the packet and
> > implementation. For example, a TCP packet is rejected with
> > TCP RST response or a UDP packet may be rejected with an
> > ICMPv4 response message with Type 3 Code 3 or ICMPv6 response
> > message Type 1 Code 4 (i.e., Destination Unreachable:
> > Destination port unreachable).";
> >}
> > ===
> >
> > Consumer-Facing Interface data model:
> >
> >identity reject {
> >  base ingress-action;
> >  base egress-action;
> >  base default-action;
> >  description
> >"The reject action.";
> >  reference
> >"draft-ietf-i2nsf-capability-data-model-29:
> > I2NSF Capability YANG Data Model - Reject Action";
> >}
> > ---
> >
> > Tom,
> > Is this approach good for you?
>
> Well, it is a step forward, in the right direction, but I see it only as
> an interim solution, that in the longer term those action identity,
> along with some other identity, belong in a common YANG module with
> supporting text in a separate I-D for other I-D to import from but that
> that approach is not something to undertake for the current set of I-D.
>
> Tom Petch
>
> > If so, I will update the Consumer-Facing Interface YANG Data Model Draft
> > accordingly.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul
> >
> >
> >
> > On Wed, Mar 30, 2022 at 7:52 AM Linda Dunbar  >
> > wrote:
> >
> >> Paul,
> >>
> >> Do you understand what Tom Petch mean by saying "*they do not subscribe
> >> to the basic tenet of 'reference not replicate'*"?
> >>
> >> *"**Those that have worked on the current five I2NSF I-D will know that
> >> they do not subscribe to the basic tenet of 'reference not replicate'
> and
> >> in doing so have created many issues of lack of coherence (some of which
> >> have been resolved, some of which may never be resolved) and have
> created
> >> much additional work.  In a sense, the current work is built on
> foundations
> >> of sand, which may or may not support ongoing work.**"*
> >> Linda
> >>
> >> -Original Message-
> >> From: I2nsf  On Behalf Of t petch
> >> Sent: Friday, March 25, 2022 4:05 AM
> >> To: Mr. Jaehoon Paul Jeong ; i2nsf@ietf.org
> >> Cc: Roman Danyliw ; Panwei (William) <
> >> william.pan...@huawei.com>; Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de>;
> >> tom petch ; DIEGO LOPEZ GARCIA <
> >> diego.r.lo...@telefonica.com>; Susan Hares ;
> yangpenglin
> >> 
> >> Subject: Re: [I2nsf] Request for Comments, Interest and Support in I2NSF
> >> Re-Chartering
> >>
> >> On 24/03/2022 07:38, Mr. Jaehoon Paul Jeong wrote:
> >>> Hi I2NSF WG,
> >>> As you know, our I2NSF WG will discuss the I2NSF Re-Chartering at
> >>> IETF-113 I2NSF WG Session today.
> >>>
> >>> I attach the text of the re-chartering as pdf and txt files.
> >>
> >> Those that have worked on the current five I2NSF I-D will know that they
> >> do not subscribe to the basic tenet of 'reference not replicate' and in
> >> doing so have created many issues of lack of coherence (some of which
> have
> >> been resolved, some of which may never be resolved) and have created
> much
> >> additional work.  In a sense, the current work is built on foundations
> of
> >> sand, which may or may not support ongoing work.
> >>
> >> What is needed, and for me it is the overwhelming priority, before any
> new
> >> models are crafted, is a 'common' I-D to reduce or eliminate this
> >> replication even if it cannot be applied immediately to those five I-D.
> >>The current charter hints at the need for this in its bullets and in
> its
> >> list of deliverables.  The terminology draft might have done this but
> has
> >> 

Re: [I2nsf] Narrowing down the scope of work for the I2NSF Re-Chartering

[Mr. Jaehoon Paul Jeong]

Hi Linda and Yoav,

I would say that the theme of this I2NSF Re-Chartering is "Security
Management Automation".
This theme is based on 7-year I2NSF standardization and hackathon projects
with our I2NSF WG colleagues.

May I suggest three more work items in addition to your proposed work items?

The following three work items can be handled with focus along with the
CCed I2NSF WG colleagues
as coauthors and contributors:
---
1. Security Service Management through Leveraging I2NSF Framework and
Interfaces
- Main Contents
 . An Extension of I2NSF Framework for Intelligent Security Management
Automation
 . Distributed Auditing Services for Supply Chain Attacks and Insider
Attacks by Distributed Ledger Technology (DLT) and Remote Attestation
 . Support of Containers for I2NSF in Cloud Native Systems
 . Support of Other Contemporary Technologies for I2NSF such as Quantum Key
Distribution (QKD) and Post Quantum Cryptography (PQC)

2. I2NSF Application Interface YANG Data Model
- Main Contents
 . A New I2NSF Interface for Feedback-control-loop-based Security
Management Automation
 . Support of Feedback Information Delivery from I2NSF (Data) Analyzer to
Security Controller for Security Policy Augmentation and Generation

3. Guidelines to Security Policy Translation for I2NSF-Based Security
Enforcement
- Main Contents
 . A Relation between I2NSF Consumer-Facing Interface and NSF
Facing-Interface
 . Handling of Default Actions for a High-level Security Policy to be
translated to a Low-level Security Policy
 . Population of Information for Security Policy Translation (e.g., mapping
of IP addresses for users and devices)
 . Implementation Guidelines for Security Policy Translator (will be put as
Appendix rather than main text)
---

As you know, my SKKU team with ETRI demonstrated the feasibility of those
three work items through the past I2NSF Projects.

For the 1st work item, this provides autonomous security management
services to minimize human engagement for security services.
The I2NSF extension for this autonomous security management is explained by
my new I2NSF I-D:
https://datatracker.ietf.org/doc/html/draft-jeong-i2nsf-security-management-automation-03

As a use case, a new outside (or inside) security attack is detected and
blocked by an I2NSF system.
For this, an NSF reports monitoring data of a suspicious activity to an
I2NSF Analyzer (as a new component which is
a data collector and a data analyzer with machine learning), which is
defined in the above I-D.

The I2NSF Analyzer analyzes the monitoring data and diagnoses what is a
problem or security attack.
The I2NSF Analyzer makes a feedback report to a Security Controller so that
the Security Controller can augment
its existing security policy or generate a new security policy to cope with
the problem or security attack.

The involved security functions include the following steps:
1. The monitoring data delivery from an NSF to an I2NSF Analyzer,
2. The analysis of the monitoring data at the I2NSF Analyzer,
3. The construction of a feedback report by the I2NSF Analyzer,
4. The delivery of the feedback report from the I2NSF Analyzer to the
Security Controller,
5. The interpretation/translation of the feedback report at the Security
Controller, and
the augmentation of an existing security policy (or the generation of a new
security policy) by the Security Controller, and
6. The delivery of the augmented (or generated) security policy to an
appropriate NSF.

These steps are explained in the above I-D. I have explained them in the
presentation of I2NSF Re-chartering slides
during the IETF-113 I2NSF WG Session.

For the support of the containers for I2NSF NSFs, the interface to security
functions on Container will be the same
with that to the security functions on VM.
However, the operation and management of I2NSF in container deployment can
be specified in the document.
Here is my I2NSF I-D for Cloud Native Systems for your reference:
https://datatracker.ietf.org/doc/html/draft-yang-i2nsf-nfv-architecture-07#page-11

I CC Dr. Kyoungjae Sun and Dr. Hyunsik Yang as the authors of this I-D for
the Cloud Native Systems for I2NSF
since they are experts in this domain.

For the support of Other Contemporary Technologies, "Quantum Key" can be
distributed to NSFs through Security Controllers.
The work of RFC 9061 (A YANG Data Model for IPsec Flow Protection Based on
Software-Defined Networking (SDN))
can be extended for this key distribution.

For the 2nd work item, I2NSF Application Interface delivers a feedback
report containing feedback information as
a high-level policy to describe a problem or security attack rather than
monitoring data.
The Application