IETF98 I2NSF Minutes Interface to Network Service Functions (I2NSF) Working Group Charter:       https://datatracker.ietf.org/wg/i2nsf/charter/ Mailing list:  https://www.ietf.org/mailman/listinfo/i2nsf/ Jabber:        i2nsf@jabber.ietf.org 3/27/2017, Chicago 1. I2NSF Chairs Slides Working Group Drafts status update 15 minutes - Adopt Use Cases, Problem Statement, and Gap Analysis as WG Documents - DONE - Adopt Framework as WG Document - DONE (framework and terminology I-Ds) - Adopt requirements for protocol extensions as WG Document - DONE - For all of the above, WG can decide if standards track or not - Adopt info model as WG document if desired - Two I-Ds on today's agenda, will be determined after meeting - Adopt secure communications mechanisms as WG Document - Plan to put in Client Facing Interface Req I-Ds Adopt Data Models as WG Document - Need another round of revisions to make consistent, consolidate where possible, and to better align with info model - Adopt Applicability Statement as WG Document - Diego suggests there may be some early docs already posted - John Strassner willingt to help, but overloaded and needs help scoping such work - Ed Lopez in jabber is willing to help - Adopt IANA Registry Considerations as WG Document - This is a list of security capabilities, and could go in the Capabiltiies I-D - No one has started this work yet - All Early Drafts to IESG for Publication - Problem and Use Cases with AD - Terminology almost ready - Framework ready soon after terminology - Gap Analysis on the shelf 2. draft-ietf-i2nsf-terminology-03- John Strassner - Terminology I-Ds of I2NSF and SACM should go forward together. Hence, we added additional terms from SACM to I2NSF, including Data Confidentiality, Data Integrity, Data Provenance, and will work together on Attestation - We refined a set of existing terms to streamline their definition and eliminate duplication (e.g., Policy Rule, I2NSF Policy Rule, ECA Policy Rule got collapsed into one) - We added some new terms; most important are directly vs. indirectly consummable policy rule (critical for defining how policies are executed and whether they require transformation to new forms) - We removed lines with just acronyms, and expanded and defined all acronyms in the document. - Need to explore attestation - there are at least two very different approaches in the IETF, and others in other SDOs - Need to explore metadata more (its use in netmod is not aligned with that of other SDOs) - Need to explore Events - should we differentiate between event types (e.g., alarms vs. threshold crossings) or assume that all are equal? - how robust a definition is needed? - Would like to see if terminology can help mismatch between info and data models AI: start list email threads on the list of issues presented 3. I2nsf framework update - Diego - Reviewed major components of I2NSF - struggling for terminology to differentiate "developer" and "vendor" - want to change from informational to standards-based 4. I2NSF Hackathon Report - Paul - Key question: is I2NSF better than writing another security protocol? - Answer: it works, and has synergy with MILE, SACM, DOTS, SECEVENT - Demonstrated deletion and update of firewall policy, as well as avoid policy duplication - used open source to simulate Consumer-Facing Interface and NSF-Facing Interface 5. I2NSF ONUG Report - Forum started by IT Executives, founded by Nick Lippis - This is a user-driven community - Report describes the Software-Defined Security Services (SDSS) WG - Whitepaper available at: https://opennetworkingusergroup.com/ software-defined-security-services-white-paper-download/ - SDSS WG develops user requirements based on specific use cases, and will publish architectural framework, data models, and API definitions - Architectural goals: - Protect against vendor- and technology lockin - Enforce policies consistently (e.g., ensure a policy remains active while workload moves across a hybrid cloud without manual intervention) - Ensure that as wide a variety as possible of security enforcement points can be used - Showed Architectura Framework - similar to I2NSF Framework, but with slightly different terminology to reflect cloud bias 6. I2NSF Capability - John - Defined what Capabilities are, and explained why they are important - Described the rewriting of this draft to make it easier to understand the key concepts without getting bogged down in the details - The model consists of two separate parts - subclasses of an external info model to derive ECA Policy Rules - this model could be SUPA - defines SecurityECAPolicyRule as well as SecurityEvent, SecurityCondition, and SecurityAction - subclasses of an external info model to derive security metadata - this model could be SUPA - defines SecurityCapability, as well as ContentSecurityCapability and AttackMitigationSecurity - Capability Algebra is used to define how the Capability Model operates - Original model was based on Condition-Action Rules; since we are using Event-Condition-Action Rules with Metadata, we needed a richer Algebra to describe their operation - note that this is currently **asymmetric** - if you add two capability objects, you are doing a set union of their events, conditions, and actions, BUT you only pick ONE of the rule's default actions and ONE of the rule's resolution strategy to use - this is because these latter two attributes can in general conflict with each other, so we choose one policy to be the "base" policy, and add other policies to it - There are some possible improvements/extensions to consider for the next version - these are all identified in the current draft - how to represent event and condition clauses (do we need a formal form, and if so, is conjunctive (or disjunctive) normal form OK?) - do we need more complex action clause evaluation strategies (e.g., execute first action only, execute all actions even if there is a failure, execute all actions until a failure and then rollback) - do we need greater expressivity in metadata? - do we keep the class design simple, or do we use more advanced patterns (e.g., decorator pattern) - current content is easy to understand, but cannot work for dynamic environments, as it uses inheritance to add subclasses to represent new functionality (this requires recompilation) - decorator avoids this problem, but is harder to understand - Adrian: This is a charter item and the WG has expressed a desire to work on it. Thanks to the two author teams for coming together. Question for the room: Who has read this combined document? - 7 people (plus one in jabber) - Does anyone object to adopting this draft? (NO) - OK we'll take the adoption question to the mailing list 7. I2NSF remote attestation - Diego The I2NSF architecture runs a TCG TPM. This includes collecting measurements of the platform, the Security Controller, and the NSFs AFTER clients have authenticated with the Security controller. Note that the trusted connection is established with either the Security Controller itself, or an Endpoint designated by the Security Controller Latest version changes - Virtualization focused has "ceased to be" (nice Monty Python ref!) - Document updated according to feedback - Document aligned with latest Terminology I-D - Better defined key terms related to attestation Diego: should we bring this terms into the Terminology I-D? John: Yes Henk: Yes, especially because there are many SDOs involved in this area, and since the only publicly available document from TCG is old. Hence, we in the IETF have an opportunity to draw from these and advance security implementations. The way forward, recommended by Diego: - Define LoAs - Consider using DAA for mutual anonymous attestation - Analyze set of applicable protocols Henk then gave a short presentation on his TUDA draft (Time-based Uni-Directional Attestation) https://datatracker.ietf.org/doc/draft-birkholz-tuda/ TUDA defines remote attestation as consisting of three steps: - attestation, which creates a set of claims describing the attestee - conveyance, which is the transfer of the claims from the attestee to the verifier - verification, which evaluates the claims presented against declarative guidance Most protocols used for attestation are typically bi-directional challenge-response protocols. In contrast, TUDA is a family of protocols that decouples the above three activities. This provides: - attestation for attestees that may have intermittent connectivity - secure audit logs by combining evidence transmitted via TUDA with logs of current and past state - a uni-directional interaction model that can be leveraged in RESTful architectures TUDA also uses a trusted Time Stamp Autority as an additional 3rd party in the attestation activity. No nonce/challenge-response interaction model is required. Advantages include: - increase the confidence in authentication and authorization procedures - addresses the requirements of constrained-node networks - support interaction models that do not maintain connection-state over time,such as RESTful architectures - able to leverage existing management interfaces, such as RESTCONF or COMI, and their corresponding bindings - support broadcast and multicast schemes - able to cope with temporary loss of connectivity 8. I2NSF Consumer facing interface data model - Paul A data model for security management based on I2NSF framework; example used is VoIP-VoLTE (Note: this can be the content for I2NSF Applicability draft, i.e. how the policies are used for VoIP and VoLTE) *** Rather than notes, I asked some questions, as I have not had time *** to read this draft. Sorry, but hopefully this will help more! - slide 5 - This should show the role of the info model, and where the data model is used - If the Policy Updater distributes how level-policies, where did the high-level policies come from? - I assume that the Security Policy Manager translates the high-level policies to a lower-level form. There should be a functional block to show this process. Also, how is this done? Does it use the model? - Why is the Developer's Management System connected to the **Registration Interface**? That doesn't make sense, as this interface is reserved for registering and deregistering NSFs - Why is the Consumer-Facing Interface uni-directional? Also, if it is, why is it pointing the wrong way? - slide 6 - please define what is meant by "low-level policy". If this is Client or YANG, then how does the Security Controller know enough about vendor-specific NSFs to program them? - The name "Developer's Management System" implies far more functionality than just registration and deregistration. Change the name of this block, and show where other functions that the developer performs tie in to the Security Controller - slide 11 - First, why didn't you import the supa-policy model? - Second, what you have is not SUPA. It is also not compatible with the information model. - I will provide more detailed comments later. 9. draft-hares-i2nsf-capability-data-model-01 - Sue *** Rather than notes, I asked some questions, as I have not had time *** to read this draft. Sorry, but hopefully this will help more! - slide 2 - The Registration Interface is ONLY appropriate for registering and deregistering NSFs. A **developer management system** will be used for far more than that. Clarify this. - The callout on the Security Controller ("Security Controller doesn't know where NSFs is[sic] located") is clearly not true. What are you trying to say? - slide 3 - AFAIK, we have not agreed to add the NSFF as a functional component to the framework. This needs to be discussed. - slide 4 - I don't understand the last bullet (unless you mean "used as" instead of "used by") - slide 6 - the address specification is missing information from the capabilities info model 10. draft-zhang-i2nsf-info-model-monitoring - Henk Monitoring is required to ensure that the system is working properly. Can be applied to short-term (e.g., decision-making) and long-term (e.g., planning) operations. What has to be monitored? Events and Logs - From John: this is likely too simplistic, will take to the mail list YANG event notifications are one way of publishing monitoring data - out of scope for netmod, maybe in scope for SecEvent? - From John: there is nothing preventing an info model from defining operations! :-) Eric Voit: Are you referring to netconf-config-event-notifications? Henk: Yes John: I'm concerned about what is specified in the 2 netconf configuration drafts. This doesn't appear to match how pub-sub systems currently work. Eric Voit: We are going to WG last call on the netconf drafts on notification and want to hear your concerns. John: thank you! Henk: We have all the information events, and now we need to categorize these events. Do you think the specification of events is useful? There is a question in SACM as to whether all events are the same, or if some specific events have additional semantics. John: I've managed networks for 20 years. Yes, even from the beginning (e.g., criticality of alarms in X.731). I'm shocked that someone thinks that all events are equal. Not only do we need to understand which events are important for correlation, filtering, and other operations, we need to be able to selectively annotate events with metadata. Plus, there is the popular event-programming paradigm that argues that all events are in fact not created equal. Key question for this draft is to define if there should be an event taxonomy and, if so, what it looks like. How can we represent the **semantics** of important events? Key question to the group is, are logs just an aggregate of some events in a loosely-defined format? Another key question is, can logs be treated as records of past events, or is this more involved? 11. draft-kim-i2nsf-nsf-facing-interface-data-model-01 - Paul *** Rather than notes, I asked some questions, as I have not had time *** to read this draft. Sorry, but hopefully this will help more! - This draft is currently not compatible with the capability info model draft. Our draft is based on SUPA, but this data model is not. - slide 7: the definition of a policy is not compatible with SUPA - note: you are free to add things, but not free to remove things or change their structure - good job in user-security-event, system-security-event, and time-security-event, but... - ...device-security-event doesn't match the info model - slide 8: I need to compare your definitions to ours. While the attributes clearly don't match, there may be some additional attributes that you have defined that we should consider, and vice-versa. - slide 9: same comment as above. 12. draft-xia-i2nsf-security-policy-object-00 - Frank This draft addresses the complexity and lack of ease of use if common concept are not bundled into objects. - a "Policy Object" is a bundle of commonly used attributes - Frank said specifically for conditions, John thinks it is more general and appropriate for constructing all types of clauses - enables such attribute collections to be treated as an object and **reused** - note that slide 12 enables access control mechanisms to be used to control visibility of, and operations to, objects in the system Chairs asked Frank send questions posed in his slides to the list 13. draft-hyun-i2nsf-nsf-triggered-steering-02 - Sangwon The purpose of this draft is to describe how packet forwarding may be done between NSFs. This can provide inspection and load balancing. - if the NSF Forwarder does not cache, then a packet forwarding header (which has capability information) is added to the packet header. This is used by the NSF Forwarder to ask the Security Controller about the capabilities, and the NSF Forwarder uses that information to determine which NSF(s) the packet should be forwarded to. - If the NSF Forwarder has caching, same operation as above, except the NSF Forwarder can cache each result. - In essence, they want to steer traffic by using a hop-by-hop ID, as opposed to using the entire NSF path. - Enables each NSF to trigger appropriate security actions - The Security Controller tells the NSF Forwarder which NSFs have the desired capabilities. Next steps include examining compliance with SFC, designing the packet forwarding header, and designing a YANG data module for the NSF Forwarder to query the next-hop of the service chain. draft-hyun-i2nsf-registration-interface-im-01 - Sangwon This draft discusses how the registration interface can be modeled in more detail.