--- 1/draft-xibassnez-i2nsf-capability-01.txt 2017-07-03 12:13:23.616412677 -0700 +++ 2/draft-xibassnez-i2nsf-capability-02.txt 2017-07-03 12:13:23.740415647 -0700 @@ -1,21 +1,21 @@ I2NSF L. Xia Internet-Draft J. Strassner Intended status: Standard Track Huawei -Expires: September 12, 2017 C. Basile +Expires: January 5, 2018 C. Basile PoliTO D. Lopez TID - March 12, 2017 + July 3, 2017 Information Model of NSFs Capabilities - draft-xibassnez-i2nsf-capability-01.txt + draft-xibassnez-i2nsf-capability-02.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. @@ -29,21 +29,21 @@ 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 September 12, 2017. + This Internet-Draft will expire on January 5, 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 @@ -169,65 +169,64 @@ security protection in various scenarios. Examples include network devices in an enterprise network, User Equipment in a mobile network, devices in the Internet of Things, or residential access users [I-D.draft-ietf-i2nsf-problem-and-use-cases]. 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 Functions - (NSFs) that are available to use for security policy enforcement + 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 needed to refer to a specific product when designing the - network; rather, the functions characterized by their Capabilities - are considered. + 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 [I-D.draft-ietf-i2nsf-framework], there are two types of I2NSF interfaces available for security policy provisioning: + o Interface between I2NSF users and applications, and a security controller (Consumer-Facing Interface): this is a service- oriented interface that provides a communication channel 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 of - consumers requesting such services from their implementation. + is to decouple the specification of security services from + their implementation. 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). According to the definition - in [I-D.draft-ietf-i2nsf-framework], the NSF-Facing Interface - information model is made up of three sub-models: Capability, - Registration and Monitoring. This document defines the - information model design for the first two parts (Capability - and Registration); the Monitoring part information model is - discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring]. + 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 ECA model. Section 4 - provides detailed information model design of I2NSF network security - Capability. + 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. @@ -246,44 +245,44 @@ 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 -3. Capability Information Model Design +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 "NAT", "filtering", and + 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. Design Principles and ECA Policy Model Overview +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 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: @@ -336,33 +335,35 @@ 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. - In defining the Capabilities of a NSF, the "Event-Condition-Action" - (ECA) policy model in [I-D.draft-ietf-i2nsf-framework] is used as - the basis for the design; definitions of all I2NSF policy-related - terms are also defined in [I-D.draft-ietf-i2nsf-terminology]: +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; definitions of all I2NSF + policy-related terms are also defined 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. + Examples of an I2NSF Event include time and user actions (e.g., logon, logoff, and actions that violate an ACL). - o Condition: A condition is defined as a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether or not the set of Actions in that (imperative) I2NSF Policy Rule can be executed or not. Examples of I2NSF Conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF to a desired state. o Action: An action is used to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied. NSFs provide security functions by executing various @@ -363,25 +364,41 @@ Policy Rule can be executed or not. Examples of I2NSF Conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF to a desired state. o Action: An action is used to control and monitor aspects of flow-based 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.2. Relation with the External Information Model +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 using the following approach: 1) Each NSF registers its Capabilities with the management system when it "joins", and hence makes its Capabilities available to @@ -402,82 +420,85 @@ [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; 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. + 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 | - +-----+------+ - | Capability | + 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. 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. + 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 a set of objects - that represent a generic ECA Policy Rule, and a set of objects that + The external ECA Information Model supplies at least a 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 specialize it (i.e., - create new model objects) to represent I2NSF-specific concepts. + 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.3. I2NSF Capability Information Model: Theory of Operation +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 @@ -510,21 +531,21 @@ 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.3.1. I2NSF Condition Clause Operator Types +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/ @@ -593,21 +614,21 @@ 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.3.2. Capability Selection and Usage +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 @@ -627,21 +648,21 @@ 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 a NSF has the Capabilities needed to enforce policies. -3.3.3. Capability Algebra +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: 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 @@ -656,21 +677,21 @@ 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 both evaluate to true. This enables the actions in this policy rule to be evaluated. Then, the - information model is defined by a 5-tuple {Ac, Cc, Ec, RSc, Dc}, + 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 @@ -736,21 +758,21 @@ * * 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 @@ -788,68 +810,68 @@ * {{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.4. Initial NSFs Capability Categories +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.4.1. Network Security Capabilities +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.4.2. Content Security Capabilities +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, Capabilities can be - used to identify various security functions that are required, such - as defending against intrusion, inspecting for viruses, filtering - malicious URL or junk email, blocking illegal web access, or - preventing malicious data retrieval. + 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 - NSFs will be characterized by their own content- specific security - Capabilities. + Capabilities will be characterized by their own content-specific + security functions. -3.4.3. Attack Mitigation Capabilities +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, @@ -859,23 +881,23 @@ - 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 content security control. A - standard interface, through which the security controller can - choose and customize the given security Capabilities according to + 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. @@ -890,30 +912,30 @@ +---------------+ 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 - with some extension, for Network Security) - such as InspectTraffic) + 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) Events, Conditions, and + 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 @@ -921,21 +943,25 @@ true, 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**. + 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