I2NSF L. Xia Internet-Draft J. Strassner Intended status: Standard Track Huawei Expires: October 3, 2018 C. Basile PoliTO D. Lopez TID April 3, 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. 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/. 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." This Internet-Draft will expire on October 3, 2018. Copyright Notice Copyright (c) 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. Xia, et al. Expires October 3, 2018 [Page 1] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 Xia, et al. Expires October 3, 2018 [Page 2] Internet-Draft Information Model of I2NSF Capabilities April 2018 Table of Contents (continued) B.3. SystemSecurityEvent Class Description .................... 44 B.3.1. The sysSecEventContent Attribute .................... 45 B.3.2. The sysSecEventFormat Attribute ..................... 45 B.3.3. The sysSecEventType Attribute ....................... 45 B.4. TimeSecurityEvent Class Description ...................... 45 B.4.1. The timeSecEventPeriodBegin Attribute ............... 46 B.4.2. The timeSecEventPeriodEnd Attribute ................. 46 B.4.3. The timeSecEventTimeZone Attribute .................. 46 Appendix C. Network Security Condition Class Definitions ......... 47 C.1. PacketSecurityCondition .................................. 47 C.1.1. PacketSecurityMACCondition .......................... 47 C.1.1.1. The pktSecCondMACDest Attribute ................ 47 C.1.1.2. The pktSecCondMACSrc Attribute ................. 47 C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48 C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48 C.1.1.5. The pktSecCondMACTCI Attribute ................. 48 C.1.2. PacketSecurityIPv4Condition ......................... 48 C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48 C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48 C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48 C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48 C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48 C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49 C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49 C.1.3. PacketSecurityIPv6Condition ......................... 49 C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49 C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49 C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49 C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49 C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49 C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49 C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50 C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50 C.1.4. PacketSecurityTCPCondition .......................... 50 C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50 C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50 C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50 C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50 C.1.5. PacketSecurityUDPCondition ....................... 50 C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50 C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51 C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51 C.2. PacketPayloadSecurityCondition ........................... 51 C.3. TargetSecurityCondition .................................. 51 C.4. UserSecurityCondition .................................... 51 C.5. SecurityContextCondition ................................. 52 C.6. GenericContextSecurityCondition .......................... 52 Xia, et al. Expires October 3, 2018 [Page 3] Internet-Draft Information Model of I2NSF Capabilities April 2018 Table of Contents (continued) Appendix D. Network Security Action Class Definitions ............. 53 D.1. IngressAction ............................................ 53 D.2. EgressAction ............................................. 53 D.3. ApplyProfileAction ....................................... 53 Appendix E. Geometric Model ...................................... 54 Authors' Addresses ............................................... 57 1. Introduction The rapid development of virtualized systems requires advanced security protection in various scenarios. Examples include network devices in an enterprise network, user equipments 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 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: 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. Xia, et al. Expires October 3, 2018 [Page 4] Internet-Draft Information Model of I2NSF Capabilities April 2018 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. 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. 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. 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 Xia, et al. Expires October 3, 2018 [Page 5] Internet-Draft Information Model of I2NSF Capabilities April 2018 3. Information Model Design 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]. 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 confidentiality, anti-reply protections, and authenticate peers. 3.1. Capability Information Model Overview 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. Some basic design principles for security Capabilities and the systems that have to 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 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, Xia, et al. Expires October 3, 2018 [Page 6] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 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. 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. 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 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 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]: 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 Policy Rules, it is used to determine whether the Condition clause of the I2NSF Policy Rule can be evaluated or not. Xia, et al. Expires October 3, 2018 [Page 7] Internet-Draft Information Model of I2NSF Capabilities April 2018 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. 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: IF is TRUE IF is TRUE THEN execute END-IF END-IF Technically, the "Policy Rule" is really a container that aggregates the above three clauses, as well as metadata. The above ECA policy model is very general and easily extensible, and can avoid potential constraints that could limit the implementation of generic security Capabilities. 3.3. 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: 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; Xia, et al. Expires October 3, 2018 [Page 8] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 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 Xia, et al. Expires October 3, 2018 [Page 9] Internet-Draft Information Model of I2NSF Capabilities April 2018 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. It is assumed that the external ECA Information Model has the ability to aggregate metadata. Capabilities are then sub-classed from an appropriate class in the external Metadata Information Model; this enables the ECA objects to use the existing aggregation between them and Metadata to add Metadata to appropriate ECA objects. Detailed descriptions of each portion of the information model are given in the following sections. 3.4. I2NSF Capability Information Model: Theory of Operation Capabilities are typically used to represent NSF functions that can be invoked. Capabilities are objects, and hence, can be used in the event, condition, and/or action clauses of an I2NSF ECA Policy Rule. The I2NSF Capability information model refines a predefined metadata model; the application of I2NSF Capabilities is done by refining a predefined ECA Policy Rule 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. Xia, et al. Expires October 3, 2018 [Page 10] Internet-Draft Information Model of I2NSF Capabilities April 2018 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. 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. 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. 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 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). In this selector, it is only meaningful to specify condition clauses that use either the "equals" or "not equals" operators: proto = tcp, udp (protocol type field equals to TCP or UDP) proto != tcp (protocol type field different 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: Xia, et al. Expires October 3, 2018 [Page 11] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 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]". 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). As an example, the condition clause: "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/*" 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. Xia, et al. Expires October 3, 2018 [Page 12] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 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 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. 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: 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 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. 3.4.3. Capability Algebra We introduce a Capability Algebra to ensure that the actions of different policy rules do not conflict with each other. Formally, two I2NSF Policy Actions conflict with each other if: Xia, et al. Expires October 3, 2018 [Page 13] Internet-Draft Information Model of I2NSF Capabilities April 2018 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: 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 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 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: 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 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. Xia, et al. Expires October 3, 2018 [Page 14] Internet-Draft Information Model of I2NSF Capabilities April 2018 - 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. Xia, et al. Expires October 3, 2018 [Page 15] Internet-Draft Information Model of I2NSF Capabilities April 2018 * 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. Xia, et al. Expires October 3, 2018 [Page 16] Internet-Draft Information Model of I2NSF Capabilities April 2018 * 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. Xia, et al. Expires October 3, 2018 [Page 17] Internet-Draft Information Model of I2NSF Capabilities April 2018 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: Xia, et al. Expires October 3, 2018 [Page 18] Internet-Draft Information Model of I2NSF Capabilities April 2018 +---------------------+ +---------------+ 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 | |---- segment = condition in S1 -----| S1 + IP source Figure 17: Geometric representation of a rule r=(c,a) that matches x1, but does not match x2. Accordingly, the condition clause c is a subset of S: c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S S represents the totality of the packets that are individually selectable by the security control to model when we use it to enforce a policy. Unfortunately, not all its subsets are valid condition clauses: only hyper-rectangles, or the union of hyper-rectangles (as they are Cartesian product of conditions), are valid. This is an intrinsic constraint of the policy language, as it specifies rules by defining a condition for each selector. Languages that allow specification of conditions as relations over more fields are modeled by the geometric model as more complex geometric shapes determined by the equations. However, the algorithms to compute intersections are much more sophisticated than intersection hyper-rectangles. Figure 17 graphically represents a condition clause c in a two-dimensional selection space. In the geometric model, a rule is expressed as r=(c,a), where c <= S (the condition clause is a subset of the selection space), and the action a belongs to A. Rule condition clauses match a packet (rules match a packet), if all the conditions forming the clauses match the packet. In Figure 17, the rule with condition clause c matches the packet x1 but not x2. Xia, et al. Expires October 3, 2018 [Page 55] Internet-Draft Information Model of I2NSF Capabilities April 2018 The rule set R is composed of n rules ri=(ci,ai). The decision criteria for the action to apply when a packet matches two or more rules is abstracted by means of the resolution strategy RS: Pow(R) -> A where Pow(R) is the power set of rules in R. Formally, given a set of rules, the resolution strategy maps all the possible subsets of rules to an action a in A. When no rule matches a packet, the security controls may select the default action d in A, if they support one. Resolution strategies may use, besides intrinsic rule data (i.e., condition clause and action clause), also external data associated to each rule, such as priority, identity of the creator, and creation time. Formally, every rule ri is associated by means of the function e(.): e(ri) = (ri,f1(ri),f2(ri),...) where E={fj:R -> Xj} (j=1,2,...) is the set that includes all functions that map rules to external attributes in Xj. However, E, e, and all the Xj are determined by the resolution strategy used. A policy is thus a function p: S -> A that connects each point 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: p(x)=RS(match{R(x)}). Therefore, in the geometric model, a policy is completely defined by the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS, the set E of mappings to the external attributes, and the default action d. Note that, the geometric model also supports ECA paradigms by simply modeling events like an additional selector. Xia, et al. Expires October 3, 2018 [Page 56] Internet-Draft Information Model of I2NSF Capabilities April 2018 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 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 Xia, et al. Expires October 3, 2018 [Page 57]