Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Oct 2016 22:21:46 +0100

Working Group,

Linda and I would like to hear some more from you about
draft-zhang-i2nsf-info-model-monitoring.

Is it something you think we should be working on?
Should we have a separate YANG module for it or fold it into other modules?
If we produce a YANG module, do we still need to publish the information model?

And, most important, what do you think of the content of the draft?

Thanks,
Adrian

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 12 Oct 2016 10:10:10 +0000

Hi Adrian,
As a co-author of the draft, my thoughts are as follows:
* We need the standardization for the data model of monitoring interface. The monitoring interface plays a very important role of collecting NSF status, malicious events, etc, for the I2NSF architecture if done in a timely and comprehensive way;
* the information model is necessary to explain which information are needed for monitoring interface, and why and how to design their classification, their attributes, etc. It's an important base and useful complement for the final data model.

B.R.
Frank

-----邮件原件-----
发件人: I2nsf [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2016年10月12日 5:22
收件人: [email-masked]
主题: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Working Group,

Linda and I would like to hear some more from you about draft-zhang-i2nsf-info-model-monitoring.

Thanks,
Adrian

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Rakesh Kumar <[email-masked]>
Date: Wed, 12 Oct 2016 15:49:27 +0000

Hi WG chairs,

Monitoring is a key piece of overall security framework. In order to build and maintain a dynamic and proactive security posture, it is very critical to monitor various activities and gather information from various sources. This information is used by security analytic engines to look for any warning signs missed by traditional security policies.

To simply state, monitoring is a key element of defense-in-depth security architecture. It must be a part of I2NSF working group, so that security applications can get the required information using I2NSF WG interfaces instead of relying on vendor/developer proprietary interfaces.

Regards,
Rakesh

On 10/11/16, 2:21 PM, "I2nsf on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Working Group,

    
    
    Thanks,
    Adrian

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 13 Oct 2016 15:35:35 +0800

>Is it something you think we should be working on?

Yes. Monitoring is very helpful for the network operators to understand
the network security state, and the dynamic running state of the Network
Security Function. The security analysis engine can utilize these
information to achieve better security management. It is a quite important
feature for I2NSF.

>If we produce a YANG module, do we still need to publish the information

Information model is the basic structure for YANG module, and other
modules.

Even we produce a YANG module, we still need to publish the information
model, since the information model is the basic block.

> And, most important, what do you think of the content of the draft?

It is a good document to start with.

About the contents of the draft, I have some suggestions:

1) I notice that for some data elements, it only lists some examples. It
will be better to list the enumerations. For example, message_type,
severity. 

2) For some elements, it is better to specify the data units. For example,
CPU_usage, memory_usage, disk_usage, disk_left.

Kind Regards
Kepeng

> 
>
>On 10/11/16, 2:21 PM, "I2nsf on behalf of Adrian Farrel"
><[email-masked] on behalf of [email-masked]> wrote:
>
>    Working Group,
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Oct 2016 09:49:22 -0400

Adrian: 

Why: Monitoring is a key component to I2NSF for monitoring NSF devices.  
Monitoring is not the same as NSF devices sending notifications - which is a
push from the NSF devices.  Monitoring may encompasses specific requests to
the device.   Monitoring is different than the DOTS - "help me" cry from a
device under attack.
While I see the security ADs are proposing Security event, it is important
that the I2NSF create monitoring concepts that work with all of the
functions (e.g. querying capabilities, sending/receiving notification, and
events). 

Data model versus Information model:  Since we do not seem to have a clear
idea of what the data model should be, it is important to create the
informational models.  

The content of the draft is a good first step. 

Sue Hares 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, October 11, 2016 5:22 PM
To: [email-masked]
Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Working Group,

Is it something you think we should be working on?
Should we have a separate YANG module for it or fold it into other modules?
If we produce a YANG module, do we still need to publish the information
model?

Thanks,
Adrian

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 20 Oct 2016 22:35:44 -0400

Adrian and Linda,

I have made a detailed review of this draft through sec 6.  I hope to 
finish tomorrow.  I have sent my comments so far to the authors.  Most 
are to clear up the text.

As such:

This is a valuable document that a YANG model alone document would not 
provide.  It may be after I read the next few sections that I might feel 
some of that part belongs in a YANG draft.  But the first few sections 
are definitely needed in I2NSF.

Bob

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 22 Oct 2016 12:03:14 +0000

Hi,

Fully agree with Susan here, especially when it comes to differentiating this from DOTS and Security Event concepts.

Some could see this related with attestation mechanisms because this monitoring implies an information flow about NSF status going from NSF to the SC, but there are key differences between both procedures. Basically, attestation is used to establish a level of trust on the NSF before it starts running, while monitoring has to deal with runtime conditions and not with the establishment of trust.  A possible point of contact could be continuous attestation, but it should be considered a particular kind of monitoring performed by a (trusted) third party, and I would avoid complicating the monitoring definition with the necessary attestation considerations, though continuous attestation could share some of the information model once agreed.

A couple of additional comments:

1) This draft (as many other) has to be reviewed once the terminology on interfaces becomes stable

2) Taking into account the reflection on information and data models made by Adrian and that I replied, I’d like to remark that the first sections of this document are the perfect example of the text that should be published, as an introduction to the data model or elsewhere, if we decide not to go for standalone information model publication.

Be goode,

On 13 Oct 2016, at 15:49 , Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Adrian:

Sue Hares

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, October 11, 2016 5:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Working Group,

Thanks,
Adrian

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 23 Oct 2016 11:32:47 -0400

I have completed my review and sent my comments to the authors.

I am struggling with the whole monitoring business.  What is the 
framework?  What is the responsiblilty of each workgroup ?  Note this 
draft completely missed RFC5424.

Bob

On 10/20/2016 10:35 PM, Robert Moskowitz wrote:
> provide.  It may be after I read the next few sections that I might 
> feel some of that part belongs in a YANG draft.  But the first few 
> sections are definitely needed in I2NSF.
>
> Bob
>
>