SACM Session Notes 2014-07-22 Notetakers: Chris Inacio, Mehmet Ersue The SACM WG held a 2.5 hour session covering the following primary topics: 1. SACM Architecture 2. SACM Information Model (wandw) 3. SACM Information Model (TNC-based) 4. XMPP Protocol Extensions for SACM transport SACM Architecture ================= Nancy Cam-Winget presented the SACM Architecture based on the -00 draft, which is an extract from the -03 SACM Requirements draft coupled with a separate architecture draft based on TNC's architecture. To be clear, draft-camwinget-sacm-architecture-00 is the combined architecture from previous versions of the SACM requirements and the TNC-based architecture submission. There was some discussion with respect to the Control Plane functions. In particular, there is an assumption that certain administrative functions will exist in the Control Plane, but the Architecture is descrbed on an abstract level. For example, the Control Plane allows for registration of other architectural entities. Additionally, the architecture allows for collocating functions or capabilities, such that a single logical component may provide many of the architectural functions. The architecture considers the use of various protocols for endpoint data collection (i.e. NETCONF, SNMP, etc.), but this is implied and the text of the draft should be updated. There are some clarifying points that need to be made with respect to the Architecture. For example, definitions of roles and functions should be provided and explained more completely. A call for additional feedback on the architecture was made. SACM Information Model (wandw) ============================== Dave Waltermire presented one of the two information model submissions the WG has received to date, and it was clarified that the information model (both submissions really) will inform the architecture work previously discussed. This presentation was essentially a "how to read the submission" type of presentation. Rather than go into all the details of the draft, we were introduced to the concepts put forward in the draft. It was noted that there is a substantial body of prior art directly relevant to the different categories of information with which SACM is concerned. Some clarification was needed with respect to the terms "endpoint", "source vendor", and "3rd party vendor". SACM Information Model (TNC-based) ================================== Lisa Lorenzin presented the second of two information model submissions the WG has received to date, which is based on learnings from the Trusted Computer Group's TNC area and, in particular, IF-MAP, which leverages a graph model. Of particular interest in this discussion was whether endpoints should be Providers directly or whehter they should be aggregated in some way - scalability concerns abound. An important lesson TNC learned with IF-MAP was providing appropriate extension points for unimagined use cases. In effect, everything should be extensible. It was noted that the authors had read each others' information model drafts and that we would continue this week with working sessions to start reconciling the two rather complementary submissions. XMPP Protocol Extensions for SACM transport =========================================== The XMPP protocol extensions (XMPP-Grid) presentation was given remotely by Syam Appala with some in-room assistance from Nancy Cam-Winget. The presentation was, unfortunately, more difficult to follow than the others because of some intermittent audio troubles. XMPP-Grid is really a layer of access control for Publish, Subscribe, and Search operations for Clients (Providers/Consumers in the SACM architecture). XMPP provides a layer of message security, but XMPP-Grid supplies controls for preventing sensitive information from going to restricted destinations. XMPP topics might be mapped to specific capabilities (i.e. software inventory) and topics could be partitioned into subtopics (i.e. software change events). Dan Romascanu asked about protecting an XMPP server (as a controller) against attacks, and Nancy indicated that this was mostly implementation specific. Conclusion (Tuesday) ==================== The WG has another meeting scheduled for Friday at 9am, and we've decided to spend three informal working sessions between now and then to address architectural issues, walking through a usage scenario to inform architecture and information models, and to start reconciling the information models. --------------------------------------------- SACM Session Notes 2014-07-22 Notetakers: Chris Inacio, David Waltermire The SACM WG held a 2 hour meeting covering the following subjects: 1. Network Security as a Service (NSaas) 2. SACM Requirements Update 3. SACM Architecture Update 4. SACM Informaiton Model Update 5. Way Forward Network Security as a Service ============================= Linda Dunbar presented Network Security as a Service (NSaaS) which seeks to be a method of conveying "security services" avaialble and in place on a given network. The domain pertains to configuring IPS, FW, routers that may not be on premise relative to the customer. Consider virtual Customer Premises Equipment (vCPE), and Policy and Charging Rules Function (PCRF) as examples of where NSaaS could be useful. The presentation was brief and there was some discussion after the presentation. Generally, the discussion was centered on the fact that there are a number of models starting out in the IETF to define a generic framework for transport protocols and information systems. In most cases, as with SACM, the scope has been restricted to a workable subset, and the scope of NSaaS feels large. Further, the IETF is successful with work that has a clear problem statement and clear deliverables, two aspects missing from the presentation. It was recommended by Kathleen Moriarty that an initial draft be created to go deeper than a presentation allows, and additionally recognized the overlap between NSaaS and SACM. SACM Requirements Update ======================== Lisa Lorenzin walked through an unsubmitted version of the SACM requirements draft with embedded changes. Some of the topics covered included adding general requirements for topology flexibility, data isolation, modularity, versioning/backward compatibility, discovery, and timestamping. Information Model requirements were also added for the purpose of discussion. It was noted that the items contained in the update may be miscategorized and that we would work on appropriate categorization later - for now, we were to focus on whether the requirements made sense. These included informaiton model requirements such as: object reference uniqueness, supporting rootless searches, data lifetime/ephemerality, looseness of coupling between producer and consumer, and "freshness". Several terms were identified as being less than ideal or otherwise marked for improvement. Two other requirements were discussed, as captured from the list during the week. One such requirement pertains to "collection separation", which really means being able to appropriately identify that which is to be collected without using the collection mechanism to describe that which is to be collected. Collection mechanisms, therefore, become less important to the expression of what collection is desired. The other requirement pertained to "collection composition" where one collection request could be comprised of several constituent collection requests. It was noted that this could also be used to support collection request decomposition, where a single collection request is recieved and then decomposed into constituent collection requests to be satisfied. The security considerations for the requirements draft was also updated. During this discussion the concept of "cardinality" came up, and we seemed to recognize that there may, at a point in time, be an "only one" requirement for informaiton to be associated with a subject, but that over time, there may be many such pieces of information associated with a given subject. SACM Architecture Update ======================== Nancy Cam-Winget presented the architecture updates from the week with a short presentation. The presentation covered notes already sent to the list, and we recognized some additional terms that need to be considered and/or changed. In particular, the term "control plane" ought to be avoided, because it has specific meaning in other circles (i.e. routing). SACM Information Model ====================== This was a verbal discussion without a presentation that led naturally into determining the "Way Forward". The Way Forward =============== The in-room participants agreed that the next submission of the requirements draft ought to be a WG draft, and the chairs will follow up with that notion on the list. We discussed and agreed, in the room, to the following new milestones between IETF 90 and through IETF 91: o 2014-08-15 Terminology update (not final) o 2014-08-15 Requirements update submitted (likely as WG draft) o 2014-08-31 Adopt Architeture I-D o 2014-08-31 Adopt Information Model I-D We also agreed that we would try to have at least one, and likely two, virtual interm meetings. The first is targeting the week of September 8, and the second sometime in October. Participants were encouraged to continue holding working sessions between these virtual interim meetings, while keeping the list "in the loop". Such working sessions are especially important to discussing "chunks" of the bigger things. For example, it may be necessary to discuss "functional taxonomy expression" or "asset identification" as distinct working sessions, but in support of the larger information model discussion. The goal at IETF 91 is to come through with WGLC for requirements and architecture, and then start getting into the details of the information model with a WGLC happening around IETF 92.