--- 1/draft-ietf-i2nsf-capability-01.txt 2018-07-02 04:13:21.859044743 -0700 +++ 2/draft-ietf-i2nsf-capability-02.txt 2018-07-02 04:13:21.907045898 -0700 @@ -1,2713 +1,973 @@ I2NSF L. Xia -Internet-Draft J. Strassner +Internet Draft J. Strassner Intended status: Standard Track Huawei -Expires: October 3, 2018 C. Basile +Expires: January 02, 2019 C. Basile PoliTO D. Lopez TID - April 3, 2018 + July 02, 2018 Information Model of NSFs Capabilities - draft-ietf-i2nsf-capability-01.txt - -Abstract - - This document defines the concept of an NSF (Network Security - Function) Capability, as well as its information model. Capabilities - are a set of features that are available from a managed entity, and - are represented as data that unambiguously characterizes an NSF. - Capabilities enable management entities to determine the set offer - features from available NSFs that will be used, and simplify the - management of NSFs. + draft-ietf-i2nsf-capability-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current - Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." + 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." - This Internet-Draft will expire on October 3, 2018. + 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 January 02, 2019. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in - Section 4.e of the Trust Legal Provisions and are provided - without warranty as described in the Simplified BSD License. - -Table of Contents - - 1. Introduction ................................................... 4 - 2. Conventions used in this document .............................. 5 - 2.1. Acronyms .................................................. 5 - 3. Capability Information Model Design ............................ 6 - 3.1. Design Principles and ECA Policy Model Overview ........... 6 - 3.2. Relation with the External Information Model .............. 8 - 3.3. I2NSF Capability Information Model Theory of Operation ... 10 - 3.3.1. I2NSF Condition Clause Operator Types ............... 11 - 3.3.2 Capability Selection and Usage ...................... 12 - 3.3.3. Capability Algebra ................................. 13 - 3.4. Initial NSFs Capability Categories ....................... 16 - 3.4.1. Network Security Capabilities ....................... 16 - 3.4.2. Content Security Capabilities ....................... 17 - 3.4.3. Attack Mitigation Capabilities ...................... 17 - 4. Information Sub-Model for Network Security Capabilities ....... 18 - 4.1. Information Sub-Model for Network Security ............... 18 - 4.1.1. Network Security Policy Rule Extensions ............. 19 - 4.1.2. Network Security Policy Rule Operation .............. 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 - 4.4. Information Model for Attack Mitigation Capabilities ..... 28 - 5. Security Considerations ....................................... 29 - 6. IANA Considerations ........................................... 29 - 7. Contributors .................................................. 29 - 8. References .................................................... 29 - 8.1. Normative References ..................................... 29 - 8.2. Informative References ................................... 30 - Appendix A. Network Security Capability Policy Rule Definitions .. 32 - A.1. AuthenticationECAPolicyRule Class Definition ............. 32 - A.2. AuthorizationECAPolicyRuleClass Definition ............... 34 - A.3. AccountingECAPolicyRuleClass Definition .................. 35 - A.4. TrafficInspectionECAPolicyRuleClass Definition ........... 37 - A.5. ApplyProfileECAPolicyRuleClass Definition ................ 38 - A.6. ApplySignatureECAPolicyRuleClass Definition .............. 40 - Appendix B. Network Security Event Class Definitions ............. 42 - B.1. UserSecurityEvent Class Description ...................... 42 - B.1.1. The usrSecEventContent Attribute .................... 42 - B.1.2. The usrSecEventFormat Attribute ..................... 42 - B.1.3. The usrSecEventType Attribute ....................... 42 - B.2. DeviceSecurityEvent Class Description .................... 43 - B.2.1. The devSecEventContent Attribute .................... 43 - B.2.2. The devSecEventFormat Attribute ..................... 43 - B.2.3. The devSecEventType Attribute ....................... 44 - B.2.4. The devSecEventTypeInfo[0..n] Attribute ............. 44 - B.2.5. The devSecEventTypeSeverity Attribute ............... 44 + Section 4.e of the Trust Legal Provisions and are provided without + warranty as described in the Simplified BSD License. -Table of Contents (continued) +Abstract - B.3. SystemSecurityEvent Class Description .................... 44 - B.3.1. The sysSecEventContent Attribute .................... 45 - B.3.2. The sysSecEventFormat Attribute ..................... 45 - B.3.3. The sysSecEventType Attribute ....................... 45 - B.4. TimeSecurityEvent Class Description ...................... 45 - B.4.1. The timeSecEventPeriodBegin Attribute ............... 46 - B.4.2. The timeSecEventPeriodEnd Attribute ................. 46 - B.4.3. The timeSecEventTimeZone Attribute .................. 46 - Appendix C. Network Security Condition Class Definitions ......... 47 - C.1. PacketSecurityCondition .................................. 47 - C.1.1. PacketSecurityMACCondition .......................... 47 - C.1.1.1. The pktSecCondMACDest Attribute ................ 47 - C.1.1.2. The pktSecCondMACSrc Attribute ................. 47 - C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48 - C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48 - C.1.1.5. The pktSecCondMACTCI Attribute ................. 48 - C.1.2. PacketSecurityIPv4Condition ......................... 48 - C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48 - C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48 - C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48 - C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48 - C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48 - C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49 - C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49 - C.1.3. PacketSecurityIPv6Condition ......................... 49 - C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49 - C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49 - C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49 - C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49 - C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49 - C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49 - C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50 - C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50 - C.1.4. PacketSecurityTCPCondition .......................... 50 - C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50 - C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50 - C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50 - C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50 - C.1.5. PacketSecurityUDPCondition ....................... 50 - C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50 - C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51 - C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51 - C.2. PacketPayloadSecurityCondition ........................... 51 - C.3. TargetSecurityCondition .................................. 51 - C.4. UserSecurityCondition .................................... 51 - C.5. SecurityContextCondition ................................. 52 - C.6. GenericContextSecurityCondition .......................... 52 + This draft defines the concept of an NSF (Network Security Function) + capability, as well as its information model. Capabilities are a set + of features that are available from a managed entity, and are + represented as data that unambiguously characterizes an NSF. + Capabilities enable management entities to determine the set of + features from available NSFs that will be used, and simplify the + management of NSFs. -Table of Contents (continued) +Table of Contents - Appendix D. Network Security Action Class Definitions ............. 53 - D.1. IngressAction ............................................ 53 - D.2. EgressAction ............................................. 53 - D.3. ApplyProfileAction ....................................... 53 - Appendix E. Geometric Model ...................................... 54 - Authors' Addresses ............................................... 57 + 1. Introduction ................................................. 2 + 2. Conventions used in this document ............................ 3 + 2.1. Acronyms ................................................ 3 + 3. Capability Information Model Design .......................... 4 + 3.1. Design Principles and ECA Policy Model Overview ......... 5 + 3.2. Relation with the External Information Model ............ 8 + 3.3. I2NSF Capability Information Model Theory of Operation .. 9 + 3.3.1. I2NSF Capability Information Model ................ 11 + 3.3.2. The SecurityCapability class ...................... 13 + 3.3.3. I2NSF Condition Clause Operator Types ............. 14 + 3.3.4. Capability Selection and Usage .................... 16 + 3.3.5. Capability Algebra ............................... 17 + 4. IANA Considerations ......................................... 19 + 5. References .................................................. 19 + 5.1. Normative References ................................... 19 + 5.2. Informative References ................................. 20 + 6. Acknowledgments ............................................. 22 1. Introduction The rapid development of virtualized systems requires advanced security protection in various scenarios. Examples include network - devices in an enterprise network, user equipments in a mobile network, - devices in the Internet of Things, or residential access users - [RFC8192]. + devices in an enterprise network, User Equipment in a mobile + network, devices in the Internet of Things, or residential access + users [RFC8192]. NSFs produced by multiple security vendors provide various security - Capabilities to customers. Multiple NSFs can be combined together to + capabilities to customers. Multiple NSFs can be combined together to provide security services over the given network traffic, regardless - of whether the NSFs are implemented as physical or virtual functions. - - Security Capabilities describe the set of network security-related - features that are available to use for security policy enforcement - purposes. Security Capabilities are independent of the actual - security control mechanisms that will implement them. Every NSF - registers the set of Capabilities it offers. Security Capabilities - are a market enabler, providing a way to define customized security - protection by unambiguously describing the security features offered - by a given NSF. Moreover, Security Capabilities enable security - functionality to be described in a vendor-neutral manner. That is, - it is not required to refer to a specific product when designing the - network; rather, the functionality characterized by their - Capabilities are considered. - - According to [RFC8329], there are two types of I2NSF interfaces - available for security policy provisioning: + of whether the NSFs are implemented as physical or virtual + functions. - 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 - between consumers of NSF data and services 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 the security - controller. The design goal of the Consumer-Facing Interface - is to decouple the specification of security services from - their implementations. + Security Capabilities describe the functions that Network Security + Functions (NSFs) are available to provide for security policy + enforcement purposes. Security Capabilities are independent of the + actual security control mechanisms that will implement them. - o Interface between NSFs (e.g., firewall, intrusion prevention, - or anti-virus) and the security controller (NSF-Facing - Interface): The NSF-Facing Interface is used to decouple the - security management scheme from the set of NSFs and their - various implementations for this scheme, and is independent - of how the NSFs are implemented (e.g., run in Virtual - Machines or physical appliances). This document defines an - object-oriented information model for network security, content - security, and attack mitigation Capabilities, along with - associated I2NSF Policy objects. + Every NSF SHOULD be described with the set of capabilities it + offers. 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 or technology when designing the + network; rather, the functions characterized by their capabilities + are considered. Security Capabilities are a market enabler, + providing a way to define customized security protection by + unambiguously describing the security features offered by a given + NSF. This document is organized as follows. Section 2 defines conventions - and acronyms used. Section 3 discusses the design principles for the - I2NSF Capability information model and related policy model objects. - Section 4 defines the structure of the information model, which - describes the policy and capability objects design; details of the - model elements are contained in the appendices. + and acronyms used. Section 3 discusses the design principles for + I2NSF capability information model, the related ECA model, and + provides detailed information model design of I2NSF network security + capability. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. - This document uses terminology defined in - [I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF - scoped terminology. + This document uses terminology defined in [I-D.draft-ietf-i2nsf- + terminology] for security related and I2NSF scoped terminology. 2.1. Acronyms - AAA: Access control, Authorization, Authentication - ACL: Access Control List - (D)DoD: (Distributed) Denial of Service (attack) - ECA: Event-Condition-Action - FMR: First Matching Rule (resolution strategy) - FW: Firewall - GNSF: Generic Network Security Function - HTTP: HyperText Transfer Protocol - I2NSF: Interface to Network Security Functions - IPS: Intrusion Prevention System - LMR: Last Matching Rule (resolution strategy) - MIME: Multipurpose Internet Mail Extensions - NAT: Network Address Translation - NSF: Network Security Function - RPC: Remote Procedure Call - SMA: String Matching Algorithm - URL: Uniform Resource Locator - VPN: Virtual Private Network + I2NSF - Interface to Network Security Functions -3. Information Model Design + NSF - Network Security Function - The starting point of the design of the Capability information model - is the categorization of types of security functions. For instance, - experts agree on what is meant by the terms "IPS", "Anti-Virus", and - "VPN concentrator". Network security experts unequivocally refer to - "packet filters" as stateless devices able to allow or deny packet - forwarding based on various conditions (e.g., source and destination - IP addresses, source and destination ports, and IP protocol type - fields) [Alshaer]. + DNF - Disjunctive Normal Form + 3. Capability Information Model Design + + A Capability Information Model (CapIM) is a formalization of the + functionality that an NSF advertises. This enables the precise + specification of what an NSF can do in terms of security policy + enforcement, so that computer-based tasks can unambiguously refer + to, use, configure, and manage NSFs. Capabilities MUST be defined in + a vendor- and technology-independent manner (e.g., regardless of the + differences among vendors and individual products). + + Humans are able to refer to categories of security controls and + understand each other. For instance, security experts agree on what + is meant by the terms "NAT", "filtering", and "VPN concentrator". + As a further example, network security experts unequivocally refer + to "packet filters" as stateless devices able to allow or deny + packet forwarding based on various conditions (e.g., source and + destination IP addresses, source and destination ports, and IP + protocol type fields) [Alshaer]. However, more information is required in case of other devices, like stateful firewalls or application layer filters. These devices filter packets or communications, but there are differences in the packets and communications that they can categorize and the states - they maintain. Analogous considerations can be applied for channel - protection protocols, where we all understand that they will protect - packets by means of symmetric algorithms whose keys could have been - negotiated with asymmetric cryptography, but they may work at - different layers and support different algorithms and protocols. To - ensure protection, these protocols apply integrity, optionally + they maintain. Humans deal with these differences by asking more + questions to determine the specific category and functionality of + the device. Machines can follow a similar approach, which is + commonly referred to as question-answering [Hirschman] [Galitsky]. + In this context, the CapIM and the derived Data Models provide + important and rich information sources. + + Analogous considerations can be applied for channel protection + protocols, where we all understand that they will protect packets by + means of symmetric algorithms whose keys could have been negotiated + with asymmetric cryptography, but they may work at different layers + and support different algorithms and protocols. To ensure + protection, these protocols apply integrity, optionally confidentiality, anti-reply protections, and authenticate peers. -3.1. Capability Information Model Overview + The CapIM is intended to clarify these ambiguities by providing a + formal description of NSF functionality. The set of functions that + are advertised MAY be restricted according to the privileges of the + user or application that is viewing those functions. I2NSF + Capabilities enable unambiguous specification of the security + capabilities available in a (virtualized) networking environment, + and their automatic processing by means of computer-based + techniques. - This document defines a model of security Capabilities that provides - the foundation for automatic management of NSFs. This includes - enabling the security controller to properly identify and manage - NSFs, and allow NSFs to properly declare their functionalities, so - that they can be used in the correct way. + This includes enabling the security controller to properly identify + and manage NSFs, and allow NSFs to properly declare their + functionality, so that they can be used in the correct way. - Some basic design principles for security Capabilities and the - systems that have to manage them are: + 3.1. Design Principles and ECA Policy Model Overview - o Independence: each security Capability should be an independent + This document defines an information model for representing NSF + capabilities. Some basic design principles for security capabilities + and the systems that manage them are: + + o Independence: each security capability SHOULD be an independent function, with minimum overlap or dependency on other - Capabilities. This enables each security Capability to be - utilized and assembled together freely. More importantly, - changes to a Capability will not affect other Capabilities. - This follows the Single Responsibility Principle - [Martin] [OODSRP]. - o Abstraction: each Capability should be defined in a vendor- - independent manner, and associated to a well-known interface - to provide a standardized ability to describe and report its - processing results. This facilitates multi-vendor + capabilities. This enables each security capability to be + utilized and assembled together freely. More importantly, changes + to one capability SHOULD NOT affect other capabilities. This + follows the Single Responsibility Principle [Martin] [OODSRP]. + + o Abstraction: each capability MUST be defined in a vendor- + independent manner. + + o Advertisement: A dedicated, well-known interface MUST be used to + advertise and register the capabilities of each NSF. This same + interface MUST be used by other I2NSF Components to determine + what Capabilities are currently available to them. + + o Execution: a dedicated, well-known interface MUST be used to + configure and monitor the use of a capability. This provides a + standardized ability to describe its functionality, and report + its processing results. This facilitates multi-vendor interoperability. - o Automation: the system has to discover, negotiate, and update its - security Capabilities automatically (i.e., without human - intervention). These features are useful especially 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 + + 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 + for adding smart services (e.g., refinement, analysis, capability + reasoning, and optimization) to the security scheme employed. + These features are supported by many design patterns, including + the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a + set of Message Exchange Patterns [Hohpe]. + + o Scalability: the management system SHOULD have the capability to scale up/down or scale in/out. Thus, it can meet various performance requirements derived from changeable network traffic - or service requests. In addition, security Capabilities 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. + or service requests. In addition, security capabilities that are + affected by scalability changes SHOULD support reporting + statistics to the security controller to assist its decision on + whether it needs to invoke scaling or not. - 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 offered by the set of NSFs used. The security - controller can compare the requirements of users and applications to - the set of 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 (i.e., the description) of the functions - provided. The security controller may also be able to customize the - functionality of selected NSFs. + Based on the above principles, this document defines a capability + model that enables an NSF to register (and hence advertise) its set + of capabilities that other I2NSF Components can use. These + capabilities MAY have their access control restricted by policy; + this is out of scope for this document. The set of capabilities + provided by a given set of NSFs unambiguously define the security + offered by the set of NSFs used. The security controller can compare + the requirements of users and applications to the set of + capabilities that are currently available in order to choose which + capabilities of which NSFs are needed to meet those requirements. + Note that this choice is independent of vendor, and instead relies + specifically on the capabilities (i.e., the description) of the + functions provided. Furthermore, when an unknown threat (e.g., zero-day exploits and - unknown malware) is reported by an NSF, new Capabilities may be - created, and/or existing Capabilities may be updated (e.g., by - updating its signature and algorithm). This results in enhancing + unknown malware) is reported by an NSF, new capabilities may be + created, and/or existing capabilities may be updated (e.g., by + updating its signature and algorithm). This results in enhancing the existing NSFs (and/or creating new NSFs) to address the new threats. - New Capabilities may be sent to and stored in a centralized - repository, or stored separately in a vendor's local repository. - In either case, a standard interface facilitates the update process. - - Note that most systems cannot dynamically create a new Capability - without human interaction. This is an area for further study. - -3.2. ECA Policy Model Overview + New capabilities may be sent to and stored in a centralized + repository, or stored separately in a vendor's local repository. In + either case, a standard interface facilitates the update process. + This document specifies a metadata model that MAY be used to further + describe and/or prescribe the characteristics and behavior of the + I2NSF capability model. For example, in this case, metadata could be + used to describe the updating of the capability, and prescribe the + particular version that an implementation should use. This initial + version of the model covers and has been validated to describe NSFs + that are designed with a set of capabilities (which covers most of + the existing NSFs). Checking the behavior of the model with systems + that change capabilities dynamically at runtime has been extensively + explored (e.g., impact on automatic registration). - The "Event-Condition-Action" (ECA) policy model is used as the basis - for the design of I2NSF Policy Rules; the definitions of the following - I2NSF policy-related terms are also specified in - [I-D.draft-ietf-i2nsf-terminology]: + The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used + as the basis for the design of the capability model; definitions of + all I2NSF policy-related terms are also defined in [I-D.draft-ietf- + i2nsf-terminology]. The following three terms define the structure + and behavior of an I2NSF imperative policy rule: - o Event: An Event is any important occurrence in time of a change - in the system being managed, and/or in the environment of the - system being managed. When used in the context of I2NSF + o Event: An Event is defined as any important occurrence in time of + a change in the system being managed, and/or in the environment + of the system being managed. When used in the context of I2NSF Policy Rules, it is used to determine whether the Condition - clause of the I2NSF Policy Rule can be evaluated or not. + 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). - Examples of an I2NSF Event include time and user actions (e.g., - logon, logoff, and actions that violate an ACL). o Condition: A condition is defined as a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether or not the set of Actions in that (imperative) I2NSF Policy Rule can be executed or not. Examples of I2NSF Conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF to a desired state. - o Action: An action is used to control and monitor of - flow-based NSFs when the event and condition clauses are - satisfied. NSFs provide security functions by executing various - Actions. Examples of I2NSF Actions include providing intrusion - detection and/or protection, web and flow filtering, and deep - packet inspection for packets and flows. + + o Action: An action is used to control and monitor aspects of flow- + based NSFs when the event and condition clauses are satisfied. + NSFs provide security functions by executing various Actions. + Examples of I2NSF Actions include providing intrusion detection + and/or protection, web and flow filtering, and deep packet + inspection for packets and flows. An I2NSF Policy Rule is made up of three Boolean clauses: an Event - clause, a Condition clause, and an Action clause. A Boolean clause - is a logical statement that evaluates to either TRUE or FALSE. It - may be made up of one or more terms; if more than one term, then a - Boolean clause connects the terms using logical connectives (i.e., - AND, OR, and NOT). It has the following semantics: + clause, a Condition clause, and an Action clause. This structure is + also called an ECA (Event-Condition-Action) Policy Rule. A Boolean + clause is a logical statement that evaluates to either TRUE or + FALSE. It may be made up of one or more terms; if more than one term + is present, then each term in the Boolean clause is combined using + logical connectives (i.e., AND, OR, and NOT). + + An I2NSF ECA Policy Rule has the following semantics: IF is TRUE + IF is TRUE - THEN execute + + THEN execute [constrained by metadata] + END-IF + END-IF Technically, the "Policy Rule" is really a container that aggregates - the above three clauses, as well as metadata. + the above three clauses, as well as metadata. Aggregating metadata + enables business logic to be used to prescribe behavior. For + example, suppose a particular ECA Policy Rule contains three actions + (A1, A2, and A3, in that order). Action A2 has a priority of 10; + actions A1 and A3 have no priority specified. Then, metadata may be + used to restrict the set of actions that can be executed when the + event and condition clauses of this ECA Policy Rule are evaluated to + be TRUE; two examples are: (1) only the first action (A1) is + executed, and then the policy rule returns to its caller, or (2) all + actions are executed, starting with the highest priority. - The above ECA policy model is very general and easily extensible, - and can avoid potential constraints that could limit the - implementation of generic security Capabilities. + The above ECA policy model is very general and easily extensible. -3.3. Relation with the External Information Model + 3.2. Relation with the External Information Model Note: the symbology used from this point forward is taken from section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model]. - The I2NSF NSF-Facing Interface is in charge of selecting and - managing the NSFs using their Capabilities. This is done by using - the following approaches: + The I2NSF NSF-Facing Interface is used to select and manage the NSFs + using their capabilities. This is done using the following approach: - 1) Each NSF registers its Capabilities with the management system - when it "joins", and hence makes its Capabilities available to - the management system; - 2) The security controller selects the set of Capabilities - required to meet the needs of the security service from all - available NSFs that it manages; + 1) Each NSF registers its capabilities with the management system + through a dedicated interface, and hence, makes its capabilities + available to the management system; + + 2) The security controller compares the needs of the security service + with the set of capabilities from all available NSFs that it + manages using the CapIM; + + 3) The security controller uses the CapIM to select the final set of + NSFs to be used; + + 4) The security controller takes the above information and creates or + uses one or more data models from the CapIM to manage the NSFs; - 3) The security controller uses the Capability information model - to match chosen Capabilities to NSFs, independent of vendor; - 4) The security controller takes the above information and - creates or uses one or more data models from the Capability - information model to manage the NSFs; 5) Control and monitoring can then begin. This assumes that an external information model is used to define the concept of an ECA Policy Rule and its components (e.g., Event, - Condition, and Action objects). This enables I2NSF Policy Rules - [I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external + Condition, and Action objects). This enables I2NSF Policy Rules [I- + D.draft-ietf-i2nsf-terminology] to be subclassed from an external information model. - Capabilities are defined as classes (e.g., a set of objects) that - exhibit a common set of characteristics and behavior - [I-D.draft-ietf-supa-generic-policy-info-model]. - - Each Capability is made up of at least one model element (e.g., - attribute, method, or relationship) that differentiates it from all - other objects in the system. Capabilities are, generically, a type - of metadata (i.e., information that describes, and/or prescribes, - the behavior of objects); hence, it is also assumed that an external - information model is used to define metadata (preferably, in the - form of a class hierarchy). Therefore, it is assumed that - Capabilities are subclassed from an external metadata model. - - The Capability sub-model is used for advertising, creating, - selecting, and managing a set of specific security Capabilities - independent of the type and vendor of device that contains the NSF. - That is, the user of the NSF-Facing Interface does not care whether - the NSF is virtualized or hosted in a physical device, who the - vendor of the NSF is, and which set of entities the NSF is - communicating with (e.g., a firewall or an IPS). Instead, the user - only cares about the set of Capabilities that the NSF has, such as - packet filtering or deep packet inspection. The overall structure - is illustrated in the figure below: - - +-------------------------+ 0..n 0..n +---------------+ - | |/ \ \| External | - | External ECA Info Model + A ----------------+ Metadata | - | |\ / Aggregates /| Info Model | - +-----------+------------+ Metadata +-------+-------+ - | / \ - | | - / \ | - Subclasses derived for I2NSF +-----+------+ - Security Policies | Capability | - | Sub-Model | - +------------+ - - Figure 1. The Overall I2NSF Information Model Design - - This draft defines a set of extensions to a generic, external, ECA - Policy Model to represent various NSF ECA Security Policy Rules. It - also defines the Capability Sub-Model; this enables ECA Policy - Rules to control which Capabilities are seen by which actors, and - used by the I2NSF system. Finally, it places requirements on what - type of extensions are required to the generic, external, ECA - information model and metadata models, in order to manage the - lifecycle of I2NSF Capabilities. - - Both of the external models shown in Figure 1 could, but do not have - to, be based on the SUPA information model - [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in - the Capability Sub-Model will inherit the AggregatesMetadata - aggregation from the External Metadata Information Model. - - The external ECA Information Model supplies at least one set of classes - that represent a generic ECA Policy Rule, and a set of classes that - represent Events, Conditions, and Actions that can be aggregated by - the generic ECA Policy Rule. This enables I2NSF to reuse this - generic model for different purposes, as well as refine it (i.e., - create new subclasses, or add attributes and relationships) to - represent I2NSF-specific concepts. + The external ECA Information Model supplies at least a set of + objects that represent a generic ECA Policy Rule, and a set of + objects that represent Events, Conditions, and Actions that can be + aggregated by the generic ECA Policy Rule. This enables appropriate + I2NSF Components to reuse this generic model for different purposes, + as well as specialize it (i.e., create new model objects) to + represent concepts that are specific to I2NSF and/or an application + that is using I2NSF. - It is assumed that the external ECA Information Model has the - ability to aggregate metadata. Capabilities are then sub-classed - from an appropriate class in the external Metadata Information Model; - this enables the ECA objects to use the existing aggregation between - them and Metadata to add Metadata to appropriate ECA objects. + It is assumed that the external ECA Information Model also has the + ability to aggregate metadata. This enables metadata to be used to + prescribe and/or describe characteristics and behavior of the ECA + Policy Rule. Specifically, Capabilities are subclassed from this + external metadata model. If the desired Capabilities are already + defined in the CapIM, then no further action is necessary. + Otherwise, new Capabilities SHOULD be defined either by defining new + classes that can wrap existing classes using the decorator pattern + [Gamma] or by another mechanism (e.g., through subclassing); the + parent class of the new Capability SHOULD be either an existing + CapIM metadata class or a class defined in the external metadata + information model. In either case, the ECA objects can use the + existing aggregation between them and the Metadata class to add + metadata to appropriate ECA objects. Detailed descriptions of each portion of the information model are given in the following sections. -3.4. I2NSF Capability Information Model: Theory of Operation + 3.3. I2NSF Capability Information Model Theory of Operation Capabilities are typically used to represent NSF functions that can be invoked. Capabilities are objects, and hence, can be used in the event, condition, and/or action clauses of an I2NSF ECA Policy Rule. - The I2NSF Capability information model refines a predefined metadata - model; the application of I2NSF Capabilities is done by refining a - predefined ECA Policy Rule information model that defines how to - use, manage, or otherwise manipulate a set of Capabilities. In this - approach, an I2NSF Policy Rule is a container that is made up of - three clauses: an event clause, a condition clause, and an action - clause. When the I2NSF policy engine receives a set of events, it - matches those events to events in active ECA Policy Rules. If the - event matches, then this triggers the evaluation of the condition - clause of the matched I2NSF Policy Rule. The condition clause is - then evaluated; if it matches, then the set of actions in the - matched I2NSF Policy Rule MAY be executed. + + The I2NSF CapIM refines a predefined (and external) metadata model; + the application of I2NSF Capabilities is done by refining a + predefined (and external) ECA Policy Rule information model that + defines how to use, manage, or otherwise manipulate a set of + capabilities. In this approach, an I2NSF Policy Rule is a container + that is made up of three clauses: an event clause, a condition + clause, and an action clause. When the I2NSF policy engine receives + a set of events, it matches those events to events in active ECA + Policy Rules. If the event matches, then this triggers the + evaluation of the condition clause of the matched I2NSF Policy Rule. + The condition clause is then evaluated; if it matches, then the set + of actions in the matched I2NSF Policy Rule MAY be executed. The + operation of each of these clauses MAY be affected by metadata that + is aggregated by either the ECA Policy Rule and/or by each clause, + as well as the selected resolution strategy. + + Condition clauses are logical formulas that combine one or more + conditions that evaluate to a Boolean (i.e., true or false) result. + The values in a condition clause are built on values received or + owned by the NSF. For instance, the condition clause 'ip source == + 1.2.3.4' is true when the IP address is equal to 1.2.3.4. Two or + more conditions require a formal mechanism to represent how to + operate on each condition to produce a result. For the purposes of + this document, every condition clause MUST be expressed in either + conjunctive or disjunctive normal form. Informally, conjunctive + normal form expresses a clause as a set of sub-clauses that are + logically ANDed together, where each sub-clause contains only terms + that use OR and/or NOT operators). Similarly, disjunctive normal + form is a set of sub-clauses that are logically ORed together, where + each sub-clause contains only terms that use AND and/or NOT + operators. This document defines additional important extensions to both the external ECA Policy Rule model and the external Metadata model that - are used by the I2NSF Information Model; examples include - resolution strategy, external data, and default action. All these - extensions come from the geometric model defined in [Bas12]. A more - detailed description is provided in Appendix E; a summary of the - important points follows. + are used by the I2NSF CapIM; examples include resolution strategy, + external data, and default actions. All these extensions come from + the geometric model defined in [Bas12]. A more detailed description + is provided in Appendix E; a summary of the important points of this + geometric model follows. Formally, given a set of actions in an I2NSF Policy Rule, the resolution strategy maps all the possible subsets of actions to an - outcome. In other words, the resolution strategy is included in the - I2NSF Policy Rule to decide how to evaluate all the actions in a - particular I2NSF Policy Rule. This is then extended to include all - possible I2NSF Policy Rules that can be applied in a particular - scenario. Hence, the final action set from all I2NSF Policy Rules - is deduced. + outcome. In other words, the resolution strategy is included in an + I2NSF Policy to decide how to evaluate all the actions from the + matching I2NSF Policy Rule. - Some concrete examples of resolution strategy are the First Matching - Rule (FMR) or Last Matching Rule (LMR) resolution strategies. When - no rule matches a packet, the NSFs may select a default action, if - they support one. + Some concrete examples of resolution strategy are: + + o First Matching Rule (FMR) + + o Last Matching Rule (LMR) + + o Prioritized Matching Rule (PMR) with Errors (PMRE) + + o Prioritized Matching Rule with No Errors (PMRN) + + In the above, a PMR strategy is defined as follows: + + 1. Order all actions by their Priority (highest is first, no + priority is last); actions that have the same priority may be + appear in any order in their relative location. + + 2. For PMRE: if any action fails to execute properly, temporarily + stop execution of all actions. Invoke the error handler of the + failed action. If the error handler is able to recover from the + error, then continue execution of any remaining actions; else, + terminate execution of the ECA Policy Rule. + + 3. For PMRN: if any action fails to execute properly, stop + execution of all actions. Invoke the error handler of the failed + action, but regardless of the result, execution of the ECA + Policy Rule MUST be terminated. + + Regardless of the resolution strategy, when no rule matches a + packet, a default action MAY be executed. Resolution strategies may use, besides intrinsic rule data (i.e., event, condition, and action clauses), "external data" associated to each rule, such as priority, identity of the creator, and creation time. Two examples of this are attaching metadata to the policy action and/or policy rule, and associating the policy rule with another class to convey such information. -3.4.1. I2NSF Condition Clause Operator Types + 3.3.1. I2NSF Capability Information Model + + Figure 1 below shows one example of an external model. This is a + simplified version of the MEF Policy model [PDO]. For our purposes: + + o MCMPolicyObject is an abstract class, and is derived from + MCMManagedEntity [MCM] + + o MCMPolicyStructure is an abstract superclass for building + different types of Policy Rules (currently, for I2NSF, only + imperative (i.e., ECA) Policy Rules are considered) + + o An I2NSFECAPolicyRule could be subclassed from MCMECAPolicyRule + + o I2NSF Events, Conditions, and Actions could be subclasses from + MCMPolicyEvent, MCMPolicyCondition, and MCMPolicyAction + + o MCMMetaData is aggregated by MCMEntity, which is the superclass + of MCMManagedEntity. So all Policy objects may aggregate + MCMMetaData + +------------------------+ + +---------------+ |HasPolicyStructure | + |MCMPolicyObject| |ComponentDecoratorDetail| + +-------A-------+ +---------------------*--+ + | * + | * + +---------------+----------------+ * + | | * ++-------+----------+ +----------+----------------+1..* * +|MCMPolicyStructure| |MCMPolicyStructureComponent|<------*+ ++--------A---------+ +-----------A---------------+ | + | | | + | +------------+--------+ | + | | | 0..1 ^ + +-------+--------+ +-------+-------+ +-----------+---------------V+ + |MCMECAPolicyRule| |MCMPolicyClause| |MCMPolicyClauseComponent | + +----------------+ +---------------+ |Decorator | + +---------------A------------+ + | + | + +--------+---------+ + |MCMPolicyComponent| + +--------A---------+ + | + | + +--------------------+---------------+----+ + +-------+------+ +---------+--------+ +--------+------+ + |MCMPolicyEvent| |MCMPolicyCondition| |MCMPolicyAction| + +--------------+ +------------------+ +---------------+ + + Figure 1 Exemplary External Information Model (from the MEF) + + The CapIM model uses the Decorator Pattern [Gamma]. The decorator + pattern enables a base object to be "wrapped" by zero or more + decorator objects. The Decorator MAY attach additional + characteristics and behavior, in the form of attributes at runtime + in a transparent manner without requiring recompilation and/or + redeployment. This is done by using composition instead of + inheritance. Objects can "wrap" (more formally, extend the interface + of) an object. In essence, a new object can be built out of pre- + existing objects. + + The Decorator Pattern is applied to allow NSF instances to aggregate + I2NSFSecurityCapability instances. By means of this aggregation, an + NSF can be associated to the functions it provides in terms of + security policy enforcement, both at specification time (i.e., when + a vendor provides a new NSF), statically, when a NSF is added to a + (virtualized) networking environment, and dynamically, during + network operations. Figure 2 shows an NSF aggregating zero or more + SecurityCapabilities. This may be thought of as an NSF possessing + (or defining) zero or more Security Capabilities. This "possession" + (or "definition") is represented in UML as an aggregated, called + HasSecurityCapability. The hasSecurityCapabilityDetail is an + association class that allows NSF instances to aggregate + I2NSFSecurityCapability instances. An NSF MAY be described by 0 or + more SecurityCapabilities. + + Since there can be many types of NSF that have many different types + of I2NSFSecurityCapabilities, the definition of a SecurityCapability + must be done using the context of an NSF. This is realized by an + association class in UML. HasSecurityCapabilityDetail is an + association class. This yields the following design: + + +-----+0..n 0..n+--------------------+ + | |/ \ HasSecurityCapability | | + | NSF | A ----------+----------------+ SecurityCapability | + | |\ / ^ | | + +-----+ | +--------------------+ + | + +-------------+---------------+ + | HasSecurityCapabilityDetail | + + ----------------------------+ + + Figure 2 Defining SecurityCapabilities of an NSF + + This enables the HasSecurityCapabilityDetail association class to be + the target of a Policy Rule. That is, the + HasSecurityCapabilityDetail class has attributes and methods that + define which I2NSFSecurityCapabilities of this NSF are visible and + can be used [MCM]. + + 3.3.2. The SecurityCapability class + + The SecurityCapability class defines the concept of metadata that + define security-related capabilities. It is subclassed from an + appropriate class of an external metadata information + model.Subclasses of the SecurityCapability class can be used to + answer the following questions: + + o What are the events that are caught by the NSF to trigger the + condition clause evaluation (Event subclass)? + + o What kind of condition clauses can be specified on the NSF to + define valid rules? This question splits into two questions: + (1) what are the conditions that can be specified (Condition + subclass), and (2) how to build a valid condition clause from a + set of individual conditions (ClauseEvaluation class). + + o What are the actions that the NSF can enforce (Action class)? + + o How to define a correct policy on the NSF? + + 3.3.3. I2NSF Condition Clause Operator Types After having analyzed the literature and some existing NSFs, the types of selectors are categorized as exact-match, range-based, regex-based, and custom-match [Bas15][Lunt]. Exact-match selectors are (unstructured) sets: elements can only be - checked for equality, as no order is defined on them. As an example, - the protocol type field of the IP header is an unordered set of - integer values associated to protocols. The assigned protocol - numbers are maintained by the IANA (http://www.iana.org/assignments/ - protocol-numbers/protocol-numbers.xhtml). + checked for equality, as no order is defined on them. As an + example, the protocol type field of the IP header is an unordered + set of integer values associated to protocols. The assigned protocol + numbers are maintained by the IANA + (http://www.iana.org/assignments/protocol-numbers/protocol- + numbers.xhtml). In this selector, it is only meaningful to specify condition clauses - that use either the "equals" or "not equals" operators: + that use either the "equals" or "not equals operators": proto = tcp, udp (protocol type field equals to TCP or UDP) + proto != tcp (protocol type field different from TCP) - No other operators are allowed on exact-match selectors. For example, - the following is an invalid condition clause, even if protocol types - map to integers: + No other operators are allowed on exact-match selectors. For + example, the following is an invalid condition clause, even if + protocol types map to integers: proto < 62 (invalid condition) Range-based selectors are ordered sets where it is possible to naturally specify ranges as they can be easily mapped to integers. - As an example, the ports in the TCP protocol may be represented with - a range-based selector (e.g., 1024-65535). As another example, the + As an example, the ports in the TCP protocol may be represented + using a range-based selector (e.g., 1024-65535). For example, the following are examples of valid condition clauses: source_port = 80 + source_port < 1024 + source_port < 30000 && source_port >= 1024 We include, in range-based selectors, the category of selectors that have been defined by Al-Shaer et al. as "prefix-match" [Alshaer]. These selectors allow the specification of ranges of values by means of simple regular expressions. The typical case is the IP address - selector (e.g., 10.10.1.*). - - There is no need to distinguish between prefix match and range-based - selectors; for example, the address range "10.10.1.*" maps to - "[10.10.1.0,10.10.1.255]". + selector (e.g., 10.10.1.*). There is no need to distinguish between + prefix match and range-based selectors as 10.10.1.* easily maps to + [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 application - layer, where data are often represented as strings of text. The - regex-based selector type also includes string-based selectors, where - matching is evaluated using string matching algorithms (SMA) - [Cormen]. Indeed, for our purposes, string matching can be mapped to - regular expressions, even if 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 (e.g., dstdom_regex). + Another category of selector types includes the regex-based + selectors, where the matching is performed by using regular + expressions. This selector type is used frequently at the + application layer, where data are often represented as strings of + text. The regex-based selector type also includes string-based + selectors, where matching is evaluated using string matching + algorithms (SMA) [Cormen]. Indeed, for our purposes, string matching + can be mapped to regular expressions, even if 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 (e.g., + dstdom_regex). As an example, the condition clause: - "URL = *.website.*" + URL = *.website.* matches all the URLs that contain a subdomain named website and the ones whose path contain the string ".website.". As another example, the condition clause: - "MIME_type = video/*" + MIME_type = video/* matches all MIME objects whose type is video. Finally, the idea of a custom check selector is introduced. For instance, malware analysis can look for specific patterns, and returns a Boolean value if the pattern is found or not. In order to be properly used by high-level policy-based processing systems (such as reasoning systems 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 next versions of the draft. Some examples are already present in Section 6. -3.4.2. Capability Selection and Usage + 3.3.4. Capability Selection and Usage Capability selection and usage are based on the set of security traffic classification and action features that an NSF provides; - these are defined by the Capability model. If the NSF has the + these are defined by the capability model. If the NSF has the classification features needed to identify the packets/flows - required by a policy, and can enforce the needed actions, then - that particular NSF is capable of enforcing the policy. + required by a policy, and 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 administrators need to know when they have to generate configurations, like the available resolution strategies and the possibility to set default actions. - The Capability information model can be used for two purposes: + The capability information model can be used for two purposes: describing the features provided by generic security functions, and describing the features provided by specific products. The term Generic Network Security Function (GNSF) refers to the classes of security functions that are known by a particular system. The idea is to have generic components whose behavior is well understood, so that the generic component can be used even if it has some vendor- specific functions. These generic functions represent a point of interoperability, and can be provided by any product that offers the - required Capabilities. GNSF examples include packet filter, URL + 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 algebra to define the - information model of Capability registration. This associates - NSFs to Capabilities, and checks whether an NSF has the - Capabilities needed to enforce policies. + The next section will introduce the algebra to compose the + information model of capability registration, defined to associate + NSFs to capabilities and to check whether a NSF has the capabilities + needed to enforce policies. -3.4.3. Capability Algebra +3.3.5. Capability Algebra We introduce a Capability Algebra to ensure that the actions of - different policy rules do not conflict with each other. + different policy rules do not conflict with each. - Formally, two I2NSF Policy Actions conflict with each other if: + Formally, two I2NSF Policy Rules conflict with each other if: o the event clauses of each evaluate to TRUE + o the condition clauses of each evaluate to TRUE + o the action clauses affect the same object in different ways - For example, if we have two Policies: + For example, if we have two Policy Rules in the same Policy: - P1: During 8am-6pm, if traffic is external, then run through FW - P2: During 7am-8pm, conduct anti-malware investigation + R1: During 8am-6pm, if traffic is external, then run through FW + R2: During 7am-8pm, conduct anti-malware investigation - There is no conflict between P1 and P2, since the actions are - different. However, consider these two policies: + There is no conflict between R1 and R2, since the actions are + different. However, consider these two rules: - P3: During 8am-6pm, John gets GoldService - P4: During 10am-4pm, FTP from all users gets BronzeService + R3: During 8am-6pm, John gets GoldService + R4: During 10am-4pm, FTP from all users gets BronzeService - P3 and P4 are now in conflict, because between the hours of 10am and - 4pm, the actions of P3 and P4 are different and apply to the same + R3 and R4 are now in conflict, between the hours of 10am and 4pm, + because the actions of R3 and R4 are different and apply to the same user (i.e., John). Let us define the concept of a "matched" policy rule as one in which - its event and condition clauses are both evaluate to true. This enables - the actions in this policy rule to be evaluated. Then, the - conflict matrix is defined by a 5-tuple {Ac, Cc, Ec, RSc, Dc}, - where: + its event and condition clauses both evaluate to true. Then, the + behavior of the Policy Rule, as specified by the CapIM, is defined + by a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where: o Ac is the set of Actions currently available from the NSF; - o Cc is the set of Conditions currently available from the NSF; - o Ec is the set of Events the NSF is able to respond to. - Therefore, the event clause of an I2NSF ECA Policy Rule that is - written for an NSF will only allow a set of designated events - in Ec. For compatibility purposes, we will assume that if Ec={} - (that is, Ec is empty), the NSF only accepts CA policies. + + o Cc is the set of Capabilities currently available from the NSF; + + o Ec is the set of Events that an NSF can catch. Note that for NSF + (e.g., a packet filter) that are not able to react to events, + this set will be empty; + o RSc is the set of Resolution Strategies that can be used to specify how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF; - o Dc defines the notion of a Default action that can be used to - specify a predefined action when no other alternative action - was matched by the currently executing I2NSF Policy Rule. An - analogy is the use of a default statement in a C switch - statement. This field of the Capability algebra can take the - following values: - - An explicit action (that has been predefined; typically, - this means that it is fixed and not configurable), denoted - as Dc ={a}. In this case, the NSF will always use the - action as as the default action. - - A set of explicit actions, denoted Dc={a1,a2, ...}; - typically, this means that any **one** action can be used - as the default action. This enables the policy writer to - choose one of a predefined set of actions {a1, a2, ...} to - serve as the 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 can be - freely selected by the policy editor from the actions Ac - available at the NSF. In other words, one of the actions - Ac may be selected by the policy writer to act as the - default action. - - No default action, denoted as Dc={}, for cases where the - NSF does not allow the explicit selection of a default - action. - -*** Note to WG: please review the following paragraphs -* -* Interesting Capability concepts that could be considered for a next -* version of the Capability model and algebra include: -* -* o Event clause representation (e.g., conjunctive vs. disjunctive -* normal form for Boolean clauses) -* o Event clause evaluation function, which would enable more -* complex expressions than simple Boolean expressions to 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 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 use of metadata, which can be associated to both an I2NSF -* Policy Rule as well as objects contained in the I2NSF Policy -* Rule (e.g., an action), that describe the object and/or -* prescribe behavior. Descriptive examples include adding -* authorship information and defining a time period when an NSF -* can be used to be defined; prescriptive examples include -* defining rule priorities and/or ordering. -* -* Given two sets of Capabilities, denoted as -* -* cap1=(Ac1,Cc1,Ec1,RSc1,Dc1) and -* cap2=(Ac2,Cc2,Ec2,RSc2,Dc2), -* -* two set operations are defined for manipulating Capabilities: -* -* o Capability addition: -* cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1} -* o Capability subtraction: -* cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1} -* -* In the above formulae, "U" is the set union operator and "\" is the -* set difference operator. - -* The addition and subtraction of Capabilities are defined as the -* addition (set union) and subtraction (set difference) of both the -* Capabilities and their associated actions. Note that **only** the -* leftmost (in this case, the first matched policy rule) Resolution -* Strategy and Default Action are used. -* -* Note: actions, events, and conditions are **symmetric**. This means -* that when two matched policy rules are merged, the resultant actions -* and Capabilities are defined as the union of each individual matched -* policy rule. However, both resolution strategies and default actions -* are **asymmetric** (meaning that in general, they can **not** be -* combined, as one has to be chosen). In order to simplify this, we -* have chosen that the **leftmost** resolution strategy and the -* **leftmost** default action are chosen. This enables the developer -* to view the leftmost matched rule as the "base" to which other -* elements are added. -* -* As an example, assume that a packet filter Capability, Cpf, is -* defined. Further, assume that a second Capability, called Ctime, -* exists, and that it defines time-based conditions. Suppose we need -* to construct a new generic packet filter, Cpfgen, that adds -* time-based conditions to Cpf. -* -* -* Conceptually, this is simply the addition of the Cpf and Ctime -* Capabilities, as 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 5-tuple that is logically ANDed with a -* time period, and uses FMR; it provides A1 as a default action, and -* it does not react to events. - -* Note: We are investigating, for a next revision of this draft, the -* possibility to add further operations that do not follow the -* symmetric vs. asymmetric properties presented in the previous note. -* We are looking for use cases that may justify the complexity added -* by the availability of more Capability manipulation operations. -* -*** End Note to WG - -3.5. Initial NSFs Capability Categories - - The following subsections define three common categories of - Capabilities: network security, content security, and attack - mitigation. Future versions of this document may expand both the - number of categories as well as the types of Capabilities within a - given category. - -3.5.1. Network Security Capabilities - - Network security is a category that describes the inspecting and - processing of network traffic based on the use of pre-defined - security policies. - - The inspecting portion may be thought of as a packet-processing - engine that inspects packets traversing networks, either directly or - in the context of flows with which the packet is associated. From - the perspective of packet-processing, implementations differ in the - depths of packet headers and/or payloads they can inspect, the - various flow and context states they can maintain, and the actions - that can be applied to the packets or flows. - -3.5.2. Content Security Capabilities - - Content security is another category of security Capabilities - applied to the application layer. Through analyzing traffic contents - carried in, for example, the application layer, content security - Capabilities can be used to identify various security functions that - are required. These include defending against intrusion, inspecting - for viruses, filtering malicious URL or junk email, blocking illegal - web access, or preventing malicious data retrieval. - - Generally, each type of threat in the content security category has - a set of unique characteristics, and requires handling using a set - of methods that are specific to that type of content. Thus, these - Capabilities will be characterized by their own content-specific - security functions. - -3.5.3. Attack Mitigation Capabilities - - This category of security Capabilities is used to detect and mitigate - various types of network attacks. Today's common network attacks can - be classified into the following sets: - - o DDoS attacks: - - Network layer DDoS attacks: Examples include SYN flood, UDP - flood, ICMP flood, IP fragment flood, IPv6 Routing header - attack, and IPv6 duplicate address detection attack; - - Application layer DDoS attacks: Examples include HTTP flood, - https flood, cache-bypass HTTP floods, WordPress XML RPC - floods, and ssl DDoS. - o Single-packet attacks: - - Scanning and sniffing attacks: IP sweep, port scanning, etc. - - malformed packet attacks: Ping of Death, Teardrop, etc. - - special packet attacks: Oversized ICMP, Tracert, IP timestamp - option packets, etc. - - Each type of network attack has its own network behaviors and - packet/flow characteristics. Therefore, each type of attack needs a - special security function, which is advertised as a set of - Capabilities, for detection and mitigation. The implementation and - management of this category of security Capabilities of attack - mitigation control is very similar to the content security control - category. A standard interface, through which the security controller - can choose and customize the given security Capabilities according to - specific requirements, is essential. - -4. Information Sub-Model for Network Security Capabilities - - The purpose of the Capability Information Sub-Model is to define the - concept of a Capability, and enable Capabilities to be aggregated to - appropriate objects. The following sections present the Network - Security, Content Security, and Attack Mitigation Capability - sub-models. - -4.1. Information Sub-Model for Network Security - - The purpose of the Network Security Information Sub-Model is to - define how network traffic is defined, and determine if one or more - network security features need to be applied to the traffic or not. - Its basic structure is shown in the following figure: - - +---------------------+ - +---------------+ 1..n 1..n | | - | |/ \ \| A Common Superclass | - | ECAPolicyRule + A -------------+ for ECA Objects | - | |\ / /| | - +-------+-------+ +---------+-----------+ - / \ / \ - | | - | | - (subclasses to define Network (subclasses of Event, - Security ECA Policy Rules Condition, and Action Objects - extensibly, so that other for Network Security - Policy Rules can be added) Policy Rules) - - Figure 2. Network Security Information Sub-Model Overview - - In the above figure, the ECAPolicyRule, along with the Event, - Condition, and Action Objects, are defined in the external ECA - Information Model. The Network Security Sub-Model extends all of - these objects in order to define security-specific ECA Policy Rules, - as well as extensions to the (generic) Event, Condition, and - Action objects. - - An I2NSF Policy Rule is a special type of Policy Rule that is in - event-condition-action (ECA) form. It consists of the Policy Rule, - components of a Policy Rule (e.g., events, conditions, actions, and - some extensions like resolution policy, default action and external - data), and optionally, metadata. It can be applied to both uni- and - bi-directional traffic across the NSF. - - Each rule is triggered by one or more events. If the set of events - evaluates to true, then a set of conditions are evaluated and, if - true, then enable a set of actions to be executed. This takes the - following conceptual form: - - IF is TRUE - IF is TRUE - THEN execute - END-IF - END-IF - - In the above example, the Event, Condition, and Action portions of a - Policy Rule are all **Boolean Clauses**. Hence, they can contain - combinations of terms connected by the three logical connectives - operators (i.e., AND, OR, NOT). An example is: - - ((SLA==GOLD) AND ((numPackets>burstRate) OR NOT(bwAvail. -Appendix E. Geometric Model + [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, + R., and J. Jeong, "Interface to Network Security Functions + (I2NSF): Problem Statement and Use Cases", RFC 8192, + DOI 10.17487/RFC8192, July 2017, + . - The geometric model defined in [Bas12] is summarized here. Note that - our work has extended the work of [Bas12] to model ECA Policy Rules, - instead of just condition-action Policy Rules. However, the - geometric model in this Appendix is simplified in this version of - this I-D, and is used to define just the CA part of the ECA model. + [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, February 2018. - All the actions available to the security function are well known - and organized in an action set A. + 5.2. Informative References - For filtering controls, the enforceable actions are either Allow or - Deny, thus A={Allow,Deny}. For channel protection controls, they may - be informally written as "enforce confidentiality", "enforce data - authentication and integrity", and "enforce confidentiality and data - authentication and integrity". However, these actions need to be - instantiated to the technology used. For example, AH-transport mode - and ESP-transport mode (and combinations thereof) are a more precise - definition of channel protection actions. + [INCITS359 RBAC] NIST/INCITS, "American National Standard for + Information Technology - Role Based Access Control", + INCITS 359, April, 2003 - Conditions are typed predicates concerning a given selector. A - selector describes the values that a protocol field may take. For - example, the IP source selector is the set of all possible IP - addresses, and it may also refer to the part of the packet where the - values come from (e.g., the IP source selector refers to the IP - source field in the IP header). Geometrically, a condition is the - subset of its selector for which it evaluates to true. A condition - on a given selector matches a packet if the value of the field - referred to by the selector belongs to the condition. For instance, - in Figure 17 the conditions are s1 <= S1 (read as s1 subset of or - equal to S1) and s2 <= S2 (s2 subset of or equal to S2), both s1 and - s2 match the packet x1, while only s2 matches x2. + [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to + Network Security Functions (I2NSF) Terminology", Work in + Progress, January, 2018 - To consider conditions in different selectors, the decision space is - extended using the Cartesian product because distinct selectors - refer to different fields, possibly from different protocol headers. - Hence, given a policy-enabled element that allows the definition of - conditions on the selectors S1, S2,..., Sm (where m is the number - of Selectors available at the security control we want to model), - its selection space is: + [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., + Halpern, J., Coleman, J., "Generic Policy Information + Model for Simplified Use of Policy Abstractions (SUPA)", + Work in Progress, May, 2017. - S=S1 X S2 X ... X Sm + [Alshaer] Al Shaer, E. and H. Hamed, "Modeling and management of + firewall policies", 2004. - To consider conditions in different selectors, the decision space is - extended using the Cartesian product because distinct selectors - refer to different fields, possibly from different protocol headers. + [Bas12] Basile, C., Cappadonia, A., and A. Lioy, "Network-Level + Access Control Policy Analysis and Transformation", 2012. - S2 ^ Destination port - | - | x2 - +......o - | . - | . - --+.............+------------------------------------+ - | | . | | - s | . | | - e | . | (rectangle) | - g | . | condition clause (c) | - m | . | here the action a is applied | - e | . | | - n | . | x1=point=packet | - t +.............|.............o | - | | . | . | - --+.............+------------------------------------+ - | . . . . - | . . . . - +------------+------+-------------+----------------------+------> - | |---- segment = condition in S1 -----| S1 - + IP source + [Bas15] Basile, C. and A. Lioy, "Analysis of application-layer + filtering policies with application to HTTP", 2015. - Figure 17: Geometric representation of a rule r=(c,a) that - matches x1, but does not match x2. + [Cormen] Cormen, T., "Introduction to Algorithms", 2009. - Accordingly, the condition clause c is a subset of S: + [Galitsky] Galitsky, B. and Pampapathi, R., "Can many agents answer + questions better than one", First Monday, 2005; + http://dx.doi.org/10.5210/fm.v10i1.1204 - c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S + [Gamma] Gamma, E., Helm, R. Johnson, R., Vlissides, J., "Design + Patterns: Elements of Reusable Object-Oriented + Software", Addison-Wesley, Nov, 1994. + ISBN 978-0201633610 - S represents the totality of the packets that are individually - selectable by the security control to model when we use it to - enforce a policy. Unfortunately, not all its subsets are valid - condition clauses: only hyper-rectangles, or the union of - hyper-rectangles (as they are Cartesian product of conditions), - are valid. This is an intrinsic constraint of the policy - language, as it specifies rules by defining a condition for each - selector. Languages that allow specification of conditions as - relations over more fields are modeled by the geometric model as - more complex geometric shapes determined by the equations. However, - the algorithms to compute intersections are much more sophisticated - than intersection hyper-rectangles. Figure 17 graphically represents - a condition clause c in a two-dimensional selection space. + [Hirschman]Hirschman, L., and Gaizauskas, R., "Natural Language + Question Answering: The View from Here", Natural Language + Engineering 7:4, pgs 275-300, Cambridge University Press, + 2001 - In the geometric model, a rule is expressed as r=(c,a), where c <= S - (the condition clause is a subset of the selection space), and the - action a belongs to A. Rule condition clauses match a packet (rules - match a packet), if all the conditions forming the clauses match the - packet. In Figure 17, the rule with condition clause c matches the - packet x1 but not x2. + [Hohpe] Hohpe, G. and Woolf, B., "Enterprise Integration + Patterns", Addison-Wesley, 2003, ISBN 0-32-120068-3 - The rule set R is composed of n rules ri=(ci,ai). + [Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable + packet classification", 2003. - The decision criteria for the action to apply when a packet matches - two or more rules is abstracted by means of the resolution strategy + [Martin] Martin, R.C., "Agile Software Development, Principles, + Patterns, and Practices", Prentice-Hall, 2002, + ISBN: 0-13-597444-5 - RS: Pow(R) -> A + [MCM] MEF, "MEF Core Model", Technical Specification MEF X, + April 2018 - where Pow(R) is the power set of rules in R. + [OODMP] http://www.oodesign.com/mediator-pattern.html - Formally, given a set of rules, the resolution strategy maps all the - possible subsets of rules to an action a in A. When no rule matches a - packet, the security controls may select the default action d in A, - if they support one. + [OODSOP] http://www.oodesign.com/observer-pattern.html - Resolution strategies may use, besides intrinsic rule data (i.e., - condition clause and action clause), also external data associated to - each rule, such as priority, identity of the creator, and creation - time. Formally, every rule ri is associated by means of the - function e(.): + [OODSRP] http://www.oodesign.com/single-responsibility- + principle.html - e(ri) = (ri,f1(ri),f2(ri),...) + [PDO] MEF, "Policy Driven Orchestration", Technical + Specification MEF Y, January 2018 - where E={fj:R -> Xj} (j=1,2,...) is the set that includes all - functions that map rules to external attributes in Xj. However, - E, e, and all the Xj are determined by the resolution strategy used. + [Taylor] Taylor, D. and J. Turner, "Scalable packet classification + using distributed crossproducting of field labels", 2004. - A policy is thus a function p: S -> A that connects each point of - the selection space to an action taken from the action set A - according to the rules in R. By also assuming RS(0)=d (where 0 is - the empty-set) and RS(ri)=ai, the policy p can be described as: + 6. Acknowledgments - p(x)=RS(match{R(x)}). + This document was prepared using 2-Word-v2.0.template.dot. - Therefore, in the geometric model, a policy is completely defined by - the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS, - the set E of mappings to the external attributes, and the default - action d. +Authors' Addresses - Note that, the geometric model also supports ECA paradigms by simply - modeling events like an additional selector. + Cataldo Basile + Politecnico di Torino + Corso Duca degli Abruzzi, 34 + Torino, 10129 + Italy + Email: cataldo.basile@polito.it -Authors' Addresses Liang Xia (Frank) Huawei 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: Frank.xialiang@huawei.com John Strassner Huawei + 2330 Central Expressway + Santa Clara, CA 95050 USA Email: John.sc.Strassner@huawei.com -Cataldo Basile -Politecnico di Torino -Corso Duca degli Abruzzi, 34 -Torino, 10129 -Italy -Email: cataldo.basile@polito.it - Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid, 28010 Spain Phone: +34 913 129 041 Email: diego.r.lopez@telefonica.com