Re: [mile] Request for draft reviews - review of FC5070-bis

["Takeshi Takahashi" <[e-mail]>]

Hi Daniel and all,

Though the discussion is on IODEF-bis rather than IODEF-SCI, I hope you do
not mind sharing my opinion here :)

> Would these be worth considering in the IODEF incident schema?
I agree.

> An incident classification level or assurance level for each incident?
I feel that the assurance or trustworthiness of the information is something
we could consider outside IODEF document.
The sender can describe "Confidence" instead of the trustworthiness.
(E.g., I cannot say that I myself is very trustworthy sender of the
information, but I can say that I am confident on the information. Receiver
can judge whether he/she trust me or not.)

> Mac address of reporting device?

I think it is good idea.
The "person" who reports IODEF document could be a machine, such as IDS.
For instance, we could reconsider the structure of "Contact" class.

> A field for whether any device is virtual or physical?

I agree.

> A hash of each incident raw data?
> Memory address space field (as you have PID)?

I agree on the usefulness of these information.
Instead of extending IODEF itself, we could consider using external schema
for that purpose.
These could be then embedded into IODEF document through the use of
IODEF-SCI.

> NTP Time source of the incident device?

I agree.

> In the example above in Appendix III below should the service IP protocol
be 4?

I've used the example described in the RFC5070, and I didn't realize this
point.
Thank you for pointing it out.

Kind wishes,
Take



From: [e-mail] [mailto:[e-mail]] On Behalf Of
Daniel Piggott
Sent: Friday, June 14, 2013 9:31 PM
To: 'Panos Kampanakis (pkampana)'; 'Moriarty, Kathleen'; [e-mail];
[e-mail]
Subject: Re: [mile] Request for draft reviews - review of FC5070-bis

Hello, is there any update to my response to the document reviewed below?
Sent 6th June 22:57? Kathleen informed me it only made part of the
distribution list.
Thks
Daniel

Structured Cybersecurity Information draft (close to final):
http://datatracker.ietf.org/doc/draft-ietf-mile-sci/

Having looked through this draft and the example  11.  Appendix III: An XML
Example

Would these be worth considering in the IODEF incident schema?

An incident classification level or assurance level for each incident?
Mac address of reporting device?
A field for whether any device is virtual or physical?
A hash of each incident raw data?
Memory address space field (as you have PID)?
NTP Time source of the incident device?

In the example above in Appendix III below should the service IP protocol be
4?

System category="target">
          <Node>
            <Address category="ipv4-net">192.0.2.16/28</Address>
          </Node>
          <Service ip_protocol="6">
            <Port>80</Port>
          </Service>

And one last question, if the receiving node getting the alerts via IODEF
goes offline

From: Panos Kampanakis (pkampana) [mailto:[e-mail]] 
Sent: 06 June 2013 19:26
To: Moriarty, Kathleen; [e-mail]; '[e-mail]'
([e-mail])
Subject: Re: [mile] Request for draft reviews - review of FC5070-bis


Hi Paul,

Good starting point. Some comments and nits below from my first pass.
There should be more when I review again.

I remember sometime in the past there was a discussion  about what is an
incidents if that should be updated in the 5070. I see that in your draft an
incident is used as it was in 5070. I was just wondering if we had reached a
consensus on it.

I also didn’t see “uid” and “set id” definitions in the draft.

I don’t see the EMailDetails class described in the document.

Nits:
- Should “This document contains changes with respect to its predecessor
      RFC5070:” be bulleted?
- The list in “This class will contain indicators from
      the list below ” is not exactly below. The same for “the
      following included indicators are ones commonly used ”. And the same
for me occurrences of “following” in this section
- I am not sure if we want to keep the “<!-- CHANGE:” comments in the draft
- there are some XML complexType like “SoftwareType” that are described as
classes in the comments IODEF schema, but these are not classes.

I aqlso see that you will have usecases-examples in this doc, so mayne I
will remove mine from the guidance document.

Rgs,
Panos



From: [e-mail] [mailto:[e-mail]] On Behalf Of
Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To: [e-mail]
Subject: [mile] Request for draft reviews

Greetings!
 
We have had a number of documents updated since the last meeting.  Thank you
to all of the editors for making the requested changes!  The current list of
drafts up for review (including those that will be a part of the WG after
the charter update) include:
 
RFC5070-bis (IODEF Revision):
http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/
 
Draft on IODEF Guidance:
(input from experience, real use cases, and draft review will be helpful)
http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/
 
Structured Cybersecurity Information draft (close to final):
http://datatracker.ietf.org/doc/draft-ietf-mile-sci/
 
IODEF Enumeration Reference Format:
http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/
 
Resource-Oriented Lightweight Indicator Exchange (ROLIE): 
http://datatracker.ietf.org/doc/draft-field-mile-rolie/
 
Please take some time to review the drafts and provide feedback to the
list.  It would be helpful if we can iterate on most of them prior to the
next meeting.  A couple of the drafts are very close to being done.  The
list of current drafts and published RFCs can be found at the following
link:
http://datatracker.ietf.org/wg/mile/
 
We will follow up soon on the charter update as well.
 
Thank you all in advance!
Kathleen