I2NSF                                                            L. Xia
Internet-Draft
Internet Draft                                             J. Strassner
Intended status: Standard Track                                  Huawei
Expires:  October 3, 2018 January 02, 2019                                     C. Basile
                                                                 PoliTO
                                                               D. Lopez
                                                                    TID
                                                           April 3,
                                                          July 02, 2018

                  Information Model of NSFs Capabilities
                   draft-ietf-i2nsf-capability-01.txt

Abstract

   This document defines the concept of an NSF (Network Security
   Function) Capability, as well as its information model. Capabilities
   are a set of features that are available from a managed entity, and
   are represented as data that unambiguously characterizes an NSF.
   Capabilities enable management entities to determine the set offer
   features from available NSFs that will be used, and simplify the
   management of NSFs.
                    draft-ietf-i2nsf-capability-02.txt

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.  The list of current
   Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 3, 2018. January 02, 2019.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   This draft defines the concept of an NSF (Network Security Function)
   capability, as well as its information model. Capabilities are a set
   of features that are available from a managed entity, and are
   represented as data that unambiguously characterizes an NSF.
   Capabilities enable management entities to determine the set of
   features from available NSFs that will be used, and simplify the
   management of NSFs.

Table of Contents

   1. Introduction ................................................... 4 ................................................. 2
   2. Conventions used in this document .............................. 5 ............................ 3
      2.1. Acronyms .................................................. 5 ................................................ 3
   3. Capability Information Model Design ............................ 6 .......................... 4
      3.1. Design Principles and ECA Policy Model Overview ........... 6 ......... 5
      3.2. Relation with the External Information Model .............. ............ 8
      3.3. I2NSF Capability Information Model Theory of Operation ... 10 .. 9
         3.3.1. I2NSF Capability Information Model ................ 11
         3.3.2. The SecurityCapability class ...................... 13
         3.3.3. I2NSF Condition Clause Operator Types ............... 11
         3.3.2 ............. 14
         3.3.4. Capability Selection and Usage ...................... 12
         3.3.3. .................... 16
         3.3.5.  Capability Algebra ................................. 13
      3.4. Initial NSFs Capability Categories ....................... 16
         3.4.1. Network Security Capabilities ....................... 16
         3.4.2. Content Security Capabilities ....................... 17
         3.4.3. Attack Mitigation Capabilities ...................... ............................... 17
   4. Information Sub-Model for Network Security Capabilities ....... 18
      4.1. Information Sub-Model for Network Security ............... 18
         4.1.1. Network Security Policy Rule Extensions ............. IANA Considerations ......................................... 19
         4.1.2. Network Security Policy Rule Operation ..............
   5. References .................................................. 19
      5.1. Normative References ................................... 19
      5.2. Informative References ................................. 20
         4.1.3. Network Security Event Sub-Model ....................
   6. Acknowledgments ............................................. 22
         4.1.4. Network Security Condition Sub-Model ................ 23
         4.1.5. Network Security Action Sub-Model ................... 25
      4.2. Information Model for I2NSF Capabilities ................. 26
      4.3. Information Model for Content Security Capabilities ...... 27
      4.4. Information Model for Attack Mitigation Capabilities ..... 28
   5. Security Considerations ....................................... 29
   6. IANA Considerations ........................................... 29
   7. Contributors .................................................. 29
   8. References .................................................... 29
      8.1. Normative References ..................................... 29
      8.2. Informative References ................................... 30
   Appendix A. Network Security Capability Policy Rule Definitions .. 32
      A.1. AuthenticationECAPolicyRule Class Definition ............. 32
      A.2. AuthorizationECAPolicyRuleClass Definition ............... 34
      A.3. AccountingECAPolicyRuleClass Definition .................. 35
      A.4. TrafficInspectionECAPolicyRuleClass Definition ........... 37
      A.5. ApplyProfileECAPolicyRuleClass Definition ................ 38
      A.6. ApplySignatureECAPolicyRuleClass Definition .............. 40
   Appendix B. Network Security Event Class Definitions ............. 42
      B.1. UserSecurityEvent Class Description ...................... 42
         B.1.1. The usrSecEventContent Attribute .................... 42
         B.1.2. The usrSecEventFormat Attribute ..................... 42
         B.1.3. The usrSecEventType Attribute ....................... 42
      B.2. DeviceSecurityEvent Class Description .................... 43
         B.2.1. The devSecEventContent Attribute .................... 43
         B.2.2. The devSecEventFormat Attribute ..................... 43
         B.2.3. The devSecEventType Attribute ....................... 44
         B.2.4. The devSecEventTypeInfo[0..n] Attribute ............. 44
         B.2.5. The devSecEventTypeSeverity Attribute ............... 44

Table of Contents (continued)

      B.3. SystemSecurityEvent Class Description .................... 44
         B.3.1. The sysSecEventContent Attribute .................... 45
         B.3.2. The sysSecEventFormat Attribute ..................... 45
         B.3.3. The sysSecEventType Attribute ....................... 45
      B.4. TimeSecurityEvent Class Description ...................... 45
         B.4.1. The timeSecEventPeriodBegin Attribute ............... 46
         B.4.2. The timeSecEventPeriodEnd Attribute ................. 46
         B.4.3. The timeSecEventTimeZone Attribute .................. 46
   Appendix C. Network Security Condition Class Definitions ......... 47
      C.1. PacketSecurityCondition .................................. 47
         C.1.1. PacketSecurityMACCondition .......................... 47
            C.1.1.1. The pktSecCondMACDest Attribute ................ 47
            C.1.1.2. The pktSecCondMACSrc Attribute ................. 47
            C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48
            C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48
            C.1.1.5. The pktSecCondMACTCI Attribute ................. 48
         C.1.2. PacketSecurityIPv4Condition ......................... 48
            C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48
            C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48
            C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48
            C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48
            C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48
            C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49
            C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49
         C.1.3. PacketSecurityIPv6Condition ......................... 49
            C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49
            C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49
            C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49
            C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49
            C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49
            C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49
            C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50
            C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50
         C.1.4. PacketSecurityTCPCondition .......................... 50
            C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50
            C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50
            C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50
            C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50
            C.1.5. PacketSecurityUDPCondition ....................... 50
               C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50
               C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51
               C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51
      C.2. PacketPayloadSecurityCondition ........................... 51
      C.3. TargetSecurityCondition .................................. 51
      C.4. UserSecurityCondition .................................... 51
      C.5. SecurityContextCondition ................................. 52
      C.6. GenericContextSecurityCondition .......................... 52

Table of Contents (continued)

  Appendix D. Network Security Action Class Definitions ............. 53
      D.1. IngressAction ............................................ 53
      D.2. EgressAction ............................................. 53
      D.3. ApplyProfileAction ....................................... 53
   Appendix E. Geometric Model ...................................... 54
   Authors' Addresses ............................................... 57

  1. Introduction

   The rapid development of virtualized systems requires advanced
   security protection in various scenarios. Examples include network
   devices in an enterprise network, user equipments User Equipment in a mobile
   network, devices in the Internet of Things, or residential access
   users [RFC8192].

   NSFs produced by multiple security vendors provide various security
   Capabilities
   capabilities to customers. Multiple NSFs can be combined together to
   provide security services over the given network traffic, regardless
   of whether the NSFs are implemented as physical or virtual
   functions.

   Security Capabilities describe the set of network security-related
   features functions that Network Security
   Functions (NSFs) are available to use provide for security policy
   enforcement purposes. Security Capabilities are independent of the
   actual security control mechanisms that will implement them.

   Every NSF
   registers SHOULD be described with the set of Capabilities capabilities it
   offers. Security Capabilities
   are a market enabler, providing a way to define customized security
   protection by unambiguously describing the security features offered
   by a given NSF. Moreover, Security Capabilities enable security functionality to be
   described in a vendor-neutral manner. That is, it is not required needed to
   refer to a specific product or technology when designing the
   network; rather, the functionality functions characterized by their
   Capabilities capabilities
   are considered.

   According to [RFC8329], there Security Capabilities are two types of I2NSF interfaces
   available for security policy provisioning:

      o Interface between I2NSF users and applications, and a security
        controller (Consumer-Facing Interface): this is a service-
        oriented interface that provides market enabler,
   providing a communication channel
        between consumers of NSF data and services and the network
        operator's security controller. This enables security
        information way to be exchanged between various applications (e.g.,
        OpenStack, or various BSS/OSS components) and the define customized security
        controller. The design goal of the Consumer-Facing Interface
        is to decouple protection by
   unambiguously describing the specification of security services from
        their implementations.

      o Interface between NSFs (e.g., firewall, intrusion prevention,
        or anti-virus) and the security controller (NSF-Facing
        Interface): The NSF-Facing Interface is used to decouple the
        security management scheme from the set of NSFs and their
        various implementations for this scheme, and is independent
        of how the NSFs are implemented (e.g., run in Virtual
        Machines or physical appliances). This document defines an
        object-oriented information model for network security, content
        security, and attack mitigation Capabilities, along with
        associated I2NSF Policy objects. features offered by a given
   NSF.

   This document is organized as follows. Section 2 defines conventions
   and acronyms used. Section 3 discusses the design principles for the
   I2NSF Capability information model and related policy model objects.
   Section 4 defines the structure of the capability information model, which
   describes the policy related ECA model, and capability objects design; details of the
   provides detailed information model elements are contained in the appendices. design of I2NSF network security
   capability.

  2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   This document uses terminology defined in
   [I-D.draft-ietf-i2nsf-terminology] [I-D.draft-ietf-i2nsf-
   terminology] for security related and I2NSF scoped terminology.

  2.1. Acronyms

   AAA:     Access control, Authorization, Authentication
   ACL:     Access Control List
   (D)DoD:  (Distributed) Denial of Service (attack)
   ECA:     Event-Condition-Action
   FMR:     First Matching Rule (resolution strategy)
   FW:      Firewall
   GNSF:    Generic Network Security Function
   HTTP:    HyperText Transfer Protocol
   I2NSF:

  I2NSF - Interface to Network Security Functions
   IPS:     Intrusion Prevention System
   LMR:     Last Matching Rule (resolution strategy)
   MIME:    Multipurpose Internet Mail Extensions
   NAT:     Network Address Translation
   NSF:

  NSF - Network Security Function
   RPC:     Remote Procedure Call
   SMA:     String Matching Algorithm
   URL:     Uniform Resource Locator
   VPN:     Virtual Private Network

  DNF - Disjunctive Normal Form
  3. Capability Information Model Design

   The starting point of the design of the

   A Capability information model Information Model (CapIM) is a formalization of the
   functionality that an NSF advertises. This enables the categorization precise
   specification of types what an NSF can do in terms of security functions. policy
   enforcement, so that computer-based tasks can unambiguously refer
   to, use, configure, and manage NSFs. Capabilities MUST be defined in
   a vendor- and technology-independent manner (e.g., regardless of the
   differences among vendors and individual products).

   Humans are able to refer to categories of security controls and
   understand each other. For instance, security experts agree on what
   is meant by the terms "IPS", "Anti-Virus", "NAT", "filtering", and "VPN concentrator".  Network
   As a further example, network security experts unequivocally refer
   to "packet filters" as stateless devices able to allow or deny
   packet forwarding based on various conditions (e.g., source and
   destination IP addresses, source and destination ports, and IP
   protocol type fields) [Alshaer].

   However, more information is required in case of other devices, like
   stateful firewalls or application layer filters. These devices
   filter packets or communications, but there are differences in the
   packets and communications that they can categorize and the states
   they maintain. Humans deal with these differences by asking more
   questions to determine the specific category and functionality of
   the device. Machines can follow a similar approach, which is
   commonly referred to as question-answering [Hirschman] [Galitsky].
   In this context, the CapIM and the derived Data Models provide
   important and rich information sources.

   Analogous considerations can be applied for channel protection
   protocols, where we all understand that they will protect packets by
   means of symmetric algorithms whose keys could have been negotiated
   with asymmetric cryptography, but they may work at different layers
   and support different algorithms and protocols. To ensure
   protection, these protocols apply integrity, optionally
   confidentiality, anti-reply protections, and authenticate peers.

3.1.  Capability Information Model Overview

   This document defines

   The CapIM is intended to clarify these ambiguities by providing a model
   formal description of security Capabilities NSF functionality. The set of functions that provides
   are advertised MAY be restricted according to the foundation for privileges of the
   user or application that is viewing those functions. I2NSF
   Capabilities enable unambiguous specification of the security
   capabilities available in a (virtualized) networking environment,
   and their automatic management processing by means of NSFs. computer-based
   techniques.

   This includes enabling the security controller to properly identify
   and manage NSFs, and allow NSFs to properly declare their functionalities,
   functionality, so that they can be used in the correct way.

  3.1. Design Principles and ECA Policy Model Overview

   This document defines an information model for representing NSF
   capabilities. Some basic design principles for security Capabilities capabilities
   and the systems that have to manage them are:

   o Independence: each security Capability should capability SHOULD be an independent
      function, with minimum overlap or dependency on other
      Capabilities.
      capabilities. This enables each security Capability capability to be
      utilized and assembled together freely. More importantly, changes
      to a Capability will not one capability SHOULD NOT affect other Capabilities. capabilities. This
      follows the Single Responsibility Principle [Martin] [OODSRP].

   o Abstraction: each Capability should capability MUST be defined in a vendor-
      independent manner, manner.

   o Advertisement: A dedicated, well-known interface MUST be used to
      advertise and associated register the capabilities of each NSF. This same
      interface MUST be used by other I2NSF Components to determine
      what Capabilities are currently available to them.

   o Execution:  a dedicated, well-known interface MUST be used to provide
      configure and monitor the use of a capability. This provides a
      standardized ability to describe its functionality, and report
      its processing results. This facilitates multi-vendor
      interoperability.

   o Automation: the system has MUST have the ability to discover, negotiate, auto-discover,
      auto-negotiate, and update auto-update its security Capabilities automatically capabilities (i.e.,
      without human intervention). These features are useful especially useful
      for the management of a large number of NSFs. They are essential to add
      for adding smart services (e.g., analysis, refinement, Capability analysis, capability
      reasoning, and optimization) for to the security scheme employed.
      These features are supported by many design patterns, including
      the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a
      set of Message Exchange Patterns [Hohpe].

   o Scalability: the management system must SHOULD have the Capability capability to
      scale up/down or scale in/out. Thus, it can meet various
      performance requirements derived from changeable network traffic
      or service requests. In addition, security Capabilities capabilities that are
      affected by scalability changes must SHOULD support reporting
      statistics to the security controller to assist its decision on
      whether it needs to invoke scaling or not. However, this requirement is for
      information only, and is beyond the scope of this document.

   Based on the above principles, this document defines a set of abstract and vendor-neutral
   Capabilities with standard interfaces is defined. This provides a
   Capability capability
   model that enables a an NSF to register (and hence advertise) its set
   of NSFs capabilities that are required at other I2NSF Components can use. These
   capabilities MAY have their access control restricted by policy;
   this is out of scope for this document. The set of capabilities
   provided by a given time to be selected, as well as the unambiguous definition set of NSFs unambiguously define the security
   offered by the set of NSFs used. The security controller can compare
   the requirements of users and applications to the set of Capabilities
   capabilities that are currently available in order to choose which
   capabilities of which NSFs are needed to meet those requirements.
   Note that this choice is independent of vendor, and instead relies
   specifically on the Capabilities capabilities (i.e., the description) of the
   functions provided. The security controller may also be able to customize the
   functionality of selected NSFs.

   Furthermore, when an unknown threat (e.g., zero-day exploits and
   unknown malware) is reported by an NSF, new Capabilities capabilities may be
   created, and/or existing Capabilities capabilities may be updated (e.g., by
   updating its signature and algorithm). This results in enhancing the
   existing NSFs (and/or creating new NSFs) to address the new threats.
   New Capabilities capabilities may be sent to and stored in a centralized
   repository, or stored separately in a vendor's local repository. In
   either case, a standard interface facilitates the update process.

   Note
   This document specifies a metadata model that MAY be used to further
   describe and/or prescribe the characteristics and behavior of the
   I2NSF capability model. For example, in this case, metadata could be
   used to describe the updating of the capability, and prescribe the
   particular version that an implementation should use. This initial
   version of the model covers and has been validated to describe NSFs
   that are designed with a set of capabilities (which covers most of
   the existing NSFs). Checking the behavior of the model with systems cannot
   that change capabilities dynamically create a new Capability
   without human interaction. This is an area for further study.

3.2.  ECA Policy Model Overview at runtime has been extensively
   explored (e.g., impact on automatic registration).

   The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used
   as the basis for the design of I2NSF Policy Rules; the capability model; definitions of the following
   all I2NSF policy-related terms are also specified defined in
   [I-D.draft-ietf-i2nsf-terminology]: [I-D.draft-ietf-
   i2nsf-terminology]. The following three terms define the structure
   and behavior of an I2NSF imperative policy rule:

   o Event: An Event is defined as any important occurrence in time of
      a change in the system being managed, and/or in the environment
      of the system being managed. When used in the context of I2NSF
      Policy Rules, it is used to determine whether the Condition
      clause of the I2NSF Policy Rule can be evaluated or not. Examples
      of an I2NSF Event include time and user actions (e.g., logon,
      logoff, and actions that violate an ACL).

   o Condition: A condition is defined as a set of attributes,
      features, and/or values that are to be compared with a set of
      known attributes, features, and/or values in order to determine
      whether or not the set of Actions in that (imperative) I2NSF
      Policy Rule can be executed or not. Examples of I2NSF Conditions
      include matching attributes of a packet or flow, and comparing
      the internal state of an NSF to a desired state.

   o Action: An action is used to control and monitor aspects of
        flow-based flow-
      based NSFs when the event and condition clauses are satisfied.
      NSFs provide security functions by executing various Actions.
      Examples of I2NSF Actions include providing intrusion detection
      and/or protection, web and flow filtering, and deep packet
      inspection for packets and flows.

   An I2NSF Policy Rule is made up of three Boolean clauses: an Event
   clause, a Condition clause, and an Action clause. This structure is
   also called an ECA (Event-Condition-Action) Policy Rule. A Boolean
   clause is a logical statement that evaluates to either TRUE or
   FALSE. It may be made up of one or more terms; if more than one term, term
   is present, then a each term in the Boolean clause connects the terms is combined using
   logical connectives (i.e., AND, OR, and NOT). It

   An I2NSF ECA Policy Rule has the following semantics:

          IF <event-clause> is TRUE

             IF <condition-clause> is TRUE

                THEN execute <action-clause> [constrained by metadata]

             END-IF

          END-IF

   Technically, the "Policy Rule" is really a container that aggregates
   the above three clauses, as well as metadata. Aggregating metadata
   enables business logic to be used to prescribe behavior. For
   example, suppose a particular ECA Policy Rule contains three actions
   (A1, A2, and A3, in that order). Action A2 has a priority of 10;
   actions A1 and A3 have no priority specified. Then, metadata may be
   used to restrict the set of actions that can be executed when the
   event and condition clauses of this ECA Policy Rule are evaluated to
   be TRUE; two examples are: (1) only the first action (A1) is
   executed, and then the policy rule returns to its caller, or (2) all
   actions are executed, starting with the highest priority.

   The above ECA policy model is very general and easily extensible,
   and can avoid potential constraints that could limit the
   implementation of generic security Capabilities.

3.3. extensible.

  3.2. Relation with the External Information Model

   Note: the symbology used from this point forward is taken from
   section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model].

   The I2NSF NSF-Facing Interface is in charge of selecting used to select and
   managing manage the NSFs
   using their Capabilities. capabilities. This is done by using the following approaches: approach:

   1) Each NSF registers its Capabilities capabilities with the management system
         when it "joins",
      through a dedicated interface, and hence hence, makes its Capabilities capabilities
      available to the management system;

   2) The security controller selects the set of Capabilities
         required to meet compares the needs of the security service
      with the set of capabilities from all available NSFs that it manages;
      manages using the CapIM;

   3) The security controller uses the Capability information model
         to match chosen Capabilities CapIM to NSFs, independent select the final set of vendor;
      NSFs to be used;

   4) The security controller takes the above information and creates or
      uses one or more data models from the Capability
         information model CapIM to manage the NSFs;

   5) Control and monitoring can then begin.

   This assumes that an external information model is used to define
   the concept of an ECA Policy Rule and its components (e.g., Event,
   Condition, and Action objects). This enables I2NSF Policy Rules
   [I-D.draft-ietf-i2nsf-terminology] [I-
   D.draft-ietf-i2nsf-terminology] to be subclassed from an external
   information model.

   Capabilities are defined as classes (e.g.,

   The external ECA Information Model supplies at least a set of objects)
   objects that
   exhibit represent a generic ECA Policy Rule, and a common set of characteristics
   objects that represent Events, Conditions, and behavior
   [I-D.draft-ietf-supa-generic-policy-info-model].

   Each Capability is made up of at least one model element (e.g.,
   attribute, method, or relationship) Actions that differentiates it from all
   other objects in can be
   aggregated by the system. Capabilities are, generically, a type
   of metadata generic ECA Policy Rule. This enables appropriate
   I2NSF Components to reuse this generic model for different purposes,
   as well as specialize it (i.e., information create new model objects) to
   represent concepts that describes, are specific to I2NSF and/or prescribes,
   the behavior of objects); hence, it an application
   that is using I2NSF.

   It is also assumed that an the external
   information model is used ECA Information Model also has the
   ability to define aggregate metadata. This enables metadata (preferably, in the
   form to be used to
   prescribe and/or describe characteristics and behavior of a class hierarchy). Therefore, it is assumed that the ECA
   Policy Rule. Specifically, Capabilities are subclassed from an this
   external metadata model.

   The Capability sub-model is used for advertising, creating,
   selecting, and managing a set of specific security If the desired Capabilities
   independent of are already
   defined in the type and vendor of device CapIM, then no further action is necessary.
   Otherwise, new Capabilities SHOULD be defined either by defining new
   classes that contains can wrap existing classes using the NSF.
   That is, decorator pattern
   [Gamma] or by another mechanism (e.g., through subclassing); the user
   parent class of the NSF-Facing Interface does not care whether
   the NSF is virtualized new Capability SHOULD be either an existing
   CapIM metadata class or hosted in a physical device, who the
   vendor of class defined in the NSF is, and which set of entities external metadata
   information model. In either case, the NSF is
   communicating with (e.g., a firewall or an IPS). Instead, ECA objects can use the user
   only cares about
   existing aggregation between them and the set Metadata class to add
   metadata to appropriate ECA objects.

   Detailed descriptions of each portion of Capabilities that the NSF has, such as
   packet filtering or deep packet inspection. The overall structure
   is illustrated information model are
   given in the figure below:

   +-------------------------+ 0..n         0..n +---------------+
   |                         |/ \               \|   External    |
   | External ECA Info Model + A ----------------+   Metadata    |
   |                         |\ /  Aggregates   /|  Info Model   |
   +-----------+------------+      Metadata      +-------+-------+
               |                                        / \
               |                                         |
              / \                                        |
   Subclasses derived for following sections.

  3.3. I2NSF                    +-----+------+
        Security Policies                          | Capability |
                                                   | Sub-Model  |
                                                   +------------+

          Figure 1. The Overall I2NSF Information Model Design

   This draft defines a set Theory of extensions to a generic, external, ECA
   Policy Model Operation

   Capabilities are typically used to represent various NSF ECA Security Policy Rules. It
   also defines the Capability Sub-Model; this enables ECA Policy
   Rules to control which functions that can
   be invoked. Capabilities are seen by which actors, objects, and hence, can be used by in the I2NSF system. Finally, it places requirements on what
   type
   event, condition, and/or action clauses of extensions are required to the generic, external, an I2NSF ECA
   information model and Policy Rule.

   The I2NSF CapIM refines a predefined (and external) metadata models, in order to manage model;
   the
   lifecycle application of I2NSF Capabilities.

   Both of the external models shown in Figure 1 could, but do not have
   to, be based on the SUPA information model
   [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in
   the Capability Sub-Model will inherit the AggregatesMetadata
   aggregation from the External Metadata Information Model.

   The external ECA Information Model supplies at least one set of classes
   that represent a generic ECA Policy Rule, and a set of classes that
   represent Events, Conditions, and Actions that can be aggregated by
   the generic ECA Policy Rule. This enables I2NSF to reuse this
   generic model for different purposes, as well as refine it (i.e.,
   create new subclasses, or add attributes and relationships) to
   represent I2NSF-specific concepts.

   It is assumed that the external ECA Information Model has the
   ability to aggregate metadata. Capabilities are then sub-classed
   from an appropriate class in the external Metadata Information Model;
   this enables the ECA objects to use the existing aggregation between
   them and Metadata to add Metadata to appropriate ECA objects.

   Detailed descriptions of each portion of the information model are
   given in the following sections.

3.4.  I2NSF Capability Information Model: Theory of Operation

   Capabilities are typically used to represent NSF functions that can
   be invoked. Capabilities are objects, and hence, can be used in the
   event, condition, and/or action clauses of an I2NSF ECA Policy Rule.
   The I2NSF Capability information model refines a predefined metadata
   model; the application of I2NSF Capabilities is done by refining a
   predefined ECA Policy Rule Capabilities is done by refining a
   predefined (and external) ECA Policy Rule information model that
   defines how to use, manage, or otherwise manipulate a set of Capabilities.
   capabilities. In this approach, an I2NSF Policy Rule is a container
   that is made up of three clauses: an event clause, a condition
   clause, and an action clause. When the I2NSF policy engine receives
   a set of events, it matches those events to events in active ECA
   Policy Rules. If the event matches, then this triggers the
   evaluation of the condition clause of the matched I2NSF Policy Rule.
   The condition clause is then evaluated; if it matches, then the set
   of actions in the matched I2NSF Policy Rule MAY be executed.

   This document defines additional important extensions to both The
   operation of each of these clauses MAY be affected by metadata that
   is aggregated by either the
   external ECA Policy Rule model and the external Metadata model that
   are used and/or by each clause,
   as well as the I2NSF Information Model; examples include selected resolution strategy, external data, and default action. All these
   extensions come from the geometric strategy.

   Condition clauses are logical formulas that combine one or more
   conditions that evaluate to a Boolean (i.e., true or false) result.
   The values in a condition clause are built on values received or
   owned by the NSF. For instance, the condition clause 'ip source ==
   1.2.3.4' is true when the IP address is equal to 1.2.3.4. Two or
   more conditions require a formal mechanism to represent how to
   operate on each condition to produce a result. For the purposes of
   this document, every condition clause MUST be expressed in either
   conjunctive or disjunctive normal form. Informally, conjunctive
   normal form expresses a clause as a set of sub-clauses that are
   logically ANDed together, where each sub-clause contains only terms
   that use OR and/or NOT operators). Similarly, disjunctive normal
   form is a set of sub-clauses that are logically ORed together, where
   each sub-clause contains only terms that use AND and/or NOT
   operators.

   This document defines additional important extensions to both the
   external ECA Policy Rule model and the external Metadata model that
   are used by the I2NSF CapIM; examples include  resolution strategy,
   external data, and default actions. All these extensions come from
   the geometric model defined in [Bas12]. A more detailed description
   is provided in Appendix E; a summary of the important points of this
   geometric model follows.

   Formally, given a set of actions in an I2NSF Policy Rule, the
   resolution strategy maps all the possible subsets of actions to an
   outcome. In other words, the resolution strategy is included in the an
   I2NSF Policy Rule to decide how to evaluate all the actions in a
   particular I2NSF Policy Rule. This is then extended to include all
   possible I2NSF Policy Rules that can be applied in a particular
   scenario. Hence, the final action set from all the
   matching I2NSF Policy Rules
   is deduced. Rule.

   Some concrete examples of resolution strategy are the are:

   o First Matching Rule (FMR) or

   o Last Matching Rule (LMR) resolution strategies. When
   no rule matches a packet,

   o Prioritized Matching Rule (PMR) with Errors (PMRE)

   o Prioritized Matching Rule with No Errors (PMRN)

   In the NSFs may select above, a default action, if
   they support one.

   Resolution strategies PMR strategy is defined as follows:

     1. Order all actions by their Priority (highest is first, no
        priority is last); actions that have the same priority may be
        appear in any order in their relative location.

     2. For PMRE:  if any action fails to execute properly, temporarily
        stop execution of all actions. Invoke the error handler of the
        failed action. If the error handler is able to recover from the
        error, then continue execution of any remaining actions; else,
        terminate execution of the ECA Policy Rule.

     3. For PMRN:  if any action fails to execute properly, stop
        execution of all actions. Invoke the error handler of the failed
        action, but regardless of the result, execution of the ECA
        Policy Rule MUST be terminated.

   Regardless of the resolution strategy, when no rule matches a
   packet, a default action MAY be executed.

   Resolution strategies may use, besides intrinsic rule data (i.e.,
   event, condition, and action clauses), "external data" associated to
   each rule, such as priority, identity of the creator, and creation
   time. Two examples of this are attaching metadata to the policy
   action and/or policy rule, and associating the policy rule with
   another class to convey such information.

3.4.1.

   3.3.1. I2NSF Condition Clause Operator Types

   After having analyzed the literature and some existing NSFs, the
   types Capability Information Model

   Figure 1 below shows one example of selectors are categorized as exact-match, range-based,
   regex-based, and custom-match [Bas15][Lunt].

   Exact-match selectors are (unstructured) sets: elements can only be
   checked for equality, as no order is defined on them. As an example,
   the protocol type field external model. This is a
   simplified version of the IP header MEF Policy model [PDO]. For our purposes:

     o  MCMPolicyObject is an unordered set of
   integer values associated to protocols. The assigned protocol
   numbers are maintained by the IANA (http://www.iana.org/assignments/
   protocol-numbers/protocol-numbers.xhtml).

   In this selector, it abstract class, and is only meaningful to specify condition clauses
   that use either the "equals" or "not equals" operators:

      proto = tcp, udp       (protocol type field equals to TCP or UDP)
      proto != tcp           (protocol type field different derived from TCP)

   No other operators are allowed on exact-match selectors. For example,
   the following
        MCMManagedEntity [MCM]

     o  MCMPolicyStructure is an invalid condition clause, even if protocol abstract superclass for building
        different types
   map to integers:

      proto < 62             (invalid condition)

   Range-based selectors are ordered sets where it is possible to
   naturally specify ranges as they can of Policy Rules (currently, for I2NSF, only
        imperative (i.e., ECA) Policy Rules are considered)

     o  An I2NSFECAPolicyRule could be easily mapped to integers.
   As an example, the ports in the TCP protocol may subclassed from MCMECAPolicyRule

     o  I2NSF Events, Conditions, and Actions could be represented with
   a range-based selector (e.g., 1024-65535). As another example, subclasses from
        MCMPolicyEvent, MCMPolicyCondition, and MCMPolicyAction

     o  MCMMetaData is aggregated by MCMEntity, which is the
   following are examples superclass
        of valid condition clauses:

      source_port = 80
      source_port < 1024
      source_port < 30000 && source_port >= 1024

   We include, in range-based selectors, MCMManagedEntity. So all Policy objects may aggregate
        MCMMetaData
                                            +------------------------+
                +---------------+           |HasPolicyStructure      |
                |MCMPolicyObject|           |ComponentDecoratorDetail|
                +-------A-------+           +---------------------*--+
                        |                                         *
                        |                                         *
        +---------------+----------------+                        *
        |                                |                        *
+-------+----------+          +----------+----------------+1..*   *
|MCMPolicyStructure|          |MCMPolicyStructureComponent|<------*+
+--------A---------+          +-----------A---------------+        |
         |                                |                        |
         |                   +------------+--------+               |
         |                   |                     |         0..1  ^
 +-------+--------+  +-------+-------+ +-----------+---------------V+
 |MCMECAPolicyRule|  |MCMPolicyClause| |MCMPolicyClauseComponent    |
 +----------------+  +---------------+ |Decorator                   |
                                       +---------------A------------+
                                                       |
                                                       |
                                              +--------+---------+
                                              |MCMPolicyComponent|
                                              +--------A---------+
                                                       |
                                                       |
                  +--------------------+---------------+----+
          +-------+------+   +---------+--------+  +--------+------+
          |MCMPolicyEvent|   |MCMPolicyCondition|  |MCMPolicyAction|
          +--------------+   +------------------+  +---------------+

        Figure 1 Exemplary External Information Model (from the category of selectors that
   have been defined MEF)

   The CapIM model uses the Decorator Pattern [Gamma]. The decorator
   pattern enables a base object to be "wrapped" by Al-Shaer et al. as "prefix-match" [Alshaer].
   These selectors allow zero or more
   decorator objects. The Decorator MAY attach additional
   characteristics and behavior, in the specification of ranges form of values attributes at runtime
   in a transparent manner without requiring recompilation and/or
   redeployment. This is done by means using composition instead of simple regular expressions. The typical case is
   inheritance. Objects can "wrap" (more formally, extend the IP address
   selector (e.g., 10.10.1.*).

   There interface
   of) an object. In essence, a new object can be built out of pre-
   existing objects.

   The Decorator Pattern is no need applied to distinguish between prefix match and range-based
   selectors; for example, the address range "10.10.1.*" maps allow NSF instances to
   "[10.10.1.0,10.10.1.255]".

   Another category aggregate
   I2NSFSecurityCapability instances. By means of selector types includes those based on regular
   expressions. this aggregation, an
   NSF can be associated to the functions it provides in terms of
   security policy enforcement, both at specification time (i.e., when
   a vendor provides a new NSF), statically, when a NSF is added to a
   (virtualized) networking environment, and dynamically, during
   network operations. Figure 2 shows an NSF aggregating zero or more
   SecurityCapabilities. This selector type may be thought of as an NSF possessing
   (or defining) zero or more Security Capabilities. This "possession"
   (or "definition") is used frequently at the application
   layer, where data are often represented in UML as strings of text. an aggregated, called
   HasSecurityCapability. The
   regex-based selector type also includes string-based selectors, where
   matching hasSecurityCapabilityDetail is evaluated using string matching algorithms (SMA)
   [Cormen]. Indeed, for our purposes, string matching an
   association class that allows NSF instances to aggregate
   I2NSFSecurityCapability instances. An NSF MAY be described by 0 or
   more SecurityCapabilities.

   Since there can be mapped to
   regular expressions, even if in practice SMA are much faster. For
   instance, Squid (http://www.squid-cache.org/), a popular Web caching
   proxy many types of NSF that offers various access control Capabilities, allows have many different types
   of I2NSFSecurityCapabilities, the definition of conditions on URLs that can a SecurityCapability
   must be evaluated with SMA
   (e.g., dstdomain) or regex matching (e.g., dstdom_regex).

   As done using the context of an example, NSF. This is realized by an
   association class in UML. HasSecurityCapabilityDetail is an
   association class. This yields the condition clause:

      "URL = *.website.*"

   matches all following design:

       +-----+0..n                      0..n+--------------------+
       |     |/ \  HasSecurityCapability    |                    |
       | NSF | A ----------+----------------+ SecurityCapability |
       |     |\ /          ^                |                    |
       +-----+             |                +--------------------+
                           |
             +-------------+---------------+
             | HasSecurityCapabilityDetail |
             + ----------------------------+

             Figure 2  Defining SecurityCapabilities of an NSF

   This enables the URLs that contain a subdomain named website and HasSecurityCapabilityDetail association class to be
   the
   ones whose path contain target of a Policy Rule. That is, the string ".website.". As another example,
   the condition clause:

      "MIME_type = video/*"

   matches all MIME objects whose type is video.

   Finally, the idea of a custom check selector is introduced. For
   instance, malware analysis can look for specific patterns,
   HasSecurityCapabilityDetail class has attributes and
   returns a Boolean value if the pattern is found or not.

   In order to be properly used by high-level policy-based processing
   systems (such as reasoning systems methods that
   define which I2NSFSecurityCapabilities of this NSF are visible and policy translation systems),
   these custom check selectors
   can be modeled as black-boxes (i.e., a
   function used [MCM].

   3.3.2. The SecurityCapability class

   The SecurityCapability class defines the concept of metadata that has a defined set
   define security-related capabilities. It is subclassed from an
   appropriate class of inputs and outputs for a
   particular state), which provide an associated Boolean output.

   More examples external metadata information
   model.Subclasses of custom check selectors will be presented in the
   next versions of SecurityCapability class can be used to
   answer the draft. Some examples are already present in
   Section 6.

3.4.2.  Capability Selection and Usage

   Capability selection and usage following questions:

     o  What are based on the set of security
   traffic classification and action features events that an NSF provides;
   these are defined caught by the Capability model. If the NSF has the
   classification features needed to identify trigger the packets/flows
   required by a policy, and
        condition clause evaluation (Event subclass)?

     o  What kind of condition clauses can enforce be specified on the needed actions, then
   that particular NSF is capable of enforcing the policy.

   NSFs may also have specific characteristics that automatic processes
   or administrators need to know when they have to generate
   configurations, like
        define valid rules? This question splits into two questions:
        (1) what are the available resolution strategies conditions that can be specified (Condition
        subclass), and the
   possibility (2) how to set default actions.

   The Capability information model can be used for two purposes:
   describing the features provided by generic security functions, and
   describing the features provided by specific products. The term
   Generic Network Security Function (GNSF) refers to the classes build a valid condition clause from a
        set of
   security functions that individual conditions (ClauseEvaluation class).

     o  What are known by a particular system. The idea
   is to have generic components whose behavior is well understood, so the actions that the generic component NSF can be used even if it has some vendor-
   specific functions. These generic functions represent enforce (Action class)?

     o  How to define a point of
   interoperability, and can be provided by any product that offers correct policy on the
   required Capabilities. GNSF examples include packet filter, URL
   filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
   filter, monitoring, NSF?

   3.3.3. I2NSF Condition Clause Operator Types

   After having analyzed the literature and anonymity proxy; these will be described
   later in a revision some existing NSFs, the
   types of this draft selectors are categorized as well exact-match, range-based,
   regex-based, and custom-match [Bas15][Lunt].

   Exact-match selectors are (unstructured) sets: elements can only be
   checked for equality, as in no order is defined on them.  As an upcoming data
   model contribution.

   The next section will introduce
   example, the algebra to define protocol type field of the
   information model IP header is an unordered
   set of Capability registration. This associates
   NSFs integer values associated to Capabilities, and checks whether an NSF has protocols. The assigned protocol
   numbers are maintained by the
   Capabilities needed to enforce policies.

3.4.3.  Capability Algebra

   We introduce a Capability Algebra IANA
   (http://www.iana.org/assignments/protocol-numbers/protocol-
   numbers.xhtml).

   In this selector, it is only meaningful to ensure specify condition clauses
   that use either the actions of
   different policy rules do not conflict with each other.

   Formally, two I2NSF Policy Actions conflict with each other if:

      o the event clauses of each evaluate "equals" or "not equals operators":

      proto = tcp, udp       (protocol type field equals to TRUE
      o TCP or UDP)

      proto != tcp           (protocol type field different from TCP)

   No other operators are allowed on exact-match selectors. For
   example, the following is an invalid condition clauses of each evaluate clause, even if
   protocol types map to TRUE
      o the action clauses affect integers:

      proto < 62             (invalid condition)

   Range-based selectors are ordered sets where it is possible to
   naturally specify ranges as they can be easily mapped to integers.
   As an example, the same object ports in different ways the TCP protocol may be represented
   using a range-based selector (e.g., 1024-65535). For example, if we the
   following are examples of valid condition clauses:

      source_port = 80

      source_port < 1024

      source_port < 30000 && source_port >= 1024

   We include, in range-based selectors, the category of selectors that
   have two Policies:

      P1: During 8am-6pm, if traffic been defined by Al-Shaer et al. as "prefix-match" [Alshaer].
   These selectors allow the specification of ranges of values by means
   of simple regular expressions. The typical case is external, then run through FW
      P2: During 7am-8pm, conduct anti-malware investigation the IP address
   selector (e.g., 10.10.1.*). There is no conflict need to distinguish between P1
   prefix match and P2, since range-based selectors as 10.10.1.* easily maps to
   [10.10.1.0, 10.10.1.255].

   Another category of selector types includes the actions are
   different. However, consider these two policies:

      P3: During 8am-6pm, John gets GoldService
      P4: During 10am-4pm, FTP from all users gets BronzeService

   P3 and P4 are now in conflict, because between regex-based
   selectors, where the hours of 10am and
   4pm, matching is performed by using regular
   expressions. This selector type is used frequently at the actions of P3 and P4
   application layer, where data are different and apply to the same
   user (i.e., John).

   Let us define the concept of a "matched" policy rule often represented as one in which
   its event and condition clauses are both evaluate strings of
   text. The regex-based selector type also includes string-based
   selectors, where matching is evaluated using string matching
   algorithms (SMA) [Cormen]. Indeed, for our purposes, string matching
   can be mapped to true. This enables
   the actions regular expressions, even if in this policy rule to be evaluated. Then, the
   conflict matrix is defined by practice SMA are
   much faster. For instance, Squid (http://www.squid-cache.org/), a 5-tuple {Ac, Cc, Ec, RSc, Dc},
   where:

      o Ac is
   popular Web caching proxy that offers various access control
   capabilities, allows the set definition of Actions currently available from conditions on URLs that can
   be evaluated with SMA (e.g., dstdomain) or regex matching (e.g.,
   dstdom_regex).

   As an example, the NSF;
      o Cc is condition clause:

      URL = *.website.*

   matches all the set of Conditions currently available from URLs that contain a subdomain named website and the NSF;
      o Ec is
   ones whose path contain the set of Events string ".website.". As another example,
   the NSF condition clause:

      MIME_type = video/*

   matches all MIME objects whose type is able to respond to.
        Therefore, video.

   Finally, the event clause idea of an I2NSF ECA Policy Rule that a custom check selector is
        written introduced. For
   instance, malware analysis can look for an NSF will only allow specific patterns, and
   returns a set of designated events
        in Ec. For compatibility purposes, we will assume that Boolean value if Ec={}
        (that is, Ec is empty), the NSF only accepts CA policies.
      o RSc pattern is the set of Resolution Strategies that can found or not.

   In order to be properly used to
        specify how to resolve conflicts by high-level policy-based processing
   systems (such as reasoning systems and policy translation systems),
   these custom check selectors can be modeled as black-boxes (i.e., a
   function that occur between has a defined set of inputs and outputs for a
   particular state), which provide an associated Boolean output.

   More examples of custom check selectors will be presented in the actions
   next versions of the same or different policy rules that draft. Some examples are matched and
        contained already present in this particular NSF;
      o Dc defines
   Section 6.

   3.3.4. Capability Selection and Usage

   Capability selection and usage are based on the notion set of a Default security
   traffic classification and action features that can be used to
        specify a predefined action when no other alternative action
        was matched an NSF provides;
   these are defined by the currently executing I2NSF Policy Rule. An
        analogy is capability model. If the use of a default statement in a C switch
        statement. This field of NSF has the Capability algebra
   classification features needed to identify the packets/flows
   required by a policy, and can take enforce the
        following values:
           - An explicit action (that has been predefined; typically,
             this means needed actions, then that it
   particular NSF is fixed and not configurable), denoted
             as Dc ={a}. In this case, capable of enforcing the NSF will always use policy.

   NSFs may also have specific characteristics that automatic processes
   or administrators need to know when they have to generate
   configurations, like the
             action as as available resolution strategies and the default action.
           - A
   possibility to set of explicit actions, denoted Dc={a1,a2, ...};
             typically, this means that any **one** action default actions.

   The capability information model can be used
             as for two purposes:
   describing the default action. This enables features provided by generic security functions, and
   describing the policy writer features provided by specific products. The term
   Generic Network Security Function (GNSF) refers to
             choose one the classes of
   security functions that are known by a predefined set of actions {a1, a2, ...} particular system. The idea
   is to
             serve as the default action.

           - A fully configurable default action, denoted as Dc={F}.
             Here, F have generic components whose behavior is a dummy symbol (i.e., a placeholder value) well understood, so
   that the generic component can be used to indicate that the default action even if it has some vendor-
   specific functions. These generic functions represent a point of
   interoperability, and can be
             freely selected provided by any product that offers the policy editor from the actions Ac
             available at the NSF. In other words, one of the actions
             Ac may
   required capabilities. GNSF examples include packet filter, URL
   filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
   filter, monitoring, and anonymity proxy; these will be selected by the policy writer to act described
   later in a revision of this draft as the
             default action.
           - No default action, denoted well as Dc={}, for cases where in an upcoming data
   model contribution.

   The next section will introduce the
             NSF does not allow algebra to compose the explicit selection
   information model of a default
             action.

*** Note capability registration, defined to WG: please review associate
   NSFs to capabilities and to check whether a NSF has the following paragraphs
*
*  Interesting capabilities
   needed to enforce policies.

3.3.5. Capability concepts that could be considered for Algebra

   We introduce a next
*  version of the Capability model and algebra include:
*
*     o Event clause representation (e.g., conjunctive vs. disjunctive
*       normal form for Boolean clauses)
*     o Event clause evaluation function, which would enable more
*       complex expressions than simple Boolean expressions Algebra to be used
*
*
* ensure that the actions of
   different policy rules do not conflict with each.

   Formally, two I2NSF Policy Rules conflict with each other if:

   o Condition clause representation (e.g., conjunctive vs.
*       disjunctive normal form for Boolean clauses)
* the event clauses of each evaluate to TRUE

   o Condition clause evaluation function, which would enable more
*       complex expressions than simple Boolean expressions the condition clauses of each evaluate to be used
* TRUE

   o Action clause evaluation strategies (e.g., execute first
*       action only, execute last the action only, execute all actions,
*       execute clauses affect the same object in different ways

   For example, if we have two Policy Rules in the same Policy:

      R1: During 8am-6pm, if traffic is external, then run through FW
      R2: During 7am-8pm, conduct anti-malware investigation

   There is no conflict between R1 and R2, since the actions are
   different. However, consider these two rules:

      R3: During 8am-6pm, John gets GoldService
      R4: During 10am-4pm, FTP from all users gets BronzeService

   R3 and R4 are now in conflict, between the hours of 10am and 4pm,
   because the actions until an action fails)
*     o The use of metadata, which can be associated R3 and R4 are different and apply to both an I2NSF
*       Policy Rule as well the same
   user (i.e., John).

   Let us define the concept of a "matched" policy rule as objects contained one in which
   its event and condition clauses both evaluate to true. Then, the
   behavior of the I2NSF Policy
*       Rule (e.g., an action), that describe Rule, as specified by the object and/or
*       prescribe behavior. Descriptive examples include adding
*       authorship information and defining CapIM, is defined
   by a time period when an NSF
*       can be used to be defined; prescriptive examples include
*       defining rule priorities and/or ordering.
*
*  Given two sets of Capabilities, denoted as
*
*     cap1=(Ac1,Cc1,Ec1,RSc1,Dc1) and
*     cap2=(Ac2,Cc2,Ec2,RSc2,Dc2),
*
*  two set operations are defined for manipulating Capabilities:
*
*     o Capability addition:
*          cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1}
* 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where:

   o Capability subtraction:
*          cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1}
*
*  In the above formulae, "U" Ac is the set union operator and "\" of Actions currently available from the NSF;

   o Cc is the
* set difference operator.

*  The addition and subtraction of Capabilities are defined as currently available from the
*  addition (set union) and subtraction (set difference) of both NSF;

   o Ec is the
*  Capabilities and their associated actions. set of Events that an NSF can catch. Note that **only** the
*  leftmost (in this case, the first matched policy rule) Resolution
*  Strategy and Default Action are used.
*
*  Note: actions, events, and conditions are **symmetric**. This means
* for NSF
      (e.g., a packet filter) that when two matched policy rules are merged, the resultant actions
*  and Capabilities are defined as not able to react to events,
      this set will be empty;

   o RSc is the union set of each individual matched
*  policy rule. However, both resolution strategies and default actions
*  are **asymmetric** (meaning Resolution Strategies that in general, they can **not** be
*  combined, as one has used to be chosen). In order
      specify how to simplify this, we
*  have chosen resolve conflicts that occur between the **leftmost** resolution strategy and actions
      of the
*  **leftmost** default action same or different policy rules that are chosen. This enables the developer
*  to view the leftmost matched rule as the "base" to which other
* and
      contained in this particular NSF;

   o Dc defines the notion of a Default action. This action can be
      either an explicit action that has been chosen {a}, or a set of
      actions {F}, where F is a dummy symbol (i.e., a placeholder
      value) that can be used to indicate that the default action can
      be freely selected by the policy editor. This is denoted as {F} U
      {a}.

   EVc defines the set of Condition Clause Evaluation Rules that can be
   used at the NSF to decide when the condition clause is true given
   the result of the evaluation of the individual conditions. Before
   introducing the rest of the capability model, we will introduce the
   symbols that we will use to represent set operations:

   o "U" is the union operation, A U B returns a new set that includes
      all the elements in A and all the elements in B

   o "\" is the set minus operation, A \ B returns all the elements
      that are added.
*
* in A but not in B.

   Given two sets of capabilities, denoted as cap1=(Ac1,Cc1,
   Ec1,RSc1,Dc1,EVc1) and cap2=(Ac2,Cc2,Ec2,RSc2,Dc2,EVc2)
   two set operations are defined for manipulating capabilities:

   o capability addition: cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U
      Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2}

   o capability subtraction: cap_1-cap_2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1
      \ Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2}

   In the above formulae, "U" is the set union operator and "\" is the
   set difference operator.

   The addition and subtraction of capabilities are defined as the
   addition (set union) and subtraction (set difference) of both the
   capabilities and their associated actions. Note that the Resolution
   Strategies and Default Actions are added in both cases.

   As an example, assume that a packet filter Capability, capability, Cpf, is
*
   defined. Further, assume that a second Capability, capability, called Ctime,
*
   exists, and that it defines time-based conditions. Suppose we need
*
   to construct a new generic packet filter, Cpfgen, that adds
*  time-based time-
   based conditions to Cpf.
*
*
* Conceptually, this is simply the addition
   of the Cpf and Ctime
*  Capabilities, capabilities, as follows:
*

      Apf   =  {Allow, Deny}
*
      Cpf   =  {IPsrc,IPdst,Psrc,Pdst,protType}
*
      Epf   =  {}
*
      RSpf  =  {FMR}
*
      Dpf   =  {A1}
*
*
      EVpf  =  {DNF}

      Atime =  {Allow, Deny, Log}
*
      Ctime =  {timestart, timeend, datestart, datestop}
*
      Etime =  {}
*
      RStime = {LMR}
*
      Dtime  = {A2}
*
*
      EVtime = {}

   Then, Cpfgen is defined as:
*

      Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf, Dpf}
* RSpf U RStime,
            Dpf U Time, EVpf U EVtime}
             = {Allow, Deny, Log},
*              {{IPsrc, IPdst, Psrc, Pdst, protType}
               {{IPsrc,IPdst,Psrc,Pdst,protType} U
* {timestart, timeend,
                 datestart, datestop}},
*              {},
*              {FMR},
*              {A1}
*
* datestop}}
               {}
               {FMR, LMR}
               {A1, A2}
               {DNF}

   In other words, Cpfgen provides three actions (Allow, Deny, Log),
*
   filters traffic based on a 5-tuple that is logically ANDed with a
*
   time period, can use either FMR or LMR (but obviously not both), and uses FMR; it provides
   can provide either A1 or A2 (but again, not both) as a default action, and
*  it does not react
   action. In any case, multiple conditions will be processed with DNF
   when evaluating the condition clause.

  4. IANA Considerations

   TBD

  5. References

  5.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to events.

*  Note: We are investigating, Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
             Syntax Specifications: ABNF", RFC 2234, Internet Mail
             Consortium and Demon Internet Ltd., November 1997.

   [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for a next revision of this draft, the
*  possibility
             Network Configuration Protocol (NETCONF)", RFC 6020,
             October 2010.

   [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
             Used to add further operations that do not follow the
*  symmetric vs. asymmetric properties presented Form Encoding Rules in the previous note.
*  We are looking Various Routing Protocol
             Specifications", RFC 5511, April 2009.

   [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
             M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
             J., and S. Waldbusser, "Terminology for use cases that may justify the complexity added
*  by the availability of more Capability manipulation operations.
*
*** End Note Policy-Based
             Management", RFC 3198, DOI 10.17487/RFC3198,
             November 2001, <http://www.rfc-editor.org/info/rfc3198>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar,
             R., and J. Jeong, "Interface to WG

3.5.  Initial NSFs Capability Categories

   The following subsections define three common categories of
   Capabilities: network security, content security, Network Security Functions
             (I2NSF): Problem Statement and attack
   mitigation. Future versions of this document may expand both the
   number of categories as well as the types of Capabilities within a
   given category.

3.5.1. Use Cases", RFC 8192,
             DOI 10.17487/RFC8192, July 2017,
             <https://www.rfc-editor.org/info/rfc8192>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R.
             Kumar, "Framework for Interface to Network Security Capabilities
             Functions", RFC 8329, February 2018.

  5.2. Informative References

   [INCITS359 RBAC]   NIST/INCITS, "American National Standard for
              Information Technology - Role Based Access Control",
              INCITS 359, April, 2003

   [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to
              Network security is a category that describes the inspecting and
   processing of network traffic based on the use of pre-defined
   security policies.

   The inspecting portion may be thought of as a packet-processing
   engine that inspects packets traversing networks, either directly or
   in the context of flows with which the packet is associated. From
   the perspective of packet-processing, implementations differ in the
   depths of packet headers and/or payloads they can inspect, the
   various flow and context states they can maintain, and the actions
   that can be applied to the packets or flows.

3.5.2.  Content Security Capabilities

   Content security is another category of security Capabilities
   applied to the application layer. Through analyzing traffic contents
   carried in, for example, the application layer, content security
   Capabilities can be used to identify various security functions that
   are required. These include defending against intrusion, inspecting
   for viruses, filtering malicious URL or junk email, blocking illegal
   web access, or preventing malicious data retrieval.

   Generally, each type of threat Functions (I2NSF) Terminology", Work in the content security category has
   a set of unique characteristics, and requires handling using a set
   of methods that are specific to that type of content. Thus, these
   Capabilities will be characterized by their own content-specific
   security functions.

3.5.3.  Attack Mitigation Capabilities

   This category of security Capabilities is used to detect and mitigate
   various types of network attacks. Today's common network attacks can
   be classified into the following sets:

      o DDoS attacks:
        - Network layer DDoS attacks: Examples include SYN flood, UDP
          flood, ICMP flood, IP fragment flood, IPv6 Routing header
          attack, and IPv6 duplicate address detection attack;
        - Application layer DDoS attacks: Examples include HTTP flood,
          https flood, cache-bypass HTTP floods, WordPress XML RPC
          floods, and ssl DDoS.
      o Single-packet attacks:
        - Scanning and sniffing attacks: IP sweep, port scanning, etc.
        - malformed packet attacks: Ping of Death, Teardrop, etc.
        - special packet attacks: Oversized ICMP, Tracert, IP timestamp
          option packets, etc.

   Each type of network attack has its own network behaviors and
   packet/flow characteristics. Therefore, each type of attack needs a
   special security function, which is advertised as a set of
   Capabilities, for detection and mitigation. The implementation and
   management of this category of security Capabilities of attack
   mitigation control is very similar to the content security control
   category. A standard interface, through which the security controller
   can choose and customize the given security Capabilities according to
   specific requirements, is essential.

4.  Information Sub-Model for Network Security Capabilities

   The purpose of the Capability Information Sub-Model is to define the
   concept of a Capability, and enable Capabilities to be aggregated to
   appropriate objects. The following sections present the Network
   Security, Content Security, and Attack Mitigation Capability
   sub-models.

4.1.  Information Sub-Model for Network Security

   The purpose of the Network Security Information Sub-Model is to
   define how network traffic is defined, and determine if one or more
   network security features need to be applied to the traffic or not.
   Its basic structure is shown in the following figure:

                                      +---------------------+
     +---------------+ 1..n      1..n |                     |
     |               |/ \            \| A Common Superclass |
     | ECAPolicyRule + A -------------+   for ECA Objects   |
     |               |\ /            /|                     |
     +-------+-------+                +---------+-----------+
            / \                                / \
             |                                  |
             |                                  |
  (subclasses to define Network         (subclasses of Event,
    Security ECA Policy Rules       Condition, and Action Objects
    extensibly, so that other           for Network Security
    Policy Rules can be added)
              Progress, January, 2018

   [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J.,
              Halpern, J., Coleman, J., "Generic Policy Rules)

       Figure 2. Network Security Information Sub-Model Overview

   In the above figure, the ECAPolicyRule, along with the Event,
   Condition, and Action Objects, are defined in the external ECA Information Model. The Network Security Sub-Model extends all of
   these objects in order to define security-specific ECA Policy Rules,
   as well as extensions to the (generic) Event, Condition, and
   Action objects.

   An I2NSF Policy Rule is a special type of Policy Rule that is in
   event-condition-action (ECA) form. It consists of the Policy Rule,
   components of a Policy Rule (e.g., events, conditions, actions, and
   some extensions like resolution policy, default action and external
   data), and optionally, metadata. It can be applied to both uni- and
   bi-directional traffic across the NSF.

   Each rule is triggered by one or more events. If the set of events
   evaluates to true, then a set of conditions are evaluated and, if
   true, then enable a set of actions to be executed. This takes the
   following conceptual form:

      IF <event-clause> is TRUE
         IF <condition-clause> is TRUE
            THEN execute <action-clause>
         END-IF
      END-IF

   In the above example, the Event, Condition, and Action portions of a
   Policy Rule are all **Boolean Clauses**. Hence, they can contain
   combinations of terms connected by the three logical connectives
   operators (i.e., AND, OR, NOT). An example is:

      ((SLA==GOLD) AND ((numPackets>burstRate) OR NOT(bwAvail<minBW)))

   Note that Metadata, such as Capabilities, can be aggregated by I2NSF
   ECA Policy Rules.

4.1.1.  Network Security Policy Rule Extensions

   Figure 3 shows an example of more detailed design of the ECA Policy
   Rule subclasses that are contained in the Network Security
   Information Sub-Model, which just illustrates how more specific
   Network Security Policies are inherited and extended from the
   SecurityECAPolicyRule class. Any new kinds of specific Network
   Security Policy can be created by following the same pattern of
   class design as below.

                            +---------------+
                            |    External   |
                            | ECAPolicyRule |
                            +-------+-------+
                                   / \
                                    |
                                    |
                       +------------+----------+
                       | SecurityECAPolicyRule |
                       +------------+----------+
                                    |
                                    |
          +----+-----+--------+-----+----+---------+---------+--- ...
          |          |        |          |         |         |
          |          |        |          |         |         |
   +------+-------+  |  +-----+-------+  |  +------+------+  |
   |Authentication|  |  |  Accounting |  |  |ApplyProfile |  |
   |ECAPolicyRule |  |  |ECAPolicyRule|  |  |ECAPolicyRule|  |
   +--------------+  |  +-------------+  |  +-------------+  |
                     |                   |                   |
              +------+------+     +------+------+     +--------------+
              |Authorization|     |   Traffic   |     |ApplySignature|
              |ECAPolicyRule|     | Inspection  |     |ECAPolicyRule |
              +-------------+     |ECAPolicyRule|     +--------------+
                                  +-------------+

   Figure 3. Network Security Info Sub-Model ECAPolicyRule Extensions

   The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule
   hierarchy. It inherits from the (external) generic ECA Policy Rule,
   and represents the specialization of this generic ECA Policy Rule to
   add security-specific ECA Policy Rules. The SecurityECAPolicyRule
   contains all of the attributes, methods, and relationships defined in
   its superclass, and adds additional concepts that are required for
   Network Security (these will be defined in the next version of this
   draft). The six SecurityECAPolicyRule subclasses extend the
   SecurityECAPolicyRule class to represent six different types of
   Network Security ECA Policy Rules. It is assumed that the (external)
   generic ECAPolicyRule class defines basic information in the form of
   attributes, such as an unique object ID, as well as a description
   and other necessary information.

*** Note to WG
*
*   The design in Figure 3 represents the simplest conceptual design
*   for network security. An alternative model would be to use a
*   software pattern (e.g., the Decorator pattern); this would result
*   in the SecurityECAPolicyRule class being "wrapped" by one or more
*   of the six subclasses shown in Figure 3. The advantage of such a
*   pattern is to reduce the number of active objects at runtime, as
*   well as offer the ability to combine multiple actions of different
*   policy rules (e.g., inspect traffic and then apply a filter) into
*   one. The disadvantage is that it is a more complex software design.
*   The design team is requesting feedback from the WG regarding this.
*
*** End of Note to WG

   It is assumed that the (external) generic ECA Policy Rule is
   abstract; the SecurityECAPolicyRule is also abstract. This enables
   data model optimizations to be made while making this information
   model detailed but flexible and extensible. For example, abstract
   classes may be collapsed into concrete classes.

   The SecurityECAPolicyRule defines network security policy as a
   container that aggregates Event, Condition, and Action objects,
   which are described in Section 4.1.3, 4.1.4, and 4.1.5,
   respectively. Events, Conditions, and Actions can be generic or
   security-specific.

   Brief class descriptions of these six ECA Policy Rules are provided
   in Appendix A.

4.1.2.  Network Security Policy Rule Operation

   A Network Security Policy consists of one or more ECA Policy Rules
   formed from the information model described above. In simpler cases,
   where the Event and Condition clauses remain unchanged, then the
   action of one Policy Rule may invoke additional network security
   actions from other Policy Rules. Network security policy examines
   and performs basic processing of the traffic as follows:

      1. The NSF evaluates the Event clause of a given
         SecurityECAPolicyRule (which can be generic or specific to
         security, such as those in Figure 3). It may use security
         Event objects to do all or part of this evaluation, which are
         defined in section 4.1.3. If the Event clause evaluates to
         be TRUE, then the Condition clause of this SecurityECAPolicyRule
         is evaluated; otherwise, the execution of this
         SecurityECAPolicyRule is stopped, and the next
         SecurityECAPolicyRule (if one exists) is evaluated.

      2. The Condition clause is then evaluated.  It may use security
         Condition objects to do all or part of this evaluation, which
         are defined in section 4.1.4. If the Condition clause
         evaluates to TRUE, it is defined as "matching" the
         SecurityECAPolicyRule; otherwise, execution of this
         SecurityECAPolicyRule is stopped, and the next
         SecurityECAPolicyRule (if one exists) is evaluated.
      3. The set of actions to be executed are retrieved, and then the
         resolution strategy is used to define their execution order.
         This process includes using any optional external data
         associated with the SecurityECAPolicyRule.
      4. Execution then takes one of the following three forms:
         a. If one or more actions is selected, then the NSF may
            perform those actions as defined by the resolution
            strategy. For example, the resolution strategy may only
            allow a single action to be executed (e.g., FMR or LMR),
            or it may allow all actions to be executed (optionally,
            in a particular order). In these and other cases, the NSF
            Capability MUST clearly define how execution will be done.
            It may use security Action objects to do all or part of
            this execution, which are defined in section 4.1.5. If the
            basic Action is permit or mirror, the NSF firstly performs
            that function, and then checks whether certain other
            security Capabilities are referenced in the rule. If yes,
            go to step 5. If no, the traffic is permitted.
         b. If no actions are selected, and if a default action exists,
            then the default action is performed. Otherwise, no actions
            are performed.
         c. Otherwise, the traffic is denied.
      5. If other security Capabilities (e.g., the conditions and/or
         actions implied by Anti-virus or IPS profile NSFs) are
         referenced in the action set of the SecurityECAPolicyRule, the
         NSF can be configured to use the referenced security
         Capabilities (e.g., check conditions or enforce actions).
         Execution then terminates.

   One policy or rule can be applied multiple times to different
   managed objects (e.g., links, devices, networks, VPNS). This not
   only guarantees consistent policy enforcement, but also decreases
   the configuration workload.

4.1.3.  Network Security Event Sub-Model

   Figure 4 shows a more detailed design of the Event subclasses that
   are contained in the Network Security Information Sub-Model.

   The four Event classes shown in Figure 4 extend the (external)
   generic Event class to represent Events that are of interest to
   Network Security. It is assumed that the (external) generic Event
   class defines basic Event information in the form of attributes,
   such as a unique event ID, a description, as well as the date and
   time that the event occurred.

                                     +---------------------+
        +---------------+ 1..n   1..n|                     |
        |               |/ \        \| A Common Superclass |
        | ECAPolicyRule + A ---------+   for ECA Objects   |
        |               |\ /        /|                     |
        +---------------+            +---------+-----------+
                                              / \
                                               |
                                               |
                   +---------------+-----------+------+
                   |               |                  |
                   |               |                  |
             +-----+----+   +------+------+     +-----+-----+
             | An Event |   | A Condition |     | An Action |
             |   Class  |   |    Class    |     |   Class   |
             +-----+----+   +-------------+     +-----------+
                  / \
                   |
                   |
             +-----+---------+----------------+--------------+-- ...
             |               |                |              |
             |               |                |              |
     +-------+----+ +--------+-----+ +--------+-----+ +------+-----+
     |UserSecurity| |    Device    | |    System    | |TimeSecurity|
     |   Event    | | SecurityEvent| | SecurityEvent| |     Event  |
     +------------+ +--------------+ +--------------+ +------------+

    Figure 4. Network Security Info Sub-Model Event Class Extensions

   The following are assumptions that define the functionality of the
   generic Event class. If desired, these could be defined as
   attributes in a SecurityEvent class (which would be a subclass of
   the generic Event class, and a superclass of the four Event classes
   shown in Figure 4). However, this makes it harder to use any
   generic Event model with the I2NSF events. Assumptions are:

      - All four SecurityEvent subclasses are concrete
      - The generic Event class uses the composite pattern, so
        individual Events as well as hierarchies of Events are
        available (the four subclasses in Figure 4 would be
        subclasses of the Atomic Event class); otherwise, a mechanism
        is needed to be able to group Events into a collection
      - The generic Event class has a mechanism to uniquely identify
        the source of the Event
      - The generic Event class has a mechanism to separate header
        information from its payload
      - The generic Event class has a mechanism to attach zero or more
        metadata objects to it

*** Note to WG:
*
*   The design in Figure 4 represents the simplest conceptual design
*   design for describing Security Events. An alternative model would
*   be to use a software pattern (e.g., the Decorator pattern); this
*   would result in the SecurityEvent class being "wrapped" by one or
*   more of the four subclasses shown in Figure 4. The advantage of
*   such a pattern is to reduce the number of active objects at runtime,
*   as well as offer the ability to combine multiple events of different
*   types into one. The disadvantage is that it is a more complex
*   software design.
*
*** End of Note to WG

   Brief class descriptions are provided in Appendix B.

4.1.4.  Network Security Condition Sub-Model

   Figure 5 shows a more detailed design of the Condition subclasses
   that are contained in the Network Security Information Sub-Model.
   The six Condition classes shown in Figure 5 extend the (external)
   generic Condition class to represent Conditions that are of interest
   to Network Security. It is assumed that the (external) generic
   Condition class is abstract, so that data model optimizations may be
   defined. It is also assumed that the generic Condition class defines
   basic Condition information in the form of attributes, such as a
   unique object ID, a description, as well as a mechanism to attach
   zero or more metadata objects to it. While this could be defined as
   attributes in a SecurityCondition class (which would be a subclass
   of the generic Condition class, and a superclass of the six
   Condition classes shown in Figure 5), this makes it harder to use
   any generic Condition model with the I2NSF conditions.

*** Note to WG:
*
*   The design in Figure 5 represents the simplest conceptual design
*   for describing Security Conditions. An alternative model would be
*   to use a software pattern (e.g., the Decorator pattern); this would
*   result in the SecurityCondition class being "wrapped" by one or
*   more of the six subclasses shown in Figure 5. The advantage of such
*   a pattern is to reduce the number of active objects at runtime, as
*   well as offer the ability to combine multiple conditions of
*   different types into one. The disadvantage is that it is a more
*   complex software design.
*   The design team is requesting feedback from he WG regarding this.
*
*** End of Note to WG
                                     +---------------------+
     +---------------+ 1..n     1..n |                     |
     |               |/ \           \| A Common Superclass |
     | ECAPolicyRule+ A -------------+   for ECA Objects   |
     |               |\ /           /|                     |
     +-------+-------+               +-----------+---------+
                                                / \
                                                 |
                                                 |
                       +--------------+----------+----+
                       |              |               |
                       |              |               |
                 +-----+----+  +------+------+  +-----+-----+
                 | An Event |  | A Condition |  | An Action |
                 |   Class  |  |    Class    |  |   Class   |
                 +----------+  +------+------+  +-----------+
                                     / \
                                      |
                                      |
           +--------+----------+------+---+---------+--------+--- ...
           |        |          |          |         |        |
           |        |          |          |         |        |
     +-----+-----+  |  +-------+-------+  |  +------+-----+  |
     |   Packet  |  |  | PacketPayload |  |  |    Target  |  |
     |  Security |  |  |    Security   |  |  |  Security  |  |
     | Condition |  |  |   Condition   |  |  |  Condition |  |
     +-----------+  |  +---------------+  |  +------------+  |
                    |                     |                  |
             +------+-------+  +----------+------+  +--------+-------+
             | UserSecurity |  | SecurityContext |  | GenericContext |
             |   Condition  |  |    Condition    |  |    Condition   |
             +--------------+  +-----------------+  +----------------+

  Figure 5. Network Security Info Sub-Model Condition Class Extensions

   Brief class descriptions are provided in Appendix C.

4.1.5.  Network Security Action Sub-Model

   Figure 6 shows a more detailed design of the Action subclasses that
   are contained in the Network Security Information Sub-Model.

   The four Action classes shown in Figure 6 extend the (external)
   generic Action class to represent Actions that perform a Network
   Security Control function.

   The three Action classes shown in Figure 6 extend the (external)
   generic Action class to represent Actions that are of interest to
   Network Security. It is assumed that the (external) generic Action
   class is abstract, so that data model optimizations may be defined.

                                      +---------------------+
      +---------------+ 1..n     1..n |                     |
      |               |/ \           \| A Common Superclass |
      | ECAPolicyRule+ A -------------+   for ECA Objects   |
      |               |\ /           /|                     |
      +---------------+               +-----------+---------+
                                                 / \
                                                  |
                                                  |
                          +--------------+--------+------+
                          |              |               |
                          |              |               |
                    +-----+----+  +------+------+  +-----+-----+
                    | An Event |  | A Condition |  | An Action |
                    |   Class  |  |    Class    |  |   Class   |
                    +----------+  +-------------+  +-----+-----+
                                                        / \
                                                         |
                                                         |
                       +-----------------+---------------+------- ...
                       |                 |               |
                       |                 |               |
                   +---+-----+      +----+---+    +------+-------+
                   | Ingress |      | Egress |    | ApplyProfile |
                   | Action  |      | Action |    |     Action   |
                   +---------+      +--------+    +--------------+

      Figure 6. Network Security Info Sub-Model Action Extensions

   It is also assumed that the generic Action class defines basic
   Action information in the form of attributes, such as a unique
   object ID, a description, as well as a mechanism to attach zero or
   more metadata objects to it. While this could be defined as
   attributes in a SecurityAction class (which would be a subclass of
   the generic Action class, and a superclass of the six Action classes
   shown in Figure 6), this makes it harder to use any generic Action
   model with the I2NSF actions.

*** Note to WG
*   The design in Figure 6 represents the simplest conceptual design
*   for describing Security Actions. An alternative model would be to
*   use a software pattern (e.g., the Decorator pattern); this would
*   result in the SecurityAction class being "wrapped" by one or more
*   of the three subclasses shown in Figure 6. The advantage of such a
*   pattern is to reduce the number of active objects at runtime, as
*   well as offer the ability to combine multiple actions of different
*   types into one. The disadvantage is that it is a more complex
*   software design.
*   The design team is requesting feedback from the WG regarding this.
*** End of Note to WG

   Brief class descriptions are provided in Appendix D.

4.2.  Information Model for I2NSF Capabilities

   The I2NSF Capability Model is made up of a number of Capabilities
   that represent various content security and attack mitigation
   functions. Each Capability protects against a specific type of
   threat in the application layer. This is shown in Figure 7.

   +-------------------------+ 0..n         0..n +---------------+
   |                         |/ \               \|   External    |
   | External ECA Info Model + A ----------------+   Metadata    |
   |                         |\ /  Aggregates   /|  Info Model   |
   +----+--------------------+      Metadata     +-----+---------+
        |                                             / \
        |                                              |
       / \                                             |
    Subclasses    +------------------------------------+-----------+
     derived      | Capability                      |              |
    for I2NSF     | Sub-Model            +----------+---------+    |
   Policy Rules   |                      | SecurityCapability |    |
                  |                      +----------+---------+    |
                  |                                 |              |
                  |                                 |              |
                  |          +----------------------+---+          |
                  |          |                          |          |
                  | +--------+---------+     +----------+--------+ |
                  | | Content Security |     | Attack Mitigation | |
                  | |   Capabilities   |     |    Capabilities   | |
                  | +------------------+     +-------------------+ |
                  +------------------------------------------------+

        Figure 7. I2NSF Security Capability High-Level Model

   Figure 7 shows a common I2NSF Security Capability class, called
   SecurityCapability. This enables us to add common attributes,
   relationships, and behavior to this class without affecting the
   design of the external metadata information model. All I2NSF
   Security Capabilities are then subclassed from the
   SecuritCapability class.

   Note: the SecurityCapability class will be defined in the next
   version of this draft, after feedback from the WG is obtained.

4.3.  Information Model for Content Security Capabilities

   Content security is composed of a number of distinct security
   Capabilities; each such Capability protects against a specific type
   of threat in the application layer. Content security is a type of
   Generic Network Security Function (GNSF), which summarizes a
   well-defined set of security Capabilities, and was shown in Figure 7.

   Figure 8 shows exemplary types of the content security GNSF.

     +--------------------------------------------------------------+
     |                             +--------------------+           |
     |   Capability                | SecurityCapability |           |
     |   Sub-Model:                +---------+----------+           |
     | Content Security                   / \                       |
     |                                     |                        |
     |                                     |                        |
     |       +-------+----------+----------+---------------+        |
     |       |       |          |                          |        |
     | +-----+----+  |  +-------+----+             +-------+------+ |
     | |Anti-Virus|  |  | Intrusion  |             |    Attack    | |
     | |Capability|  |  | Prevention |             |  Mitigation  | |
     | +----------+  |  | Capability |             | Capabilities | |
     |               |  +------------+             +--------------+ |
     |               |                                              |
     |      +--------+----+------------+-----------+--------+       |
     |      |             |            |           |        |       |
     | +----+-----+ +-----+----+ +-----+----+ +----+-----+  |       |
     | |   URL    | |   Mail   | |   File   | |  Data    |  |       |
     | |Filtering | |Filtering | |Filtering | |Filtering |  |       |
     | |Capability| |Capability| |Capability| |Capability|  |       |
     | +----------+ +----------+ +----------+ +----------+  |       |
     |                                                      |       |
     |             +----------------+------------------+----+       |
     |             |                |                  |            |
     |      +------+------+  +------+------+ +---------+---------+  |
     |      |PacketCapture|  |FileIsolation| |ApplicationBehavior|  |
     |      | Capability  |  | Capability  | |    Capability     |  |
     |      +-------------+  +-------------+ +-------------------+  |
     +--------------------------------------------------------------+

          Figure 8. Network Security Capability Information Model

   The detailed description about a standard interface, and the
   parameters for all the security Capabilities of this category, will
   be defined in a future version of this document.

4.4.  Information Model for Attack Mitigation Capabilities

   Attack mitigation is composed of a number of GNSFs; each one
   protects against a specific type of network attack. Attack
   Mitigation security is a type of GNSF, which summarizes a
   well-defined set of security Capabilities, and was shown in
   Figure 7. Figure 9 shows exemplary types of Attack Mitigation GNSFs.

     +---------------------------------------------------------------+
     |                           +--------------------+              |
     |    Capability             | SecurityCapability |              |
     |    Sub-Model:             +---------+----------+              |
     | Attack Mitigation                  / \                        |
     |                                     |                         |
     |                                     |                         |
     |       +-------+--------+------------+-------------+           |
     |       |       |        |                          |           |
     | +-----+----+  |  +-----+----+             +-------+------+    |
     | | SSLDDoS  |  |  | PortScan |             |    Content   |    |
     | |Capability|  |  |Capability|             |   Security   |    |
     | +----------+  |  +----------+             | Capabilities |    |
     |               |                           +--------------+    |
     |               |                                               |
     |      +--------+----+------------+-----------+--------+        |
     |      |             |            |           |        |        |
     | +----+-----+ +-----+----+ +-----+----+ +----+-----+  |        |
     | | SYNFlood | | UDPFlood | |ICMPFlood | | WebFlood |  |        |
     | |Capability| |Capability| |Capability| |Capability|  |        |
     | +----------+ +----------+ +----------+ +----------+  |        |
     |                                                      |        |
     |         +-----------------+--------------+-----------+        |
     |         |                 |              |                    |
     | +-------+-------+ +-------+------+ +-----+-----+ +-----+----+ |
     | |IPFragmentFlood| |DNSAmplication| |PingOfDeath| | IPSweep  | |
     | |  Capability   | |  Capability  | |Capability | |Capability| |
     | +---------------+ +--------------+ +-----------+ +----------+ |
     +---------------------------------------------------------------+

        Figure 9. Attack Mitigation Capability Information Model

   The detailed description about a standard interface, and the
   parameters for all the security Capabilities of this category, will
   be defined in a future version of this document.

5.  Security Considerations

   The security Capability policy information sent to NSFs should be
   protected by a secure communication channel, to ensure its
   confidentiality and integrity. Note that the NSFs and security
   controller can all be spoofed, which leads to undesirable results
   (e.g., security policy leakage from security controller, or a spoofed
   security controller sending false information to mislead the NSFs).
   Hence, mutual authentication MUST be supported to protected against
   this kind of threat.  The current mainstream security technologies
   (i.e., TLS, DTLS, and IPSEC) can be employed to protect against the
   above threats.

   In addition, to defend against DDoS attacks caused by a hostile
   security controller sending too many configuration messages to the
   NSFs, rate limiting or similar mechanisms should be considered.

6.  IANA Considerations

   TBD

7.  Contributors

   The following people contributed to creating this document, and are
   listed below in alphabetical order:

      Antonio Lioy (Politecnico di Torino)
      Dacheng Zhang (Huawei)
      Edward Lopez (Fortinet)
      Fulvio Valenza (Politecnico di Torino)
      Kepeng Li (Alibaba)
      Luyuan Fang (Microsoft)
      Nicolas Bouthors (QoSmos)

8.  References

8.1.  Normative References

   [RFC2119]
      Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
   [RFC3539]
      Aboba, B., and Wood, J., "Authentication, Authorization, and
      Accounting (AAA) Transport Profile", RFC 3539, June 2003.

8.2.  Informative References

   [RFC2975]
      Aboba, B., et al., "Introduction to Accounting Management",
      RFC 2975, October 2000.
   [RFC8192]
      Hares, S., et.al., "I2NSF Problem Statement and Use cases",
      RFC8192, July 2017.
   [RFC8329]
      Lopez, E., et.al., "Framework for Interface to Network Security
      Functions", RFC 8329, February 2018.
   [I-D.draft-ietf-i2nsf-terminology]
      Hares, S., et.al., "Interface to Network Security Functions
      (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03,
      March, 2017
   [I-D.draft-ietf-supa-generic-policy-info-model]
      Strassner, J., Halpern, J., van der Meer, S., "Generic Policy
      Information Model for Simplified Use of Policy Abstractions
      (SUPA)", draft-ietf-supa-generic-policy-info-model-03,
      May, 2017.
   [Alshaer]
      Al Shaer, E. and H. Hamed, "Modeling and management of firewall
      policies", 2004.
   [Bas12]
      Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access
      Control Policy Analysis and Transformation", 2012.
   [Bas15]
      Basile, C. and Lioy, A., "Analysis of application-layer filtering
      policies with application to HTTP", IEEE/ACM Transactions on
      Networking, Vol 23, Issue 1, February 2015.
   [Cormen]
      Cormen, T., "Introduction to Algorithms", 2009.
   [Hohpe]
      Hohpe, G. and Woolf, B., "Enterprise Integration Patterns",
      Addison-Wesley, 2003, ISBN 0-32-120068-3
   [Lunt]
      van Lunteren, J. and T. Engbersen, "Fast and scalable packet
      classification", IEEE Journal on Selected Areas in Communication,
      vol 21, Issue 4, September 2003.
   [Martin]
      Martin, R.C., "Agile Software Development, Principles, Patterns,
      and Practices", Prentice-Hall, 2002, ISBN: 0-13-597444-5
   [OODMP]
      http://www.oodesign.com/mediator-pattern.html
   [OODOP]
      http://www.oodesign.com/observer-pattern.html
   [OODSRP]
      http://www.oodesign.com/single-responsibility-principle.html

Appendix A.  Network Security Capability Policy Rule Definitions

   Six exemplary Network Security Capability Policy Rules are
   introduced in this Appendix to clarify how to create different kinds
   of specific ECA policy rules to manage Network Security Capabilities.

   Note that there is a common pattern that defines how these
   ECAPolicyRules operate; this simplifies their implementation. All of
   these six ECA Policy Rules are concrete classes.

   In addition, none of these six subclasses define attributes. This
   enables them to be viewed as simple object containers, and hence,
   applicable to a wide variety of content. It also means that the
   content of the function (e.g., how an entity is authenticated, what
   specific traffic is inspected, or which particular signature is
   applied) is defined solely by the set of events, conditions, and
   actions that are contained by the particular subclass. This enables
   the policy rule, with its aggregated set of events, conditions, and
   actions, to be treated as a reusable object.

A.1.  AuthenticationECAPolicyRule Class Definition

   The purpose of an AuthenticationECAPolicyRule is to define an I2NSF
   ECA Policy Rule that can verify whether an entity has an attribute
   of a specific value. A high-level conceputal figure is shown below.

                                                    +----------------+
   +----------------+ 1..n                    1...n |                |
   |                |/ \  HasAuthenticationMethod  \| Authentication |
   | Authentication + A ----------+-----------------+     Method     |
   | ECAPolicyRule  |\ /          ^                /|                |
   |                |             |                 +----------------+
   +----------------+             |
                                  |
                     +------------+-------------+
                     | AuthenticationRuleDetail |
                     +------------+-------------+
                                 / \ 0..n
                                  |
                                  | PolicyControlsAuthentication
                                  |
                                 / \
                                  A
                                 \ / 0..n
                       +----------+--------------+
                       | ManagementECAPolicyRule |
                       +-------------------------+

            Figure 10.  Modeling Authentication Mechanisms

   This class does NOT define the authentication method used. This is
   because this would effectively "enclose" this information within the
   AuthenticationECAPolicyRule. This has two drawbacks. First, other
   entities that need to use information from the Authentication
   class(es) could not; they would have to associate with the
   AuthenticationECAPolicyRule class, and those other classes would not
   likely be interested in the AuthenticationECAPolicyRule. Second, the
   evolution of new authentication methods should be independent of the
   AuthenticationECAPolicyRule; this cannot happen if the
   Authentication class(es) are embedded in the
   AuthenticationECAPolicyRule.

   This document only defines the AuthenticationECAPolicyRule; all other
   classes, and the aggregations, are defined in an external model. For
   completeness, descriptions of how the two aggregations are used are
   described below.

   Figure 10 defines an aggregation between an external class, which
   defines one or more authentication methods, and an
   AuthenticationECAPolicyRule. This decouples the implementation of
   authentication mechanisms from how authentication mechanisms are
   managed and used.

   Since different AuthenticationECAPolicyRules can use different
   authentication mechanisms in different ways, the aggregation is
   realized as an association class. This enables the attributes and
   methods of the association class (i.e., AuthenticationRuleDetail) to
   be used to define how a given AuthenticationMethod is used by a
   particular AuthenticationECAPolicyRule.

   Similarly, the PolicyControlsAuthentication aggregation defines
   Policy Rules to control the configuration of the
   AuthenticationRuleDetail association class. This enables the entire
   authentication process to be managed by ECA PolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define two
   attributes for the AuthenticationECAPolicyRule class (e.g., called
   authenticationMethodCurrent and authenticationMethodSupported), to
   represent the HasAuthenticationMethod aggregation and its
   association class. The former would be a string attribute that
   defines the current authentication method used by this
   AuthenticationECAPolicyRule, while the latter would define a set of
   authentication methods, in the form of an authentication Capability,
   which this AuthenticationECAPolicyRule can advertise.

A.2.  AuthorizationECAPolicyRuleClass Definition

   The purpose of an AuthorizationECAPolicyRule is to define an I2NSF
   ECA Policy Rule that can determine whether access to a resource
   should be given and, if so, what permissions should be granted to
   the entity that is accessing the resource.

   This class does NOT define the authorization method(s) used. This
   is because this would effectively "enclose" this information within
   the AuthorizationECAPolicyRule. This has two drawbacks. First, other
   entities that need to use information from the Authorization
   class(es) could not; they would have to associate with the
   AuthorizationECAPolicyRule class, and those other classes would not
   likely be interested in the AuthorizationECAPolicyRule. Second, the
   evolution of new authorization methods should be independent of the
   AuthorizationECAPolicyRule; this cannot happen if the Authorization
   class(es) are embedded in the AuthorizationECAPolicyRule. Hence,
   this document recommends the following design:

                                                    +---------------+
    +----------------+ 1..n                   1...n |               |
    |                |/ \   HasAuthorizationMethod \| Authorization |
    | Authorization  + A ----------+----------------+     Method    |
    | ECAPolicyRule  |\ /          ^               /|               |
    |                |             |                +---------------+
    +----------------+             |
                                   |
                      +------------+------------+
                      | AuthorizationRuleDetail |
                      +------------+------------+
                                  / \ 0..n
                                   |
                                   | PolicyControlsAuthorization
                                   |
                                  / \
                                   A
                                  \ / 0..n
                        +----------+--------------+
                        | ManagementECAPolicyRule |
                        +-------------------------+

             Figure 11.  Modeling Authorization Mechanisms

   This document only defines the AuthorizationECAPolicyRule; all other
   classes, and the aggregations, are defined in an external model. For
   completeness, descriptions of how the two aggregations are used are
   described below.

   Figure 11 defines an aggregation between the
   AuthorizationECAPolicyRule and an external class that defines one or
   more authorization methods. This decouples the implementation of
   authorization mechanisms from how authorization mechanisms are
   managed and used.

   Since different AuthorizationECAPolicyRules can use different
   authorization mechanisms in different ways, the aggregation is
   realized as an association class. This enables the attributes and
   methods of the association class (i.e., AuthorizationRuleDetail)
   to be used to define how a given AuthorizationMethod is used by a
   particular AuthorizationECAPolicyRule.

   Similarly, the PolicyControlsAuthorization aggregation defines
   Policy Rules to control the configuration of the
   AuthorizationRuleDetail association class. This enables the entire
   authorization process to be managed by ECA PolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define
   two attributes for the AuthorizationECAPolicyRule class, called
   (for example) authorizationMethodCurrent and
   authorizationMethodSupported, to represent the
   HasAuthorizationMethod aggregation and its association class. The
   former is a string attribute that defines the current authorization
   method used by this AuthorizationECAPolicyRule, while the latter
   defines a set of authorization methods, in the form of an
   authorization Capability, which this AuthorizationECAPolicyRule
   can advertise.

A.3.  AccountingECAPolicyRuleClass Definition

   The purpose of an AccountingECAPolicyRule is to define an I2NSF
   ECA Policy Rule that can determine which information to collect,
   and how to collect that information, from which set of resources
   for the purpose of trend analysis, auditing, billing, or cost
   allocation [RFC2975] [RFC3539].

   This class does NOT define the accounting method(s) used. This is
   because this would effectively "enclose" this information within
   the AccountingECAPolicyRule. This has two drawbacks. First, other
   entities that need to use information from the Accounting class(es)
   could not; they would have to associate with the
   AccountingECAPolicyRule class, and those other classes would not
   likely be interested in the AccountingECAPolicyRule. Second, the
   evolution of new accounting methods should be independent of the
   AccountingECAPolicyRule; this cannot happen if the Accounting
   class(es) are embedded in the AccountingECAPolicyRule. Hence, this
   document recommends the following design:

                                                    +-------------+
      +----------------+ 1..n                 1...n |             |
      |                |/ \   HasAccountingMethod  \| Accounting  |
      |  Accounting    + A ----------+--------------+   Method    |
      | ECAPolicyRule  |\ /          ^             /|             |
      |                |             |              +-------------+
      +----------------+             |
                                     |
                          +----------+-----------+
                          | AccountingRuleDetail |
                          +----------+-----------+
                                    / \ 0..n
                                     |
                                     | PolicyControlsAccounting
                                     |
                                    / \
                                     A
                                    \ / 0..n
                          +----------+--------------+
                          | ManagementECAPolicyRule |
                          +-------------------------+

              Figure 12.  Modeling Accounting Mechanisms

   This document only defines the AccountingECAPolicyRule; all other
   classes, and the aggregations, are defined in an external model.
   For completeness, descriptions of how the two aggregations are used
   are described below.

   Figure 12 defines an aggregation between the AccountingECAPolicyRule
   and an external class that defines one or more accounting methods.
   This decouples the implementation of accounting mechanisms from how
   accounting mechanisms are managed and used.

   Since different AccountingECAPolicyRules can use different
   accounting mechanisms in different ways, the aggregation is realized
   as an association class. This enables the attributes and methods of
   the association class (i.e., AccountingRuleDetail) to be used to
   define how a given AccountingMethod is used by a particular
   AccountingECAPolicyRule.

   Similarly, the PolicyControlsAccounting aggregation defines Policy
   Rules to control the configuration of the AccountingRuleDetail
   association class. This enables the entire accounting process to be
   managed by ECA PolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define
   two attributes for the AccountingECAPolicyRule class, called
   (for example) accountingMethodCurrent and accountingMethodSupported,
   to represent the HasAccountingMethod aggregation and its association
   class.

   The former is a string attribute that defines the current accounting
   method used by this AccountingECAPolicyRule, while the latter
   defines a set of accounting methods, in the form of an accounting
   Capability, which this AccountingECAPolicyRule can advertise.

A.4.  TrafficInspectionECAPolicyRuleClass Definition

   The purpose of a TrafficInspectionECAPolicyRule is to define an I2NSF
   ECA Policy Rule that, based on a given context, can determine which
   traffic to examine on which devices, which information to collect
   from those devices, and how to collect that information.

   This class does NOT define the traffic inspection method(s) used.
   This is because this would effectively "enclose" this information
   within the TrafficInspectionECAPolicyRule. This has two drawbacks.
   First, other entities that need to use information from the
   TrafficInspection class(es) could not; they would have to associate
   with the TrafficInspectionECAPolicyRule class, and those other
   classes would not likely be interested in the
   TrafficInspectionECAPolicyRule. Second, the evolution of new traffic
   inspection methods should be independent of the
   TrafficInspectionECAPolicyRule; this cannot happen if the
   TrafficInspection class(es) are embedded in the
   TrafficInspectionECAPolicyRule. Hence, this document recommends the
   following design:

                                                  +------------------+
   +-------------------+1..n                   1..n|                  |
   |                   |/ \ HasTrafficInspection  \|      Traffic     |
   | TrafficInspection + A ----------+-------------+ InspectionMethod |
   |   ECAPolicyRule   |\ /          ^           / |                  |
   |                   |             |             +------------------+
   +-------------------+             |
                                     |
                        +------------+------------+
                        | TrafficInspectionDetail |
                        +------------+------------+
                                    / \ 0..n
                                     |
                                     | PolicyControlsTrafficInspection
                                     |
                                    / \
                                     A
                                    \ / 0..n
                          +----------+--------------+
                          | ManagementECAPolicyRule |
                          +-------------------------+

           Figure 13.  Modeling Traffic Inspection Mechanisms

   This document only defines the TrafficInspectionECAPolicyRule; all
   other classes, and the aggregations, are defined in an external
   model. For completeness, descriptions of how the two aggregations
   are used are described below.

   Figure 13 defines an aggregation between the
   TrafficInspectionECAPolicyRule and an external class that defines
   one or more traffic inspection mechanisms. This decouples the
   implementation of traffic inspection mechanisms from how traffic
   inspection mechanisms are managed and used.

   Since different TrafficInspectionECAPolicyRules can use different
   traffic inspection mechanisms in different ways, the aggregation is
   realized as an association class. This enables the attributes and
   methods of the association class (i.e., TrafficInspectionDetail) to
   be used to define how a given TrafficInspectionMethod is used by a
   particular TrafficInspectionECAPolicyRule.

   Similarly, the PolicyControlsTrafficInspection aggregation defines
   Policy Rules to control the configuration of the
   TrafficInspectionDetail association class. This enables the entire
   traffic inspection process to be managed by ECA PolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define
   two attributes for the TrafficInspectionECAPolicyRule class, called
   (for example) trafficInspectionMethodCurrent and
   trafficInspectionMethodSupported, to represent the
   HasTrafficInspectionMethod aggregation and its association class.
   The former is a string attribute that defines the current traffic
   inspection method used by this TrafficInspectionECAPolicyRule,
   while the latter defines a set of traffic inspection methods, in
   the form of a traffic inspection Capability, which this
   TrafficInspectionECAPolicyRule can advertise.

A.5.  ApplyProfileECAPolicyRuleClass Definition

   The purpose of an ApplyProfileECAPolicyRule is to define an I2NSF
   ECA Policy Rule that, based on a given context, can apply a
   particular profile to specific traffic. The profile defines the
   security Capabilities for content security control and/or attack
   mitigation control; these will be described in sections 4.4 and
   4.5, respectively.

   This class does NOT define the set of Profiles used. This is
   because this would effectively "enclose" this information within
   the ApplyProfileECAPolicyRule. This has two drawbacks. First, other
   entities that need to use information from the Profile class(es)
   could not; they would have to associate with the
   ApplyProfileECAPolicyRule class, and those other classes would not
   likely be interested in the ApplyProfileECAPolicyRule. Second, the
   evolution of new Profile classes should be independent of the
   ApplyProfileECAPolicyRule; this cannot happen if the Profile
   class(es) are embedded in the ApplyProfileECAPolicyRule. Hence,
   this document recommends the following design:

                                                       +-------------+
      +-------------------+ 1..n                  1..n |             |
      |                   |/ \  ProfileApplied        \|             |
      | ApplyProfile      + A -----------+-------------+   Profile   |
      |   ECAPolicyRule   |\ /           ^            /|             |
      |                   |              |             +-------------+
      +-------------------+              |
                                         |
                            +------------+---------+
                            | ProfileAppliedDetail |
                            +------------+---------+
                                        / \ 0..n
                                         |
                                         |
        PolicyControlsProfileApplication |
                                         |
                                        / \
                                         A
                                        \ / 0..n
                              +----------+--------------+
                              | ManagementECAPolicyRule |
                              +-------------------------+

           Figure 14.  Modeling Profile ApplicationMechanisms

   This document only defines the ApplyProfileECAPolicyRule; all other
   classes, and the aggregations, are defined in an external model.
   For completeness, descriptions of how the two aggregations are used
   are described below.

   Figure 14 defines an aggregation between the
   ApplyProfileECAPolicyRule and an external Profile class. This
   decouples the implementation of Profiles from how Profiles are used.

   Since different ApplyProfileECAPolicyRules can use different
   Profiles in different ways, the aggregation is realized as an
   association class. This enables the attributes and methods of the
   association class (i.e., ProfileAppliedDetail) to be used to define
   how a given Profile is used by a particular
   ApplyProfileECAPolicyRule.

   Similarly, the PolicyControlsProfileApplication aggregation defines
   policies to control the configuration of the ProfileAppliedDetail
   association class. This enables the application of Profiles to be
   managed and used by ECA PolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define two
   attributes for the ApplyProfileECAPolicyRuleclass, called (for
   example) profileAppliedCurrent and profileAppliedSupported, to
   represent the ProfileApplied aggregation and its association class.
   The former is a string attribute that defines the current Profile
   used by this ApplyProfileECAPolicyRule, while the latter defines a
   set of Profiles, in the form of a Profile Capability, which this
   ApplyProfileECAPolicyRule can advertise.

A.6.  ApplySignatureECAPolicyRuleClass Definition

   The purpose of an ApplySignatureECAPolicyRule is to define an I2NSF
   ECA Policy Rule that, based on a given context, can determine which
   Signature object (e.g., an anti-virus file, or aURL filtering file,
   or a script) to apply to which traffic. The Signature object defines
   the security Capabilities for content security control and/or attack
   mitigation control; these will be described in sections 4.4 and 4.5,
   respectively.

   This class does NOT define the set of Signature objects used. This
   is because this would effectively "enclose" this information within
   the ApplySignatureECAPolicyRule. This has two drawbacks. First,
   other entities that need to use information from the Signature
   object class(es) could not; they would have to associate with the
   ApplySignatureECAPolicyRule class, and those other classes would not
   likely be interested in the ApplySignatureECAPolicyRule. Second, the
   evolution of new Signature object classes should be independent of
   the ApplySignatureECAPolicyRule; this cannot happen if the Signature
   object class(es) are embedded in the ApplySignatureECAPolicyRule.
   Hence, this document recommends the following design:

   This document only defines the ApplySignatureECAPolicyRule; all
   other classes, and the aggregations, are defined in an external
   model. For completeness, descriptions of how the two aggregations
   are used are described below.

   Figure 15 defines an aggregation between the
   ApplySignatureECAPolicyRule and an external Signature object class.
   This decouples the implementation of signature objects from how
   Signature objects are used.

   Since different ApplySignatureECAPolicyRules can use different
   Signature objects in different ways, the aggregation is realized as
   an association class. This enables the attributes and methods of the
   association class (i.e., SignatureAppliedDetail) to be used to
   define how a given Signature object is used by a particular
   ApplySignatureECAPolicyRule.

                                                 +-------------+
    +---------------+ 1..n                  1..n |             |
    |               |/ \   SignatureApplied     \|             |
    | ApplySignature+ A ----------+--------------+  Signature  |
    | ECAPolicyRule |\ /          ^             /|             |
    |               |             |              +-------------+
    +---------------+             |
                                  |
                     +------------+-----------+
                     | SignatureAppliedDetail |
                     +------------+-----------+
                                 / \ 0..n
                                  |
                                  | PolicyControlsSignatureApplication
                                  |
                                 / \
                                  A
                                 \ / 0..n
                       +----------+--------------+
                       | ManagementECAPolicyRule |
                       +-------------------------+

         Figure 15.  Modeling Sginature Application Mechanisms

   Similarly, the PolicyControlsSignatureApplication aggregation
   defines policies to control the configuration of the
   SignatureAppliedDetail association class. This enables the
   application of the Signature object to be managed by policy.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a data model could define
   two attributes for the ApplySignatureECAPolicyRule class, called
   (for example) signature signatureAppliedCurrent and
   signatureAppliedSupported, to represent the SignatureApplied
   aggregation and its association class. The former is a string
   attribute that defines the current Signature object used by this
   ApplySignatureECAPolicyRule, while the latter defines a set of
   Signature objects, in the form of a Signature Capability, which
   this ApplySignatureECAPolicyRule can advertise.

Appendix B. Network Security Event Class Definitions

   This Appendix defines a preliminary set of Network Security Event
   classes, along with their attributes.

B.1.  UserSecurityEvent Class Description

   The purpose of this class is to represent Events that are initiated
   by a user, such as logon and logoff Events. Information in this
   Event may be used as part of a test to determine if the Condition
   clause in this ECA Policy Rule should be evaluated or not. Examples
   include user identification data and the type of connection used by
   the user.

   The UserSecurityEvent class defines the following attributes.

B.1.1.  The usrSecEventContent Attribute

   This is a mandatory string that contains the content of the
   UserSecurityEvent. The format of the content is specified in the
   usrSecEventFormat class attribute, and the type of Event is defined
   in the usrSecEventType class attribute. An example of the
   usrSecEventContent attribute is the string "hrAdmin", with the
   usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute
   set to 5 (new logon).

B.1.2.  The usrSecEventFormat Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the data type of the usrSecEventContent attribute. The
   content is specified in the usrSecEventContent class attribute, and
   the type of Event is defined in the usrSecEventType class attribute.
   An example of the usrSecEventContent attribute is the string
   "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and
   the usrSecEventType attribute set to 5 (new logon). Values include:

      0:  unknown
      1:  GUID (Generic Unique IDentifier)
      2:  UUID (Universal Unique IDentifier)
      3:  URI (Uniform Resource Identifier)
      4:  FQDN (Fully Qualified Domain Name)
      5:  FQPN (Fully Qualified Path Name)

B.1.3.  The usrSecEventType Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the type of Event that involves this user. The content
   and format are specified in the usrSecEventContent and
   usrSecEventFormat class attributes, respectively.

   An example of the usrSecEventContent attribute is the string
   "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID), and
   the usrSecEventType attribute set to 5 (new logon). Values include:

      0:  unknown
      1:  new user created
      2:  new user group created
      3:  user deleted
      4:  user group deleted
      5:  user logon
      6:  user logoff
      7:  user access request
      8:  user access granted
      9:  user access violation

B.2.  DeviceSecurityEvent Class Description

   The purpose of a DeviceSecurityEvent is to represent Events that
   provide information from the Device that are important to I2NSF
   Security. Information in this Event may be used as part of a test
   to determine if the Condition clause in this ECA Policy Rule should
   be evaluated or not. Examples include alarms and various device
   statistics (e.g., a type of threshold that was exceeded), which may
   signal the need for further action.

   The DeviceSecurityEvent class defines the following attributes.

B.2.1.  The devSecEventContent Attribute

   This is a mandatory string that contains the content of the
   DeviceSecurityEvent. The format of the content is specified in the
   devSecEventFormat class attribute, and the type of Event is defined
   in the devSecEventType class attribute. An example of the
   devSecEventContent attribute is "alarm", with the devSecEventFormat
   attribute set to 1 (GUID), the devSecEventType attribute set to
   5 (new logon).

B.2.2.  The devSecEventFormat Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the data type of the devSecEventContent attribute.
   Values include:

      0:  unknown
      1:  GUID (Generic Unique IDentifier)
      2:  UUID (Universal Unique IDentifier)
      3:  URI (Uniform Resource Identifier)
      4:  FQDN (Fully Qualified Domain Name)
      5:  FQPN (Fully Qualified Path Name)

B.2.3.  The devSecEventType Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the type of Event that was generated by this device.
   Values include:

      0:  unknown
      1:  communications alarm
      2:  quality of service alarm
      3:  processing error alarm
      4:  equipment error alarm
      5:  environmental error alarm

   Values 1-5 are defined in X.733. Additional types of errors may also
   be defined.

B.2.4.  The devSecEventTypeInfo[0..n] Attribute

   This is an optional array of strings, which is used to provide
   additional information describing the specifics of the Event
   generated by this Device. For example, this attribute could contain
   probable cause information in the first array, trend information in
   the second array, proposed repair actions in the third array, and
   additional information in the fourth array.

B.2.5.  The devSecEventTypeSeverity Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the perceived severity of the Event generated by this
   Device. Values (which are defined in X.733) include:

      0:  unknown
      1:  cleared
      2:  indeterminate
      3:  critical
      4:  major
      5:  minor
      6:  warning

B.3.  SystemSecurityEvent Class Description

   The purpose of a SystemSecurityEvent is to represent Events that
   are detected by the management system, instead of Events that are
   generated by a user or a device. Information in this Event may be
   used as part of a test to determine if the Condition clause in
   this ECA Policy Rule should be evaluated or not. Examples include
   an event issued by an analytics system that warns against a
   particular pattern of unknown user accesses, or an Event issued by
   a management system that represents a set of correlated and/or
   filtered Events.

   The SystemSecurityEvent class defines the following attributes.

B.3.1.  The sysSecEventContent Attribute

   This is a mandatory string that contains the content of the
   SystemSecurityEvent. The format of the content is specified in the
   sysSecEventFormat class attribute, and the type of Event is defined
   in the sysSecEventType class attribute. An example of the
   sysSecEventContent attribute is the string "sysadmin3", with the
   sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType
   attribute set to 2 (audit log cleared).

B.3.2.  The sysSecEventFormat Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the data type of the sysSecEventContent attribute.
   Values include:

      0:  unknown
      1:  GUID (Generic Unique IDentifier)
      2:  UUID (Universal Unique IDentifier)
      3:  URI (Uniform Resource Identifier)
      4:  FQDN (Fully Qualified Domain Name)
      5:  FQPN (Fully Qualified Path Name)

B.3.3.  The sysSecEventType Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the type of Event that involves this device.
   Values include:

      0:  unknown
      1:  audit log written to
      2:  audit log cleared
      3:  policy created
      4:  policy edited
      5:  policy deleted
      6:  policy executed

B.4.  TimeSecurityEvent Class Description

   The purpose of a TimeSecurityEvent is to represent Events that are
   temporal in nature (e.g., the start or end of a period of time).
   Time events signify an individual occurrence, or a time period, in
   which a significant event happened. Information in this Event may be
   used as part of a test to determine if the Condition clause in this
   ECA Policy Rule should be evaluated or not. Examples include issuing
   an Event at a specific time to indicate that a particular resource
   should not be accessed, or that different authentication and
   authorization mechanisms should now be used (e.g., because it is now
   past regular business hours).

   The TimeSecurityEvent class defines the following attributes.

B.4.1.  The timeSecEventPeriodBegin Attribute

   This is a mandatory DateTime attribute, and represents the beginning
   of a time period. It has a value that has a date and/or a time
   component (as in the Java or Python libraries).

B.4.2.  The timeSecEventPeriodEnd Attribute

   This is a mandatory DateTime attribute, and represents the end of a
   time period. It has a value that has a date and/or a time component
   (as in the Java or Python libraries). If this is a single Event
   occurence, and not a time period when the Event can occur, then the
   timeSecEventPeriodEnd attribute may be ignored.

B.4.3.  The timeSecEventTimeZone Attribute

   This is a mandatory string attribute, and defines the time zone that
   this Event occurred in using the format specified in ISO8601.

Appendix C. Network Security Condition Class Definitions

   This Appendix defines a preliminary set of Network Security Condition
   classes, along with their attributes.

C.1.  PacketSecurityCondition

   The purpose of this Class is to represent packet header information
   that can be used as part of a test to determine if the set of Policy
   Actions in this ECA Policy Rule should be executed or not. This class
   is abstract, and serves as the superclass of more detailed conditions
   that act on different types of packet formats. Its subclasses are
   shown in Figure 16, and are defined in the following sections.

                             +-------------------------+
                             | PacketSecurityCondition |
                             +------------+------------+
                                         / \
                                          |
                                          |
                 +---------+----------+---+-----+----------+
                 |         |          |         |          |
                 |         |          |         |          |
        +--------+-------+ | +--------+-------+ | +--------+-------+
        | PacketSecurity | | | PacketSecurity | | | PacketSecurity |
        |  MACCondition  | | | IPv4Condition  | | | IPv6Condition  |
        +----------------+ | +----------------+ | +----------------+
                           |                    |
                  +--------+-------+   +--------+-------+
                  |  TCPCondition  |   |  UDPCondition  |
                  +----------------+   +----------------+

   Figure 16. Network Security Info Sub-Model PacketSecurityCondition
              Class Extensions

C.1.1.  PacketSecurityMACCondition

   The purpose of this Class is to represent packet MAC packet header
   information that can be used as part of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes.

C.1.1.1.  The pktSecCondMACDest Attribute

   This is a mandatory string attribute, and defines the MAC
   destination address (6 octets long).

C.1.1.2.  The pktSecCondMACSrc Attribute

   This is a mandatory string attribute, and defines the MAC source
   address (6 octets long).

C.1.1.3.  The pktSecCondMAC8021Q Attribute

   This is an optional string attribute, and defines the 802.1Q tag
   value (2 octets long). This defines VLAN membership and 802.1p
   priority values.

C.1.1.4.  The pktSecCondMACEtherType Attribute

   This is a mandatory string attribute, and defines the EtherType
   field (2 octets long). Values up to and including 1500 indicate the
   size of the payload in octets; values of 1536 and above define
   which protocol is encapsulated in the payload of the frame.

C.1.1.5.  The pktSecCondMACTCI Attribute

   This is an optional string attribute, and defines the Tag Control
   Information. This consists of a 3 bit user priority field, a drop
   eligible indicator (1 bit), and a VLAN identifier (12 bits).

C.1.2.  PacketSecurityIPv4Condition

   The purpose of this Class is to represent packet IPv4 packet header
   information that can be used as part of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes.

C.1.2.1.  The pktSecCondIPv4SrcAddr Attribute

   This is a mandatory string attribute, and defines the IPv4 Source
   Address (32 bits).

C.1.2.2.  The pktSecCondIPv4DestAddr Attribute

   This is a mandatory string attribute, and defines the IPv4
   Destination Address (32 bits).

C.1.2.3.  The pktSecCondIPv4ProtocolUsed Attribute

   This is a mandatory string attribute, and defines the protocol used
   in the data portion of the IP datagram (8 bits).

C.1.2.4.  The pktSecCondIPv4DSCP Attribute

   This is a mandatory string attribute, and defines the Differentiated
   Services Code Point field (6 bits).

C.1.2.5.  The pktSecCondIPv4ECN Attribute

   This is an optional string attribute, and defines the Explicit
   Congestion Notification field (2 bits).

C.1.2.6.  The pktSecCondIPv4TotalLength Attribute

   This is a mandatory string attribute, and defines the total length
   of the packet (including header and data) in bytes (16 bits).

C.1.2.7.  The pktSecCondIPv4TTL Attribute

   This is a mandatory string attribute, and defines the Time To Live
   in seconds (8 bits).

C.1.3.  PacketSecurityIPv6Condition

   The purpose of this Class is to represent packet IPv6 packet header
   information that can be used as part of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes.

C.1.3.1.  The pktSecCondIPv6SrcAddr Attribute

   This is a mandatory string attribute, and defines the IPv6 Source
   Address (128 bits).

C.1.3.2.  The pktSecCondIPv6DestAddr Attribute

   This is a mandatory string attribute, and defines the IPv6
   Destination Address (128 bits).

C.1.3.3.  The pktSecCondIPv6DSCP Attribute

   This is a mandatory string attribute, and defines the Differentiated
   Services Code Point field (6 bits). It consists of the six most
   significant bits of the Traffic Class field in the IPv6 header.

C.1.3.4.  The pktSecCondIPv6ECN Attribute

   This is a mandatory string attribute, and defines the Explicit
   Congestion Notification field (2 bits). It consists of the two least
   significant bits of the Traffic Class field in the IPv6 header.

C.1.3.5.  The pktSecCondIPv6FlowLabel Attribute

   This is a mandatory string attribute, and defines an IPv6 flow
   label. This, in combination with the Source and Destination Address
   fields, enables efficient IPv6 flow classification by using only the
   IPv6 main header fields (20 bits).

C.1.3.6.  The pktSecCondIPv6PayloadLength Attribute

   This is a mandatory string attribute, and defines the total length
   of the packet (including the fixed and any extension headers, and
   data) in bytes (16 bits).

C.1.3.7.  The pktSecCondIPv6NextHeader Attribute

   This is a mandatory string attribute, and defines the type of the
   next header (e.g., which extension header to use) (8 bits).

C.1.3.8.  The pktSecCondIPv6HopLimit Attribute

   This is a mandatory string attribute, and defines the maximum
   number of hops that this packet can traverse (8 bits).

C.1.4.  PacketSecurityTCPCondition

   The purpose of this Class is to represent packet TCP packet header
   information that can be used as part of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes.

C.1.4.1.  The pktSecCondTPCSrcPort Attribute

   This is a mandatory string attribute, and defines the Source Port
   number (16 bits).

C.1.4.2.  The pktSecCondTPCDestPort Attribute

   This is a mandatory string attribute, and defines the Destination
   Port number (16 bits).

C.1.4.3.  The pktSecCondTCPSeqNum Attribute

   This is a mandatory string attribute, and defines the sequence
   number (32 bits).

C.1.4.4.  The pktSecCondTCPFlags Attribute

   This is a mandatory string attribute, and defines the nine Control
   bit flags (9 bits).

C.1.5.  PacketSecurityUDPCondition

   The purpose of this Class is to represent packet UDP packet header
   information that can be used as part of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes.

C.1.5.1.1.  The pktSecCondUDPSrcPort Attribute

   This is a mandatory string attribute, and defines the UDP Source
   Port number (16 bits).

C.1.5.1.2.  The pktSecCondUDPDestPort Attribute

   This is a mandatory string attribute, and defines the UDP
   Destination Port number (16 bits).

C.1.5.1.3.  The pktSecCondUDPLength Attribute

   This is a mandatory string attribute, and defines the length in
   bytes of the UDP header and data (16 bits).

C.2.  PacketPayloadSecurityCondition

   The purpose of this Class is to represent packet payload data that
   can be used as part of a test to determine if the set of Policy
   Actions in this ECA Policy Rule should be executed or not. Examples
   include a specific set of bytes in the packet payload.

C.3.  TargetSecurityCondition

   The purpose of this Class is to represent information about
   different targets of this policy (i.e., entities to which this
   Policy Rule should be applied), which can be used as part of a
   test to determine if the set of Policy Actions in this ECA Policy
   Rule should be executed or not. Examples include whether the
   targeted entities are playing the same role, or whether each
   device is administered by the same set of users, groups, or roles.
   This Class has several important subclasses, including:

      a. ServiceSecurityContextCondition is the superclass for all
         information that can be used in an ECA Policy Rule that
         specifies data about the type of service to be analyzed
         (e.g., the protocol type and port number)
      b. ApplicationSecurityContextCondition is the superclass for all
         information that can be used in a ECA Policy Rule that
         specifies data that identifies a particular application
         (including metadata, such as risk level)
      c. DeviceSecurityContextCondition is the superclass for all
         information that can be used in a ECA Policy Rule that
         specifies data about a device type and/or device OS that is
         being used

C.4.  UserSecurityCondition

   The purpose of this Class is to represent data about the user or
   group referenced in this ECA Policy Rule that can be used as part of
   a test to determine if the set of Policy Actions in this ECA Policy
   Rule should be evaluated or not. Examples include the user or group
   id used, the type of connection used, whether a given user or group
   is playing a particular role, or whether a given user or group has
   failed to login a particular number of times.

C.5.  SecurityContextCondition

   The purpose of this Class is to represent security conditions that
   are part of a specific context, which can be used as part of a test
   to determine if the set of Policy Actions in this ECA Policy Rule
   should be evaluated or not. Examples include testing to determine
   if a particular pattern of security-related data have occurred, or
   if the current session state matches the expected session state.

C.6.  GenericContextSecurityCondition

   The purpose of this Class is to represent generic contextual
   information in which this ECA Policy Rule is being executed, which
   can be used as part of a test to determine if the set of Policy
   Actions in this ECA Policy Rule should be evaluated or not.
   Examples include geographic location and temporal information.

Appendix D. Network Security Action Class Definitions

   This Appendix defines a preliminary set of Network Security Action
   classes, along with their attributes.

D.1.  IngressAction

   The purpose of this Class is to represent actions performed on
   packets that enter an NSF. Examples include pass, dropp, or
   mirror traffic.

D.2.  EgressAction

   The purpose of this Class is to represent actions performed on
   packets that exit an NSF. Examples include pass, drop, or mirror
   traffic, signal, and encapsulate.

D.3.  ApplyProfileAction

   The purpose of this Class is to define the application of a profile
   to packets to perform content security and/or attack mitigation
   control.

Appendix E. Geometric Model

   The geometric model defined in [Bas12] is summarized here. Note that
   our work has extended the work of [Bas12] to model ECA Policy Rules,
   instead of just condition-action Policy Rules. However, the
   geometric model in this Appendix is simplified in this version of
   this I-D, and is used to define just the CA part of the ECA model.

   All the actions available to the security function are well known
   and organized in an action set A.

   For filtering controls, the enforceable actions are either Allow or
   Deny, thus A={Allow,Deny}. For channel protection controls, they may
   be informally written as "enforce confidentiality", "enforce data
   authentication and integrity", and "enforce confidentiality and data
   authentication and integrity". However, these actions need to be
   instantiated to the technology used. For example, AH-transport mode
   and ESP-transport mode (and combinations thereof) are a more precise
   definition of channel protection actions.

   Conditions are typed predicates concerning a given selector. A
   selector describes the values that a protocol field may take. For
   example, the IP source selector is the set of all possible IP
   addresses, and it may also refer to the part of the packet where the
   values come from (e.g., the IP source selector refers to the IP
   source field in the IP header). Geometrically, a condition is the
   subset of its selector for which it evaluates to true. A condition
   on a given selector matches a packet if the value of the field
   referred to by the selector belongs to the condition.  For instance,
   in Figure 17 the conditions are s1 <= S1 (read as s1 subset of or
   equal to S1) and s2 <= S2 (s2 subset of or equal to S2), both s1 and
   s2 match the packet x1, while only s2 matches x2.

   To consider conditions in different selectors, the decision space is
   extended using the Cartesian product because distinct selectors
   refer to different fields, possibly from different protocol headers.
   Hence, given a policy-enabled element that allows the definition of
   conditions on the selectors S1, S2,..., Sm (where m is the number
   of Selectors available at the security control we want to model),
   its selection space is:

      S=S1 X S2 X ...  X Sm

   To consider conditions in different selectors, the decision space is
   extended using the Cartesian product because distinct selectors
   refer to different fields, possibly from different protocol headers.

        S2 ^ Destination port
           |
           |      x2
           +......o
           |      .
           |      .
         --+.............+------------------------------------+
         | |      .      |                                    |
         s |      .      |                                    |
         e |      .      |            (rectangle)             |
         g |      .      |        condition clause (c)        |
         m |      .      |   here the action a is applied     |
         e |      .      |                                    |
         n |      .      |             x1=point=packet        |
         t +.............|.............o                      |
         | |      .      |             .                      |
         --+.............+------------------------------------+
           |      .      .             .                      .
           |      .      .             .                      .
     +------------+------+-------------+----------------------+------>
           |             |---- segment = condition in S1 -----|     S1
           +                                                 IP source

      Figure 17: Geometric representation of a rule r=(c,a) that
                 matches x1, but does not match x2.

   Accordingly, the condition clause c is a subset of S:

      c = s1 X s2 X ...  X sm <= S1 X S2 X ...  X Sm = S

   S represents the totality of the packets that are individually
   selectable by the security control to model when we use it to
   enforce a policy. Unfortunately, not all its subsets are valid
   condition clauses: only hyper-rectangles, or the union of
   hyper-rectangles (as they are Cartesian product of conditions),
   are valid. This is an intrinsic constraint of the policy
   language, as it specifies rules by defining a condition for each
   selector. Languages that allow specification of conditions as
   relations over more fields are modeled by the geometric model as
   more complex geometric shapes determined by the equations. However,
   the algorithms to compute intersections are much more sophisticated
   than intersection hyper-rectangles. Figure 17 graphically represents
   a condition clause c in a two-dimensional selection space.

   In the geometric model, a rule is expressed as r=(c,a), where c <= S
   (the condition clause is a subset of the selection space), and the
   action a belongs to A. Rule condition clauses match a packet (rules
   match a packet), if all the conditions forming the clauses match the
   packet. In Figure 17, the rule with condition clause c matches the
   packet x1 but not x2.

   The rule set R is composed of n rules ri=(ci,ai).

   The decision criteria for the action to apply when a packet matches
   two or more rules is abstracted by means of the resolution strategy

      RS: Pow(R) -> A

   where Pow(R) is the power set of rules in R.

   Formally, given a set of rules, the resolution strategy maps all the
   possible subsets of rules to an action a in A. When no rule matches a
   packet, the security controls may select the default action d in A,
   if they support one.

   Resolution strategies may use, besides intrinsic rule data (i.e.,
   condition clause and action clause), also external data associated to
   each rule, such as priority, identity of the creator, and creation
   time.  Formally, every rule ri is associated by means
              Model for Simplified Use of the
   function e(.):

      e(ri) = (ri,f1(ri),f2(ri),...)

   where E={fj:R -> Xj} (j=1,2,...) is the set that includes all
   functions that map rules to external attributes Policy Abstractions (SUPA)",
              Work in Xj. However,
   E, e, Progress, May, 2017.

   [Alshaer]  Al Shaer, E. and all the Xj are determined by the resolution strategy used.

   A policy is thus a function p: S -> A that connects each point H. Hamed, "Modeling and management of
   the selection space
              firewall policies", 2004.

   [Bas12]    Basile, C., Cappadonia, A., and A. Lioy, "Network-Level
              Access Control Policy Analysis and Transformation", 2012.

   [Bas15]    Basile, C. and A. Lioy, "Analysis of application-layer
              filtering policies with application to an action taken from the action set A
   according HTTP", 2015.

   [Cormen]   Cormen, T., "Introduction to the rules in Algorithms", 2009.

   [Galitsky] Galitsky, B. and Pampapathi, R., "Can many agents answer
              questions better than one", First Monday, 2005;
              http://dx.doi.org/10.5210/fm.v10i1.1204

   [Gamma]    Gamma, E., Helm, R. By also assuming RS(0)=d (where 0 is
   the empty-set) Johnson, R., Vlissides, J., "Design
              Patterns: Elements of Reusable Object-Oriented
              Software", Addison-Wesley, Nov, 1994.
              ISBN 978-0201633610

   [Hirschman]Hirschman, L., and Gaizauskas, R., "Natural Language
              Question Answering: The View from Here", Natural Language
              Engineering 7:4, pgs 275-300, Cambridge University Press,
              2001

   [Hohpe]    Hohpe, G. and RS(ri)=ai, the policy p can be described as:

      p(x)=RS(match{R(x)}).

   Therefore, in the geometric model, a policy is completely defined by
   the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS,
   the set E of mappings to the external attributes, Woolf, B., "Enterprise Integration
              Patterns", Addison-Wesley, 2003, ISBN 0-32-120068-3

   [Lunt]     van Lunteren, J. and the default
   action d.

   Note that, the geometric model also supports ECA paradigms by simply
   modeling events like an additional selector. T. Engbersen, "Fast and scalable
              packet classification", 2003.

   [Martin]   Martin, R.C., "Agile Software Development, Principles,
              Patterns, and Practices", Prentice-Hall, 2002,
              ISBN: 0-13-597444-5

   [MCM]      MEF, "MEF Core Model", Technical Specification MEF X,
              April 2018

   [OODMP]    http://www.oodesign.com/mediator-pattern.html

   [OODSOP]   http://www.oodesign.com/observer-pattern.html

   [OODSRP]   http://www.oodesign.com/single-responsibility-
              principle.html

   [PDO]      MEF, "Policy Driven Orchestration", Technical
              Specification MEF Y, January 2018

   [Taylor]   Taylor, D. and J. Turner, "Scalable packet classification
              using distributed crossproducting of field labels", 2004.

  6. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Cataldo Basile
   Politecnico di Torino
   Corso Duca degli Abruzzi, 34
   Torino, 10129
   Italy
   Email: cataldo.basile@polito.it

   Liang Xia (Frank)
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   China
   Email: Frank.xialiang@huawei.com

   John Strassner
   Huawei
   2330 Central Expressway
   Santa Clara, CA  95050  USA
   Email: John.sc.Strassner@huawei.com

Cataldo Basile
Politecnico di Torino
Corso Duca degli Abruzzi, 34
Torino, 10129
Italy
Email: cataldo.basile@polito.it

   Diego R. Lopez
   Telefonica I+D
   Zurbaran, 12
   Madrid,   28010
   Spain
   Phone: +34 913 129 041
   Email: diego.r.lopez@telefonica.com