Subject: [Gen-art] Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02

From: Dan Romascanu <[email-masked]>
Date: Sun, 18 Feb 2018 11:04:58 -0800

Reviewer: Dan Romascanu
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sacm-nea-swima-patnc-02
Reviewer: Dan Romascanu
Review Date: 2018-02-18
IETF LC End Date: 2018-02-21
IESG Telechat date: 2018-02-22

Summary:

This is a solid and detailed specification, which extends PA-TNS with specific
attributes and message exchanges to allow endpoints to report their installed
software inventory information to a NEA server. It is Almost Ready from a
Gen-ART point of view, but there are some problems that I recommend to be
addressed before approval. The major problem is related to the complete lack of
information about how this specification fits into SACM, which SACM
requirements are addressed, how terminologies are made consistent and how
entities are mapped.

Major issues:

1. The document is labeled as a SACM document, but the text never explains the
connection with the SACM work, or the relation with the SACM architecture and
framework. There is no reference to SACM documents either. Section 9
'Relationship with other specifications' does not mention SACM either.

At a minimum, I believe that the document should:
- relate to the use cases of SACM - RFC 7632 (it does this for NEA, but this is
not sufficient for a SACM document) - ensure consistency, refer to the
terminology of SACM (draft-ietf-sacm-terminology), and provide a mapping
between the terms and entities defined in this document (e.g. SWIMA-PC,
SWIMA-PV, Evidence Record, Software Identifier) and the SACM terminology -
explain how the message exchanges fit in a SACM solution to meet the
requirements defined by RFC 8248. As an example, RFC 5792 has a detailed
appendix that evaluates the specifications against the requirements in RFC 5209
(NEA requirements).

2. The charter item that this WG falls under reads:

'- Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to
collect and deliver information about firmware, operating systems, and software
installed on an endpoint.'

The document covers in detail software inventory, but is mute about firmware
and operating systems. Arguably these two would fall under a broad
interpretation of 'software' but it would be better - at least - to provide an
explanation about these being covered and how, if not specific attributes
related to the types of software specified in the charter.

Minor issues:

1.Section 2.3:

I believe that the 'Interoperable' requirement is trivial and unnecessary in
the text of a Standards-Track document.

'   Interoperable:  This specification defines the protocol for how PCs
      and PVs can exchange and use software information to provide a NEA
      Server with information about an endpoint’s software inventory.
      Therefore, a key goal for this specification is ensuring that all
      SWIMA PCs and PVs, regardless of the vendor who created them, are
      able to interoperate in their performance of these duties.'

Interoperability is the obvious goal of any IETF standards-track document.
There is no need to repeat such an obvious statement.

2. Section 3.3

'   In the case that it is possible to do so, the SWIMA-PC SHOULD send
   its SWIMA Response attribute to the SWIMA-PV that requested it using
   exclusive delivery ...'

Assuming that 'it is possible to do so' means support for the mechanism, why is
this a SHOULD, and not a MUST?

Nits/editorial comments:

1. The Abstract section - quotation marks are open around the first document
name and never closed.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 21 Feb 2018 20:50:05 +0000

Hello,

Thanks a bunch for the comments. I'm glad that you feel that it looks like a solid contribution.

With regard to your feedback, I have developed wording to address both your major concerns and wanted to run it by you:

---
With regard to the lack of mention of SACM, I agree that it was an oversight not to mention it in the Relationship to Other Standards section. I propose adding the following paragraph at the end of that section:

"The NEA architecture is intended to support a broad range of activities and, as such, might be employed by other specifications. For example, requirement T-001 in the SACM Requirements document (RFC 8248) notes that NEA can support data collection from endpoints within the broader SACM architecture. (Other parts of the NEA architecture, which SWIMA uses, meet the other SACM data transport requirements.) In the SACM architecture, a SWIMA-PV corresponds to a “SACM Collector” and a SWIMA-PC is a “SACM Internal Collector”. In the SACM architecture, the SWIMA specification can support activities relating to software inventory collection. Specifically, SWIMA supports the SACM “Endpoint Posture Attribute Value Collection” use case (section 2.1.3 or RFC 7632) by describing a collection mechanism that enables event driven, scheduled, and ad-hoc data collection of software inventory information. SWIMA’s flexibility with regard to the format of inventory data records means that it is compatible with virtually any data format that implements SACM’s “Define, Publish, Query, and Retrieve Security Automation Data” (section 2.1.1 in RFC 7632). This is just one example of how SWIMA can support broader security solution standards. Note that, while SWIMA can support these SACM use cases, SWIMA has no dependencies upon the SACM architecture or any other context in which NEA might reasonably be applied."

I believe this addresses most of the specific points you wanted to include. I did not include a terminology mapping to "evidence record" and "software identifier" because the SACM Terminology definition of "attribute" is not internally consistent: it states "Attribute - Is a data element, as defined in [RFC5209], that is
atomic" and "equivalent to attribute-value-pairs". However, RFC 5209 (NEA) attributes are not atomic in nature, and will consist of many name-value pairs. (I'll send a separate comment to the SACM list regarding this.) As such, I'm not sure the terminology draft has a good parallel at this time and I stuck to the clearer mappings. 

-----

With regard to firmware and OS information, I added the following to the introduction:

" Note that while this specification focuses on “software inventory”, the mechanisms it describes could also be used to convey information about firmware and operating systems associated with an endpoint. The focus on software throughout this document should not be read as excluding the use of SWIMA for these other purposes."

---------

Do these additions adequately address your concerns?

Finally, with regard to the following question:

> Assuming that 'it is possible to do so' means support for the mechanism, why
> is this a SHOULD, and not a MUST?

In the NEA specification, the EXCL flag is only a recommendation to the Posture Broker Server/Client, and the recipient of a message with the flag set only "SHOULD" deliver it to a single party. (I realize that, in retrospect, my assertion that exclusive delivery "ensures" a behavior is incorrect and will fix that.) As such, saying that implementations MUST set a flag that only SHOULD be obeyed seems to be of questionable use, especially given that the specification clearly describes what to do if messages are not exclusively delivered.

Let me know if you disagree - I don't feel too strongly about this, but wanted to explain my thoughts.

----

Thanks again for the comments.

Charles

> -----Original Message-----
> From: Dan Romascanu [mailto:[email-masked]]
> Sent: Sunday, February 18, 2018 1:05 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
> 
> Reviewer: Dan Romascanu

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 22 Feb 2018 00:10:30 +0200

Hi Charles,

Thank you for your response and for addressing my comments. I feel that
they are largely addressed by your proposed resolution. See also in-line.

Regards,

Dan

On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M. <[email-masked]>
wrote:

> With regard to your feedback, I have developed wording to address both
> your major concerns and wanted to run it by you:
>
> ---
> With regard to the lack of mention of SACM, I agree that it was an
> oversight not to mention it in the Relationship to Other Standards section.
> I propose adding the following paragraph at the end of that section:
>
> "The NEA architecture is intended to support a broad range of activities
> and, as such, might be employed by other specifications. For example,
> requirement T-001 in the SACM Requirements document (RFC 8248) notes that
> NEA can support data collection from endpoints within the broader SACM
> architecture. (Other parts of the NEA architecture, which SWIMA uses, meet
> the other SACM data transport requirements.) In the SACM architecture, a
> SWIMA-PV corresponds to a “SACM Collector” and a SWIMA-PC is a “SACM
> Internal Collector”. In the SACM architecture, the SWIMA specification can
> support activities relating to software inventory collection. Specifically,
> SWIMA supports the SACM “Endpoint Posture Attribute Value Collection” use
> case (section 2.1.3 or RFC 7632) by describing a collection mechanism that
> enables event driven, scheduled, and ad-hoc data collection of software
> inventory information. SWIMA’s flexibility with regard to the format of
> inventory data records means that it is compatible with virtually any data
> format that implements SACM’s “Define, Publish, Query, and Retrieve
> Security Automation Data” (section 2.1.1 in RFC 7632). This is just one
> example of how SWIMA can support broader security solution standards. Note
> that, while SWIMA can support these SACM use cases, SWIMA has no
> dependencies upon the SACM architecture or any other context in which NEA
> might reasonably be applied."
>

This looks good. I would also suggest to add a sentence or paragraph
describing for short the relationship to SACM in the Introduction. As this
is a SACM WG document, some readers would probably expect to see this
relationship mentioned earlier than in Section 9.

>
> I believe this addresses most of the specific points you wanted to
> include. I did not include a terminology mapping to "evidence record" and
> "software identifier" because the SACM Terminology definition of
> "attribute" is not internally consistent: it states "Attribute - Is a data
> element, as defined in [RFC5209], that is
> atomic" and "equivalent to attribute-value-pairs". However, RFC 5209 (NEA)
> attributes are not atomic in nature, and will consist of many name-value
> pairs. (I'll send a separate comment to the SACM list regarding this.) As
> such, I'm not sure the terminology draft has a good parallel at this time
> and I stuck to the clearer mappings.
>

I understand your point. Please continue the discussion with the SACM
terminology authors to try to reach consistency.

> " Note that while this specification focuses on “software inventory”, the
> mechanisms it describes could also be used to convey information about
> firmware and operating systems associated with an endpoint. The focus on
> software throughout this document should not be read as excluding the use
> of SWIMA for these other purposes."
>
>
Fine - this is exactly what I was looking for.

> In the NEA specification, the EXCL flag is only a recommendation to the
> Posture Broker Server/Client, and the recipient of a message with the flag
> set only "SHOULD" deliver it to a single party. (I realize that, in
> retrospect, my assertion that exclusive delivery "ensures" a behavior is
> incorrect and will fix that.) As such, saying that implementations MUST set
> a flag that only SHOULD be obeyed seems to be of questionable use,
> especially given that the specification clearly describes what to do if
> messages are not exclusively delivered.
>

Makes sense.

> > 1. The document is labeled as a SACM document, but the text never
> explains
> > the
> > appendix that evaluates the specifications against the requirements in
> RFC
> > 5209
> > (NEA requirements).
> >
> > '- Define an extension of IETF NEA [https://ietf.org/wg/
> concluded/nea.html]
> > to

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 21 Feb 2018 22:23:46 +0000

Hi Dan,

Thanks for your response. I agree on all points. I'll add the following paragraph to the end of the introduction:

"Part of the motivation for the development of SWIMA was to support the IETF’s Security Automation and Continuous Monitoring (SACM) architecture. More details about SWIMA’s role in SACM appear in <xref target=”Relationship”/>. However, SWIMA has no dependencies on any part of SACM and is usable wherever the NEA architecture is employed."

Does this seem reasonable? (I agree that we need to address the expectation that people will have to see SACM mentioned in a SACM WG document, but I also want to make very sure that people don't see SWIMA as only being applicable in that context.)

Thanks,
Charles

From: Dan Romascanu [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 4:11 PM
To: Schmidt, Charles M. <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02

Hi Charles,
Thank you for your response and for addressing my comments. I feel that they are largely addressed by your proposed resolution. See also in-line.
Regards,
Dan

On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M. <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

---

This looks good. I would also suggest to add a sentence or paragraph describing for short the relationship to SACM in the Introduction. As this is a SACM WG document, some readers would probably expect to see this relationship mentioned earlier than in Section 9.

I understand your point. Please continue the discussion with the SACM terminology authors to try to reach consistency.

-----

---------

Makes sense.

----

Charles

> From: Dan Romascanu [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Feb 2018 21:19:32 -0800

Dan, thank you for your review. I don’t think your major issues are quite DISCUSS-worthy, but I’ve called them out in my No Objection ballot.

Alissa

> On Feb 18, 2018, at 11:04 AM, Dan Romascanu <[email-masked]> wrote:
> 
> Reviewer: Dan Romascanu
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 22 Feb 2018 10:35:06 +0200

Hi Charles.

This paragraph is very reasonable and informative for all audiences.

Thanks again.

Dan

On Thu, Feb 22, 2018 at 12:23 AM, Schmidt, Charles M. <[email-masked]>
wrote:

> Hi Dan,
>
>
>
> Thanks for your response. I agree on all points. I'll add the following
> paragraph to the end of the introduction:
>
>
>
> "Part of the motivation for the development of SWIMA was to support the
> IETF’s Security Automation and Continuous Monitoring (SACM) architecture.
> More details about SWIMA’s role in SACM appear in <xref
> target=”Relationship”/>. However, SWIMA has no dependencies on any part of
> SACM and is usable wherever the NEA architecture is employed."
>
>
>
> Does this seem reasonable? (I agree that we need to address the
> expectation that people will have to see SACM mentioned in a SACM WG
> document, but I also want to make very sure that people don't see SWIMA as
> only being applicable in that context.)
>
>
>
> Thanks,
>
> Charles
>
>
>
> *From:* Dan Romascanu [mailto:[email-masked]]
> *Sent:* Wednesday, February 21, 2018 4:11 PM
> *To:* Schmidt, Charles M. <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Genart telechat review of draft-ietf-sacm-nea-swima-
> patnc-02
>
>
>
> Hi Charles,
>