Incident Object Description Exchange Format Usage Guidance
draft-ietf-mile-iodef-guidance-11

Received changes through RFC Editor sync (created alias RFC 8274, changed abstract to 'The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) .  Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing.  This document provides guidelines for IODEF implementers.  It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used.  This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world.', changed pages to 33, changed standardization level to Informational, changed state to RFC, added RFC published event at 2017-11-20, changed IESG state to RFC Published)

[Ballot comment]
I agree with the other comments that this reads like a BCP, and should probably be re-characterized.

The diagram in section 3.1 (which I would like to refer to by number but cannot -- consider adding figure numbers) appears to be using UML. While many software engineers will be familiar with this notation, it's likely that many also will not. A citation to ISO/IEC 19501:2005 to explain the meaning of the various symbols may be appropriate.

Section 3.1 says "Implementers can refer to Appendix B and Section 7 of [RFC7970]..." which is ambiguous: it reads as if it is directing readers to Appendix B of RFC7970. I think it means Appendix B of this document. Suggest: "Implementers can refer to Section 7 of [RFC7970] and Appendix B...".

Section 3.2 refers to the use of external schemata for reporting certain types of events. I would have expected to see guidance here (and/or in Section 4.2) indicating that the event report should be useful even for those implementations that don't comprehend these external schemata (unless this guidance already exists in the base IODEF definition; in which case, feel free to silently ignore this comment).

It would be useful to provide a definition of the term "spear-phishing."

____

I assume the version of the ID Nits tool used to check this document varies from the one at . The following issues appear to be legitimate problems in need of addressing. If formatting of the XML documents without adding line breaks is considered critical (which seems possible but unlikely), consider base64-encoding them.

  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  ** There are 28 instances of too long lines in the document, the longest
    one being 53 characters in excess of 72.

  ** The abstract seems to contain references ([RFC7970]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  == There are 2 instances of lines with private range IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
    198.51.100.x or 203.0.113.x.

[Ballot comment]
I agree with the other comments that this reads like a BCP, and should probably be re-characterized.

The diagram in section 3.1 (which I would like to refer to by number but cannot -- consider adding figure numbers) appears to be using UML. While many software engineers will be familiar with this notation, it's likely that many also will not. A citation to ISO/IEC 19501:2005 to explain the meaning of the various symbols may be appropriate.

Section 3.1 says "Implementers can refer to Appendix B and Section 7 of [RFC7970]..." which is ambiguous: it reads as if it is directing readers to Appendix B of RFC7970. I think it means Appendix B of this document. Suggest: "Implementers can refer to Section 7 of [RFC7970] and Appendix B...".

Section 3.2 refers to the use of external schemata for reporting certain types of events. I would have expected to see guidance here (and/or in Section 4.2) indicating that the event report should be useful even for those implementations that don't comprehend these external schemata (unless this guidance already exists in the base IODEF definition; in which case, feel free to silently ignore this comment).

It would be useful to provide a concrete definition of the term "spear-phishing."

____

I assume the version of the ID Nits tool used to check this document varies from the one at . The following issues appear to be legitimate problems in need of addressing. If formatting of the XML documents without adding line breaks is considered critical (which seems possible but unlikely), consider base64-encoding them.

  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  ** There are 28 instances of too long lines in the document, the longest
    one being 53 characters in excess of 72.

  ** The abstract seems to contain references ([RFC7970]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  == There are 2 instances of lines with private range IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
    198.51.100.x or 203.0.113.x.

[Ballot comment]
I agree with the other comments that this reads like a BCP, and should probably be re-characterized.

The diagram in section 3.1 (which I would like to refer to by number but cannot -- consider adding figure numbers) appears to be using UML. While many software engineers will be familiar with this notation, it's likely that many also will not. A citation to ISO/IEC 19501:2005 to explain the meaning of the various symbols may be appropriate.

Section 3.1 says "Implementers can refer to Appendix B and Section 7 of [RFC7970]..." which is ambiguous: it reads as if it is directing readers to Appendix B of RFC7970. I think it means Appendix B of this document. Suggest: "Implementers can refer to Section 7 of [RFC7970] and Appendix B...".

Section 3.2 refers to the use of external schemata for reporting certain types of events. I would have expected to see guidance here (and/or in Section 4.2) indicating that the event report should be useful even for those implementations that don't comprehend these external schemata (unless this guidance already exists in the base IODEF definition; in which case, feel free to silently ignore this comment).

It would be useful to provide a concrete definition of the term "spear-phishing."
____

I assume the version of the ID Nits tool used to check this document varies from the one at . The following issues appear to be legitimate problems in need of addressing. If formatting of the XML documents without adding line breaks is considered critical (which seems possible but unlikely), consider base64-encoding them.

  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  ** There are 28 instances of too long lines in the document, the longest
    one being 53 characters in excess of 72.

  ** The abstract seems to contain references ([RFC7970]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  == There are 2 instances of lines with private range IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
    198.51.100.x or 203.0.113.x.

[Ballot comment]
I agree with the other comments that this reads like a BCP, and should probably be re-characterized.

The diagram in section 3.1 (which I would like to refer to by number but cannot -- consider adding figure numbers) appears to be using UML. While many software engineers will be familiar with this notation, it's likely that many also will not. A citation to ISO/IEC 19501:2005 to explain the meaning of the various symbols may be appropriate.

Section 3.1 says "Implementers can refer to Appendix B and Section 7 of [RFC7970]..." which is ambiguous reads as if it is directing readers to Appendix B of RFC7970. I think it means Appendix B of this document. Suggest: "Implementers can refer to Section 7 of [RFC7970] and Appendix B...".

Section 3.2 refers to the use of external schemata for reporting certain types of events. I would have expected to see guidance here (and/or in Section 4.2) indicating that the event report should be useful even for those implementations that don't comprehend these external schemata (unless this guidance already exists in the base IODEF definition; in which case, feel free to silently ignore this comment).

It would be useful to provide a concrete definition of the term "spear-phishing."
____

I assume the version of the ID Nits tool used to check this document varies from the one at . The following issues appear to be legitimate problems in need of addressing. If formatting of the XML documents without adding line breaks is considered critical (which seems possible but unlikely), consider base64-encoding them.

  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  ** There are 28 instances of too long lines in the document, the longest
    one being 53 characters in excess of 72.

  ** The abstract seems to contain references ([RFC7970]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  == There are 2 instances of lines with private range IPv4 addresses in the
    document.  If these are generic example addresses, they should be changed
    to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
    198.51.100.x or 203.0.113.x.

[Ballot comment]
* Please use example IP addresses from one or more of the documentation blocks in RFC6890 exclusively instead of using RFC1918 private addresses mixed in (e.g. 10.1.1.1)

[Ballot comment]
I'll also echo Ben / Benoit's comments and also thank Qin Wu for the OpsDir review. I've just seen that you have responded to it, thank you.

I especially don't understand the:
"Interoperability between RID agents and the standards, Use of  [RFC6545] and [RFC6546], were also proven in this exercise." -- is the "Use of" superfluous? I *think* so, and removing it fixes it, but I'm not quite sure what was intended.

Many of the nit checker things seem simply to solve (like the use of non-documentation addresses) - these should be addressed.

In addition I have some nits:
Section3.1. 
"Minimal IODEF document IODEF includes one mandatory classes. "
s/classes/class/


Section 3.2.  Information represented
" The implementer should  carefully look into the schema and decide classes to implement (or not)." -- I think this is missing a "which" between "decide" and "classes".

[Ballot comment]
I noted the exact same point as Ben regarding the intended status.
This is really a BCP, right? https://tools.ietf.org/html/rfc2026#section-5
However, I believe the combination of BCP and RFC2119 language is fine.
If I take a single sentence, as an example:

  An IODEF document MUST include
  at least an Incident class, an xml:lang attribute that defines the
  supported language an the IODEF version attribute.

Is this a specification coming from RFC 7970 (which I could not find, by browsing for a few minutes)?
Or is this is a new specification of this "BCP"?

See also Qin's OPS DIR feedback.

[Ballot comment]
I'm confused by the use of 2119 language in this document. Some of it seems to restate requirements already defined elsewhere. Some of it seems too vague  for 2119 keywords (e.g. "SHOULD consider"). The rest seems like BCP material rather than informational, since it seems to say that we recommend people do certain things rather than describe choices and consequences. The latter is reasonable for an informational RFC, but the former belongs in standards track documents or BCPs. I suggest that the 2119 language be removed, the 2119 boilerplate be replaced with something that more accurately describes the intended meaning of MUST and SHOULD,  or that you reconsider the intended status.

IDNits calls out some issues that should be considered. (e.g. lack of an IANA considerations section.)

Otherwise, I have a number of editorial comments:

- General: This draft uses a lot of words (and repetition) to convey some very basic concepts. A good part of it could be summarized as "Don't include objects you don't need".  Please consider editing for conciseness.

- Title: Please expand IODEF in the title.

- Abstract: It's only necessary to expand CSIRT on the first mention in the abstract.

-1, first paragraph: Please mention the acronym IODEF the first time you expand it.

-3, first paragraph: " It is important for IODEF implementers to be able to distinguish how
  the IODEF classes will be used in incident information exchanges.  To
  do that one has to follow a strategy according to which of the
  various IODEF classes will be implemented.

I don't understand the point of the second sentence.  It seems to restate the idea from the first sentence in a more complicated way.

-3.3, 2nd paragraph: I have trouble following the first sentence. I _think_ this paragraph seeks to distinguish attempted attacks from successful attacks, without actually using those terms.

-4, section title: What kind of considerations? I assume the entire document is about considerations of one form or another.

-4.1: s/cary/vary

-4.1, 3rd paragraph: "IODEF implementers SHOULD NOT consider using"
Does this mean "SHOULD NOT use"? (we can't really mandate what they consider.)

-4.4 "SHOULD be treated carefully": That's vague for a 2119 keyword--can you offer more concrete guidance? (Or avoid the keyword?)
"SHOULD consider" - also vague.

-5.1: It's not clear whether "section 7" refers to this document or to [implementreport].

-5.2: Please expand RID on first mention. s/compteting/competing

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-mile-iodef-guidance-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-08-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mile-iodef-guidance@ietf.org, mile@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ncamwing@cisco.com, mile-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IODEF Usage Guidance) to Informational RFC


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document: - 'IODEF Usage
Guidance'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Incident Object Description Exchange Format v2 [RFC7970] defines
  a data representation that provides a framework for sharing
  information commonly exchanged by Computer Security Incident Response
  Teams (CSIRTs) about computer security incidents.  Since the IODEF
  model includes a wealth of available options that can be used to
  describe a security incident or issue, it can be challenging for
  security practitioners to develop tools that can leverage IODEF for
  incident sharing.  This document provides guidelines for IODEF
  implementers.  It also addresses how common security indicators can
  be represented in IODEF and use-cases of how IODEF is being used.
  This document aims to make IODEF's adoption by vendors easier and
  encourage faster and wider adoption of the model by Computer Security
  Incident Response Teams (CSIRTs) around the world.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as an Informational RFC. It provides guidance to IODEF implementers and use cases for how IODEF can be used inclusive of common indicators used.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides guidance and indicator examples for how IODEF can be implemented.  Details for how to implement the mandatory classes and common indicators are provided along with example use cases.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:

This document has been reviewed and revised several times. It is well written and clear. There were no specific external expert reviews conducted.

Personnel:

Nancy Cam-Winget is acting as the Document Shepherd.  Kathleen is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as an informational RFC. The document does represent the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that they have dealt with all appropriate IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents WG consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

== Section 7 titled “Update” should be removed

== The font of Appendix B, section B.1 and B.2 examples are not consistant with the rest of the document in the pdf format

== Informative Reference [I-D.ietf-mile-implementreport] should now be RFC 8134


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no normative references in an unclear state.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references in the document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no new IANA considerations contained in this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA considerations contained in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language sections in this document.