Re: [sacm] Comments on draft-ietf-sacm-ecp

[Adam Montville <[e-mail]>]

> On Apr 3, 2018, at 1:28 PM, Haynes Jr., Dan <[e-mail]> wrote:
> 
> Hi Adam,
>  
> Comments inline below.
>  
> Thanks,
> 
> Danny
>  
> From: Adam Montville [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Monday, April 02, 2018 3:29 PM
> To: [e-mail] <mailto:[e-mail]>
> Cc: <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>
> Subject: Comments on draft-ietf-sacm-ecp
>  
> Hello ECP'ers (and SACM),
>  
> I'm still going through the 01 revision of the ECP draft, but am now really looking at some of the documents it points to. I have a few comments and clarifying questions, in no particular order (I do apologize for the shotgun approach here)...
>  
> This is a really verbose draft. I'd be happy to help trim it down. :-) 
> [danny] Sounds good to me :). Feel free to propose changes.

I'll do that. I assume on-list. Though, this seems like a spot where using git would be helpful (just saying).

> I'm noting that Lisa Lorenzin is no longer with Pulse Secure - does her information need to be updated?
> [danny] It probably should be, but, I don’t have her latest information. Does anyone have it?

I believe she's with zScaler now, but I haven't any contact information.
> I'm not 100% clear on the scope of this draft. At one point, the draft seems relegated to what it calls the posture manager and the software executing on an endpoint, but at another point the draft talks about necessary repository functions. (See my final comment below.)
> [danny] Yes, you are correct. We have been slowly iterating the draft to get it away from as solution for connected and compliant use cases to a common framework for the collection of endpoint information (needed for asset management, hardware/software inventory, configuration, vulnerability) and the communication of that information to a centralized server. Your comment about being one way to collect information is also correct. We updated it from being entirely NEA/TNC focused to be open and support other protocols like NETMOD.
> How related are IM-IMC and/or IM-IVC to IF-MAP? I don't think very related, but this is outside my area of knowledge. I ask because at one point Lisa warned the working group about some IF-MAP-related pitfalls to avoid.
> [danny] They are not related. IF-IMC and IF-IMV are interfaces between Posture Collectors and the Posture Broker Client and Posture Validators and the Posture Broker Server respectively. This provides a common interface by which Posture Collectors and Posture Validators can developed and easily deployed into the system. IF-MAP is just an interface between TNC components and the metadata access point (MAP) server which stores network and endpoint information. Unfortunately, I am not familiar with the IF-MAP-related pitfalls to avoid. Can someone with more TCG experience elaborate on the pitfall associated with IF-MAP?

If unrelated, then no need to spend time on it.
> I would consider removing section 8 (though retaining section 9 might be helpful from a scoping perspective)
> [danny] I think both could be good from a scoping perspective. Perhaps, we should move these to an appendix?


Yes, an appendix would be great - may help keep the main points of the draft focused.
> I would move section 10 way up front.
> Note that these examples are relying on SWID collectors which aren't really what the examples are intended to convey.
> For example, 10.1 claims "posture assessment" but shows only SWIMA, which may be part of posture collection, but is not wholly posture collection.
> [danny] I don’t have an objection to that. What do others think about this?
> I would like to see how the authors feel ECP maps to RFC8248 (similar to the attempt we made in the mandm draft [2])
> [danny] It doesn’t directly map to RFC8248, but, it talks about how ECP aligns with SACM (https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00 <https://tools.ietf.org/html/draft-haynes-sacm-ecp-recommendations-00>). Does this help?

Am I the only one that finds this to be odd? I would like to think that, because ECP is essentially proposing at least a part of our intended architecture, some of the requirements would apply...

> Not being as familiar with NEA as I perhaps should be, I'm interested to know whether NEA prescribes an event-driven approach to monitoring or if that is an ECP agumentation (see 10.1.1)
> [danny] Events are prescribed in the extensions to NEA. For example, in SWIMA, it states:
>  
>                   All SWIMA-PCs MUST be able to be able to detect changes to the Software Inventory Evidence Collection.  Specifically, SWIMA-PCs MUST be able to detect:
> o   The creation of records
> o   The deletion of records
> o   The alteration of records
>  
> 
> 

Great, thanks. I wonder if there's a way to mention more about where collector behaviors are expected to be defined.
> Wherever the draft says something like "SWIMA Posture Collection", I would say "SWIMA inventory collection" or something similar to that. Posture has s specific definition per our terminology draft [3], and the information enabled by use of SWIMA is part of, but is not in total, posture information.
> [danny] Can you clarify? Looking at the definition for posture in GitHub, it says: “…the configuration and state information that is collected from a target endpoint in the form of endpoint attributes (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses). This information may constitute one or more posture attributes.”. It seems like what SWIMA collects is posture to me?

Sure. The context I have is that we, long ago, talked about the posture of an endpoint being the collection of software load, configuration state, vulnerability state (or something similar to that). Software load is a part of that. If I read the definition very literally, it reads "configuration and state information" rather than "configuration or state information" or "configuration and/or state information". The singular examples in the definition notwithstanding, when I read the phrase "SWIMA Posture Collection" I feel like SWIMA should be capable of collecting all possible posture information.

I'm interested in what others think as well. Also, the only reason I'm commenting is for others' benefit - I understand what the draft means, but a first-time reader may not.

> Do the authors (or does anyone) have any notion of what a repository would look like?
> [danny] No, it’s to be defined at a later time :). For now, I think we have to let implementers define their own repository and interfaces to the repository. After we get these major components standardized, we can try and tackle that problem. 

This is why I don't feel like the repository is in scope.
> I would like to see some expository text helping a reader understand how various collectors (not just a SWIMA collector) could be created and deployed potentially from multiple parties on a single endpoint.
> [danny] The IF-IMC/IF-IMV interfaces provide this functionality. If all PCs/PVs and all PCMs/PCEs implement these interfaces they should be able to deploy PCs/PVs from multiple parties on a single endpoint.   

Great! The draft should, IMO, mention that. It may also benefit from mentioning this in terms of just how different the implementations from different parties can be. Can one, for example be C++ compiled to native machine language and another be some Groovy running in a JVM?
> Do the authors anticipate the administrative interface/API to be fully specified elsewhere? I think the same goes for the repository. And the evaluator at at least one point in the draft.
> [danny] Yes, IF-IMC/IF-IMV are TCG specifications and we are proposing that we just reference them directly rather than trying to submit them to SACM. At some point, we will need interfaces/APIs for the repository and evaluator, but, those are both things we need to tackle later on.


I agree that the TCG specifications can be handled in this manner. What about the administrative interface? Is that defined in the TCG specs? If not, this is another reason I have trouble with scope on this draft.
> I'm not sure what SACM SWAM means in the title of 7.1.6
> [danny]  SWAM is supposed to be “Software Asset Management”. ACTION: Just expand SWAM in the document since it is only used in two places.

:-) Got it. I didn't pick up on that before.
> There's a lot of talk about policy content, but no real details - is the expectation that these will be handled in separate drafts?
> [danny] Yes, as of right now, policy is not defined anywhere. It is something that can be defined in separate drafts at a later time.

Thanks.

> If entering these into Trac or GitHub as issues makes more sense, let me know. 

>  
> [danny] Let’s keep going on the list and see what concrete actions come out of this thread. If we have a bunch, we can go ahead and add them. For now, I just want to keep the discussion in one place (easier for management – I think :)). 

No problem.

>  
> I think the ECP draft is less about compliance and more about collection, and it's specifically about agent-based (or in-built) collection capabilities based on NEA and extensions thereto - in other words, ECP begins to specify a collection infrastructure for agent-based collection (sorry if I'm slow). In this way, the draft adds value to SACM, and leaves room for alternative approaches that may not be agent-based. If a tight scope statement could be created along these lines, I think that would go a long way toward clarifying the draft. 
>  
> [danny] Do you want to take a pass at that statement :)? Also, where are you thinking it would go? In the introduction?

:-) Dude. (Yeah, I'll give it a shot.) The big important question: Do I get authorship benes? ;-)

>  
> Thoughts?
>  
> Kind regards,
>  
> Adam
>  
>  
>  
> [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/>
> [2] https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/ <https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/>
> [3] https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/>
>