Minutes IETF98: i2nsf
minutes-98-i2nsf-00

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.