I2NSF                                                             L. Xia
Internet Draft
Internet-Draft                                              J. Strassner
Intended status: Standard Track                               D.Zhang                                   Huawei
                                                                K. Li
                                                              Alibaba
Expires:  September 12, 2017                                   C. Basile
                                                              A. Lioy
                                                                  PoliTO
                                                                D. Lopez
                                                                     TID
                                                             E. Lopez
                                                             Fortinet
                                                          N. BOUTHORS
                                                               Qosmos
                                                          Luyuan Fang
                                                            Microsoft

Expires: December
                                                          March 12, 2017                                November 1, 2016

                 Information Model of NSFs Capabilities
                  draft-xibassnez-i2nsf-capability-00.txt
                 draft-xibassnez-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.

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), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-
   Drafts. Internet-Drafts.  The list of current
   Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

   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 December 1,2016. September 12, 2017.

Copyright Notice

   Copyright (c) 2016 2017 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 aims at defining the concept of capability. Capabilities
   are data that unambiguously characterize NSFs (Network Security
   Functions). Their correct definition will ease all the management
   and automation that can be. Moreover, it allows the definition of
   Interfaces to manage NSFs.

   This draft is the first trial to merge two previous existing drafts
   on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on
   the capability interface [I-D.draft-xia-i2nsf-capability-interface-
   im-06]. Further work will be needed to homogenize all the concepts
   and incorporate the feedback that will result after its publication.

Table of Contents

   1. Introduction ................................................ ................................................... 4
   2. Conventions used in this document ........................... 6 .............................. 5
      2.1. Terminology ............................................ 6 Acronyms .................................................. 5
   3. Management of NSFs: Design Principles towards a model of
   Capabilities ................................................... 7
   4. Capability Information Model .......................................... 10
   5. Capabilities for security policy enforcement ............... 12
      5.1. The CA Design ............................ 6
      3.1. Design Principles and ECA Policy Model ................................... 13
      5.2. Geometric Overview ........... 6
      3.2. Relation with the External Information Model .............. 8
      3.3. I2NSF Capability Information Model Theory of CA Policies ........................ 14
      5.3. Operation ... 10
         3.3.1. I2NSF Condition Clause Operator Types ....................................... 17
      5.4. Model of Capabilities for Policy Specification ............... 11
         3.3.2  Capability Selection and Enforcement
      Purposes ................................................... 19
      5.5. Usage ...................... 12
         3.3.3.  Capability Algebra of capabilities ............................... 20
      5.6. Examples of ................................. 13
      3.4. Initial NSFs Capability Categories ........................... 21
         5.6.1. ....................... 16
         3.4.1. Network Security ................................. 22
         5.6.2. Capabilities ....................... 16
         3.4.2. Content Security .................................. 22
         5.6.3. Capabilities ....................... 17
         3.4.3. Attack Mitigation ................................. 22
   6. Capabilities ...................... 17
   4. Information Sub-Model for Network Security Capabilities ..... 23
      6.1. ....... 18
      4.1. Information Sub-Model for Network Security ............. 23
         6.1.1. ............... 18
         4.1.1. Network Security Policy Rule Extensions ........... 24
         6.1.2. ............. 19
         4.1.2. Network Security Policy Rule Operation ............ 26
         6.1.3. .............. 20
         4.1.3. Network Security Event Sub-Model .................. .................... 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
            6.1.3.1.
      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 .......... 29
               6.1.3.1.1. ...................... 42
         B.1.1. The usrSecEventContent Attribute ........ 29
               6.1.3.1.2. .................... 42
         B.1.2. The usrSecEventFormat Attribute.......... 29
               6.1.3.1.3. Attribute ..................... 42
         B.1.3. The usrSecEventType Attribute ........... 30
            6.1.3.2. ....................... 42
      B.2. DeviceSecurityEvent Class Description ........ 30
               6.1.3.2.1. .................... 43
         B.2.1. The devSecEventContent Attribute ........ 30
               6.1.3.2.2. .................... 43
         B.2.2. The devSecEventFormat Attribute.......... 31
               6.1.3.2.3. Attribute ..................... 43
         B.2.3. The devSecEventType Attribute ........... 31
               6.1.3.2.4. ....................... 44
         B.2.4. The devSecEventTypeInfo[0..n] Attribute . 31
               6.1.3.2.5. ............. 44
         B.2.5. The devSecEventTypeSeverity Attribute ... 32
            6.1.3.3. ............... 44

Table of Contents (continued)

      B.3. SystemSecurityEvent Class Description ........ 32
               6.1.3.3.1. .................... 44
         B.3.1. The sysSecEventContent Attribute ........ 32
               6.1.3.3.2. .................... 45
         B.3.2. The sysSecEventFormat Attribute.......... 33
               6.1.3.3.3. Attribute ..................... 45
         B.3.3. The sysSecEventType Attribute ........... 33
            6.1.3.4. ....................... 45
      B.4. TimeSecurityEvent Class Description .......... 33
               6.1.3.4.1. ...................... 45
         B.4.1. The timeSecEventPeriodBegin Attribute ... 34
               6.1.3.4.2. ............... 46
         B.4.2. The timeSecEventPeriodEnd Attribute ..... 34
               6.1.3.4.3. ................. 46
         B.4.3. The timeSecEventTimeZone Attribute ...... 34
         6.1.4. .................. 46
   Appendix C. Network Security Condition Sub-Model .............. 34
            6.1.4.1. Class Definitions ......... 47
      C.1. PacketSecurityCondition ...................... 36
               6.1.4.1.1. .................................. 47
         C.1.1. PacketSecurityMACCondition .............. 36
                  6.1.4.1.1.1. .......................... 47
            C.1.1.1. The pktSecCondMACDest Attribute .... 37
                  6.1.4.1.1.2. ................ 47
            C.1.1.2. The pktSecCondMACSrc Attribute ..... 37
                  6.1.4.1.1.3. ................. 47
            C.1.1.3. The pktSecCondMAC8021Q Attribute ... 37
                  6.1.4.1.1.4. ............... 48
            C.1.1.4. The pktSecCondMACEtherType Attribute 37
                  6.1.4.1.1.5. ........... 48
            C.1.1.5. The pktSecCondMACTCI Attribute ..... 37
               6.1.4.1.2. ................. 48
         C.1.2. PacketSecurityIPv4Condition ............. 37
                  6.1.4.1.2.1. ......................... 48
            C.1.2.1. The pktSecCondIPv4SrcAddr Attribute  37
                  6.1.4.1.2.2. ............ 48
            C.1.2.2. The pktSecCondIPv4DestAddr Attribute 37
                  6.1.4.1.2.3. ........... 48
            C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute
                   ................................................ 38
                  6.1.4.1.2.4. ....... 48
            C.1.2.4. The pktSecCondIPv4DSCP Attribute ... 38
                  6.1.4.1.2.5. ............... 48
            C.1.2.5. The pktSecCondIPv4ECN Attribute .... 38
                  6.1.4.1.2.6. ................ 48
            C.1.2.6. The pktSecCondIPv4TotalLength Attribute
                   ................................................ 38
                  6.1.4.1.2.7. ........ 49
            C.1.2.7. The pktSecCondIPv4TTL Attribute .... 38
               6.1.4.1.3. ................ 49
         C.1.3. PacketSecurityIPv6Condition ............. 38
                  6.1.4.1.3.1. ......................... 49
            C.1.3.1. The pktSecCondIPv6SrcAddr Attribute  38
                  6.1.4.1.3.2. ............ 49
            C.1.3.2. The pktSecCondIPv6DestAddr Attribute 38
                  6.1.4.1.3.3. ........... 49
            C.1.3.3. The pktSecCondIPv6DSCP Attribute ... 38
                  6.1.4.1.3.4. ............... 49
            C.1.3.4. The pktSecCondIPv6ECN Attribute .... 39
                  6.1.4.1.3.5. ................ 49
            C.1.3.5. The pktSecCondIPv6FlowLabel Attribute39
                  6.1.4.1.3.6. Attribute .......... 49
            C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ....................................... 39
                  6.1.4.1.3.7. ...... 49
            C.1.3.7. The pktSecCondIPv6NextHeader Attribute39
                  6.1.4.1.3.8. Attribute ......... 50
            C.1.3.8. The pktSecCondIPv6HopLimit Attribute 39
               6.1.4.1.4. ........... 50
         C.1.4. PacketSecurityTCPCondition .............. 39
                  6.1.4.1.4.1. .......................... 50
            C.1.4.1. The pktSecCondTPCSrcPort pktSecCondTCPSrcPort Attribute . 39
                  6.1.4.1.4.2. ............. 50
            C.1.4.2. The pktSecCondTPCDestPort pktSecCondTCPDestPort Attribute  39
                  6.1.4.1.4.3. ............ 50
            C.1.4.3. The pktSecCondTPCSeqNum pktSecCondTCPSeqNum Attribute .. 40
                  6.1.4.1.4.4. .............. 50
            C.1.4.4. The pktSecCondTPCFlags pktSecCondTCPFlags Attribute ... 40
               6.1.4.1.5. ............... 50
            C.1.5. PacketSecurityUDPCondition .............. 40
                  6.1.4.1.5.1. ....................... 50
               C.1.5.1.1. The pktSecCondUDPSrcPort Attribute . 40
                  6.1.4.1.5.2. ........ 50
               C.1.5.1.2. The pktSecCondUDPDestPort Attribute  40
                  6.1.4.1.5.3. ....... 51
               C.1.5.1.3. The pktSecCondUDPLength Attribute .. 40
            6.1.4.2. ......... 51
      C.2. PacketPayloadSecurityCondition ............... 40
            6.1.4.3. ........................... 51
      C.3. TargetSecurityCondition ...................... 40
            6.1.4.4. .................................. 51
      C.4. UserSecurityCondition ........................ 41
            6.1.4.5. .................................... 51
      C.5. SecurityContextCondition ..................... 41
            6.1.4.6. ................................. 52
      C.6. GenericContextSecurityCondition .............. 41
         6.1.5. .......................... 52

Table of Contents (continued)

  Appendix D. Network Security Action Sub-Model ................. 42
            6.1.5.1. Class Definitions ............. 53
      D.1. IngressAction ................................ 43
            6.1.5.2. ............................................ 53
      D.2. EgressAction ................................. 43
            6.1.5.3. ............................................. 53
      D.3. ApplyProfileAction ........................... 43
            6.1.5.4. ApplySignatureAction ......................... 43
      6.2. Information Model for Content Security Control ......... 43
      6.3. Information Model for Attack Mitigation Control ........ 44
   7. Security Considerations ..................................... 45
   8. IANA Considerations ......................................... 46
   9. References .................................................. 46
      9.1. Normative References ................................... 46
      9.2. Informative References ................................. 46
   10. Acknowledgments ............................................ 47 ....................................... 53
   Appendix A. .................................................... 48
      A.1. AuthenticationECAPolicyRule Class Definition ........... 48
      A.2. AuthorizationECAPolicyRuleClass Definition ............. 50
      A.3. AccountingECAPolicyRuleClass Definition ................ 52
      A.4. TrafficInspectionECAPolicyRuleClass Definition.......... E. Geometric Model ...................................... 54
      A.5. ApplyProfileECAPolicyRuleClass Definition .............. 56
      A.6. ApplySignatureECAPolicyRuleClass Definition ............ 58
   Authors' Addresses ............................................... 57

1.  Introduction

   The rapid development of virtualized systems, along with the demand
   of security services in virtualized systems, systems requires advanced
   security protection in various scenarios. Examples include network
   devices in an enterprise network, User Equipment (UE) in a mobile network,
   devices in the Internet of Things (IoT), Things, or residential access users
   [I-D.draft-ietf-i2nsf-problem-and-use-cases].

   Capabilities are precise information that characterize in an
   unambiguous way (in a given virtualized system) what a NSF can do in
   terms of

   NSFs produced by multiple security policy enforcement and how a Controller vendors provide various security
   Capabilities to customers. Multiple NSFs can
   interact with it in order be combined together to enforce a
   provide security policy. Even if services over the
   aim is a general given network traffic, regardless
   of capabilities, whether the unambiguity of capabilities is
   only assured in a given virtualized system.

   According to [I-D.draft-ietf-i2nsf-framework], there NSFs are two types implemented as physical or virtual functions.

   Security Capabilities describe the set of I2NSF interfaces Network Security Functions
   (NSFs) that are available to use for security rules provisioning:

   o Interface between I2NSF clients and a policy enforcement
   purposes. Security Capabilities are independent of the actual
   security controller (Client
      Facing Interface): This is control mechanisms that will implement them. Every NSF
   registers the set of Capabilities it offers. Security Capabilities
   are a service-oriented interface, whose
      main objective is 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 needed to refer to a specific product when designing the
   network; rather, the functions characterized by their Capabilities
   are considered.

   According to [I-D.draft-ietf-i2nsf-framework], there 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 a communication channel over which
      information defining security
        between consumers of NSF data and services controlling client's
      specific flow can be requested. and the network
        operator's security controller. This enables security
        information to be exchanged between various applications (e.g.,
        OpenStack, or various BSS/OSS components) and other components (e.g., the security
      controllers).
        controller. The design goal of the service interface Consumer-Facing Interface
        is to decouple the security service in the application layer from
      various kinds specification of security devices and services of
        consumers requesting such services from their device-specific
      security functions. implementation.

      o Interface between NSFs (e.g., firewall, intrusion prevention,
        or anti-virus) and a the security controller (NSFs Facing (NSF-Facing
        Interface):
      This interface is independent of how the NSFs are implemented
      (e.g., run in Virtual Machines (VMs) or physical appliances). The
      NSFs Facing NSF-Facing Interface is used to decouple the
        security management scheme from the set of NSFs and their
        various implementations for this scheme, so as to specify and monitor a number is independent
        of flow based
      security policies to individual NSFs. how the NSFs are implemented (e.g., run in Virtual
        Machines or physical appliances). According to the definition
        in [I-D.draft-ietf-i2nsf-framework], NSFs Facing the NSF-Facing Interface
      includes sub-interfaces
        information model is made up of Capability Interface, three sub-models: Capability,
        Registration
      Interface and Monitoring Interface. Monitoring. This document proposes defines the
        information model design for the first two interfaces parts (Capability
        and Registration), Registration); the Monitoring Interface part information model is
        discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring].

   This document is organized as follows: follows. Section 2 defines conventions
   and acronyms used. Section 3 discusses the design principles for NSF capabilities the
   I2NSF Capability information model and related ECA model. Section 4 further describes design principles for I2NSF capability
   information model. Section 5
   provides more details about the detailed information model design of I2NSF network security capability. Section 6 presents further
   information on specific aspects of the information model.
   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 references to uses terminology defined in
   [I-D.draft-ietf-i2nsf-terminology] for
   more specific security related and I2NSF
   scoped terminology
   definitions. terminology.

2.1.                  Terminology

  AAA -Access  Acronyms

   AAA:     Access control, Authorization, Authentication

  ACL -
   ACL:     Access Control List

  AD - Active Directory

  ANSI - American National Standards Institute

  DDoS - Distributed Deny of Services

  FW -
   (D)DoD:  (Distributed) Denial of Service (attack)
   ECA:     Event-Condition-Action
   FMR:     First Matching Rule (resolution strategy)
   FW:      Firewall

  I2NSF -
   GNSF:    Generic Network Security Function
   HTTP:    HyperText Transfer Protocol
   I2NSF:   Interface to Network Security Functions

  INCITS - International Committee for Information Technology
Standards

  IoT - Internet of Things

  IPS -
   IPS:     Intrusion Prevention System

  LDAP - Lightweight Directory Access Protocol

  NAT -
   LMR:     Last Matching Rule (resolution strategy)
   MIME:    Multipurpose Internet Mail Extensions
   NAT:     Network Address Translation

  NBI - North-bound Interface

  NIST - National Institute of Standard Technology

  NSF -
   NSF:     Network Security Function

  RBAC - Role Based Access Control

  UE - User Equipment
  URL - Uniform/Universal
   RPC:     Remote Procedure Call
   SMA:     String Matching Algorithm
   URL:     Uniform Resource Locator

  VM -
   VPN:     Virtual Machine

  WAF - Web Application Firewall Private Network

3. Management of NSFs:  Capability Information Model Design Principles towards a

   The starting point of the design of the Capability information model
   is the categorization of types of
     Capabilities

   Some basic principles for security capabilities and functions.  For instance,
   experts agree on what is meant by the systems that
   have to manage them need to be considered:

   o Flexibility: each security capability should be an independent
      function, with minimum overlap or dependency to other
      capabilities. This enables each security capability to be
      utilized terms "NAT", "filtering", and assembled together freely. More importantly, changes
      to one capability will not affect other capabilities;

   o High level of abstraction: each capability should be associated
      to a unified interface
   "VPN concentrator".  Network security experts unequivocally refer to make it programmable; this in turn
      provides a standardized ability
   "packet filters" as stateless devices able to describe allow or deny packet
   forwarding based on various conditions (e.g., source and report its
      processing results destination
   IP addresses, source and corresponding statistics information.
      Furthermore, it facilitates the multi-vendor interoperability;

   o Automation: The system must have the ability to auto-discover,
      auto-negotiate, destination ports, and auto-update security capabilities. IP protocol type
   fields) [Alshaer].

   However, more information is required in case of other devices, like
   stateful firewalls or application layer filters.  These
      features devices
   filter packets or communications, but there are especially useful for differences in the management of a large
      number
   packets and communications that they can categorize and the states
   they maintain. Analogous considerations can be applied for channel
   protection protocols, where we all understand that they will protect
   packets by means of NSFs. They are essential to add smart services
      (refinement, analysis, capability reasoning, optimization) on top 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.  Design Principles and ECA Policy Model Overview

   This document defines a model of security Capabilities that provides
   the virtual layer;

   o Scalability: the foundation for automatic management system must have of NSFs. This includes
   enabling the capability security controller to
      scale up/down or scale in/out. Thus, it properly identify and manage
   NSFs, and allow NSFs to properly declare their functionality, so
   that they can meet various
      performance requirements derived from changeable network traffic
      or service requests. In addition, be used in the correct way.

   Some basic design principles for security capability must
      support reporting statistics to Capabilities and the security controller to assist
      its decision on whether it needs
   systems that have to invoke scaling manage them are:

   o Independence: each security Capability should be an independent
      function, with minimum overlap or not.

   Based dependency on other
      Capabilities. This enables each security Capability to be
      utilized and assembled together freely. More importantly,
      changes to one Capability will not affect other Capabilities.
      This follows the above principles, Single Responsibility Principle
      [Martin] [OODSRP].
   o Abstraction: each Capability should be defined in a set of abstract vendor-
      independent manner, and vendor-neutral
   capabilities with standard interfaces is needed together with associated to a
   model of capabilities that allows well-known interface
      to unambiguously determine what
   NSFs provide a standardized ability to describe and report its
      processing results. This facilitates multi-vendor
      interoperability.
   o Automation: the system must have the ability to auto-discover,
      auto-negotiate, and auto-update its security Capabilities
      (i.e., without human intervention). These features are
      especially useful for the management of a large number of
      NSFs. They are essential to add smart services (e.g., analysis,
      refinement, Capability reasoning, and optimization) for 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 have the Capability to
      scale up/down or scale in/out. Thus, it can do in terms meet various
      performancerequirements derived from changeable network traffic
      or service requests. In addition, security Capabilities that are
      affected by scalability changes must 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, a set of abstract and vendor-neutral
   Capabilities with standard interfaces is defined. This provides a
   Capability model that enables a set of NSFs that are required at a
   given time to be selected, as well as the unambiguous definition of
   the security policy enforcement. offered by the set of NSFs used. The security
   controller can compare the requirements of clients users and applications to
   the set of
   capabilities Capabilities that are currently available in order to
   choose 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. This The security controller may also facilitates the customization of be able to customize the
   functionality of the selected NSFs by setting the parameters of their interfaces. NSFs.

   Furthermore, when an unknown threat (e.g., zero-day exploits,
   unknown malware, exploits and APTs)
   unknown malware) is reported by a network security device, NSF, new capabilities Capabilities may be
   created, and/or existing capabilities Capabilities may be updated (e.g., by
   updating its signature and algorithm), to correspond to the algorithm). This results in enhancing
   existing NSFs (and/or creating new
   functionality provided by the NSF NSFs) to handle address the threat. The new
   capabilities are provided from different vendors after their
   analysis of the new threats and subsequent installation of the
   functions required to report on (and possibly mitigate) the threat. 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
   cases, case, a standard interface is needed during this automated facilitates the update process.

   Note that most systems cannot dynamically create a new Capability
   without human interaction. This is an area for further study.

   In defining the capabilities Capabilities of a NSF, the "Event-Condition-Action"
   (ECA) policy rule set model in [I-D.draft-ietf-i2nsf-framework]
   should be here is used as
   the basis for the design: design; definitions of all I2NSF policy-related
   terms are also defined in [I-D.draft-ietf-i2nsf-terminology]:

      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 policy
      rules for I2NSF, 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); 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 make a decision. When used in the context of
      policy rules for I2NSF, it is used to determine
        whether or not the set of Actions in that (imperative) I2NSF
        Policy Rule can be executed or not.
      The following are exemplary types of conditions:

        ? Packet content values: Refer to the kind Examples of information or I2NSF Conditions
        include matching attributes acquired directly from the of a packet headers or
          payloads that can be flow, and comparing
        the internal state of an NSF to a desired state.
      o Action: An action is used in to control and monitor aspects of
        flow-based NSFs when the event and condition clauses are
        satisfied. NSFs provide security policy. It can be
          any fields or attributes in the packet L2/L3/L4 header, or
          special segment functions by executing various
        Actions. Examples of bytes in the I2NSF Actions include providing intrusion
        detection and/or protection, web and flow filtering, and deep
        packet payload;

        ? Context values: Refer to the context information inspection for the
          received packets. It can be (and not limited to):

             * User: packets and flows.

   The user (or user group) information to which a
               network flow above ECA policy model is associated. A user has many attributes,
               such as name, id, password, authentication mode, very general and so
               on. The combination of name easily extensible,
   and id (where id can avoid potential constraints that could be a
               password, a certificate, or other means of identifying
               the user) is often used in limit the
   implementation of generic security policy to
               identify Capabilities.

3.2.  Relation with the user. For example, if an NSF External Information Model

   Note: the symbology used from this point forward is aware 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 and
   managing the IP (or MAC) address associated with the user, NSFs using their Capabilities. This is done using
   the following approach:

      1) Each NSF can use a pre-defined or dynamically learned name-
               address association to enforce registers its Capabilities with the security functions
               for this given user (or user group);

             * Schedule: Time or time range management system
         when packet or flow is
               received;

             * Region: The geographic location where network traffic is
               received;

             * Target: it "joins", and hence makes its Capabilities available to
         the management system;
      2) The target indicates security controller selects the entity set of Capabilities
         required to which meet the needs of the security services are applied. This can be a service,
               application, or device. A service is identified by the
               protocol type and/or port number. An application is a
               computer program for a specific task or purpose. It
               provides additional semantics (e.g., dependencies
               between services) for matching traffic. A device is a
               managed entity from all
         available NSFs that is connected to the network. it manages;
      3) The
               attributes that can identify a device include type (e.g.,
               router, switch, pc) and operating system (e.g., Windows,
               Linux, or Android), as well as security controller uses the device's owner;

             * State: It refers Capability information model
         to various states match chosen Capabilities to which the network
               flow is associated. It can be either NSFs, independent of vendor;
      4) The security controller takes the TCP session
               state (e.g., new, established, related, invalid, above information and
         creates or
               untracked), the session AAA state (e.g., authenticated
               but not authorized), uses one or more data models from the access mode of the device
               (e.g., wireline, wireless, or cellular; these could be
               augmented with additional attributes, such as Capability
         information model to manage the type
               of VPN NSFs;
      5) Control and monitoring can then begin.

   This assumes that is being used);

             * Direction: an external information model is used to define
   the direction concept of the network flow.

   o Action: NSFs provide security functions by executing various
      Actions, which at least includes:

        ? Ingress actions, such as pass, drop, mirroring, etc;
        ? Egress actions, such as invoke signaling, tunnel
          encapsulation, packet forwarding and/or transformation;

        ? Applying a specific Functional Profile or signature - e.g., an IPS Profile, a signature file, ECA Policy Rule and its components (e.g., Event,
   Condition, and Action objects). This enables I2NSF Policy Rules
   [I-D.draft-ietf-i2nsf-terminology] to be subclassed from an anti-virus file, or external
   information model.

   Capabilities are defined as classes (e.g., a
          URL filtering file. It is one set of the key properties objects that
          determine the effectiveness
   exhibit a common set of the NSF, characteristics and behavior
   [I-D.draft-ietf-supa-generic-policy-info-model].

   Each Capability is mostly vendor-
          specific today. One goal made up of I2NSF is to standardize at least one model element (e.g.,
   attribute, method, or relationship) that differentiates it from all
   other objects in the form
          and functional interface of those security capabilities while
          supporting vendor-specific implementations system. Capabilities are, generically, a type
   of each. However, metadata; hence, it is important to properly model the parts also assumed that are related
          to the action (what an external information
   model is enforced) and used to define metadata (preferably, in the conditions (on what form of a class
   hierarchy). Therefore, it is enforced). assumed that Capabilities are subclassed
   from an external metadata model.

   The above ECA ruleset Capability sub-model is very general used for advertising, creating,
   selecting, and easily extensible, thus
   can avoid any potential constraints which could limit the
   implementation managing a set of the network specific security control capability.

  4. Information Model

   An information model will be developed in order to describe in an
   abstract Capabilities
   independent of the type and vendor independent manner all of device that contains the aspects related to NSF.
   That is, the capabilities user of NSFs. A detailed information model will be
   designed in the next versions of this draft as NSF-Facing Interface does not care whether
   the NSF is virtualized or hosted in a consequence physical device, who the
   vendor of the
   discussions, feedback, NSF is, and extensions that will originate after the
   publication of this draft. In this version which set of entities the draft, we present NSF is
   communicating with (e.g., a simplified view that only highlights firewall or an IPS). Instead, the most important concepts.

   The I2NSF capability interface is in charge of controlling and
   managing user
   only cares about the NSFs by means set of Capabilities that the information about the capabilities
   each NSF owns. This has, such as
   packet filtering or deep packet inspection. The overall structure
   is done using the following approach:

   1) User of the capability interface selects illustrated in the figure below:

   +-------------------------+ 0..n         0..n +---------------+
   |                         |/ \               \|   External    |
   | External ECA Info Model + A ----------------+   Metadata    |
   |                         |\ /  Aggregates   /|  Info Model   |
   +-----------+------------+      Metadata      +-------+-------+
               |                                        / \
               |                                         |
              / \                                        |
   Subclasses derived for I2NSF                          |
                                                   +-----+------+
                                                   | Capability |
                                                   | Sub-Model  |
                                                   +------------+

          Figure 1. The Overall I2NSF Information Model Design

   This draft defines a set of capabilities
      required extensions to meet a generic, external, ECA
   Policy Model to represent various NSF ECA Security Policy Rules. It
   also defines the needs Capability Sub-Model. Finally, it places
   requirements on what type of the application;

   2) A management entity uses the information model to match chosen
      capabilities extensions are required to NSFs, independent of vendor;

   3) A management entity takes the above generic,
   external, ECA information model and creates or
      uses vendor-specific data models metadata models, in order to install
   manage the NSFs identified by lifecycle of I2NSF Capabilities.

   Both of the chosen capabilities;

   4) Control and monitoring can then begin.

   This assumes that an external model, or set of models, is used to
   define the concept of an ECA Policy Rule and its components (e.g.,
   Event, Condition, and Action objects).

   Since Capabilities are unambiguous only within the same management
   system, and are models shown in Figure 1 could, but do not inherent characteristics that differentiate
   objects, it is also assumed that an external model (or set of models)
   will define a generic metadata concept.

   The Capability is a general abstract concept. Currently, the most
   promising approach for defining have
   to, be based on the SUPA information model of the
   Capabilities uses the sub-classing to define non-overlapping and
   independent concepts. For instance,
   [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in
   the Capability model that Sub-Model will
   be presented in inherit the next sections that abstractly determines AggregatesMetadata
   aggregation from the
   security policies that External Metadata Information Model.

   The external ECA Information Model supplies at least a NSF can enforce does not overlap with an
   independent model set of objects
   that specifies how represent a NSF generic ECA Policy Rule, and a set of objects that
   represent Events, Conditions, and Actions that can be contacted aggregated by
   the
   controller generic ECA Policy Rule. This enables I2NSF to reuse this
   generic model for different purposes, as well as specialize it (i.e.,
   create new model objects) to represent I2NSF-specific concepts.

   It is assumed that the protocols and secure channels) and when (i.e., external ECA Information Model has the events
   ability to which it reacts). aggregate metadata. Capabilities are then sub-classed
   from an appropriate class in the external metadata model.

   The capability interface is used for advertising, creating,
   selecting and managing a set of specific security capabilities
   independent of Metadata Information Model;
   this enables the type ECA objects to use the existing aggregation between
   them and vendor Metadata to add Metadata to appropriate ECA objects.

   Detailed descriptions of device that contains the NSF.
   That is, the user each portion of the capability interface does not care whether
   the NSF is virtualized or hosted information model are
   given in a physical device, the vendor of the NSF, and which set following sections.

3.3.  I2NSF Capability Information Model: Theory of entities the Operation

   Capabilities are typically used to represent NSF is communicating with
   (e.g., a firewall or an IPS). Instead, the user only cares about the
   set of capabilities functions that the NSF has, such as packet filtering or
   deep packet inspection. The overall structure is illustrated can
   be invoked. Capabilities are objects, and hence, can be used in the
   figure below:

   +-------------------------+ 0..n         0..n +---------------+
   |                         |/ \               \|   External    |
   | External
   event, condition, and/or action clauses of an I2NSF ECA Info Model + A ----------------+   Metadata    |
   |                         |\ /  Aggregates   /|  Info Model   |
   +-------------------------+      Metadata     +------+--------+
                                                       / \
                                                        |
                                                        |
                                                        |
                                                   +----+-------+
                                                   | Capability |
                                                   | Sub-Model  |
                                                   +------------+

          Figure 1. Policy Rule.
   The Overall I2NSF Information Model Design

   This draft defines the Capability sub-Model shown in Figure 1. This
   model assumes that another, generic, information model for defining
   ECA policy rules (which includes refines a specific one for predefined metadata
   model; the CA part application of I2NSF Capabilities is done by refining a
   predefined ECA policy rules) exists outside of I2NSF.

   It also assumes Policy Rule information model that Capabilities are modeled as metadata, since defines how to
   use, manage, or otherwise manipulate a
   Capability set of Capabilities. In this
   approach, an I2NSF Policy Rule is something a container that describes and/or prescribes
   functionality about an object, but is not an inherent part made up of that
   object. Hence, the Security Capability Sub-Model extends
   three clauses: an event clause, a condition clause, and an action
   clause. When the generic
   external metadata model.

   Both I2NSF policy engine receives a set of these external models could, but do not have to, draw from
   the SUPA model [I-D.draft-ietf-supa-generic-policy-info-model].

   The external events, it
   matches those events to events in active ECA Information Model supplies at least a set Policy Rules. If the
   event matches, then this triggers the evaluation of
   objects that represent a generic ECA the condition
   clause of the matched I2NSF Policy Rule, and a Rule. The condition clause is
   then evaluated; if it matches, then the set of
   objects that represent Events, Conditions, and Actions that can be
   aggregated by actions in the generic ECA
   matched I2NSF Policy Rule. Rule MAY be executed.

   This enables I2NSF document defines additional important extensions to
   reuse this generic model for different purposes.

   It is assumed that both the
   external ECA Information Model has the
   ability to aggregate metadata. Capabilities are then sub-classed
   from an appropriate class in Policy Rule model and the external Metadata model that
   are used by the I2NSF Information Model;
   this enables the ECA objects to use the existing aggregation between
   them examples include
   resolution strategy, external data, and Metadata to add Metadata to appropriate ECA objects.

   Detailed descriptions of each portion of default action. All these
   extensions come from the information geometric model are
   given defined in the following sections.

  5. Capabilities for security policy enforcement

   At present, [Bas12]. A more
   detailed description is provided in Appendix E; a variety summary of NSFs produced by multiple security vendors
   provide various security capabilities to customers. Multiple NSFs
   can be combined together to provide security services over the
   important points follows.

   Formally, given
   network traffic, regardless a set of whether actions in an I2NSF Policy Rule, the NSFs are implemented as
   physical or virtual functions.

   Security Capabilities are intended
   resolution strategy maps all the possible subsets of actions to describe an
   outcome. In other words, the potentiality that
   Network Security Functions (NSFs) have for security policy
   enforcement purposes. Security Capabilities are abstract concepts
   that are independent of resolution strategy is included in the actual security control that will
   implement them. However, every NSF will be associated
   I2NSF Policy Rule to the
   capabilities it owns. Security Capabilities are required decide how to allow
   differentiating among network functions. It would be a market
   enabler having evaluate all the actions in a way
   particular I2NSF Policy Rule. This is then extended to substitute include all
   possible I2NSF Policy Rules that can be applied in a NSF with an equivalent one
   (i.e., having particular
   scenario. Hence, the same functionality). Moreover, Security
   Capabilities are very useful to reason about generic functions,
   which may be needed at design time. That is, it final action set from all I2NSF Policy Rules
   is not needed to
   refer to a specific product when designing deduced.

   Some concrete examples of resolution strategy are the network; rather First Matching
   Rule (FMR) or Last Matching Rule (LMR) resolution strategies. When
   no rule matches a packet, the
   functions characterized by their capabilities are considered.

   Therefore, we have developed another model where Security
   Capabilities determine what NSFs may select a security control can do in terms of
   conditions, actions, resolution strategies, external data, if it
   supports default action, etc. That is, Security Capabilities define
   without any ambiguity if
   they support one.

   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 actions a function can do in term creator, and creation
   time. Two examples of
   security this are attaching metadata to the policy enforcement. The Security Capability model is built
   on a predefined general
   action and/or policy model. The type of policies that a
   NSF can enforce is obtained by customizing rule, and associating the general policy model rule with the Security Capability
   another class to convey such information.

   The Capability Model has been preliminarily validated by verifying
   that is allows

3.3.1.  I2NSF Condition Clause Operator Types

   After having analyzed the correct description of several literature and some existing security
   controls.

  5.1.                  The CA Policy Model

   The starting point of NSFs, the design
   types of our capability model 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 a simple
   observation. defined on them. As human beings, we all understand immediately each
   other when we refer an example,
   the protocol type field of the IP header is an unordered set of
   integer values associated to security controls protocols. The assigned protocol
   numbers are maintained by just naming their
   category. For instance, experts agree on what the IANA (http://www.iana.org/assignments/
   protocol-numbers/protocol-numbers.xhtml).

   In this selector, it is a NAT, a filtering
   control, or a VPN concentrator.  Network security experts
   unequivocally refer only meaningful to "packet filters" as stateless devices able specify condition clauses
   that use either the "equals" or "not equals" operators:

      proto = tcp, udp       (protocol type field equals to
   allow TCP or deny packets forwarding based on conditions on source and
   destination IP addresses, source and destination ports, and IP
   protocol UDP)
      proto != tcp           (protocol type fields [Alshaer].  Moreover, it field different from TCP)

   No other operators are allowed on exact-match selectors. For example,
   the following is known that packet
   filter rules an invalid condition clause, even if protocol types
   map to integers:

      proto < 62             (invalid condition)

   Range-based selectors are prioritized and ordered sets where it is possible to
   naturally specify a default
   action. More precisely, packet filters implement ranges as they can be easily mapped to integers.
   As an example, the First Matching
   Rule (FMR) or Last Matching Rule (LMR) resolution strategies.

   However, we feel the need for more information in case of other
   devices, like stateful firewalls or application layer filters.
   These devices filter packets or communications, but there are
   differences among products ports in the packets and communications that
   they can categorize and the states they maintain. Analogous
   considerations can TCP protocol may 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 represented 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, apply
   anti-reply protections, and authenticate peers.

   The purpose is to build
   a model of security capabilities that allow
   automatic management of virtualized systems, where intelligent
   components are able to properly identify and manage NSFs, and allow
   NSFs to properly declare their functionality so that they can be
   used in range-based selector (e.g., 1024-65535). As another example, the correct way.

  5.2.                  Geometric Model
   following are examples of CA Policies valid condition clauses:

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

   We refer include, in this draft to range-based selectors, the policy model category of selectors that
   have been defined in [Bas12] by Al-Shaer et al. as
   geometric model, which is summarized here. Policies are specified "prefix-match" [Alshaer].
   These selectors allow the specification of ranges of values by means
   of a set of rules in simple regular expressions. The typical case is the "if condition then action" format
   [RFC3198]. Rules are formed by a condition clause IP address
   selector (e.g., 10.10.1.*).

   There is no need to distinguish between prefix match and an action
   clause. This model can be further extended to support events, that
   is, in the Event-Condition-Action paradigms. However, range-based
   selectors; for our
   purpose, example, the geometric model will only be used address range "10.10.1.*" maps to define the CA part
   "[10.10.1.0,10.10.1.255]".

   Another category of selector types includes those based on regular
   expressions. This selector type is used frequently at the ECA model that we have selected as reference.

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

   For filtering controls, the enforceable actions application
   layer, where data are either Allow and
   Deny, thus A={Allow,Deny}. For channel protection controls, they may
   be informally written often represented as "enforce confidentiality", "enforce data
   authentication and integrity", and "enforce confidentiality and data
   authentication and integrity". However, these actions need to 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
   instantiated mapped to the technology used, for instance AH-transport mode
   and ESP-transport mode (and combinations thereof)
   regular expressions, even if in practice SMA are much faster. For
   instance, Squid (http://www.squid-cache.org/), a more precise
   and univocal popular Web caching
   proxy that offers various access control Capabilities, allows the
   definition of channel protection actions.

   Conditions are typed predicates concerning a given selector. A
   selector describes conditions on URLs that can be evaluated with SMA
   (e.g., dstdomain) or regex matching (e.g., dstdom_regex).

   As an example, the values condition clause:

      "URL = *.website.*"

   matches all the URLs that contain a protocol field may take, e.g., subdomain named website and the IP source selector is
   ones whose path contain the set of string ".website.". As another example,
   the condition clause:

      "MIME_type = video/*"

   matches 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 MIME objects whose type is video.

   Finally, the subset idea of its
   selector for which it evaluates to true. A condition on a given custom check selector matches is introduced. For
   instance, malware analysis can look for specific patterns, and
   returns a packet if the Boolean value of if the field referred pattern is found or not.

   In order to be properly used 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 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 selector belongs to
   next versions of the condition.  For instance, draft. Some examples are already present in Figure 2
   the conditions
   Section 6.

3.3.2.  Capability Selection and Usage

   Capability selection and usage are s1 <= S1 (read as s1 subset based on the set of or equal security
   traffic classification and action features that an NSF provides;
   these are defined by the Capability model. If the NSF has the
   classification features needed to S1) identify the packets/flows
   required by a policy, and s2 <= S2 (s1 can enforce the needed actions, then
   that particular NSF is capable of enforcing the policy.

   NSFs may also have specific characteristics that automatic processes
   or equal administrators need to S2), both s1 know when they have to generate
   configurations, like the available resolution strategies and s2 match the packet
   x1, while only s2 matches x2.

       S2 ^ Destination port
          |
          |
          |      x2
          +......o
          |      .
          |      .
        --+.............+------------------------------------+
        | |      .      |                                    |
        s |      .      |                                    |
        e |      .      |            (rectangle)             |
        g |      .      |        condition clause (c)        |
        m |      .      |   here
   possibility to set default actions.

   The Capability information model can be used for two purposes:
   describing the action a is applied     |
        e |      .      |                                    |
        n |      .      |             x1=point=packet        |
        t +.............|.............o                      |
        | |      .      |             .                      |
        --+.............+------------------------------------+
          |      .      .             .                      .
          |      .      .             .                      .
          |      .      .             .                      .
          |      .      .             .                      .
          |      .      .             .                      .
          |      .      .             .                      .
    +------------+------+-------------+----------------------+------>
          |             |---- segment = condition in S1 -----|     S1
          +                                                 IP source

   Figure 2: Geometric representation 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 of a rule r=(c,a)
   security functions that matches x1
   but does not match x2.

   To consider conditions in different selectors, the decision space are known by a particular system. The idea
   is
   extended using the Cartesian product because distinct selectors
   refer to different fields, possibly from different protocol headers.
   Hence, given a policy-enabled element have generic components whose behavior is well understood, so
   that allows the definition generic component can be used even if it has some vendor-
   specific functions. These generic functions represent a point of
   conditions on the selectors S1, S2,..., Sm (where m is
   interoperability, and can be provided by any product that offers the number of
   Selectors available at
   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 described
   later in a revision of this draft as well as in an upcoming data
   model contribution.

   The next section will introduce the security control we want algebra to model), its
   selection space is:

      S=S1 X S2 X ...  X Sm

   To consider conditions in different selectors, define the decision space is
   extended using
   information model of Capability registration. This associates
   NSFs to Capabilities, and checks whether a NSF has the Cartesian product because distinct selectors
   refer
   Capabilities needed to enforce policies.

3.3.3.  Capability Algebra

   We introduce a Capability Algebra to ensure that the actions of
   different fields, possibly from different protocol headers.

   Accordingly, policy rules do not conflict with each other.

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

      o the condition clause c is a subset event clauses of S:

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

   S represents each evaluate to TRUE
      o the totality condition clauses of each evaluate to TRUE
      o the packets that are individually
   selectable by action clauses affect the security control to model when same object in different ways

   For example, if we use it to
   enforce a policy. Unfortunately, not have two Policies:

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

   There is no conflict between P1 and P2, since the actions are
   different. However, consider these two policies:

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

   P3 and P4 are valid
   condition clauses: only hyper-rectangles or union now in conflict, because between the hours of hyper-
   rectangles (as they are Cartesian product 10am and
   4pm, the actions of conditions) P3 and P4 are valid.
   This is an intrinsic constraint of different and apply to the policy languages as they
   specify 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 1 graphically represents a condition clause c in
   a two-dimensional selection space.

   In same
   user (i.e., John).

   Let us define the geometric model, concept of a "matched" policy rule is expressed as r=(c,a), where c <= S
   (the condition clause is a subset of the selection space), one in which
   its event and the
   action a belongs to A. Rule condition clauses matche a packet (rules
   matche a packet), if all the conditions forming the clauses match both evaluate to true. This enables
   the packet: actions in Figure 1, the this policy rule with condition clause c matches to be evaluated. Then, the packet x1 but not x2.

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

   The decision criteria for the action to apply when defined by a packet matches
   two or more rules 5-tuple {Ac, Cc, Ec, RSc, Dc},
   where:

      o Ac is abstracted by means the set of Actions currently available from the resolution strategy
   RS: Pow(R) -> A, where Pow(R) NSF;
      o Cc is the power set of rules in R.

   Formally, given a Conditions currently available from the NSF;
      o Ec is the set of rules, Events the resolution strategy maps all NSF is able to respond to.
        Therefore, the
   possible subsets event clause of rules to an action I2NSF ECA Policy Rule that is
        written for an NSF will only allow a set of designated events
        in A. When no rule matches
   a packet, Ec. For compatibility purposes, we will assume that if Ec={}
        (that is, Ec is empty), the security controls may select NSF only accepts CA policies.
      o RSc is the default action d in A,
   if they support one. set of Resolution strategies may use, besides intrinsic rule data (i.e.,
   condition clause and action clause), also ``external data''
   associated Strategies that can be used to each rule, such as priority, identity of
        specify how to resolve conflicts that occur between the creator,
   and creation time.  Formally, every rule ri is associated by means actions
        of the function e(.) to:

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

   where E={fj:R -> Xj} (j=1,2,...) is the set same or different policy rules that includes all are matched and
        contained in this particular NSF;
      o Dc defines the
   functions notion of a Default action that map rules can be used to external attributes in Xj. However, E, e,
   and all the Xj are determined
        specify a predefined action when no other alternative action
        was matched by the resolution strategy used.

   A policy currently executing I2NSF Policy Rule. An
        analogy is thus the use of a function p: S -> A that connects each point default statement in a C switch
        statement. This field of the selection space to an action taken from Capability algebra can take the
        following values:
           - An explicit action set A
   according to the rules in R. By also assuming RS(0)=d (where 0 (that has been predefined; typically,
             this means that it is
   the empty-set) fixed and RS(ri)=ai, the policy p can be described with not configurable), denoted
             as Dc ={a}. In this formula

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

   Therefore, in case, the geometric model, a policy is completely defined by NSF will always use the 4-tuple (R,RS,E,d):
             action as as the rule default action.
           - A set R, of explicit actions, denoted Dc={a1,a2, ...};
             typically, this means that any **one** action can be used
             as the resolution function RS, default action. This enables the policy writer to
             choose one of a predefined set E of mappings actions {a1, a2, ...} to
             serve as the external attributes, and default action.
           - A fully configurable default action, denoted as Dc={F}.
             Here, F is a dummy symbol (i.e., a placeholder value) that
             can be used to indicate that the default action d.

   Note that, the geometric model also supports ECA paradigms can be
             freely selected by simply
   modeling events like an additional selector.

  5.3.                  Condition Types

   After having analyzed the literature and the existing security
   controls, we have categorized policy editor from the types of selectors in 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, actions Ac
             available at the protocol type field NSF. In other words, one of the IP header is a unordered set of
   integer values associated to protocols. The assigned protocol
   numbers are maintained actions
             Ac may be selected by the IANA
   (http://www.iana.org/assignments/protocol-numbers/protocol-
   numbers.xhtml).

   In this selector, it is only meaningful to specify conditions

      proto = tcp, udp       (protocol type field equals policy writer to TCP or UDP)

      proto != tcp           (protocol type field different from TCP) act as the
             default action.
           - No other operators are allowed on exact-match selectors, default action, denoted as Dc={}, for
   instance

      proto < 62             (invalid condition)

   is cases where the
             NSF does not allow the explicit selection of a valid condition, even if protocol types map to integers.

   Range-based selectors are ordered sets where it is possible to
   naturally specify ranges as they can be easily mapped default
             action.

*** Note to integers.

   As an example, the ports in WG: please review the TCP protocol are well represented
   using following paragraphs
*
*  Interesting Capability concepts that could be considered for a range-based selector (e.g., 1024-65535). As an example

      source_port = 80

      source_port < 1024

      source_port < 30000 && source_port >= 1024

   are valid conditions.

   We include in the range-based selectors all the category of
   selectors that have been defined by Al-Shaer et al. as prefix match
   [Alshaer]. These selectors allow the specification of ranges of
   values by means next
*  version of simple regular expressions. The typical case is the IP address selector Capability model and algebra include:
*
*     o Event clause representation (e.g., 10.10.1.*). There is no need conjunctive vs. disjunctive
*       normal form for Boolean clauses)
*     o Event clause evaluation function, which would enable more
*       complex expressions than simple Boolean expressions to
   distinguish between prefix match and range-based selectors as
   10.10.1.* easily maps be used
*
*
*     o Condition clause representation (e.g., conjunctive vs.
*       disjunctive normal form for Boolean clauses)
*     o Condition clause evaluation function, which would enable more
*       complex expressions than simple Boolean expressions to [10.10.1.0, 10.10.1.255].

   Another category of selector types includes the regex-based
   selectors, where the matching is performed by using regular
   expressions. This selector type is frequent at the application layer,
   where data are often represented as strings of text. be used
*     o Action clause evaluation strategies (e.g., execute first
*       action only, execute last action only, execute all actions,
*       execute all actions until an action fails)
*     o The regex-based
   selector type also includes as sub-case the string-based selectors,
   where matching is evaluated using string matching algorithms (SMA)
   [Cormen] Indeed, for our purposes, string matching use of metadata, which can be mapped associated to
   regular expressions, even if both an I2NSF
*       Policy Rule as well as objects contained in practice SMA are much faster. For
   instance, Squid (http://www.squid-cache.org/), a popular Web caching
   proxy that offers various access control capabilities, allows the
   definition of conditions on URLs that can be evaluated with SMA
   (e.g., dstdomain) or regex matching I2NSF Policy
*       Rule (e.g., dstdom_regex).

   As an example,

      URL = *.website.*

   matches all the URLs action), that contain a domain, subdomain named website
   and the ones whose path contain the string .website.

      MIME_type = video/*

   matches all the MIME objects whose type is video.

   Finally, we introduce the idea of custom check selectors. For
   instance describe the malware analysis looks for specific patterns object and/or
*       prescribe behavior. Descriptive examples include adding
*       authorship information and
   returns defining a Boolean value is time period when an example of custom check selector, if
   the logic of checking is not seen (nor really interesting) from the
   outside.

   In order to NSF
*       can be properly used by high-level policy based processed
   (like reasoning systems, refinement systems) these custom check
   selector need at least to be described as black-boxes, that is, the
   list of fields that they process (inputs) in order to return the
   Boolean verdict (output).

   More defined; prescriptive examples include
*       defining rule priorities and/or ordering.
*
*  Given two sets of custom check selectors will be presented in 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}
*     o Capability subtraction:
*          cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1}
*
*  In the
   next versions of above formulae, "U" is the draft. Some example set union operator and "\" is already present in
   Section 6.

  5.4.                  Model the
*  set difference operator.
*
*  The addition and subtraction of Capabilities for Policy Specification are defined as the
*  addition (set union) and Enforcement
     Purposes

   Our model subtraction (set difference) of capabilities is based on actions both the
*  Capabilities and traffic
   classification features. Indeed, their associated actions. Note that **only** the need for enforcing one of
*  leftmost (in this case, the
   actions that a security control can apply to packets/flows is the
   main reason to use a security control. Moreover, security controls
   have classification features first matched policy rule) Resolution
*  Strategy and Default Action are used.
*
*  Note: actions, events, and conditions are **symmetric**. This means
*  that permit when two matched policy rules are merged, the identification of resultant actions
*  and Capabilities are defined as the
   target packets/flows union of the each individual matched
*  policy rule. However, both resolution strategies and default actions enforced, i.e., the selectors
   presented
*  are **asymmetric** (meaning that in Section 5.2. A security manager decides for a specific
   security control depending on the actions and classification
   features. If the security control general, they can enforce the needed actions and **not** be
*  combined, as one has the classification features needed to identify the packets flows
   required by a policy, then the security control is capable of
   enforcing the policy. Our refinement model needs to know NSFs
   capabilities be chosen). In order to perform its operations.

   However, security controls may simplify this, we
*  have specific characteristics chosen that
   automatic processes or administrators need to know when they have to
   generate configurations, like the available **leftmost** resolution strategies strategy and the possibility to set
*  **leftmost** default actions. We have ignored, to
   simplify this presentation, options action are chosen. This enables the developer
*  to generate configurations that
   may have better performance, like view the use of chains or ad hoc
   structures [Taylor]. Adding support leftmost matched rule as the "base" to these forms of optimization which other
*  elements are added.
*
*  As an example, assume that a packet filter Capability, Cpf, is certainly feasible with
*  defined. Further, assume that a limited effort but it was outside the
   scope of this paper, second Capability, called Ctime,
*  exists, and that is, it defines time-based conditions. Suppose we need
*  to show construct a new generic packet filter, Cpfgen, that adding security awareness adds
*  time-based conditions to NFV management and orchestration features is possible. It Cpf.
*
*
*  Conceptually, this is one simply the addition of the task for future work.

   Capabilities can be used for two purposes: describing generic
   security functions, Cpf and describing specific products. With the term
   generic security function (GNSF) we denote known classes of security
   functions. The idea is to have generic components whose behavior is
   as well understood Ctime
*  Capabilities, as for the network components (i.e., follows:
*     Apf   =  {Allow, Deny}
*     Cpf   =  {IPsrc,IPdst,Psrc,Pdst,protType}
*     Epf   =  {}
*     RSpf  =  {FMR}
*     Dpf   =  {A1}
*
*     Atime =  {Allow, Deny, Log}
*     Ctime =  {timestart, timeend, datestart, datestop}
*     Etime =  {}
*     RStime = {LMR}
*     Dtime =  {A2}
*
*  Then, Cpfgen is defined as:
*     Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf, Dpf}
*            = {Allow, Deny, Log},
*              {{IPsrc, IPdst, Psrc, Pdst, protType} U
*               {timestart, timeend, datestart, datestop}},
*              {},
*              {FMR},
*              {A1}
*
*  In other words, Cpfgen provides three actions (Allow, Deny, Log),
*  filters traffic based on a switch 5-tuple that is logically ANDed with a switch
*  time period, and we know to use uses FMR; it even if provides A1 as a default action, and
*  it may have some vendor-
   specific functions). These generic functions can be substituted by
   any product that owns the required capability at instantiation time. does not react to events.
*
*  Note: We have analyzed several classes are investigating, for a next revision of NSFs this draft, the
*  possibility to prove add further operations that do not follow the validity of
   our approach.
*  symmetric vs. asymmetric properties presented in the previous note.
*  We found are looking for use cases that may justify the complexity added
*  by the availability of more Capability manipulation operations.
*
*** End Note to WG

3.4.  Initial NSFs Capability Categories

   The following subsections define three common features and defined a set categories of
   generic NSFs, including packet filter, URL filter, HTTP filter, VPN
   gateway, anti-virus, anti-malware,
   Capabilities: network security, content filter, monitoring,
   anonymity proxy that will be described in a data model TBD.

   Moreover, we have also categorized common extensions security, and attack
   mitigation. Future versions of this document may expand both the generic
   NSFs, packet filters that may decide based on time information.
   Moreover, some other packet filters add stateful features at ISO/OSI
   layer 4.

   The next section will introduce our algebra to compose capabilities,
   defined to associate NSFs to capabilities and to check whether a NSF
   has
   number of categories as well as the capabilities needed to enforce policies.

  5.5.                  Algebra types of capabilities

   Our capabilities are defined by Capabilities within a 4-tuple, that
   given category.

3.4.1.  Network Security Capabilities

   Network security is every NSF N will
   be associated to a 4-tuple (Ac; Cc; RSc; Dc) such that:

      (Ac; Cc; RSc; Dc) <= (XAC; XCC; XRSC; XDC)= K

   where

   o XAC is the set of all the supported actions, category that is, describes the set inspecting and
   processing of
      all network traffic based on the actions supported by at least one use of the existing NSFs;

   o Ac <= XAC is a set pre-defined
   security policies.

   The inspecting portion may be thought of actions as a packet-processing
   engine that determine inspects packets traversing networks, either directly or
   in the actions actually
      available at context of flows with which the NSF N;

   o XCC packet is set of all associated. From
   the supported conditions types, that is, perspective of packet-processing, implementations differ in the
      set
   depths of all packet headers and/or payloads they can inspect, the conditions
   various flow and context states they can maintain, and the actions
   that can be applied to specify rules in at
      least one of the existing NSFs;

   o Cc <= XCC is the sef of conditions actually available at the NSF
      N;

   o XRSC packets or flows.

3.4.2.  Content Security Capabilities

   Content security is the set another category of all security Capabilities
   applied to the existing resolutions strategies,

   o RSc <= XCC is application layer. Through analyzing traffic contents
   carried in, for example, the set of resolution strategies that application layer, Capabilities can be
   used to specify solve conflicts of multiple matching rules at the NSF
      N;

   o XDC={F} U XAC, is the set identify various security functions that are required, such
   as 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 all threat in the existing actions plus content security category has
   a
      dummy symbol F, set of unique characteristics, and requires handling using a placeholder value set
   of methods that can be used are specific to indicate that the default action can type of content. Thus, these
   NSFs will be freely selected characterized by the policy
      editor; and

   o Dc <= XDC, Dc may be {F}, their own content- specific security
   Capabilities.

3.4.3.  Attack Mitigation Capabilities

   This category of security Capabilities is used to indicate that the default action detect and mitigate
   various types of network attacks. Today's common network attacks can
   be freely selected by the policy editor, thus it can vary in
      every policy, or an explicit action {a<=XAC} to indicate that classified into the
      default action is fixed 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 the policy editor will not have the
      possibility to choice it.

   Given cap1=(Ac1,Cc1,RSc1,def1) IPv6 duplicate address detection attack;
        - Application layer DDoS attacks: Examples include HTTP flood,
          https flood, cache-bypass HTTP floods, WordPress XML RPC
          floods, and cap2=(Ac2,Cc2,RSc2,def2), we
   define two operations that are useful to manipulate capabilities:

   o capability addition: cap1+cap2 = (Ac1 U Ac2, Cc1 U Cc2, RSc1,def1) ssl DDoS.
      o capability subtraction: cap_1-cap_2 = (Ac1\Ac2,Cc1\Cc2,RSc1,def1)

   Note that addition and subtraction do not alter the resolution
   strategy Single-packet attacks:
        - Scanning and the default action method, as our main intent was to
   model addition sniffing attacks: IP sweep, port scanning, etc.
        - malformed packet attacks: Ping of modules.

   As an example, a generic Death, Teardrop, etc.
        - special packet filter that supports the first
   matching rule resolution strategies, allows the explicit
   specification of default actions and also supports time-based
   conditions. The description attacks: Oversized ICMP, Tracert, IP timestamp
          option packets, etc.

   Each type of network attack has its capabilities is the following:

      Apf = {Allow, Deny}

      Cpf= {IPsrc,IPdst,Psrc,Pdst,protType}

      Ctime = {timestart,days,datestart,datestop}

      cap_pf=(Apf; Cpf; {FMR}; F)

      cap_pf+time=cap_pf + Ctime

   By abuse of notation, we have written cap_pf+time=cap_pf + Ctime to
   shorten the more correct expression cap_pf+time=cap_pf +(;Ctime;;).

  5.6.                  Examples of NSFs Categories

   As an example of the application of the general capability model, we
   present in the next sections three examples of common categories: own network security, content security, behaviors and
   packet/flow characteristics. Therefore, each type of attack mitigation.

5.6.1. Network Security

   Network needs a
   special security function, which is advertised as a category that describes the inspecting set of
   Capabilities, for detection and
   processing mitigation. The implementation and
   management of this category of network traffic based on pre-defined security policies.

   The inspecting portion may be thought Capabilities of as a packet-processing
   engine that inspects packets traversing networks, either directly or
   in context attack
   mitigation control is very similar to flows with content security control. A
   standard interface, through which the packet is associated. From security controller can
   choose and customize the
   perspective given security Capabilities according to
   specific requirements, is essential.

4.  Information Sub-Model for Network Security Capabilities

   The purpose of packet-processing, implementations differ in the
   depths of packet headers and/or payloads they can inspect, Capability Information Sub-Model is to define the
   various flow and context states they can maintain,
   concept of a Capability, and the actions
   that can enable Capabilities to be applied aggregated to
   appropriate objects. The following sections present the packets or flows.

5.6.2. Content Security Network
   Security, Content security is another category 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 capabilities features need to be applied to application layer. Through detecting the contents carried
   over the traffic in application layer, these capabilities can
   realize various security functions, such as defending against
   intrusion, inspecting virus, filtering malicious URL or junk email,
   blocking illegal web access or malicious data retrieval.

   Generally, each type of threat not.
   Its basic structure is shown in the application layer has a set following figure:

                                      +---------------------+
     +---------------+ 1..n      1..n |                     |
     |               |/ \            \| A Common Superclass |
     | ECAPolicyRule + A -------------+   for ECA Objects   |
     |               |\ /            /|                     |
     +-------+-------+                +---------+-----------+
            / \                                / \
             |                                  |
             |                                  |
  (subclasses to define Network         (subclasses of
   unique characteristics, Event,
    Security ECA Policy Rules       Condition, and requires handling Action Objects
     with a set some extension,               for Network Security)
    such as InspectTraffic)

       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 specific
   methods. Thus,
   these NSFs will be characterized by their own
   security capabilities.

5.6.3. Attack Mitigation

   This category of security capabilities is used objects in order to define security-specific ECA policy rules,
   as well as extensions to detect and
   mitigate various types of network attacks. Today's common network
   attacks can be classified into the following sets, (generic) Events, Conditions, and each set
   further consists of
   Action objects.

   An I2NSF Policy Rule is a number special type of specific attacks:

   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, ssl DDoS.

   o Single-packet attack:

        ?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 Policy Rule that is in
   event-condition-action (ECA) form. It consists of network attack has its own network behaviors and
   packet/flow characteristics. Therefore, each type the Policy Rule,
   components of attack needs a
   special security function, which is advertised as a capability, for
   detection Policy Rule (e.g., events, conditions, actions, and mitigation.

   Overall, the implementation
   some extensions like resolution policy, default action and management of this category of
   security capabilities of attack mitigation control is very similar
   to content security control. A standard interface, through which the
   security controller can choose external
   data), and customize the given security
   capabilities according optionally, metadata. It can be applied to specific requirements, is essential.

  6. Information Sub-Model for Network Security Capabilities

   The purpose of both uni- and
   bi-directional traffic across the Capability Framework Information Sub-Model NSF.

   Each rule is to
   define triggered by one or more events. If the concept set of events
   evaluates to true, then a Capability from an external metadata model,
   and set of conditions are evaluated and, if
   true, enable Capabilities a set of actions to be aggregated to appropriate objects. In executed. This takes the
   following sections we will present conceptual form:

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

   In the cases of Network Security,
   Content Security, and Attack Mitigation sub-models.

  6.1.                  Information Sub-Model for above example, the Event, Condition, and Action portions of a
   Policy Rule are all **Boolean Clauses**.

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

4.1.1.  Network Security

   The purpose 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 is to
   define Sub-Model, which just illustrates 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 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 figure:

                                       +---------------------+ the same pattern of
   class design as below.

                            +---------------+
                            |    External   |
                            |               |/ ECAPolicyRule |
                            +-------+-------+
                                   / \            \| A Common Superclass
                                    |
                                    | ECAPolicyRule + A -------------+   for ECA Objects
                       +------------+----------+
                       | SecurityECAPolicyRule |               |\ /            /|
                       +------------+----------+
                                    |
      +-------+-------+                +---------+-----------+
             / \                                / \
                                    |
          +----+-----+--------+-----+----+---------+---------+--- ...
          |          |        |
   (subclasses to define Network         (subclasses of Event,
     Security ECA Policy Rules,       Condition, and Action Objects
      such as InspectTraffic)         for Network Security Control)          |         |         |
          |          |        |          |         |         |
   +------+-------+  |  +-----+-------+  |  +------+------+  |
   |Authentication|  |  |  Accounting |  |  |ApplyProfile |  |
   |ECAPolicyRule |  |  |ECAPolicyRule|  |  |ECAPolicyRule|  |
   +--------------+  |  +-------------+  |  +-------------+  |
                     |                   |                   |
              +------+------+     +------+------+     +--------------+
              |Authorization|     |   Traffic   |     |ApplySignature|
              |ECAPolicyRule|     | Inspection  |     |ECAPolicyRule |
              +-------------+     |ECAPolicyRule|     +--------------+
                                  +-------------+

   Figure 3. Network Security Information Info Sub-Model Overview

   In the above figure, ECAPolicyRule Extensions
   The SecurityECAPolicyRule is the ECAPolicyRule, along with top of the Event,
   Condition, and Action Objects, 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 external ECA Info
   Model. next version of this
   draft). The six SecurityECAPolicyRule subclasses extend the
   SecurityECAPolicyRule class to represent six different types of
   Network Security Sub-Model extends both to define
   security-specific ECA policy rules, as well as Events, Conditions,
   and Actions.
   An I2NSF Policy Rule Rules. It is a special type of Policy Rule assumed that is the (external)
   generic ECAPolicyRule class defines basic information in
   event-condition-action (ECA) form. It consists of the Policy Rule,
   components form of
   attributes, such as an unique object ID, as well as a Policy Rule (e.g., events, conditions, and actions), description
   and optionally, metadata. It can other necessary information.

*** Note to WG
*
*   The design in Figure 3 represents the simplest conceptual design
*   for network security. An alternative model would be applied to both uni-directional
   and bi-directional traffic across use a
*   software pattern (e.g., the NSF.

   Each rule is triggered Decorator pattern); this would result
*   in the SecurityECAPolicyRule class being "wrapped" by one or more events. If the set
*   of events
   evaluates to true, then a set the six subclasses shown in Figure 3. The advantage of conditions are evaluated and, if
   true, enable such a set of actions
*   pattern is to be executed.

      An example reduce the number of an I2NSF Policy Rule is, in pseudo-code:

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

   In active objects at runtime, as
*   well as offer the above example, 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 portions 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 a these six ECA Policy Rule Rules are all **Boolean Clauses**.

6.1.1. provided
   in Appendix A.

4.1.2.  Network Security Policy Rule Extensions

   Figure 3 shows an example Operation

   A Network Security Policy consists of one or more detailed design of the ECA Policy
   Rule subclasses that are contained in Rules
   formed from the information model described above. In simpler cases,
   where the Event and Condition clauses remain unchanged, then network
   security may be performed by calling additional network security
   actions. Network Security
   Information Sub-Model, which just illustrates how more specific
   Network Security Policies are inherited security policy examines and extended from performs basic
   processing of the
   SecurityECAPolicyRule class. Any new kinds traffic as follows:

      1. The NSF evaluates the Event clause of specific Network
   Security Policy a given
         SecurityECAPolicyRule (which can be created by following the same pattern of
   class design generic or specific to
         security, such as below.

                             +---------------+
                             |    External   |
                             | ECAPolicyRule |
                             +-------+-------+
                                    / \
                                     |
                                     |
                        +------------+----------+
                        | SecurityECAPolicyRule |
                        +------------+----------+
                                     |
                                     |
           +----+-----+--------+-----+----+---------+---------+--- ...
           |          |        |          |         |         |
           |          |        |          |         |         |
    +------+-------+  |  +-----+-------+  |  +------+------+  |
    |Authentication|  |  |  Accounting |  |  |ApplyProfile |  |
    |ECAPolicyRule |  |  |ECAPolicyRule|  |  |ECAPolicyRule|  |
    +--------------+  |  +-------------+  |  +-------------+  |
                      |                   |                   |
               +------+------+     +------+------+     +--------------+
               |Authorization|     |   Traffic   |     |ApplySignature|
               |ECAPolicyRule|     | Inspection  |     |ECAPolicyRule |
               +-------------+     |ECAPolicyRule|     +--------------+
                                   +-------------+ those in Figure 4. Network Security Info Sub-Model ECAPolicyRule Extensions

   The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule
   hierarchy. 3). It inherits from the (external) generic ECA Policy Rule may use security
         Event objects to define Security ECA Policy Rules. The SecurityECAPolicyRule
   contains do all or part of the attributes, methods, and relationships defined
   in its superclass, and adds additional concepts that this evaluation, which are required
   for Network Security (these will be
         defined in section 4.1.3. If the next version Event clause evaluates to
         TRUE, then the Condition clause 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 evaluated; otherwise, the form execution of
   attributes, such as an unique object ID, as well as a description
   and other basic, but necessary, information.

   It is assumed that the (external) generic ECA Policy Rule this
         SecurityECAPolicyRule is
   abstract; stopped, and the next
         SecurityECAPolicyRule (if one exists) is also abstract. This enables
   data model optimizations to be made while making this information
   model detailed but flexible and extensible. evaluated.
      2. The SecurityECAPolicyRule defines network security policy as a
   container that aggregates Event, Condition, and Action objects,
   which are described in Section 6.1.3, 6.1.4, and 6.1.5, respectively.
   Events, Conditions, and Actions can be generic or security-specific.
   Section 4.6 defines the concept of default security Actions.

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

6.1.2. Network Security Policy Rule Operation

   Network security policy consists of a number of more granular ECA
   Policy Rules formed from the information model described above. In
   simpler cases, where the Event and Condition clauses remain
   unchanged, then network security control may be performed by calling
   additional network security actions. Network security policy
   examines and performs basic processing of the traffic as follows:

   1. For a given SecurityECAPolicyRule (which can be generic or
      specific to security, such as those in Figure 3), the NSF
      evaluates the Event clause. It may use security Event objects to
      do all or part of this evaluation, which are defined in section
      4.3.3. If the Event clause evaluates to TRUE, then the Condition
      clause of this SecurityECAPolicyRule is evaluated; otherwise,
      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 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.3.4. 4.1.4. If the Condition clause
         evaluates to TRUE, then the set of Actions in this SecurityECAPolicyRule MUST
      be executed. This it is defined as "matching" the
         SecurityECAPolicyRule; otherwise, execution of this
         SecurityECAPolicyRule is stopped, and the next
         SecurityECAPolicyRule (if one exists) is evaluated; evaluated.
      3. If none The set of the SecurityECAPolicyRules actions to be executed are matched, retrieved, and then the NSF
      denies
         resolution strategy is used to define their execution order.
         This process includes using any optional external data
         associated with the traffic by default; SecurityECAPolicyRule.
      4. Execution then takes one of the following three forms:
         a. If the traffic matches a rule, one or more actions is selected, then the NSF performs the may
            perform those actions as defined
      Actions on by the traffic. 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.3.5.
      If the action is "deny", the NSF blocks the traffic. 4.1.5. If the
            basic
      action Action is permit or mirror, the NSF firstly performs
            that function, and then checks whether certain other
            security
      capabilities Capabilities are referenced in the rule. If yes,
            go to step 5. If no, the traffic is permitted; 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 Capabilities (e.g., the conditions and/or
         actions implied by Anti-virus or IPS) IPS profile NSFs) are
         referenced in the SecurityECAPolicyRule, and the Action defined
      in action set of the rule is permit or mirror, SecurityECAPolicyRule, the
         NSF performs the referenced
      security capabilities.

   Metadata attached to the SecurityECAPolicyRule MAY can be used to
   control how the SecurityECAPolicyRule is evaluated. This is called a
   Policy Rule Evaluation Strategy. For example, one strategy is configured to
   match and execute use the first SecurityECAPolicyRule, and then exit
   without executing any other SecurityECAPolicyRules (even if they
   matched). In contrast, a second strategy is to first collect all
   SecurityECAPolicyRules that matched, and then execute them according
   to a pre-defined order referenced security
         Capabilities (e.g., the priority of each
   SecurityECAPolicyRule). 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.

6.1.3.

4.1.3.  Network Security Event Sub-Model

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

                                     +---------------------+
        +---------------+ 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 5. 4. Network Security Info Sub-Model Event Class Extensions

   The four Event classes shown in Figure 5 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.

   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 10). 4). However, this makes it harder to use any
   generic Event model with the I2NSF events. Assumptions are:

      - The generic Event class is abstract
      - 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 10 4 would be
        subclasses of the Atomic Event) 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

   Brief class descriptions are provided

*** Note to WG:
*
*   The design in Figure 4 represents the following sub-sections.

6.1.3.1. UserSecurityEvent Class Description

   The purpose of this class is to represent Events that are initiated
   by a user, such as logon and logoff simplest conceptual design
*   design for describing Security Events. Information in this
   Event may An alternative model would
*   be used as part of a test to determine if use a software pattern (e.g., the Condition
   clause in Decorator pattern); this ECA Policy Rule should be evaluated or not. Examples
   include user identification data and the type of connection used by
*   would result in the user.

   The UserSecurityEvent SecurityEvent class defines the following attributes:

6.1.3.1.1. The usrSecEventContent Attribute

   This is a mandatory string that contains the content of the
   UserSecurityEvent. The format being "wrapped" by one or
*   more of the content is specified four subclasses shown in the
   usrSecEventFormat class attribute, and the type Figure 4. The advantage of Event
*   such a pattern is defined
   in to reduce the usrSecEventType class attribute. An example number of active objects at runtime,
*   as well as offer the
   usrSecEventContent attribute is the string "hrAdmin", with the
   usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute
   set ability to 5 (new logon).

6.1.3.1.2. combine multiple events of different
*   types into one. The usrSecEventFormat Attribute

   This disadvantage is a mandatory non-negative enumerated integer, which that it is used a more complex
*   software design.
*
*** End of Note to specify the data type 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 usrSecEventContent attribute. Condition subclasses
   that are contained in the Network Security Information Sub-Model.
   The
   content is specified six Condition classes shown in Figure 5 extend the usrSecEventContent (external)
   generic Condition class attribute, and
   the type to represent Conditions that are of Event interest
   to Network Security. It is defined in assumed that the usrSecEventType (external) generic
   Condition 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)

6.1.3.1.3. The usrSecEventType Attribute

   This is a mandatory non-negative enumerated integer, which abstract, so that data model optimizations may be
   defined. It is used
   to specify the type of Event also assumed that involves this user. The content
   and format are specified in the usrSecEventContent and
   usrSecEventFormat generic Condition class attributes, respectively. An example of the
   usrSecEventContent attribute is the string "hrAdmin", with the
   usrSecEventFormat attribute set to 1 (GUID) and defines
   basic Condition information in 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

6.1.3.2. DeviceSecurityEvent Class Description

   The purpose form of attributes, such as a DeviceSecurityEvent is
   unique object ID, a description, as well as a mechanism to represent Events that
   provide information from the Device that are important attach
   zero or more metadata objects to I2NSF
   Security. Information in it. While this Event may could be used defined as part of
   attributes in a test to
   determine if SecurityCondition class (which would be a subclass
   of the generic Condition clause in this ECA Policy Rule should be
   evaluated or not. Examples include alarms class, and various device
   statistics (e.g., a type superclass of threshold that was exceeded), which may
   signal the need six
   Condition classes shown in Figure 5), this makes it harder to use
   any generic Condition model with the I2NSF conditions.

                                     +---------------------+
     +---------------+ 1..n     1..n |                     |
     |               |/ \           \| A Common Superclass |
     | ECAPolicyRule+ A -------------+   for further action. 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

*** Note to WG:
*
*   The DeviceSecurityEvent class defines design in Figure 5 represents the following attributes:

6.1.3.2.1. The devSecEventContent Attribute

   This is simplest conceptual design
*   for describing Security Conditions. An alternative model would be
*   to use a mandatory string that contains software pattern (e.g., the content Decorator pattern); this would
*   result in the SecurityCondition class being "wrapped" by one or
*   more of the
   DeviceSecurityEvent. six subclasses shown in Figure 5. The format advantage of the content such
*   a pattern is specified in the
   devSecEventFormat class attribute, and the type of Event is defined
   in to reduce the devSecEventType class attribute. An example number of active objects at runtime, as
*   well as offer the
   devSecEventContent attribute is "alarm", with the devSecEventFormat
   attribute set to 1 (GUID), the devSecEventType attribute set to 5
   (new logon).

6.1.3.2.2. The devSecEventFormat Attribute

   This is a mandatory non-negative enumerated integer, which is used ability to specify the data type combine multiple conditions 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)

6.1.3.2.3.
*   different types into one. The devSecEventType Attribute

   This is a mandatory non-negative enumerated integer, which disadvantage 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.

6.1.3.2.4. it is a more
*   complex software design.
*   The devSecEventTypeInfo[0..n] Attribute

   This design team is an optional array requesting feedback from he WG regarding this.
*
*** End of strings, which is used Note 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 WG

   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 third array, and
   additional information Action subclasses that
   are contained in the fourth array.

6.1.3.2.5. The devSecEventTypeSeverity Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to specify the perceived severity of the Network Security Information Sub-Model.

                                      +---------------------+
      +---------------+ 1..n     1..n |                     |
      |               |/ \           \| A Common Superclass |
      | ECAPolicyRule+ A -------------+   for ECA Objects   |
      |               |\ /           /|                     |
      +---------------+               +-----------+---------+
                                                 / \
                                                  |
                                                  |
                          +--------------+--------+------+
                          |              |               |
                          |              |               |
                    +-----+----+  +------+------+  +-----+-----+
                    | An Event generated by this
   Device. Values include:

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

   Values 1-6 are from X.733.

6.1.3.3. SystemSecurityEvent |  | A Condition |  | An Action |
                    |   Class Description  |  |    Class    |  |   Class   |
                    +----------+  +-------------+  +-----+-----+
                                                        / \
                                                         |
                                                         |
                       +-----------------+---------------+------- ...
                       |                 |               |
                       |                 |               |
                   +---+-----+      +----+---+    +------+-------+
                   | Ingress |      | Egress |    | ApplyProfile |
                   | Action  |      | Action |    |     Action   |
                   +---------+      +--------+    +--------------+

      Figure 6. Network Security Info Sub-Model Action Extensions

   The purpose of a SystemSecurityEvent is four Action classes shown in Figure 6 extend the (external)
   generic Action class to represent Events Actions that are
   detected by perform a Network
   Security Control function.

   The three Action classes shown in Figure 6 extend the management system, instead of Events (external)
   generic Action class to represent Actions that are
   generated by a user or a device. Information in this Event may be
   used as part of a test interest to determine if
   Network Security. It is assumed that the Condition clause in this
   ECA Policy Rule should (external) generic Action
   class is abstract, so that data model optimizations may be evaluated or not. Examples include an
   event issued by an analytics system defined.
   It is also assumed that warns against a particular
   pattern the generic Action class defines basic
   Action information in the form of unknown user accesses, attributes, such as a unique
   object ID, a description, as well as a mechanism to attach zero or an Event issued by
   more metadata objects to it. While this could be defined as
   attributes in a management
   system that represents SecurityAction class (which would be a set subclass of correlated and/or filtered Events.

   The SystemSecurityEvent class defines
   the following attributes:

6.1.3.3.1. The sysSecEventContent Attribute

   This is generic Action class, and a mandatory string that contains the content superclass of the
   SystemSecurityEvent. The format of six Action classes
   shown in Figure 6), this makes it harder to use any generic Action
   model with the content is specified I2NSF actions.

*** Note to WG
*   The design in Figure 6 represents the
   sysSecEventFormat class attribute, and simplest conceptual design
*   for describing Security Actions. An alternative model would be to
*   use a software pattern (e.g., the type of Event is defined Decorator pattern); this would
*   result in the sysSecEventType SecurityAction class attribute. An example being "wrapped" by one or more
*   of the
   sysSecEventContent attribute three subclasses shown in Figure 6. The advantage of such a
*   pattern is the string "sysadmin3", with the
   sysSecEventFormat attribute set to 1 (GUID), and reduce the sysSecEventType
   attribute set number of active objects at runtime, as
*   well as offer the ability to 2 (audit log cleared).

6.1.3.3.2. combine multiple actions of different
*   types into one. The sysSecEventFormat Attribute

   This disadvantage is that it is a mandatory non-negative enumerated integer, which more complex
*   software design.
*   The design team is used
   to specify requesting feedback from the data type WG regarding this.
*
*** End 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)

6.1.3.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

6.1.3.4. TimeSecurityEvent Class Description

   The purpose of a TimeSecurityEvent is Note to represent Events that WG

   Brief class descriptions 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, provided in
   which a significant event happened. Appendix D.

4.2.  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:

6.1.3.4.1. Model for I2NSF Capabilities

   The timeSecEventPeriodBegin Attribute

   This I2NSF Capability Model is a mandatory DateTime attribute, and represents the beginning made up of a time period. It has a value number of Capabilities
   that has a date and/or represent various content security and attack mitigation
   functions. Each Capability protects against a time
   component (as specific type of
   threat in the Java or Python libraries).

6.1.3.4.2. The timeSecEventPeriodEnd Attribute application layer. 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.

6.1.3.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 shown in ISO8601.

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

                                     +---------------------+ 7.

+-------------------------+ 0..n         0..n +---------------+ 1..n  1..n |                     |
|                         |/ \               \| A Common Superclass   External    |
| ECAPolicyRule+ A ----------+   for External ECA Objects Info Model + A ----------------+   Metadata    |
|                         |\ /  Aggregates   /|  Info Model   |
+-------+-----------------+      Metadata     +-----+---------+
        |
        +-------+-------+            +-----------+---------+                                          / \
        |                                           |
                       +--------------+----------+----+
                       |              |               |
                       |              |               |
                 +-----+----+  +------+------+  +-----+-----+
                 | An Event |  | A Condition |  | An Action |
                 |   Class  |  |    Class    |  |   Class   |
                 +----------+  +------+------+  +-----------+
       / \                                          |
    Subclasses    +---------------------------------+--------------+
     derived      |
           +--------+----------+------+---+---------+--------+--- ...
           |        |          |          |         | Capability                      |              |
    for I2NSF     | Sub-Model            +----------+---------+    |
                  |                      | SecurityCapability |
     +-----+-----+    |  +-------+-------+
                  |  +------+-----+                      +----------+---------+    |
                  |   Packet                                 |              |
                  | PacketPayload                                 |              |
                  |    Target          +----------------------+---+          |
                  |          |  Security                          |          |
                  |    Security +--------+---------+     +----------+--------+ |
                  | | Content Security |     |
     | Condition |  |  |   Condition   |  |  |  Condition |  |
     +-----------+  |  +---------------+  |  +------------+  |
                    |                     |                  |
             +------+-------+  +----------+------+  +--------+-------+
             | UserSecurity |  | SecurityContext Attack Mitigation | | GenericContext
                  | +   Capabilities   |   Condition     |    Capabilities   |    Condition |
                  |    Condition +------------------+     +-------------------+ |
             +--------------+  +-----------------+  +----------------+
                  +------------------------------------------------+

        Figure 6. Network 7. I2NSF Security Info Sub-Model Condition Class
                                Extensions

   The six Condition classes shown in Capability High-Level Model

   Figure 6 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 7 shows a mechanism common I2NSF Security Capability class, called
   SecurityCapability. This enables us to attach
   zero or more metadata objects add common attributes,
   relationships, and behavior to it. While this could be defined as
   attributes in a SecurityCondition class (which would be a subclass
   of without affecting the generic Condition class, and a superclass
   design of the six
   Condition classes shown in Figure 11), this makes it harder to use
   any generic Condition model with the external metadata information model.

   All I2NSF conditions.

   Brief class descriptions Security Capabilities are provided then subclassed from the
   SecuritCapability class.

   Note: the SecurityCapability class will be defined in the following sub-sections.

6.1.4.1. PacketSecurityCondition

   The purpose next
   version of this Class draft, after feedback from the WG is to represent packet header information
   that can be used as part obtained.

4.3.  Information Model for Content Security Capabilities

   Content security is composed of a test to determine if the set number of Policy
   Actions distinct security
   functions; each such function protects against a specific type of
   threat in this ECA Policy Rule should be executed or not. This
   class is abstract, and serves as the superclass application layer. Content security is a type of more detailed
   conditions that involve different types
   Generic Network Security Function, which summarizes a well-defined
   set of packet formats. Its
   subclasses are security Capabilities, and was shown in Figure 7, and are defined in the following
   sections.

                          +-------------------------+ 7. Figure 8
   shows exemplary types of content security Generic Network
   Security Function.

     +--------------------------------------------------------------+
     | PacketSecurityCondition                             +--------------------+           |
                          +------------+------------+
     |   Capability                | SecurityCapability |           |
     |   Sub-Model:                +---------+----------+           |
     | Content Security                   / \                       |
     |
              +---------+----------+---+-----+----------+                                     |                        |
     |                                     |                        |
     |       +-------+----------+----------+---------------+        |
     |       |       |
     +--------+-------+          | +--------+-------+                          | +--------+-------+        | PacketSecurity
     | +-----+----+  |  +-------+----+             +-------+------+ | PacketSecurity
     | |Anti-Virus|  |  | PacketSecurity Intrusion  |             |  MACCondition    Attack    | |
     | IPv4Condition |Capability|  |  | Prevention | IPv6Condition             |
     +----------------+  Mitigation  | +----------------+ | +----------------+
     | +----------+  |  |
               +--------+-------+   +--------+-------+ Capability |  TCPCondition             | Capabilities |  UDPCondition |
               +----------------+   +----------------+
     |               |  +------------+             +--------------+ |
     |               |                                              |
     |      +--------+----+------------+-----------+--------+       |
     |      |             |            |           |        |       |
     | +----+-----+ +-----+----+ +-----+----+ +----+-----+  |       |
     | |   URL    | |   Mail   | |   File   | |  Data    |  |       |
     | |Filtering | |Filtering | |Filtering | |Filtering |  |       |
     | |Capability| |Capability| |Capability| |Capability|  |       |
     | +----------+ +----------+ +----------+ +----------+  |       |
     |                                                      |       |
     |             +----------------+------------------+----+       |
     |             |                |                  |            |
     |      +------+------+  +------+------+ +---------+---------+  |
     |      |PacketCapture|  |FileIsolation| |ApplicationBehavior|  |
     |      | Capability  |  | Capability  | |    Capability     |  |
     |      +-------------+  +-------------+ +-------------------+  |
     +--------------------------------------------------------------+

          Figure 7. 8. Network Security Info Sub-Model PacketSecurityCondition
                             Class Extensions

6.1.4.1.1. PacketSecurityMACCondition Capability Information Model

   The purpose detailed description about a standard interface, and the
   parameters for all the security Capabilities of this Class is to represent packet MAC packet header
   information that can category, will
   be used as part of defined in a test to determine if the
   set future version of Policy Actions in this ECA Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes:

6.1.4.1.1.1. The pktSecCondMACDest Attribute

   This document.

4.4.  Information Model for Attack Mitigation Capabilities

   Attack mitigation is composed of a mandatory string attribute, and defines the MAC
   destination address (6 octets long).

6.1.4.1.1.2. The pktSecCondMACSrc Attribute

   This number of Generic Network Security
   Functions; each one protects against a specific type of network
   attack. Attack Mitigation security is a mandatory string attribute, and defines the MAC source
   address (6 octets long).

6.1.4.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 type of Generic Network
   Security Function, which summarizes a well-defined set of security
   Capabilities, and 802.1p
   priority values.

6.1.4.1.1.4. was shown in Figure 7. Figure 9 shows exemplary
   types of Attack Mitigation Generic Network Security Functions.

     +---------------------------------------------------------------+
     |                           +--------------------+              |
     |    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 pktSecCondMACEtherType Attribute

   This is detailed description about a mandatory string attribute, and defines the EtherType
   field (2 octets long). Values up to standard interface, and including 1500 indicate the
   size of
   parameters for all the payload in octets; values security Capabilities of 1536 and above define which
   protocol is encapsulated this category, will
   be defined in the payload a future version of the frame.

6.1.4.1.1.5. this document.

5.  Security Considerations

   The pktSecCondMACTCI Attribute

   This is an optional string attribute, and defines security Capability policy information sent to NSFs should be
   protected by 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).

6.1.4.1.2. PacketSecurityIPv4Condition

   The purpose of this Class is secure communication channel, to represent packet IPv4 packet header
   information ensure its
   confidentiality and integrity. Note that the NSFs and security
   controller can all be used as part of spoofed, which leads to undesirable results
   (e.g., security policy leakage from security controller, or a test spoofed
   security controller sending false information to determine if mislead the
   set of Policy Actions in this ECA Policy Rule should NSFs).
   Hence, mutual authentication MUST be executed or
   not. This class is concrete, and defines the following attributes:

6.1.4.1.2.1. supported to protected against
   this kind of attack.  The pktSecCondIPv4SrcAddr Attribute

   This is a mandatory string attribute, current mainstream security technologies
   (i.e., TLS, DTLS, and defines IPSEC) can be employed to protect against the IPv4 Source
   Address (32 bits).

6.1.4.1.2.2. The pktSecCondIPv4DestAddr Attribute

   This is
   above threats.

   In addition, to defend against DDoS attacks caused by a mandatory string attribute, and defines hostile
   security controller sending too many configuration messages to the IPv4
   Destination Address (32 bits).

6.1.4.1.2.3.
   NSFs, rate limiting or similar mechanisms should be considered.

6.  IANA Considerations

   TBD

7.  Contributors

   The pktSecCondIPv4ProtocolUsed Attribute

   This is a mandatory string attribute, following people contributed to creating this document, and defines the protocol used are
   listed below in the data portion of the IP datagram (8 bits).

6.1.4.1.2.4. The pktSecCondIPv4DSCP Attribute

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

6.1.4.1.2.5. The pktSecCondIPv4ECN Attribute

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

6.1.4.1.2.6. The pktSecCondIPv4TotalLength Attribute

   This is a mandatory string attribute, 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 defines the total length
   of the packet (including header Wood, J., "Authentication, Authorization, and data) in bytes (16 bits).

6.1.4.1.2.7. The pktSecCondIPv4TTL Attribute

   This is a mandatory string attribute,
      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.
   [I-D.draft-ietf-i2nsf-problem-and-use-cases]
      Hares, S., et.al., "I2NSF Problem Statement and defines the Time To Live
   in seconds (8 bits).

6.1.4.1.3. PacketSecurityIPv6Condition

   The purpose of this Class is Use cases",
      draft-ietf-i2nsf-problem-and-use-cases-11, March 2017.
   [I-D.draft-ietf-i2nsf-framework]
      Lopez, E., et.al., "Framework for Interface to represent packet IPv6 packet header
   information that can be used as part of a test Network Security
      Functions", draft-ietf-i2nsf-framework-04, October, 2016.
   [I-D.draft-ietf-i2nsf-terminology]
      Hares, S., et.al., "Interface to determine if the
   set of 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 Actions in this ECA
      Information Model for Simplified Use of Policy Rule should be executed or
   not. This class is concrete, and defines the following attributes:

6.1.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute

   This is a mandatory string attribute, and defines Abstractions
      (SUPA)", Woaft-ietf-supa-generic-policy-info-model-02,
      October, 2016.
   [I-D.draft-zhang-i2nsf-info-model-monitoring]
      Zhang, D., et al., "An Information Model for the IPv6 Source
   Address (128 bits).

6.1.4.1.3.2. The pktSecCondIPv6DestAddr Attribute

   This is a mandatory string attribute, Monitoring of
      Network Security Functions (NSF)",
      draft-zhang-i2nsf-info-model-monitoring-02, September, 2016.
   [Alshaer]
      Al Shaer, E. and defines the IPv6
   Destination Address (128 bits).

6.1.4.1.3.3. The pktSecCondIPv6DSCP Attribute

   This is a mandatory string attribute, H. Hamed, "Modeling and defines the Differentiated
   Services Code Point field (6 bits). It consists management of the six most
   significant bits 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 the Traffic Class field 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 the IPv6 header.

6.1.4.1.3.4. The pktSecCondIPv6ECN Attribute

   This 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 mandatory string attribute, and common pattern that defines the Explicit
   Congestion Notification field (2 bits). It consists how these
   ECAPolicyRules operate; this simplifies their implementation. All of the two least
   significant bits
   these six ECA Policy Rules are concrete classes.

   In addition, none of the Traffic Class field in the IPv6 header.

6.1.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute these six subclasses define attributes. 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).

6.1.4.1.3.6. The pktSecCondIPv6PayloadLength Attribute

   This is a mandatory string attribute, them to be viewed as simple object containers, and defines the total length hence,
   applicable to a wide variety of content. It also means that the packet (including
   content of the fixed and any extension headers, and
   data) in bytes (16 bits).

6.1.4.1.3.7. The pktSecCondIPv6NextHeader Attribute

   This function (e.g., how an entity is a mandatory string attribute, and defines authenticated, what
   specific traffic is inspected, or which particular signature is
   applied) is defined solely by the type set of events, conditions, and
   actions that are contained by the
   next header (e.g., which extension header to use) (8 bits).

6.1.4.1.3.8. The pktSecCondIPv6HopLimit Attribute particular subclass. This is a mandatory string attribute, and defines enables
   the maximum number policy rule, with its aggregated set of hops that this packet can traverse (8 bits).

6.1.4.1.4. PacketSecurityTCPCondition events, conditions, and
   actions, to be treated as a reusable object.

A.1.  AuthenticationECAPolicyRule Class Definition

   The purpose of this Class an AuthenticationECAPolicyRule is to represent packet TCP packet header
   information define an I2NSF
   ECA Policy Rule that can be used as part verify whether an entity has an attribute
   of a test to determine if the
   set of Policy Actions in this ECA Policy Rule should be executed or
   not. 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 is concrete, and defines does NOT define the following attributes:

6.1.4.1.4.1. The pktSecCondTPCSrcPort Attribute authentication method used. This is a mandatory string attribute, and defines
   because this would effectively "enclose" this information within the Source Port
   (16 bits).

6.1.4.1.4.2. The pktSecCondTPCDestPort Attribute
   AuthenticationECAPolicyRule. This is a mandatory string attribute, and defines has two drawbacks. First, other
   entities that need to use information from the Destination
   Port (16 bits).

6.1.4.1.4.3. The pktSecCondTPCSeqNum Attribute

   This is a mandatory string attribute, and defines Authentication
   class(es) could not; they would have to associate with the sequence
   number (32 bits).

6.1.4.1.4.4. The pktSecCondTPCFlags Attribute

   This is a mandatory string attribute,
   AuthenticationECAPolicyRule class, and defines those other classes would not
   likely be interested in the nine Control
   bit flags (9 bits).

6.1.4.1.5. PacketSecurityUDPCondition

   The purpose AuthenticationECAPolicyRule. Second, the
   evolution of this Class is to represent packet UDP packet header
   information that can new authentication methods should be used as part independent of a test to determine if the
   set of Policy Actions in
   AuthenticationECAPolicyRule; this ECA Policy Rule should be executed or
   not. This class is concrete, and defines cannot happen if the following attributes:

6.1.4.1.5.1. The pktSecCondUDPSrcPort Attribute

   This is a mandatory string attribute, and defines
   Authentication class(es) are embedded in the UDP Source
   Port (16 bits).

6.1.4.1.5.2. The pktSecCondUDPDestPort Attribute
   AuthenticationECAPolicyRule.

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

6.1.4.1.5.3. The pktSecCondUDPLength Attribute

   This is a mandatory string attribute, AuthenticationECAPolicyRule; all other
   classes, and defines the length aggregations, are defined in
   bytes an external model. For
   completeness, descriptions of how the UDP header and data (16 bits).

6.1.4.2. PacketPayloadSecurityCondition

   The purpose of this Class is to represent packet payload data that
   can be two aggregations are used as part of a test to determine if 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 set implementation of Policy
   Actions in this ECA Policy Rule should be executed or not. Examples
   include a specific set of bytes
   authentication mechanisms from how authentication mechanisms are
   managed and used.

   Since different AuthenticationECAPolicyRules can use different
   authentication mechanisms in different ways, the packet payload.

6.1.4.3. TargetSecurityCondition

   The purpose of this Class aggregation is to represent information about
   different targets
   realized as an association class. This enables the attributes and
   methods of this policy the association class (i.e., entities AuthenticationRuleDetail) 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 define how a given AuthenticationMethod is
   administered used by a
   particular AuthenticationECAPolicyRule.

   Similarly, the same set PolicyControlsAuthentication aggregation defines
   Policy Rules to control the configuration of users, groups, or roles. the
   AuthenticationRuleDetail association class. This Class has several important subclasses, including:

   a. ServiceSecurityContextCondition is enables the superclass for all
      information that can entire
   authentication process to be used in an managed by ECA Policy Rule that specifies PolicyRules.

   Note: a data about the type of service model MAY choose to be analyzed (e.g., collapse this design into a more
   efficient implementation. For example, a data model could define two
   attributes for the protocol
      type AuthenticationECAPolicyRule class (e.g., called
   authenticationMethodCurrent and port number)

   b. ApplicationSecurityContextCondition is authenticationMethodSupported), to
   represent the superclass for all
      information that can HasAuthenticationMethod aggregation and its
   association class. The former would be used in a ECA Policy Rule that specifies
      data string attribute that identifies a particular application (including metadata,
      such as risk level)

   c. DeviceSecurityContextCondition is
   defines the superclass for all
      information that can be current authentication method used in a ECA Policy Rule that specifies
      data about by this
   AuthenticationECAPolicyRule, while the latter would define a device type and/or device OS that is being used

6.1.4.4. UserSecurityCondition set of
   authentication methods, in the form of an authentication Capability,
   which this AuthenticationECAPolicyRule can advertise.

A.2.  AuthorizationECAPolicyRuleClass Definition

   The purpose of this Class an AuthorizationECAPolicyRule is to represent data about the user or
   group referenced in this define an I2NSF
   ECA Policy Rule that can be used as part of
   a test to determine whether access to a resource
   should be given and, if the set of Policy Actions in this ECA Policy
   Rule so, what permissions should be evaluated or not. Examples include granted to
   the user or group
   id used, entity that is accessing the type of connection used, whether a given user or group resource.

   This class does NOT define the authorization method(s) used. This
   is playing a particular role, or whether a given user or group because this would effectively "enclose" this information within
   the AuthorizationECAPolicyRule. This has
   failed two drawbacks. First, other
   entities that need to login a particular number of times.

6.1.4.5. SecurityContextCondition

   The purpose of this Class is use information from the Authorization
   class(es) could not; they would have to represent security conditions that
   are part associate with the
   AuthorizationECAPolicyRule class, and those other classes would not
   likely be interested in the AuthorizationECAPolicyRule. Second, the
   evolution of a specific context, which can new authorization methods should be used as part independent of a test
   to determine the
   AuthorizationECAPolicyRule; this cannot happen if the set of Policy Actions Authorization
   class(es) are embedded in the AuthorizationECAPolicyRule. Hence,
   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.

6.1.4.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.

6.1.5. Network Security Action Sub-Model

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

                                     +---------------------+ following design:

                                                    +---------------+
    +----------------+ 1..n  1..n                   1...n |               |
    |                |/ \   HasAuthorizationMethod \| A Common Superclass Authorization |
    | ECAPolicyRule+ Authorization  + A ----------+   for ECA Objects ----------+----------------+     Method    |
    | ECAPolicyRule  |\ /          ^               /|               |
        +---------------+            +-----------+---------+
                                                / \
                                                 |
                                                 |
                         +--------------+--------+------+
                         |              |               |
                         |              |               |
                   +-----+----+  +------+------+  +-----+-----+
                   | An Event |  | A Condition |  | An Action
    |                |   Class             |                +---------------+
    +----------------+             |    Class
                                   |
                      +------------+------------+
                      |   Class AuthorizationRuleDetail |
                   +----------+  +-------------+  +-----+-----+
                      +------------+------------+
                                  / \ 0..n
                                   |
                                   |
          +------------+-------------+------------------+-------- ...
          |            |             |                  |
          |            |             |                  |
     +----+----+  +----+---+  +------+-------+  +-------+--------+
     | Ingress |  | Egress |  | ApplyProfile |  | ApplySignature |
     | Action  |  | Action |  |    Action PolicyControlsAuthorization
                                   |
                                  / \
                                   A
                                  \ / 0..n
                        +----------+--------------+
                        |     Action ManagementECAPolicyRule |
     +---------+  +--------+  +--------------+  +----------------+
                        +-------------------------+

             Figure 7. Network Security Info Sub-Model Action Extensions

   The four Action classes shown 11.  Modeling Authorization Mechanisms

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

   Figure 11 defines an aggregation between the
   AuthorizationECAPolicyRule and an external class to represent Actions that perform a Network
   Security Control function. Brief class descriptions defines one or
   more authorization methods. This decouples the implementation of
   authorization mechanisms from how authorization mechanisms are provided
   managed and used.

   Since different AuthorizationECAPolicyRules can use different
   authorization mechanisms in different ways, the following sub-sections.

6.1.5.1. IngressAction

   The purpose of this Class aggregation is to represent actions performed on
   packets that enter
   realized as an NSF. Examples include pass, drop, mirror
   traffic.

6.1.5.2. EgressAction

   The purpose association class. This enables the attributes and
   methods of this Class is the association class (i.e., AuthorizationRuleDetail)
   to represent actions performed on
   packets that exit an NSF. Examples include pass, drop, mirror
   traffic, signal, encapsulate.

6.1.5.3. ApplyProfileAction

   The purpose of this Class is be used to represent applying define how a profile to
   packets to perform content security and/or attack mitigation control.

6.1.5.4. ApplySignatureAction

   The purpose of this Class given AuthorizationMethod is to represent applying used by a signature file
   to packets
   particular AuthorizationECAPolicyRule.

   Similarly, the PolicyControlsAuthorization aggregation defines
   Policy Rules to perform content security and/or attack mitigation
   control.

  6.2.                  Information Model for Content Security Control

   The block for content security control is composed the configuration of the
   AuthorizationRuleDetail association class. This enables the entire
   authorization process to be managed by ECA PolicyRules.

   Note: a number of
   security capabilities, while each one aims for protecting against data model MAY choose to collapse this design into a
   specific type of threat in the application layer.

   Following figure shows more
   efficient implementation. For example, a basic structure of data model could define
   two attributes for the information model:

                   +----------------------------------+
                   |                                  |
                   |                                  |
                   |     Anti-Virus                   |
                   |     Intrusion Prevention         |
                   |     URL Filtering                |
                   |     File Blocking                |
                   |     Data Filtering               |
                   |     Application Behavior Control |
                   |     Mail Filtering 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 |             |     Packet Capturing
      |                |/ \   HasAccountingMethod  \| Accounting  |     File Isolation
      |  Accounting    + A ----------+--------------+   Method    |     ...
      | ECAPolicyRule  |\ /          ^             /|             |
      |                |             |              +-------------+
      +----------------+             |
                                     |
                          +----------+-----------+
                          | AccountingRuleDetail |
                          +----------+-----------+
                                    / \ 0..n
                                     |              Information model
                                     | PolicyControlsAccounting
                                     |              for content security|
                                    / \
                                     A
                                    \ / 0..n
                          +----------+--------------+
                          |              control ManagementECAPolicyRule |
                   +----------------------------------+
                          +-------------------------+

              Figure 8. The basic structure of information model for content
                             security control

   The detailed description about 12.  Modeling Accounting Mechanisms

   This document only defines the standard interface AccountingECAPolicyRule; all other
   classes, and the
   parameters for all aggregations, are defined in an external model.
   For completeness, descriptions of how the security capabilities 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 this category accounting mechanisms from how
   accounting mechanisms are
   TBD.

  6.3.                  Information Model for Attack Mitigation Control

   The block for attack mitigation control managed and used.

   Since different AccountingECAPolicyRules can use different
   accounting mechanisms in different ways, the aggregation is composed 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 number given AccountingMethod is used by a particular
   AccountingECAPolicyRule.

   Similarly, the PolicyControlsAccounting aggregation defines Policy
   Rules to control the configuration of
   security capabilities, while each one aims 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 mitigating the AccountingECAPolicyRule class, called
   (for example) accountingMethodCurrent and accountingMethodSupported,
   to represent the HasAccountingMethod aggregation and its association
   class.

   The former is a specific
   type of network attack.

   Following figure shows string attribute that defines the current accounting
   method used by this AccountingECAPolicyRule, while the latter
   defines a basic structure set of the information model:

             Please view accounting methods, in a fixed-width font such as Courier.

            +-------------------------------------------------+
            |                                                 |
            | +---------------------+    +---------------+    |
            | |Attack mitigation    |    | General Shared|    |
            | |capabilites:         |    | Parameters:   |    |
            | | SYN flood,          |    |               |    |
            | | UDP flood,          |    |               |    |
            | | ICMP flood,         |    |               |    |
            | | IP fragment flood,  |    |               |    |
            | | IPv6 related attacks|    |               |    |
            | | HTTP flood,         |    |               |    |
            | | HTTPS flood,        |    |               |    |
            | | DNS flood,          |    | 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     |
   | DNS amplification, TrafficInspection + A ----------+-------------+ InspectionMethod |
   |   ECAPolicyRule   |\ /          ^           / |                  |
   |                   | SSL DDoS,             |             +------------------+
   +-------------------+             |
                                     |
                        +------------+------------+
                        | TrafficInspectionDetail |
                        +------------+------------+
                                    / \ 0..n
                                     | IP sweep,
                                     | PolicyControlsTrafficInspection
                                     |
                                    / \
                                     A
                                    \ / 0..n
                          +----------+--------------+
                          | ManagementECAPolicyRule |
            | | Port scanning,      |    |               |    |
            | | Ping
                          +-------------------------+

           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 Death,      |    |               |    |
            | | Oversized ICMP      |    |               |    |
            | |                     |    |               |    |
            | | ...                 |    |               |    |
            | |                     |    |               |    |
            | +---------------------+    +---------------+    |
            |                                                 |
            |                            Information model    |
            |                            for attack mitigation|
            |                            control              |
            +-------------------------------------------------+ how the two aggregations
   are used are described below.

   Figure 9. The basic structure 13 defines an aggregation between the
   TrafficInspectionECAPolicyRule and an external class that defines
   one or more traffic inspection mechanisms. This decouples the
   implementation of information 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 attack
                            mitigation control 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 detailed description about content
   and format are specified in the standard interface usrSecEventContent and
   usrSecEventFormat class attributes, respectively.

   An example of the
   general shared parameters for all usrSecEventContent attribute is the security capabilities of this
   category are TBD.

  7. Security Considerations 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 security capability policy purpose of a DeviceSecurityEvent is to represent Events that
   provide information sent from the Device that are important to NSFs should I2NSF
   Security. Information in this Event may be
   protected by the secure communication channel, used as part of a test
   to ensure determine if the
   confidentiality Condition clause in this ECA Policy Rule should
   be evaluated or not. Examples include alarms and integrity. In another side, various device
   statistics (e.g., a type of threshold that was exceeded), which may
   signal the NSFs 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
   security controller can all be faked, 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 lead to undesirable
   results, i.e., security policy leakage from security controller,
   faked security controller sending false information is used
   to mislead specify the
   NSFs. 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 mutual authentication devSecEventType Attribute

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

      0:  unknown
      1:  communications alarm
      2:  quality of attack.  The current mainstream security technologies
   (i.e., TLS, DTLS, IPSEC, X.509 PKI) can 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 employed appropriately 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 above security functionalities.

   In addition, to defend against specifics of the DDoS attack caused Event
   generated by the
   security controller sending too much configuration messages to the
   NSFs, the rate limiting or similar mechanisms should be considered
   in NSF, whether in advance or just in the process of DDoS attack.

  8. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please remove this section before publication.

  9. References

  9.1.                  Normative References

   [RFC2119] Bradner, S., "Key words for use Device. For example, this attribute could contain
   probable cause information in the first array, trend information in RFCs to 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
   the
             Network Configuration Protocol (NETCONF)", RFC 6020,
             October 2010.

   [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
             Used to Form Encoding Rules second array, proposed repair actions in 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 Policy-Based
             Management", RFC 3198, DOI 10.17487/RFC3198,
             November 2001, <http://www.rfc-editor.org/info/rfc3198>.

  9.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-problem-and-use-cases] Hares, S., et.al.,
             "I2NSF Problem Statement the third array, and Use cases", Work
   additional information in Progress,
             February, 2016.

   [I-D.draft-ietf-i2nsf-framework] Lopez, E., et.al., "Framework for
             Interface the fourth array.

B.2.5.  The devSecEventTypeSeverity Attribute

   This is a mandatory non-negative enumerated integer, which is used
   to Network Security Functions", Work specify the perceived severity of the Event generated by this
   Device. Values (which are defined in Progress,
             October, 2016.

   [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface 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
             Network Security Functions (I2NSF) Terminology", Work in
             Progress, April, 2016

   [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J.,
             Halpern, J., Coleman, J., "Generic Policy represent Events that
   are detected by the management system, instead of Events that are
   generated by a user or a device. Information
             Model for Simplified Use in this Event may be
   used as part of Policy Abstractions (SUPA)",
             Work a test to determine if the Condition clause in Progress, June, 2016.

   [I-D.draft-baspez-i2nsf-capabilities-00] Basile C., Lopez D. R., "A
             Model
   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 Security Capabilities for Network Security
             Functions", July 2016

   [I-D.draft-xia-i2nsf-capability-interface-im-06] Xia L., et al.,
             "Information Model 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 Interface to Network Security
             Functions Capability Interface", June 2016

   [Alshaer]  Al Shaer, E. and H. Hamed, "Modeling and management the
   SystemSecurityEvent. The format of
             firewall policies", 2004.

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

   [Bas15]    Basile, C. the content is specified in the
   sysSecEventFormat class attribute, and A. Lioy, "Analysis the type of application-layer
             filtering policies Event is defined
   in the sysSecEventType class attribute. An example of the
   sysSecEventContent attribute is the string "sysadmin3", with application to HTTP", 2015.

   [Cormen]   Cormen, T., "Introduction the
   sysSecEventFormat attribute set to Algorithms", 2009.

   [Lunt]     van Lunteren, J. and T. Engbersen, "Fast and scalable
             packet classification", 2003.

   [Taylor]   Taylor, D. 1 (GUID), and J. Turner, "Scalable packet classification
             using distributed crossproducting 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 field labels", 2004.

  10. Acknowledgments 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 document was prepared using 2-Word-v2.0.template.dot.

Appendix A.

   Six exemplary 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 rules 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 Network Security Capability are
   introduced a period of time).
   Time events signify an individual occurrence, or a time period, in
   which a significant event happened. Information in this Appendix to clarify how to create different kinds Event may be
   used as part of specific ECA policy rules.

   Note that there is a common pattern that defines how these
   ECAPolicyRules operate; test to determine if the Condition clause in 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 Rule should be evaluated or not. Examples include issuing
   an Event at a specific time to indicate that a particular resource
   should not be viewed as simple object containers, accessed, or that different authentication and hence,
   applicable to
   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 wide variety mandatory DateTime attribute, and represents the beginning
   of content. a time period. It also means has a value that has a date and/or a time
   component (as in the
   content 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 function (e.g., how an entity is authenticated, what
   specific traffic is inspected, Java or which particular signature Python libraries). If this is
   applied) 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 defined solely by the set of events, conditions, a mandatory string attribute, and
   actions defines the time zone that are contained by
   this Event occurred in using the particular subclass. format specified in ISO8601.

Appendix C. Network Security Condition Class Definitions

   This enables
   the policy rule, with its aggregated Appendix defines a preliminary set of events, conditions, and
   actions, to be treated as a reusable object.

A.1. AuthenticationECAPolicyRule Class Definition Network Security Condition
   classes, along with their attributes.

C.1.  PacketSecurityCondition

   The purpose of an AuthenticationECAPolicyRule this Class is to define an ECA
   Policy Rule represent packet header information
   that can verify whether an entity has an attribute be used as part of a
   specific value.

   This class does NOT define test to determine if the authentication method used. This is
   because this would effectively "enclose" set of Policy
   Actions in this information within the
   AuthenticationECAPolicyRule. ECA Policy Rule should be executed or not. 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, class
   is abstract, and those other classes would not
   likely be interested in the AuthenticationECAPolicyRule. Second, serves as the
   evolution superclass of new authentication methods should be independent more detailed conditions
   that act on different types of the
   AuthenticationECAPolicyRule; this cannot happen if the
   Authentication class(es) packet formats. Its subclasses are embedded
   shown in Figure 16, and are defined in the
   AuthenticationECAPolicyRule. Hence, this document recommends the following design:
                                                     +----------------+
    +----------------+ 1..n                    1...n sections.

                             +-------------------------+
                             | PacketSecurityCondition |
                             +------------+------------+
                                         / \
                                          |
                                          |
                 +---------+----------+---+-----+----------+
                 |         |          |         |          |
                 |         |          |         |          |
        +--------+-------+ | +--------+-------+ | +--------+-------+
        | PacketSecurity | | | PacketSecurity | | |                |/ \  HasAuthenticationMethod  \| Authentication PacketSecurity |
        | Authentication + A ----------+-----------------+     Method  MACCondition  | | ECAPolicyRule  |\ /          ^                /| | IPv4Condition  | | |                 +----------------+
    +----------------+ IPv6Condition  |
        +----------------+ |
                      +------------+-------------+ +----------------+ | AuthenticationRuleDetail +----------------+
                           |
                      +------------+-------------+
                                  / \ 0..n                    |
                  +--------+-------+   +--------+-------+
                  | PolicyControlsAuthentication  TCPCondition  |
                                  / \
                                   A
                                  \ / 0..n
                        +----------+--------------+   | ManagementECAPolicyRule  UDPCondition  |
                        +-------------------------+
                  +----------------+   +----------------+

   Figure 10.  Modeling Authentication Mechanisms 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 document only class is concrete, and defines the AuthenticationECAPolicyRule; all
   other classes, following attributes.

C.1.1.1.  The pktSecCondMACDest Attribute

   This is a mandatory string attribute, and defines the aggregations, are defined in an external
   model. For completeness, descriptions of how the two aggregations
   are used are below.

   Figure 10 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 aggregation between optional string attribute, and defines the
   AuthenticationECAPolicyRule 802.1Q tag
   value (2 octets long). This defines VLAN membership and an externalAuthenticationMethod
   class (which 802.1p
   priority values.

C.1.1.4.  The pktSecCondMACEtherType Attribute

   This is likely a superclass for different types mandatory string attribute, and defines the EtherType
   field (2 octets long). Values up to and including 1500 indicate the
   size of
   authentication mechanisms). This decouples the implementation payload in octets; values of
   authentication mechanisms from how authentication mechanisms are
   used.

   Since different AuthenticationECAPolicyRules can use different
   authentication mechanisms 1536 and above define
   which protocol is encapsulated in different ways, the aggregation payload of the frame.

C.1.1.5.  The pktSecCondMACTCI Attribute

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

C.1.2.  PacketSecurityIPv4Condition

   The purpose of the association class (i.e., AuthenticationRuleDetail) this Class is to represent packet IPv4 packet header
   information that can be used as part of a test to define how 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 given AuthenticationMethod mandatory string attribute, and defines the IPv4 Source
   Address (32 bits).

C.1.2.2.  The pktSecCondIPv4DestAddr Attribute

   This is used by a
   particular AuthenticationECAPolicyRule.

   Similarly, mandatory string attribute, and defines the PolicyControlsAuthentication aggregation IPv4
   Destination Address (32 bits).

C.1.2.3.  The pktSecCondIPv4ProtocolUsed Attribute

   This is a mandatory string attribute, and defines
   policies to control the configuration protocol used
   in the data portion of the
   AuthenticationRuleDetail association class. IP datagram (8 bits).

C.1.2.4.  The pktSecCondIPv4DSCP Attribute

   This enables the entire
   authentication process to be managed by ECAPolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, is a data model could define two
   attributes for mandatory string attribute, and defines the AuthenticationECAPolicyRule class, called (for
   example) authenticationMethodCurrent Differentiated
   Services Code Point field (6 bits).

C.1.2.5.  The pktSecCondIPv4ECN Attribute

   This is an optional string attribute, and
   authenticationMethodSupported, to represent defines the
   HasAuthenticationMethod aggregation 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 its association class. data) in bytes (16 bits).

C.1.2.7.  The
   former pktSecCondIPv4TTL Attribute

   This is a mandatory string attribute that attribute, and defines the current authentication
   method used by this AuthenticationECAPolicyRule, while the latter
   defines a set of authentication methods, Time To Live
   in the form of an
   authentication capability, which this AuthenticationECAPolicyRule
   can advertise.

A.2. AuthorizationECAPolicyRuleClass Definition seconds (8 bits).

C.1.3.  PacketSecurityIPv6Condition

   The purpose of an AuthorizationECAPolicyRule this Class is to define an 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 represent packet IPv6 packet header
   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 can be independent used as part of the
   AuthorizationECAPolicyRule; this cannot happen a test to determine if the Authorization
   class(es) are embedded
   set of Policy Actions 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 ECA Policy Rule should be executed or
   not. This document only class is concrete, and defines the AuthorizationECAPolicyRule; all other
   classes, following attributes.

C.1.3.1.  The pktSecCondIPv6SrcAddr Attribute

   This is a mandatory string attribute, and the aggregations, are defined in an external model. For
   completeness, descriptions of how the two aggregations are used are
   below.

   Figure 11 defines an aggregation between the
   AuthorizationECAPolicyRule IPv6 Source
   Address (128 bits).

C.1.3.2.  The pktSecCondIPv6DestAddr Attribute

   This is a mandatory string attribute, and an external AuthorizationMethod class
   (which defines the IPv6
   Destination Address (128 bits).

C.1.3.3.  The pktSecCondIPv6DSCP Attribute

   This is likely a superclass for different types mandatory string attribute, and defines the Differentiated
   Services Code Point field (6 bits). It consists of authorization
   mechanisms). This decouples the implementation six most
   significant bits of authorization
   mechanisms from how authorization mechanisms are used.

   Since different AuthorizationECAPolicyRules can use different
   authorization mechanisms the Traffic Class field in different ways, the aggregation is
   realized as an association class. IPv6 header.

C.1.3.4.  The pktSecCondIPv6ECN Attribute

   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 mandatory string attribute, and defines
   policies to control the configuration Explicit
   Congestion Notification field (2 bits). It consists of the AuthorizationRuleDetail
   association class. This enables two least
   significant bits of the entire authorization process to
   be managed by ECAPolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, Traffic Class field in the IPv6 header.

C.1.3.5.  The pktSecCondIPv6FlowLabel Attribute

   This is a data model could define two
   attributes for 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 AuthorizationECAPolicyRule class, called (for
   example) authorizationMethodCurrent
   IPv6 main header fields (20 bits).

C.1.3.6.  The pktSecCondIPv6PayloadLength Attribute

   This is a mandatory string attribute, and authorizationMethodSupported,
   to represent defines the HasAuthorizationMethod aggregation total length
   of the packet (including the fixed and its
   association class. any extension headers, and
   data) in bytes (16 bits).

C.1.3.7.  The former pktSecCondIPv6NextHeader Attribute

   This is a mandatory string attribute that attribute, and defines the
   current authorization method used by this AuthorizationECAPolicyRule,
   while type of the latter defines
   next header (e.g., which extension header to use) (8 bits).

C.1.3.8.  The pktSecCondIPv6HopLimit Attribute

   This is a set of authorization methods, in mandatory string attribute, and defines the form maximum
   number of an authorization capability, which hops that this
   AuthorizationECAPolicyRule packet can advertise.

A.3. AccountingECAPolicyRuleClass Definition traverse (8 bits).

C.1.4.  PacketSecurityTCPCondition

   The purpose of an AccountingECAPolicyRule this Class is to define an ECA Policy
   Rule that can determine which represent packet TCP packet header
   information to collect, and how to
   collect that information, from which set can be used as part of resources for a test to determine if the
   purpose
   set of trend analysis, auditing, billing, Policy Actions in this ECA Policy Rule should be executed or cost allocation
   [RFC2975] [RFC3539].
   not. This class does NOT define is concrete, and defines the accounting method(s) used. following attributes.

C.1.4.1.  The pktSecCondTPCSrcPort Attribute

   This is
   because this would effectively "enclose" this information within a mandatory string attribute, and defines the
   AccountingECAPolicyRule. Source Port
   number (16 bits).

C.1.4.2.  The pktSecCondTPCDestPort Attribute

   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 is a mandatory string attribute, and defines the
   AccountingECAPolicyRule class, Destination
   Port number (16 bits).

C.1.4.3.  The pktSecCondTCPSeqNum Attribute

   This is a mandatory string attribute, and those other classes would not
   likely be interested in defines the AccountingECAPolicyRule. Second, sequence
   number (32 bits).

C.1.4.4.  The pktSecCondTCPFlags Attribute

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

C.1.5.  PacketSecurityUDPCondition

   The purpose of new accounting methods should this Class is to represent packet UDP packet header
   information that can be independent used as part of the
   AccountingECAPolicyRule; this cannot happen a test to determine if the Accounting
   class(es) are embedded
   set of Policy Actions in the AccountingECAPolicyRule. Hence, this
   document recommends ECA Policy Rule should be executed or
   not. This class is concrete, and defines 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 attributes.

C.1.5.1.1.  The pktSecCondUDPSrcPort Attribute

   This document only is a mandatory string attribute, and defines the AccountingECAPolicyRule; all other
   classes, UDP Source
   Port number (16 bits).

C.1.5.1.2.  The pktSecCondUDPDestPort Attribute

   This is a mandatory string attribute, and defines the aggregations, are defined 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 an external model. For
   completeness, descriptions
   bytes of how the two aggregations are used are
   below.

   Figure 12 defines an aggregation between the AccountingECAPolicyRule UDP header and an external AccountingMethod class (which data (16 bits).

C.2.  PacketPayloadSecurityCondition

   The purpose of this Class is likely a superclass
   for different types to represent packet payload data that
   can be used as part of accounting mechanisms). This decouples a test to determine if the
   implementation set of accounting mechanisms from how accounting
   mechanisms are used.

   Since different AccountingECAPolicyRules can use different
   accounting mechanisms Policy
   Actions in this ECA Policy Rule should be executed or not. Examples
   include a specific set of bytes in different ways, the aggregation packet payload.

C.3.  TargetSecurityCondition

   The purpose of this Class is realized
   as an association class. This enables the attributes and methods to represent information about
   different targets of
   the association class this policy (i.e., AccountingRuleDetail) entities to which this
   Policy Rule should be applied), which can be used to
   define how a given AccountingMethod is used by as part of a particular
   AccountingECAPolicyRule.

   Similarly, the PolicyControlsAccounting aggregation defines policies
   test to control determine if the configuration set of Policy Actions in this ECA Policy
   Rule should be executed or not. Examples include whether the AccountingRuleDetail association
   class.
   targeted entities are playing the same role, or whether each
   device is administered by the same set of users, groups, or roles.
   This enables Class has several important subclasses, including:

      a. ServiceSecurityContextCondition is the entire accounting process to superclass for all
         information that can be managed by
   ECAPolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, a used in an ECA Policy Rule that
         specifies data model could define two
   attributes for about the AccountingECAPolicyRule class, called (for
   example) accountingMethodCurrent and accountingMethodSupported, type of service to
   represent be analyzed
         (e.g., the HasAccountingMethod aggregation protocol type and its association
   class. The former port number)
      b. ApplicationSecurityContextCondition is a string attribute that defines the current
   accounting method superclass for all
         information that can be used by this AccountingECAPolicyRule, while the
   latter defines a set of accounting methods, in a ECA Policy Rule that
         specifies data that identifies a particular application
         (including metadata, such as risk level)
      c. DeviceSecurityContextCondition is the form of an
   authorization capability, which this AccountingECAPolicyRule superclass for all
         information that can
   advertise.

A.4. TrafficInspectionECAPolicyRuleClass Definition 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 a TrafficInspectionECAPolicyRule this Class is to define an represent data about the user or
   group referenced in this ECA Policy Rule that, based on a given context, that can determine which
   traffic to examine on which devices, which information to collect
   from those devices, and how be used as part of
   a test to collect that information.

   This class does NOT define determine if the traffic inspection method(s) used.
   This is because this would effectively "enclose" set of Policy Actions in this information
   within ECA Policy
   Rule should be evaluated or not. Examples include the TrafficInspectionECAPolicyRule. This 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 two drawbacks.
   First, other entities that need
   failed to use information from the
   TrafficInspection class(es) could not; they would have login a particular number of times.

C.5.  SecurityContextCondition

   The purpose of this Class is to associate
   with the TrafficInspectionECAPolicyRule class, and those other
   classes would not likely represent security conditions that
   are part of a specific context, which can be interested in the
   TrafficInspectionECAPolicyRule. Second, used as part of a test
   to determine if the evolution set of new traffic
   inspection methods Policy Actions in this ECA Policy Rule
   should be independent evaluated or not. Examples include testing to determine
   if a particular pattern of security-related data have occurred, or
   if the
   TrafficInspectionECAPolicyRule; current session state matches the expected session state.

C.6.  GenericContextSecurityCondition

   The purpose of this cannot happen 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
   TrafficInspection class(es) are embedded set of Policy
   Actions 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 ECA Policy Rule should be evaluated or not.
   Examples include geographic location and temporal information.

Appendix D. Network Security Action Class Definitions

   This document only Appendix defines the TrafficInspectionECAPolicyRule; all
   other a preliminary set of Network Security Action
   classes, and the aggregations, are defined in along with their attributes.

D.1.  IngressAction

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

D.2.  EgressAction

   The purpose of how the two aggregations
   are used are below.

   Figure 13 defines this Class is to represent actions performed on
   packets that exit an aggregation between the
   TrafficInspectionECAPolicyRule NSF. Examples include pass, drop, or mirror
   traffic, signal, and an external TrafficInspection
   class (which is likely a superclass for different types encapsulate.

D.3.  ApplyProfileAction

   The purpose of traffic
   inspection mechanisms). This decouples this Class is to define the implementation application of traffic
   inspection mechanisms from how traffic inspection mechanisms are
   used.

   Since different TrafficInspectionECAPolicyRules can use different
   traffic inspection mechanisms a profile
   to packets to perform content security and/or attack mitigation
   control.

Appendix E. Geometric Model

   The geometric model defined in different ways, the aggregation [Bas12] is
   realized as an association class. This enables summarized here. Note that
   our work has extended the attributes and
   methods work of the association class (i.e., TrafficInspectionDetail) to
   be used [Bas12] to define how a given TrafficInspectionMethod 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 by a
   particular TrafficInspectionECAPolicyRule.

   Similarly, the PolicyControlsTrafficInspection aggregation defines
   policies to control define just the configuration CA part of the TrafficInspectionDetail
   association class. This enables ECA model.

   All the entire traffic inspection
   process 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 managed by ECAPolicyRules.

   Note: a informally written as "enforce confidentiality", "enforce data model MAY choose to collapse this design into a more
   efficient implementation. For example, a
   authentication and integrity", and "enforce confidentiality and data model could define two
   attributes for the TrafficInspectionECAPolicyRule class, called (for
   example) trafficInspectionMethodCurrent
   authentication and
   trafficInspectionMethodSupported, integrity". However, these actions need to be
   instantiated to represent the
   HasTrafficInspectionMethod aggregation technology used. For example, AH-transport mode
   and its association class.
   The former is ESP-transport mode (and combinations thereof) are a string attribute more precise
   definition of channel protection actions.

   Conditions are typed predicates concerning a given selector. A
   selector describes the values that defines a protocol field may take. For
   example, the current traffic
   inspection method used by this TrafficInspectionECAPolicyRule, while IP source selector is the latter defines a set of traffic inspection methods, in all possible IP
   addresses, and it may also refer to the form 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 traffic inspection capability, which this
   TrafficInspectionECAPolicyRule can advertise.

A.5. ApplyProfileECAPolicyRuleClass Definition

   The purpose of an ApplyProfileECAPolicyRule condition is the
   subset of its selector for which it evaluates to define an ECA
   Policy Rule that, based true. A condition
   on a given context, can apply selector matches a particular
   profile packet if the value of the field
   referred to specific traffic. The profile defines by the security
   capabilities for content security control and/or attack mitigation
   control; these will be described selector belongs to the condition.  For instance,
   in sections 4.4 and 4.5,
   respectively.

   This class does NOT define Figure 17 the set conditions are s1 <= S1 (read as s1 subset of Profiles used. This is because
   this would effectively "enclose" this information within the
   ApplyProfileECAPolicyRule. This has two drawbacks. First, other
   entities that need or
   equal to use information from the Profile class(es)
   could not; they would have S1) and s2 <= S2 (s1 of or equal to associate with the
   ApplyProfileECAPolicyRule class, S2), both s1 and those other classes would not
   likely be interested s2
   match the packet x1, while only s2 matches x2.

   To consider conditions in different selectors, the ApplyProfileECAPolicyRule. Second, decision space is
   extended using the
   evolution of new Profile classes should be independent 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
   ApplyProfileECAPolicyRule; this cannot happen if selectors S1, S2,..., Sm (where m is the Profile
   class(es) are embedded 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 ApplyProfileECAPolicyRule. Hence, this
   document recommends decision space is
   extended using the following design:

                                                        +-------------+
       +-------------------+ 1..n                  1..n Cartesian product because distinct selectors
   refer to different fields, possibly from different protocol headers.

        S2 ^ Destination port
           |
           |      x2
           +......o
           |                   |/ \  ProfileApplied        \|      .
           |      .
         --+.............+------------------------------------+
         | ApplyProfile      + A -----------+-------------+   Profile |      .      |   ECAPolicyRule   |\ /           ^            /|                                    |
         s |      .      |                                    |             +-------------+
       +-------------------+
         e |      .      |
                             +------------+---------+            (rectangle)             | ProfileAppliedDetail
         g |
                             +------------+---------+
                                         / \ 0..n      .      |        condition clause (c)        |
         PolicyControlsProfileApplication
         m |      .      |
                                         / \
                                          A
                                         \ / 0..n
                               +----------+--------------+   here the action a is applied     | ManagementECAPolicyRule
         e |
                               +-------------------------+

             Figure 14.  Modeling Profile ApplicationMechanisms

   This document only defines the ApplyProfileECAPolicyRule; all other
   classes, and the aggregations, are defined      .      |                                    |
         n |      .      |             x1=point=packet        |
         t +.............|.............o                      |
         | |      .      |             .                      |
         --+.............+------------------------------------+
           |      .      .             .                      .
           |      .      .             .                      .
     +------------+------+-------------+----------------------+------>
           |             |---- segment = condition in an external model. For
   completeness, descriptions of how the two aggregations are used are
   below. S1 -----|     S1
           +                                                 IP source

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

   Accordingly, the
   ApplyProfileECAPolicyRule and an external Profile class (which condition clause c is
   likely a superclass for different types subset of Profiles). This decouples S:

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

   S represents the implementation totality 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 packets that are individually
   selectable by the
   association class (i.e., ProfileAppliedDetail) security control to be used model when we use it to define
   how a given Profileis used by
   enforce a particular ApplyProfileECAPolicyRule.

   Similarly, the PolicyControlsProfileApplication aggregation defines
   policies to control policy. Unfortunately, not all its subsets are valid
   condition clauses: only hyper-rectangles, or the configuration union of the ProfileAppliedDetail
   association class.
   hyper-rectangles (as they are Cartesian product of conditions),
   are valid. This enables the application is an intrinsic constraint of Profiles to be
   managed the policy
   language, as it specifies rules by ECAPolicyRules.

   Note: a data model MAY choose to collapse this design into a more
   efficient implementation. For example, defining a data model could define two
   attributes condition for the ApplyProfileECAPolicyRuleclass, called (for
   example) profileAppliedCurrent and profileAppliedSupported, to
   represent the ProfileApplied aggregation and its association class.
   The former is a string attribute each
   selector. Languages that defines allow specification of conditions as
   relations over more fields are modeled by the current Profile
   used geometric model as
   more complex geometric shapes determined by this ApplyProfileECAPolicyRule, while the latter defines equations. However,
   the algorithms to compute intersections are much more sophisticated
   than intersection hyper-rectangles. Figure 17 graphically represents
   a
   set of Profiles, condition clause c in a two-dimensional selection space.

   In the form of geometric model, a Profile capability, which this
   ApplyProfileECAPolicyRule can advertise.

A.6. ApplySignatureECAPolicyRuleClass Definition

   The purpose of an ApplySignatureECAPolicyRule 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 define an ECA
   Policy A. Rule that, based on condition clauses match a given context, can determine which
   Signature object (e.g., an anti-virus file, or aURL filtering file,
   or packet (rules
   match a script) to apply to which traffic. The Signature object defines packet), if all 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 conditions forming the set of Signature objects used. This
   is because this would effectively "enclose" this information within clauses match the ApplySignatureECAPolicyRule. This has two drawbacks. First,
   other entities that need to use information from
   packet. In Figure 17, the Signature
   object class(es) could not; they would have to associate rule with condition clause c matches the
   ApplySignatureECAPolicyRule class, and those other classes would
   packet x1 but not
   likely be interested in x2.

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

   The decision criteria for the ApplySignatureECAPolicyRule. Second, 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
   evolution power set of new Signature object classes should be independent rules in R.

   Formally, given a set of rules, the ApplySignatureECAPolicyRule; this cannot happen if resolution strategy maps all the Signature
   object class(es) are embedded
   possible subsets of rules to an action a in A. When no rule matches a
   packet, the ApplySignatureECAPolicyRule.
   Hence, this document recommends security controls may select the following design:

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

           Figure 15.  Modeling Sginature Application Mechanisms

   This document only defines 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 ApplySignatureECAPolicyRule; all
   other classes, creator, and creation
   time.  Formally, every rule ri is associated by means of the aggregations, are defined in an
   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
   model. For completeness, descriptions of how attributes in Xj. However,
   E, e, and all the two aggregations
   are used Xj are below.

   Figure 15 defines an aggregation between determined by the
   ApplySignatureECAPolicyRule and an external Signature object class
   (which resolution strategy used.

   A policy is likely thus a superclass for different types function p: S -> A that connects each point of Signature
   objects). This decouples
   the implementation of signature objects selection space to an action taken from how Signature objects are used.

   Since different ApplySignatureECAPolicyRules can use different
   Signature objects in different ways, the aggregation action set A
   according to the rules in R. By also assuming RS(0)=d (where 0 is realized as
   an association class. This enables
   the attributes empty-set) and methods of RS(ri)=ai, the
   association class (i.e., SignatureAppliedDetail) to policy p can be used to
   define how described as:

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

   Therefore, in the geometric model, a given Signature object policy is used completely defined by a particular
   ApplySignatureECAPolicyRule.

   Similarly,
   the PolicyControlsSignatureApplication aggregation
   defines policies to control 4-tuple (R,RS,E,d): the configuration of rule set R, the
   SignatureAppliedDetail association class. This enables resolution function RS,
   the
   application set E of the Signature object to be managed by policy.

   Note: a data model MAY choose mappings 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 external attributes, and
   signatureAppliedSupported, to represent the SignatureApplied
   aggregation and its association class. The former is a string
   attribute that defines default
   action d.

   Note that, the current Signature object used geometric model also supports ECA paradigms by this
   ApplySignatureECAPolicyRule, while the latter defines a set of
   Signature objects, in the form of a Signature capability, which this
   ApplySignatureECAPolicyRule can advertise. simply
   modeling events like an additional selector.

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

John Strassner
Huawei
Email: John.sc.Strassner@huawei.com

   DaCheng Zhang
   Huawei

   Email: dacheng.zhang@huawei.com

   Kepeng Li
   Alibaba

   Email:  kepeng.lkp@alibaba-inc.com

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

   Antonio Lioy
   Politecnico di Torino
   Corso Duca degli Abruzzi, 34
   Torino, 10129
   Italy
   Email: lioy@polito.it

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

   Edward Lopez
   Fortinet
   899 Kifer Road
   Sunnyvale, CA 94086
   Phone: +1 703 220 0988

   EMail: elopez@fortinet.com

   Nicolas BOUTHORS
   Qosmos

   Email: Nicolas.BOUTHORS@qosmos.com

   Luyuan Fang
   Microsoft
   15590 NE 31st St
   Redmond, WA 98052
   Email: lufang@microsoft.com