draft-xibassnez-i2nsf-capability-01.txt   draft-xibassnez-i2nsf-capability-02.txt 
I2NSF L. Xia I2NSF L. Xia
Internet-Draft J. Strassner Internet-Draft J. Strassner
Intended status: Standard Track Huawei Intended status: Standard Track Huawei
Expires: September 12, 2017 C. Basile Expires: January 5, 2018 C. Basile
PoliTO PoliTO
D. Lopez D. Lopez
TID TID
March 12, 2017 July 3, 2017
Information Model of NSFs Capabilities Information Model of NSFs Capabilities
draft-xibassnez-i2nsf-capability-01.txt draft-xibassnez-i2nsf-capability-02.txt
Abstract Abstract
This document defines the concept of an NSF (Network Security This document defines the concept of an NSF (Network Security
Function) Capability, as well as its information model. Capabilities Function) Capability, as well as its information model. Capabilities
are a set of features that are available from a managed entity, and are a set of features that are available from a managed entity, and
are represented as data that unambiguously characterizes an NSF. are represented as data that unambiguously characterizes an NSF.
Capabilities enable management entities to determine the set offer Capabilities enable management entities to determine the set offer
features from available NSFs that will be used, and simplify the features from available NSFs that will be used, and simplify the
management of NSFs. management of NSFs.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on September 12, 2017. This Internet-Draft will expire on January 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 27 skipping to change at page 4, line 27
security protection in various scenarios. Examples include network security protection in various scenarios. Examples include network
devices in an enterprise network, User Equipment in a mobile network, devices in an enterprise network, User Equipment in a mobile network,
devices in the Internet of Things, or residential access users devices in the Internet of Things, or residential access users
[I-D.draft-ietf-i2nsf-problem-and-use-cases]. [I-D.draft-ietf-i2nsf-problem-and-use-cases].
NSFs produced by multiple security vendors provide various security 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 provide security services over the given network traffic, regardless
of whether the NSFs are implemented as physical or virtual functions. of whether the NSFs are implemented as physical or virtual functions.
Security Capabilities describe the set of Network Security Functions Security Capabilities describe the set of network security-related
(NSFs) that are available to use for security policy enforcement features that are available to use for security policy enforcement
purposes. Security Capabilities are independent of the actual purposes. Security Capabilities are independent of the actual
security control mechanisms that will implement them. Every NSF security control mechanisms that will implement them. Every NSF
registers the set of Capabilities it offers. Security Capabilities registers the set of Capabilities it offers. Security Capabilities
are a market enabler, providing a way to define customized security are a market enabler, providing a way to define customized security
protection by unambiguously describing the security features offered protection by unambiguously describing the security features offered
by a given NSF. Moreover, Security Capabilities enable security by a given NSF. Moreover, Security Capabilities enable security
functionality to be described in a vendor-neutral manner. That is, functionality to be described in a vendor-neutral manner. That is,
it is not needed to refer to a specific product when designing the it is not required to refer to a specific product when designing the
network; rather, the functions characterized by their Capabilities network; rather, the functionality characterized by their
are considered. Capabilities are considered.
According to [I-D.draft-ietf-i2nsf-framework], there are two types According to [I-D.draft-ietf-i2nsf-framework], there are two types
of I2NSF interfaces available for security policy provisioning: of I2NSF interfaces available for security policy provisioning:
o Interface between I2NSF users and applications, and a security o Interface between I2NSF users and applications, and a security
controller (Consumer-Facing Interface): this is a service- controller (Consumer-Facing Interface): this is a service-
oriented interface that provides a communication channel oriented interface that provides a communication channel
between consumers of NSF data and services and the network between consumers of NSF data and services and the network
operator's security controller. This enables security operator's security controller. This enables security
information to be exchanged between various applications (e.g., information to be exchanged between various applications (e.g.,
OpenStack, or various BSS/OSS components) and the security OpenStack, or various BSS/OSS components) and the security
controller. The design goal of the Consumer-Facing Interface controller. The design goal of the Consumer-Facing Interface
is to decouple the specification of security services of is to decouple the specification of security services from
consumers requesting such services from their implementation. their implementation.
o Interface between NSFs (e.g., firewall, intrusion prevention, o Interface between NSFs (e.g., firewall, intrusion prevention,
or anti-virus) and the security controller (NSF-Facing or anti-virus) and the security controller (NSF-Facing
Interface): The NSF-Facing Interface is used to decouple the Interface): The NSF-Facing Interface is used to decouple the
security management scheme from the set of NSFs and their security management scheme from the set of NSFs and their
various implementations for this scheme, and is independent various implementations for this scheme, and is independent
of how the NSFs are implemented (e.g., run in Virtual of how the NSFs are implemented (e.g., run in Virtual
Machines or physical appliances). According to the definition Machines or physical appliances). This document defines an
in [I-D.draft-ietf-i2nsf-framework], the NSF-Facing Interface object-oriented information model for network security, content
information model is made up of three sub-models: Capability, security, and attack mitigation Capabilities, along with
Registration and Monitoring. This document defines the associated I2NSF Policy objects.
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].
This document is organized as follows. Section 2 defines conventions This document is organized as follows. Section 2 defines conventions
and acronyms used. Section 3 discusses the design principles for the and acronyms used. Section 3 discusses the design principles for the
I2NSF Capability information model and related ECA model. Section 4 I2NSF Capability information model and related policy model objects.
provides detailed information model design of I2NSF network security Section 4 defines the structure of the information model, which
Capability. describes the policy and capability objects design; details of the
model elements are contained in the appendices.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
This document uses terminology defined in This document uses terminology defined in
[I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF [I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF
scoped terminology. scoped terminology.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
IPS: Intrusion Prevention System IPS: Intrusion Prevention System
LMR: Last Matching Rule (resolution strategy) LMR: Last Matching Rule (resolution strategy)
MIME: Multipurpose Internet Mail Extensions MIME: Multipurpose Internet Mail Extensions
NAT: Network Address Translation NAT: Network Address Translation
NSF: Network Security Function NSF: Network Security Function
RPC: Remote Procedure Call RPC: Remote Procedure Call
SMA: String Matching Algorithm SMA: String Matching Algorithm
URL: Uniform Resource Locator URL: Uniform Resource Locator
VPN: Virtual Private Network VPN: Virtual Private Network
3. Capability Information Model Design 3. Information Model Design
The starting point of the design of the Capability information model The starting point of the design of the Capability information model
is the categorization of types of security functions. For instance, 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 "VPN concentrator". Network security experts unequivocally refer to
"packet filters" as stateless devices able to allow or deny packet "packet filters" as stateless devices able to allow or deny packet
forwarding based on various conditions (e.g., source and destination forwarding based on various conditions (e.g., source and destination
IP addresses, source and destination ports, and IP protocol type IP addresses, source and destination ports, and IP protocol type
fields) [Alshaer]. fields) [Alshaer].
However, more information is required in case of other devices, like However, more information is required in case of other devices, like
stateful firewalls or application layer filters. These devices stateful firewalls or application layer filters. These devices
filter packets or communications, but there are differences in the filter packets or communications, but there are differences in the
packets and communications that they can categorize and the states packets and communications that they can categorize and the states
they maintain. Analogous considerations can be applied for channel they maintain. Analogous considerations can be applied for channel
protection protocols, where we all understand that they will protect protection protocols, where we all understand that they will protect
packets by means of symmetric algorithms whose keys could have been packets by means of symmetric algorithms whose keys could have been
negotiated with asymmetric cryptography, but they may work at negotiated with asymmetric cryptography, but they may work at
different layers and support different algorithms and protocols. To different layers and support different algorithms and protocols. To
ensure protection, these protocols apply integrity, optionally ensure protection, these protocols apply integrity, optionally
confidentiality, anti-reply protections, and authenticate peers. 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 This document defines a model of security Capabilities that provides
the foundation for automatic management of NSFs. This includes the foundation for automatic management of NSFs. This includes
enabling the security controller to properly identify and manage enabling the security controller to properly identify and manage
NSFs, and allow NSFs to properly declare their functionality, so NSFs, and allow NSFs to properly declare their functionality, so
that they can be used in the correct way. that they can be used in the correct way.
Some basic design principles for security Capabilities and the Some basic design principles for security Capabilities and the
systems that have to manage them are: systems that have to manage them are:
skipping to change at page 7, line 43 skipping to change at page 7, line 43
created, and/or existing Capabilities may be updated (e.g., by created, and/or existing Capabilities may be updated (e.g., by
updating its signature and algorithm). This results in enhancing updating its signature and algorithm). This results in enhancing
existing NSFs (and/or creating new NSFs) to address the new threats. existing NSFs (and/or creating new NSFs) to address the new threats.
New Capabilities may be sent to and stored in a centralized New Capabilities may be sent to and stored in a centralized
repository, or stored separately in a vendor's local repository. repository, or stored separately in a vendor's local repository.
In either case, a standard interface facilitates the update process. In either case, a standard interface facilitates the update process.
Note that most systems cannot dynamically create a new Capability Note that most systems cannot dynamically create a new Capability
without human interaction. This is an area for further study. without human interaction. This is an area for further study.
In defining the Capabilities of a NSF, the "Event-Condition-Action" 3.2. ECA Policy Model Overview
(ECA) policy model in [I-D.draft-ietf-i2nsf-framework] is used as
the basis for the design; definitions of all I2NSF policy-related The "Event-Condition-Action" (ECA) policy model is used as the basis
terms are also defined in [I-D.draft-ietf-i2nsf-terminology]: 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 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 in the system being managed, and/or in the environment of the
system being managed. When used in the context of I2NSF system being managed. When used in the context of I2NSF
Policy Rules, it is used to determine whether the Condition 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., Examples of an I2NSF Event include time and user actions (e.g.,
logon, logoff, and actions that violate an ACL). logon, logoff, and actions that violate an ACL).
o Condition: A condition is defined as a set of attributes, o Condition: A condition is defined as a set of attributes,
features, and/or values that are to be compared with a set of features, and/or values that are to be compared with a set of
known attributes, features, and/or values in order to determine known attributes, features, and/or values in order to determine
whether or not the set of Actions in that (imperative) I2NSF whether or not the set of Actions in that (imperative) I2NSF
Policy Rule can be executed or not. Examples of I2NSF Conditions Policy Rule can be executed or not. Examples of I2NSF Conditions
include matching attributes of a packet or flow, and comparing include matching attributes of a packet or flow, and comparing
the internal state of an NSF to a desired state. the internal state of an NSF to a desired state.
o Action: An action is used to control and monitor aspects of o Action: An action is used to control and monitor aspects of
flow-based NSFs when the event and condition clauses are flow-based NSFs when the event and condition clauses are
satisfied. NSFs provide security functions by executing various satisfied. NSFs provide security functions by executing various
skipping to change at page 8, line 19 skipping to change at page 8, line 21
Policy Rule can be executed or not. Examples of I2NSF Conditions Policy Rule can be executed or not. Examples of I2NSF Conditions
include matching attributes of a packet or flow, and comparing include matching attributes of a packet or flow, and comparing
the internal state of an NSF to a desired state. the internal state of an NSF to a desired state.
o Action: An action is used to control and monitor aspects of o Action: An action is used to control and monitor aspects of
flow-based NSFs when the event and condition clauses are flow-based NSFs when the event and condition clauses are
satisfied. NSFs provide security functions by executing various satisfied. NSFs provide security functions by executing various
Actions. Examples of I2NSF Actions include providing intrusion Actions. Examples of I2NSF Actions include providing intrusion
detection and/or protection, web and flow filtering, and deep detection and/or protection, web and flow filtering, and deep
packet inspection for packets and flows. 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 <event-clause> is TRUE
IF <condition-clause> is TRUE
THEN execute <action-clause>
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, The above ECA policy model is very general and easily extensible,
and can avoid potential constraints that could limit the and can avoid potential constraints that could limit the
implementation of generic security Capabilities. 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 Note: the symbology used from this point forward is taken from
section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model]. section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model].
The I2NSF NSF-Facing Interface is in charge of selecting and The I2NSF NSF-Facing Interface is in charge of selecting and
managing the NSFs using their Capabilities. This is done using managing the NSFs using their Capabilities. This is done using
the following approach: the following approach:
1) Each NSF registers its Capabilities with the management system 1) Each NSF registers its Capabilities with the management system
when it "joins", and hence makes its Capabilities available to when it "joins", and hence makes its Capabilities available to
skipping to change at page 9, line 8 skipping to change at page 9, line 25
[I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external [I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external
information model. information model.
Capabilities are defined as classes (e.g., a set of objects that Capabilities are defined as classes (e.g., a set of objects that
exhibit a common set of characteristics and behavior exhibit a common set of characteristics and behavior
[I-D.draft-ietf-supa-generic-policy-info-model]. [I-D.draft-ietf-supa-generic-policy-info-model].
Each Capability is made up of at least one model element (e.g., Each Capability is made up of at least one model element (e.g.,
attribute, method, or relationship) that differentiates it from all attribute, method, or relationship) that differentiates it from all
other objects in the system. Capabilities are, generically, a type other objects in the system. Capabilities are, generically, a type
of metadata; hence, it is also assumed that an external information of metadata (i.e., information that describes, and/or prescribes,
model is used to define metadata (preferably, in the form of a class the behavior of objects); hence, it is also assumed that an external
hierarchy). Therefore, it is assumed that Capabilities are subclassed information model is used to define metadata (preferably, in the
from an external metadata model. 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, The Capability sub-model is used for advertising, creating,
selecting, and managing a set of specific security Capabilities selecting, and managing a set of specific security Capabilities
independent of the type and vendor of device that contains the NSF. 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 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 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 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 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 only cares about the set of Capabilities that the NSF has, such as
packet filtering or deep packet inspection. The overall structure packet filtering or deep packet inspection. The overall structure
is illustrated in the figure below: is illustrated in the figure below:
+-------------------------+ 0..n 0..n +---------------+ +-------------------------+ 0..n 0..n +---------------+
| |/ \ \| External | | |/ \ \| External |
| External ECA Info Model + A ----------------+ Metadata | | External ECA Info Model + A ----------------+ Metadata |
| |\ / Aggregates /| Info Model | | |\ / Aggregates /| Info Model |
+-----------+------------+ Metadata +-------+-------+ +-----------+------------+ Metadata +-------+-------+
| / \ | / \
| | | |
/ \ | / \ |
Subclasses derived for I2NSF | Subclasses derived for I2NSF +-----+------+
+-----+------+ Security Policies | Capability |
| Capability |
| Sub-Model | | Sub-Model |
+------------+ +------------+
Figure 1. The Overall I2NSF Information Model Design Figure 1. The Overall I2NSF Information Model Design
This draft defines a set of extensions to a generic, external, ECA This draft defines a set of extensions to a generic, external, ECA
Policy Model to represent various NSF ECA Security Policy Rules. It Policy Model to represent various NSF ECA Security Policy Rules. It
also defines the Capability Sub-Model. Finally, it places also defines the Capability Sub-Model; this enables ECA Policy
requirements on what type of extensions are required to the generic, Rules to control which Capabilities are seen by which actors, and
external, ECA information model and metadata models, in order to used by the I2NSF system. Finally, it places requirements on what
manage the lifecycle of I2NSF Capabilities. 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 Both of the external models shown in Figure 1 could, but do not have
to, be based on the SUPA information model to, be based on the SUPA information model
[I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in
the Capability Sub-Model will inherit the AggregatesMetadata the Capability Sub-Model will inherit the AggregatesMetadata
aggregation from the External Metadata Information Model. aggregation from the External Metadata Information Model.
The external ECA Information Model supplies at least a set of objects The external ECA Information Model supplies at least a set of classes
that represent a generic ECA Policy Rule, and a set of objects that that represent a generic ECA Policy Rule, and a set of classes that
represent Events, Conditions, and Actions that can be aggregated by represent Events, Conditions, and Actions that can be aggregated by
the generic ECA Policy Rule. This enables I2NSF to reuse this the generic ECA Policy Rule. This enables I2NSF to reuse this
generic model for different purposes, as well as specialize it (i.e., generic model for different purposes, as well as refine it (i.e.,
create new model objects) to represent I2NSF-specific concepts. create new subclasses, or add attributes and relationships) to
represent I2NSF-specific concepts.
It is assumed that the external ECA Information Model has the It is assumed that the external ECA Information Model has the
ability to aggregate metadata. Capabilities are then sub-classed ability to aggregate metadata. Capabilities are then sub-classed
from an appropriate class in the external Metadata Information Model; from an appropriate class in the external Metadata Information Model;
this enables the ECA objects to use the existing aggregation between this enables the ECA objects to use the existing aggregation between
them and Metadata to add Metadata to appropriate ECA objects. them and Metadata to add Metadata to appropriate ECA objects.
Detailed descriptions of each portion of the information model are Detailed descriptions of each portion of the information model are
given in the following sections. 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 Capabilities are typically used to represent NSF functions that can
be invoked. Capabilities are objects, and hence, can be used in the be invoked. Capabilities are objects, and hence, can be used in the
event, condition, and/or action clauses of an I2NSF ECA Policy Rule. event, condition, and/or action clauses of an I2NSF ECA Policy Rule.
The I2NSF Capability information model refines a predefined metadata The I2NSF Capability information model refines a predefined metadata
model; the application of I2NSF Capabilities is done by refining a model; the application of I2NSF Capabilities is done by refining a
predefined ECA Policy Rule information model that defines how to predefined ECA Policy Rule information model that defines how to
use, manage, or otherwise manipulate a set of Capabilities. In this use, manage, or otherwise manipulate a set of Capabilities. In this
approach, an I2NSF Policy Rule is a container that is made up of approach, an I2NSF Policy Rule is a container that is made up of
three clauses: an event clause, a condition clause, and an action three clauses: an event clause, a condition clause, and an action
skipping to change at page 11, line 17 skipping to change at page 11, line 34
no rule matches a packet, the NSFs may select a default action, if no rule matches a packet, the NSFs may select a default action, if
they support one. they support one.
Resolution strategies may use, besides intrinsic rule data (i.e., Resolution strategies may use, besides intrinsic rule data (i.e.,
event, condition, and action clauses), "external data" associated to event, condition, and action clauses), "external data" associated to
each rule, such as priority, identity of the creator, and creation each rule, such as priority, identity of the creator, and creation
time. Two examples of this are attaching metadata to the policy time. Two examples of this are attaching metadata to the policy
action and/or policy rule, and associating the policy rule with action and/or policy rule, and associating the policy rule with
another class to convey such information. 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 After having analyzed the literature and some existing NSFs, the
types of selectors are categorized as exact-match, range-based, types of selectors are categorized as exact-match, range-based,
regex-based, and custom-match [Bas15][Lunt]. regex-based, and custom-match [Bas15][Lunt].
Exact-match selectors are (unstructured) sets: elements can only be Exact-match selectors are (unstructured) sets: elements can only be
checked for equality, as no order is defined on them. As an example, 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 the protocol type field of the IP header is an unordered set of
integer values associated to protocols. The assigned protocol integer values associated to protocols. The assigned protocol
numbers are maintained by the IANA (http://www.iana.org/assignments/ numbers are maintained by the IANA (http://www.iana.org/assignments/
skipping to change at page 12, line 47 skipping to change at page 13, line 15
In order to be properly used by high-level policy-based processing In order to be properly used by high-level policy-based processing
systems (such as reasoning systems and policy translation systems), systems (such as reasoning systems and policy translation systems),
these custom check selectors can be modeled as black-boxes (i.e., a 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 function that has a defined set of inputs and outputs for a
particular state), which provide an associated Boolean output. particular state), which provide an associated Boolean output.
More examples of custom check selectors will be presented in the More examples of custom check selectors will be presented in the
next versions of the draft. Some examples are already present in next versions of the draft. Some examples are already present in
Section 6. 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 Capability selection and usage are based on the set of security
traffic classification and action features that an NSF provides; 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 classification features needed to identify the packets/flows
required by a policy, and can enforce the needed actions, then required by a policy, and can enforce the needed actions, then
that particular NSF is capable of enforcing the policy. that particular NSF is capable of enforcing the policy.
NSFs may also have specific characteristics that automatic processes NSFs may also have specific characteristics that automatic processes
or administrators need to know when they have to generate or administrators need to know when they have to generate
skipping to change at page 13, line 30 skipping to change at page 13, line 49
filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
filter, monitoring, and anonymity proxy; these will be described filter, monitoring, and anonymity proxy; these will be described
later in a revision of this draft as well as in an upcoming data later in a revision of this draft as well as in an upcoming data
model contribution. model contribution.
The next section will introduce the algebra to define the The next section will introduce the algebra to define the
information model of Capability registration. This associates information model of Capability registration. This associates
NSFs to Capabilities, and checks whether a NSF has the NSFs to Capabilities, and checks whether a NSF has the
Capabilities needed to enforce policies. 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 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 other.
Formally, two I2NSF Policy Actions conflict with each other if: Formally, two I2NSF Policy Actions conflict with each other if:
o the event clauses of each evaluate to TRUE o the event clauses of each evaluate to TRUE
o the condition 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 o the action clauses affect the same object in different ways
skipping to change at page 14, line 8 skipping to change at page 14, line 27
P3: During 8am-6pm, John gets GoldService P3: During 8am-6pm, John gets GoldService
P4: During 10am-4pm, FTP from all users gets BronzeService P4: During 10am-4pm, FTP from all users gets BronzeService
P3 and P4 are now in conflict, because between the hours of 10am and 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 4pm, the actions of P3 and P4 are different and apply to the same
user (i.e., John). user (i.e., John).
Let us define the concept of a "matched" policy rule as one in which 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 its event and condition clauses both evaluate to true. This enables
the actions in this policy rule to be evaluated. Then, the 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: where:
o Ac is the set of Actions currently available from the NSF; 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 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. 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 Therefore, the event clause of an I2NSF ECA Policy Rule that is
written for an NSF will only allow a set of designated events written for an NSF will only allow a set of designated events
in Ec. For compatibility purposes, we will assume that if Ec={} in Ec. For compatibility purposes, we will assume that if Ec={}
(that is, Ec is empty), the NSF only accepts CA policies. (that is, Ec is empty), the NSF only accepts CA policies.
o RSc is the set of Resolution Strategies that can be used to o RSc is the set of Resolution Strategies that can be used to
skipping to change at page 15, line 34 skipping to change at page 16, line 4
* *
* two set operations are defined for manipulating Capabilities: * two set operations are defined for manipulating Capabilities:
* *
* o Capability addition: * o Capability addition:
* cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1} * cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1}
* o Capability subtraction: * o Capability subtraction:
* cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1} * cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1}
* *
* In the above formulae, "U" is the set union operator and "\" is the * In the above formulae, "U" is the set union operator and "\" is the
* set difference operator. * set difference operator.
*
* The addition and subtraction of Capabilities are defined as the * The addition and subtraction of Capabilities are defined as the
* addition (set union) and subtraction (set difference) of both the * addition (set union) and subtraction (set difference) of both the
* Capabilities and their associated actions. Note that **only** the * Capabilities and their associated actions. Note that **only** the
* leftmost (in this case, the first matched policy rule) Resolution * leftmost (in this case, the first matched policy rule) Resolution
* Strategy and Default Action are used. * Strategy and Default Action are used.
* *
* Note: actions, events, and conditions are **symmetric**. This means * Note: actions, events, and conditions are **symmetric**. This means
* that when two matched policy rules are merged, the resultant actions * that when two matched policy rules are merged, the resultant actions
* and Capabilities are defined as the union of each individual matched * and Capabilities are defined as the union of each individual matched
* policy rule. However, both resolution strategies and default actions * policy rule. However, both resolution strategies and default actions
skipping to change at page 16, line 32 skipping to change at page 17, line 4
* {{IPsrc, IPdst, Psrc, Pdst, protType} U * {{IPsrc, IPdst, Psrc, Pdst, protType} U
* {timestart, timeend, datestart, datestop}}, * {timestart, timeend, datestart, datestop}},
* {}, * {},
* {FMR}, * {FMR},
* {A1} * {A1}
* *
* In other words, Cpfgen provides three actions (Allow, Deny, Log), * In other words, Cpfgen provides three actions (Allow, Deny, Log),
* filters traffic based on a 5-tuple that is logically ANDed with a * 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 * time period, and uses FMR; it provides A1 as a default action, and
* it does not react to events. * it does not react to events.
*
* Note: We are investigating, for a next revision of this draft, the * Note: We are investigating, for a next revision of this draft, the
* possibility to add further operations that do not follow the * possibility to add further operations that do not follow the
* symmetric vs. asymmetric properties presented in the previous note. * symmetric vs. asymmetric properties presented in the previous note.
* We are looking for use cases that may justify the complexity added * We are looking for use cases that may justify the complexity added
* by the availability of more Capability manipulation operations. * by the availability of more Capability manipulation operations.
* *
*** End Note to WG *** End Note to WG
3.4. Initial NSFs Capability Categories 3.5. Initial NSFs Capability Categories
The following subsections define three common categories of The following subsections define three common categories of
Capabilities: network security, content security, and attack Capabilities: network security, content security, and attack
mitigation. Future versions of this document may expand both the mitigation. Future versions of this document may expand both the
number of categories as well as the types of Capabilities within a number of categories as well as the types of Capabilities within a
given category. given category.
3.4.1. Network Security Capabilities 3.5.1. Network Security Capabilities
Network security is a category that describes the inspecting and Network security is a category that describes the inspecting and
processing of network traffic based on the use of pre-defined processing of network traffic based on the use of pre-defined
security policies. security policies.
The inspecting portion may be thought of as a packet-processing The inspecting portion may be thought of as a packet-processing
engine that inspects packets traversing networks, either directly or engine that inspects packets traversing networks, either directly or
in the context of flows with which the packet is associated. From in the context of flows with which the packet is associated. From
the perspective of packet-processing, implementations differ in the the perspective of packet-processing, implementations differ in the
depths of packet headers and/or payloads they can inspect, the depths of packet headers and/or payloads they can inspect, the
various flow and context states they can maintain, and the actions various flow and context states they can maintain, and the actions
that can be applied to the packets or flows. 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 Content security is another category of security Capabilities
applied to the application layer. Through analyzing traffic contents applied to the application layer. Through analyzing traffic contents
carried in, for example, the application layer, Capabilities can be carried in, for example, the application layer, content security
used to identify various security functions that are required, such Capabilities can be used to identify various security functions that
as defending against intrusion, inspecting for viruses, filtering are required. These include defending against intrusion, inspecting
malicious URL or junk email, blocking illegal web access, or for viruses, filtering malicious URL or junk email, blocking illegal
preventing malicious data retrieval. web access, or preventing malicious data retrieval.
Generally, each type of threat in the content security category has Generally, each type of threat in the content security category has
a set of unique characteristics, and requires handling using a set a set of unique characteristics, and requires handling using a set
of methods that are specific to that type of content. Thus, these of methods that are specific to that type of content. Thus, these
NSFs will be characterized by their own content- specific security Capabilities will be characterized by their own content-specific
Capabilities. 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 This category of security Capabilities is used to detect and mitigate
various types of network attacks. Today's common network attacks can various types of network attacks. Today's common network attacks can
be classified into the following sets: be classified into the following sets:
o DDoS attacks: o DDoS attacks:
- Network layer DDoS attacks: Examples include SYN flood, UDP - Network layer DDoS attacks: Examples include SYN flood, UDP
flood, ICMP flood, IP fragment flood, IPv6 Routing header flood, ICMP flood, IP fragment flood, IPv6 Routing header
attack, and IPv6 duplicate address detection attack; attack, and IPv6 duplicate address detection attack;
- Application layer DDoS attacks: Examples include HTTP flood, - Application layer DDoS attacks: Examples include HTTP flood,
skipping to change at page 17, line 53 skipping to change at page 18, line 29
- Scanning and sniffing attacks: IP sweep, port scanning, etc. - Scanning and sniffing attacks: IP sweep, port scanning, etc.
- malformed packet attacks: Ping of Death, Teardrop, etc. - malformed packet attacks: Ping of Death, Teardrop, etc.
- special packet attacks: Oversized ICMP, Tracert, IP timestamp - special packet attacks: Oversized ICMP, Tracert, IP timestamp
option packets, etc. option packets, etc.
Each type of network attack has its own network behaviors and Each type of network attack has its own network behaviors and
packet/flow characteristics. Therefore, each type of attack needs a packet/flow characteristics. Therefore, each type of attack needs a
special security function, which is advertised as a set of special security function, which is advertised as a set of
Capabilities, for detection and mitigation. The implementation and Capabilities, for detection and mitigation. The implementation and
management of this category of security Capabilities of attack management of this category of security Capabilities of attack
mitigation control is very similar to content security control. A mitigation control is very similar to the content security control
standard interface, through which the security controller can category. A standard interface, through which the security controller
choose and customize the given security Capabilities according to can choose and customize the given security Capabilities according to
specific requirements, is essential. specific requirements, is essential.
4. Information Sub-Model for Network Security Capabilities 4. Information Sub-Model for Network Security Capabilities
The purpose of the Capability Information Sub-Model is to define the The purpose of the Capability Information Sub-Model is to define the
concept of a Capability, and enable Capabilities to be aggregated to concept of a Capability, and enable Capabilities to be aggregated to
appropriate objects. The following sections present the Network appropriate objects. The following sections present the Network
Security, Content Security, and Attack Mitigation Capability Security, Content Security, and Attack Mitigation Capability
sub-models. sub-models.
skipping to change at page 18, line 31 skipping to change at page 19, line 16
+---------------+ 1..n 1..n | | +---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass | | |/ \ \| A Common Superclass |
| ECAPolicyRule + A -------------+ for ECA Objects | | ECAPolicyRule + A -------------+ for ECA Objects |
| |\ / /| | | |\ / /| |
+-------+-------+ +---------+-----------+ +-------+-------+ +---------+-----------+
/ \ / \ / \ / \
| | | |
| | | |
(subclasses to define Network (subclasses of Event, (subclasses to define Network (subclasses of Event,
Security ECA Policy Rules Condition, and Action Objects Security ECA Policy Rules Condition, and Action Objects
with some extension, for Network Security) extensibly, so that other for Network Security
such as InspectTraffic) Policy Rules can be added) Policy Rules)
Figure 2. Network Security Information Sub-Model Overview Figure 2. Network Security Information Sub-Model Overview
In the above figure, the ECAPolicyRule, along with the Event, In the above figure, the ECAPolicyRule, along with the Event,
Condition, and Action Objects, are defined in the external ECA Condition, and Action Objects, are defined in the external ECA
Information Model. The Network Security Sub-Model extends all of Information Model. The Network Security Sub-Model extends all of
these objects in order to define security-specific ECA policy rules, these objects in order to define security-specific ECA Policy Rules,
as well as extensions to the (generic) Events, Conditions, and as well as extensions to the (generic) Event, Condition, and
Action objects. Action objects.
An I2NSF Policy Rule is a special type of Policy Rule that is in 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, event-condition-action (ECA) form. It consists of the Policy Rule,
components of a Policy Rule (e.g., events, conditions, actions, and components of a Policy Rule (e.g., events, conditions, actions, and
some extensions like resolution policy, default action and external some extensions like resolution policy, default action and external
data), and optionally, metadata. It can be applied to both uni- and data), and optionally, metadata. It can be applied to both uni- and
bi-directional traffic across the NSF. bi-directional traffic across the NSF.
Each rule is triggered by one or more events. If the set of events Each rule is triggered by one or more events. If the set of events
skipping to change at page 19, line 12 skipping to change at page 19, line 47
true, enable a set of actions to be executed. This takes the true, enable a set of actions to be executed. This takes the
following conceptual form: following conceptual form:
IF <event-clause> is TRUE IF <event-clause> is TRUE
IF <condition-clause> is TRUE IF <condition-clause> is TRUE
THEN execute <action-clause> THEN execute <action-clause>
END-IF END-IF
END-IF END-IF
In the above example, the Event, Condition, and Action portions of a 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<minBW)))
Note that Metadata, such as Capabilities, can be aggregated by I2NSF Note that Metadata, such as Capabilities, can be aggregated by I2NSF
ECA Policy Rules. ECA Policy Rules.
4.1.1. Network Security Policy Rule Extensions 4.1.1. Network Security Policy Rule Extensions
Figure 3 shows an example of more detailed design of the ECA Policy Figure 3 shows an example of more detailed design of the ECA Policy
Rule subclasses that are contained in the Network Security Rule subclasses that are contained in the Network Security
Information Sub-Model, which just illustrates how more specific Information Sub-Model, which just illustrates how more specific
Network Security Policies are inherited and extended from the Network Security Policies are inherited and extended from the
skipping to change at page 20, line 52 skipping to change at page 21, line 39
respectively. Events, Conditions, and Actions can be generic or respectively. Events, Conditions, and Actions can be generic or
security-specific. security-specific.
Brief class descriptions of these six ECA Policy Rules are provided Brief class descriptions of these six ECA Policy Rules are provided
in Appendix A. in Appendix A.
4.1.2. Network Security Policy Rule Operation 4.1.2. Network Security Policy Rule Operation
A Network Security Policy consists of one or more ECA Policy Rules A Network Security Policy consists of one or more ECA Policy Rules
formed from the information model described above. In simpler cases, formed from the information model described above. In simpler cases,
where the Event and Condition clauses remain unchanged, then network where the Event and Condition clauses remain unchanged, then the
security may be performed by calling additional network security action of one Policy Rule may invoke additional network security
actions. Network security policy examines and performs basic actions from other Policy Rules. Network security policy examines
processing of the traffic as follows: and performs basic processing of the traffic as follows:
1. The NSF evaluates the Event clause of a given 1. The NSF evaluates the Event clause of a given
SecurityECAPolicyRule (which can be generic or specific to SecurityECAPolicyRule (which can be generic or specific to
security, such as those in Figure 3). It may use security security, such as those in Figure 3). It may use security
Event objects to do all or part of this evaluation, which are Event objects to do all or part of this evaluation, which are
defined in section 4.1.3. If the Event clause evaluates to defined in section 4.1.3. If the Event clause evaluates to
TRUE, then the Condition clause of this SecurityECAPolicyRule TRUE, then the Condition clause of this SecurityECAPolicyRule
is evaluated; otherwise, the execution of this is evaluated; otherwise, the execution of this
SecurityECAPolicyRule is stopped, and the next SecurityECAPolicyRule is stopped, and the next
SecurityECAPolicyRule (if one exists) is evaluated. SecurityECAPolicyRule (if one exists) is evaluated.
skipping to change at page 22, line 10 skipping to change at page 22, line 51
One policy or rule can be applied multiple times to different One policy or rule can be applied multiple times to different
managed objects (e.g., links, devices, networks, VPNS). This not managed objects (e.g., links, devices, networks, VPNS). This not
only guarantees consistent policy enforcement, but also decreases only guarantees consistent policy enforcement, but also decreases
the configuration workload. the configuration workload.
4.1.3. Network Security Event Sub-Model 4.1.3. Network Security Event Sub-Model
Figure 4 shows a more detailed design of the Event subclasses that Figure 4 shows a more detailed design of the Event subclasses that
are contained in the Network Security Information Sub-Model. are contained in the Network Security Information Sub-Model.
The four Event classes shown in Figure 4 extend the (external)
generic Event class to represent Events that are of interest to
Network Security. It is assumed that the (external) generic Event
class defines basic Event information in the form of attributes,
such as a unique event ID, a description, as well as the date and
time that the event occurred.
+---------------------+ +---------------------+
+---------------+ 1..n 1..n| | +---------------+ 1..n 1..n| |
| |/ \ \| A Common Superclass | | |/ \ \| A Common Superclass |
| ECAPolicyRule + A ---------+ for ECA Objects | | ECAPolicyRule + A ---------+ for ECA Objects |
| |\ / /| | | |\ / /| |
+---------------+ +---------+-----------+ +---------------+ +---------+-----------+
/ \ / \
| |
| |
+---------------+-----------+------+ +---------------+-----------+------+
| | | | | |
| | | | | |
+-----+----+ +------+------+ +-----+-----+ +-----+----+ +------+------+ +-----+-----+
| An Event | | A Condition | | An Action | | An Event | | A Condition | | An Action |
| Class | | Class | | Class | | Class | | Class | | Class |
+-----+----+ +-------------+ +-----------+ +-----+----+ +-------------+ +-----------+
/ \ / \
| |
| |
|
+-----+---------+----------------+--------------+-- ... +-----+---------+----------------+--------------+-- ...
| | | | | | | |
| | | | | | | |
+-------+----+ +--------+-----+ +--------+-----+ +------+-----+ +-------+----+ +--------+-----+ +--------+-----+ +------+-----+
|UserSecurity| | Device | | System | |TimeSecurity| |UserSecurity| | Device | | System | |TimeSecurity|
| Event | | SecurityEvent| | SecurityEvent| | Event | | Event | | SecurityEvent| | SecurityEvent| | Event |
+------------+ +--------------+ +--------------+ +------------+ +------------+ +--------------+ +--------------+ +------------+
Figure 4. Network Security Info Sub-Model Event Class Extensions Figure 4. Network Security Info Sub-Model Event Class Extensions
The four Event classes shown in Figure 4 extend the (external)
generic Event class to represent Events that are of interest to
Network Security. It is assumed that the (external) generic Event
class defines basic Event information in the form of attributes,
such as a unique event ID, a description, as well as the date and
time that the event occurred.
The following are assumptions that define the functionality of the The following are assumptions that define the functionality of the
generic Event class. If desired, these could be defined as generic Event class. If desired, these could be defined as
attributes in a SecurityEvent class (which would be a subclass of attributes in a SecurityEvent class (which would be a subclass of
the generic Event class, and a superclass of the four Event classes the generic Event class, and a superclass of the four Event classes
shown in Figure 4). However, this makes it harder to use any shown in Figure 4). However, this makes it harder to use any
generic Event model with the I2NSF events. Assumptions are: generic Event model with the I2NSF events. Assumptions are:
- All four SecurityEvent subclasses are concrete - All four SecurityEvent subclasses are concrete
- The generic Event class uses the composite pattern, so - The generic Event class uses the composite pattern, so
individual Events as well as hierarchies of Events are individual Events as well as hierarchies of Events are
skipping to change at page 24, line 5 skipping to change at page 24, line 38
Condition class is abstract, so that data model optimizations may be Condition class is abstract, so that data model optimizations may be
defined. It is also assumed that the generic Condition class defines defined. It is also assumed that the generic Condition class defines
basic Condition information in the form of attributes, such as a basic Condition information in the form of attributes, such as a
unique object ID, a description, as well as a mechanism to attach unique object ID, a description, as well as a mechanism to attach
zero or more metadata objects to it. While this could be defined as zero or more metadata objects to it. While this could be defined as
attributes in a SecurityCondition class (which would be a subclass attributes in a SecurityCondition class (which would be a subclass
of the generic Condition class, and a superclass of the six of the generic Condition class, and a superclass of the six
Condition classes shown in Figure 5), this makes it harder to use Condition classes shown in Figure 5), this makes it harder to use
any generic Condition model with the I2NSF conditions. any generic Condition model with the I2NSF conditions.
*** Note to WG:
*
* The design in Figure 5 represents the simplest conceptual design
* for describing Security Conditions. An alternative model would be
* to use a software pattern (e.g., the Decorator pattern); this would
* result in the SecurityCondition class being "wrapped" by one or
* more of the six subclasses shown in Figure 5. The advantage of such
* a pattern is to reduce the number of active objects at runtime, as
* well as offer the ability to combine multiple conditions of
* different types into one. The disadvantage is that it is a more
* complex software design.
* The design team is requesting feedback from he WG regarding this.
*
*** End of Note to WG
+---------------------+ +---------------------+
+---------------+ 1..n 1..n | | +---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass | | |/ \ \| A Common Superclass |
| ECAPolicyRule+ A -------------+ for ECA Objects | | ECAPolicyRule+ A -------------+ for ECA Objects |
| |\ / /| | | |\ / /| |
+-------+-------+ +-----------+---------+ +-------+-------+ +-----------+---------+
/ \ / \
| |
| |
+--------------+----------+----+ +--------------+----------+----+
skipping to change at page 24, line 40 skipping to change at page 25, line 39
| Condition | | | Condition | | | Condition | | | Condition | | | Condition | | | Condition | |
+-----------+ | +---------------+ | +------------+ | +-----------+ | +---------------+ | +------------+ |
| | | | | |
+------+-------+ +----------+------+ +--------+-------+ +------+-------+ +----------+------+ +--------+-------+
| UserSecurity | | SecurityContext | | GenericContext | | UserSecurity | | SecurityContext | | GenericContext |
| Condition | | Condition | | Condition | | Condition | | Condition | | Condition |
+--------------+ +-----------------+ +----------------+ +--------------+ +-----------------+ +----------------+
Figure 5. Network Security Info Sub-Model Condition Class Extensions Figure 5. Network Security Info Sub-Model Condition Class Extensions
*** Note to WG:
*
* The design in Figure 5 represents the simplest conceptual design
* for describing Security Conditions. An alternative model would be
* to use a software pattern (e.g., the Decorator pattern); this would
* result in the SecurityCondition class being "wrapped" by one or
* more of the six subclasses shown in Figure 5. The advantage of such
* a pattern is to reduce the number of active objects at runtime, as
* well as offer the ability to combine multiple conditions of
* different types into one. The disadvantage is that it is a more
* complex software design.
* The design team is requesting feedback from he WG regarding this.
*
*** End of Note to WG
Brief class descriptions are provided in Appendix C. Brief class descriptions are provided in Appendix C.
4.1.5. Network Security Action Sub-Model 4.1.5. Network Security Action Sub-Model
Figure 6 shows a more detailed design of the Action subclasses that Figure 6 shows a more detailed design of the Action subclasses that
are contained in the Network Security Information Sub-Model. are contained in the Network Security Information Sub-Model.
The four Action classes shown in Figure 6 extend the (external)
generic Action class to represent Actions that perform a Network
Security Control function.
The three Action classes shown in Figure 6 extend the (external)
generic Action class to represent Actions that are of interest to
Network Security. It is assumed that the (external) generic Action
class is abstract, so that data model optimizations may be defined.
+---------------------+ +---------------------+
+---------------+ 1..n 1..n | | +---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass | | |/ \ \| A Common Superclass |
| ECAPolicyRule+ A -------------+ for ECA Objects | | ECAPolicyRule+ A -------------+ for ECA Objects |
| |\ / /| | | |\ / /| |
+---------------+ +-----------+---------+ +---------------+ +-----------+---------+
/ \ / \
| |
| |
+--------------+--------+------+ +--------------+--------+------+
skipping to change at page 25, line 39 skipping to change at page 26, line 34
+-----------------+---------------+------- ... +-----------------+---------------+------- ...
| | | | | |
| | | | | |
+---+-----+ +----+---+ +------+-------+ +---+-----+ +----+---+ +------+-------+
| Ingress | | Egress | | ApplyProfile | | Ingress | | Egress | | ApplyProfile |
| Action | | Action | | Action | | Action | | Action | | Action |
+---------+ +--------+ +--------------+ +---------+ +--------+ +--------------+
Figure 6. Network Security Info Sub-Model Action Extensions Figure 6. Network Security Info Sub-Model Action Extensions
The four Action classes shown in Figure 6 extend the (external)
generic Action class to represent Actions that perform a Network
Security Control function.
The three Action classes shown in Figure 6 extend the (external)
generic Action class to represent Actions that are of interest to
Network Security. It is assumed that the (external) generic Action
class is abstract, so that data model optimizations may be defined.
It is also assumed that the generic Action class defines basic It is also assumed that the generic Action class defines basic
Action information in the form of attributes, such as a unique Action information in the form of attributes, such as a unique
object ID, a description, as well as a mechanism to attach zero or object ID, a description, as well as a mechanism to attach zero or
more metadata objects to it. While this could be defined as more metadata objects to it. While this could be defined as
attributes in a SecurityAction class (which would be a subclass of attributes in a SecurityAction class (which would be a subclass of
the generic Action class, and a superclass of the six Action classes the generic Action class, and a superclass of the six Action classes
shown in Figure 6), this makes it harder to use any generic Action shown in Figure 6), this makes it harder to use any generic Action
model with the I2NSF actions. model with the I2NSF actions.
*** Note to WG *** Note to WG
* The design in Figure 6 represents the simplest conceptual design * The design in Figure 6 represents the simplest conceptual design
* for describing Security Actions. An alternative model would be to * for describing Security Actions. An alternative model would be to
* use a software pattern (e.g., the Decorator pattern); this would * use a software pattern (e.g., the Decorator pattern); this would
* result in the SecurityAction class being "wrapped" by one or more * result in the SecurityAction class being "wrapped" by one or more
* of the three subclasses shown in Figure 6. The advantage of such a * of the three subclasses shown in Figure 6. The advantage of such a
* pattern is to reduce the number of active objects at runtime, as * pattern is to reduce the number of active objects at runtime, as
* well as offer the ability to combine multiple actions of different * well as offer the ability to combine multiple actions of different
* types into one. The disadvantage is that it is a more complex * types into one. The disadvantage is that it is a more complex
* software design. * software design.
* The design team is requesting feedback from the WG regarding this. * The design team is requesting feedback from the WG regarding this.
*
*** End of Note to WG *** End of Note to WG
Brief class descriptions are provided in Appendix D. Brief class descriptions are provided in Appendix D.
4.2. Information Model for I2NSF Capabilities 4.2. Information Model for I2NSF Capabilities
The I2NSF Capability Model is made up of a number of Capabilities The I2NSF Capability Model is made up of a number of Capabilities
that represent various content security and attack mitigation that represent various content security and attack mitigation
functions. Each Capability protects against a specific type of functions. Each Capability protects against a specific type of
threat in the application layer. This is shown in Figure 7. threat in the application layer. This is shown in Figure 7.
+-------------------------+ 0..n 0..n +---------------+ +-------------------------+ 0..n 0..n +---------------+
| |/ \ \| External | | |/ \ \| External |
| External ECA Info Model + A ----------------+ Metadata | | External ECA Info Model + A ----------------+ Metadata |
| |\ / Aggregates /| Info Model | | |\ / Aggregates /| Info Model |
+-------+-----------------+ Metadata +-----+---------+ +----+--------------------+ Metadata +-----+---------+
| / \ | / \
| | | |
/ \ | / \ |
Subclasses +---------------------------------+--------------+ Subclasses +------------------------------------+-----------+
derived | Capability | | derived | Capability | |
for I2NSF | Sub-Model +----------+---------+ | for I2NSF | Sub-Model +----------+---------+ |
| | SecurityCapability | | Policy Rules | | SecurityCapability | |
| +----------+---------+ | | +----------+---------+ |
| | | | | |
| | | | | |
| +----------------------+---+ | | +----------------------+---+ |
| | | | | | | |
| +--------+---------+ +----------+--------+ | | +--------+---------+ +----------+--------+ |
| | Content Security | | Attack Mitigation | | | | Content Security | | Attack Mitigation | |
| + Capabilities | | Capabilities | | | | Capabilities | | Capabilities | |
| +------------------+ +-------------------+ | | +------------------+ +-------------------+ |
+------------------------------------------------+ +------------------------------------------------+
Figure 7. I2NSF Security Capability High-Level Model Figure 7. I2NSF Security Capability High-Level Model
Figure 7 shows a common I2NSF Security Capability class, called Figure 7 shows a common I2NSF Security Capability class, called
SecurityCapability. This enables us to add common attributes, SecurityCapability. This enables us to add common attributes,
relationships, and behavior to this class without affecting the relationships, and behavior to this class without affecting the
design of the external metadata information model. design of the external metadata information model. All I2NSF
Security Capabilities are then subclassed from the
All I2NSF Security Capabilities are then subclassed from the
SecuritCapability class. SecuritCapability class.
Note: the SecurityCapability class will be defined in the next Note: the SecurityCapability class will be defined in the next
version of this draft, after feedback from the WG is obtained. version of this draft, after feedback from the WG is obtained.
4.3. Information Model for Content Security Capabilities 4.3. Information Model for Content Security Capabilities
Content security is composed of a number of distinct security Content security is composed of a number of distinct security
functions; each such function protects against a specific type of Capabilities; each such Capability protects against a specific type
threat in the application layer. Content security is a type of of threat in the application layer. Content security is a type of
Generic Network Security Function, which summarizes a well-defined Generic Network Security Function (GNSF), which summarizes a
set of security Capabilities, and was shown in Figure 7. Figure 8 well-defined set of security Capabilities, and was shown in Figure 7.
shows exemplary types of content security Generic Network
Security Function. Figure 8 shows exemplary types of the content security GNSF.
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| +--------------------+ | | +--------------------+ |
| Capability | SecurityCapability | | | Capability | SecurityCapability | |
| Sub-Model: +---------+----------+ | | Sub-Model: +---------+----------+ |
| Content Security / \ | | Content Security / \ |
| | | | | |
| | | | | |
| +-------+----------+----------+---------------+ | | +-------+----------+----------+---------------+ |
| | | | | | | | | | | |
skipping to change at page 28, line 11 skipping to change at page 28, line 46
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 8. Network Security Capability Information Model Figure 8. Network Security Capability Information Model
The detailed description about a standard interface, and the The detailed description about a standard interface, and the
parameters for all the security Capabilities of this category, will parameters for all the security Capabilities of this category, will
be defined in a future version of this document. be defined in a future version of this document.
4.4. Information Model for Attack Mitigation Capabilities 4.4. Information Model for Attack Mitigation Capabilities
Attack mitigation is composed of a number of Generic Network Security Attack mitigation is composed of a number of GNSFs; each one
Functions; each one protects against a specific type of network protects against a specific type of network attack. Attack
attack. Attack Mitigation security is a type of Generic Network Mitigation security is a type of GNSF, which summarizes a
Security Function, which summarizes a well-defined set of security well-defined set of security Capabilities, and was shown in
Capabilities, and was shown in Figure 7. Figure 9 shows exemplary Figure 7. Figure 9 shows exemplary types of Attack Mitigation GNSFs.
types of Attack Mitigation Generic Network Security Functions.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| +--------------------+ | | +--------------------+ |
| Capability | SecurityCapability | | | Capability | SecurityCapability | |
| Sub-Model: +---------+----------+ | | Sub-Model: +---------+----------+ |
| Attack Mitigation / \ | | Attack Mitigation / \ |
| | | | | |
| | | | | |
| +-------+--------+------------+-------------+ | | +-------+--------+------------+-------------+ |
| | | | | | | | | | | |
skipping to change at page 29, line 8 skipping to change at page 30, line 8
Figure 9. Attack Mitigation Capability Information Model Figure 9. Attack Mitigation Capability Information Model
The detailed description about a standard interface, and the The detailed description about a standard interface, and the
parameters for all the security Capabilities of this category, will parameters for all the security Capabilities of this category, will
be defined in a future version of this document. be defined in a future version of this document.
5. Security Considerations 5. Security Considerations
The security Capability policy information sent to NSFs should be The security Capability policy information sent to NSFs should be
protected by the secure communication channel, to ensure its protected by a secure communication channel, to ensure its
confidentiality and integrity. Note that the NSFs and security confidentiality and integrity. Note that the NSFs and security
controller can all be spoofed, which leads to undesirable results controller can all be spoofed, which leads to undesirable results
(e.g., security policy leakage from security controller, or a spoofed (e.g., security policy leakage from security controller, or a spoofed
security controller sending false information to mislead the NSFs). security controller sending false information to mislead the NSFs).
Hence, mutual authentication MUST be supported to protected against Hence, mutual authentication MUST be supported to protected against
this kind of attack. The current mainstream security technologies this kind of threat. The current mainstream security technologies
(i.e., TLS, DTLS, and IPSEC) can be employed to protect against the (i.e., TLS, DTLS, and IPSEC) can be employed to protect against the
above threats. above threats.
In addition, to defend against DDoS attacks caused by a hostile In addition, to defend against DDoS attacks caused by a hostile
security controller sending too many configuration messages to the security controller sending too many configuration messages to the
NSFs, rate limiting or similar mechanisms should be considered. NSFs, rate limiting or similar mechanisms should be considered.
6. IANA Considerations 6. IANA Considerations
TBD TBD
skipping to change at page 30, line 12 skipping to change at page 31, line 12
Aboba, B., and Wood, J., "Authentication, Authorization, and Aboba, B., and Wood, J., "Authentication, Authorization, and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
8.2. Informative References 8.2. Informative References
[RFC2975] [RFC2975]
Aboba, B., et al., "Introduction to Accounting Management", Aboba, B., et al., "Introduction to Accounting Management",
RFC 2975, October 2000. RFC 2975, October 2000.
[I-D.draft-ietf-i2nsf-problem-and-use-cases] [I-D.draft-ietf-i2nsf-problem-and-use-cases]
Hares, S., et.al., "I2NSF Problem Statement and Use cases", Hares, S., et.al., "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-11, March 2017. draft-ietf-i2nsf-problem-and-use-cases-16, May 2017.
[I-D.draft-ietf-i2nsf-framework] [I-D.draft-ietf-i2nsf-framework]
Lopez, E., et.al., "Framework for Interface to Network Security Lopez, E., et.al., "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-04, October, 2016. Functions", draft-ietf-i2nsf-framework-06, July, 2017.
[I-D.draft-ietf-i2nsf-terminology] [I-D.draft-ietf-i2nsf-terminology]
Hares, S., et.al., "Interface to Network Security Functions Hares, S., et.al., "Interface to Network Security Functions
(I2NSF) Terminology", draft-ietf-i2nsf-terminology-03, (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03,
March, 2017 March, 2017
[I-D.draft-ietf-supa-generic-policy-info-model] [I-D.draft-ietf-supa-generic-policy-info-model]
Strassner, J., Halpern, J., van der Meer, S., "Generic Policy Strassner, J., Halpern, J., van der Meer, S., "Generic Policy
Information Model for Simplified Use of Policy Abstractions Information Model for Simplified Use of Policy Abstractions
(SUPA)", Woaft-ietf-supa-generic-policy-info-model-02, (SUPA)", draft-ietf-supa-generic-policy-info-model-03,
October, 2016. May, 2017.
[I-D.draft-zhang-i2nsf-info-model-monitoring]
Zhang, D., et al., "An Information Model for the Monitoring of
Network Security Functions (NSF)",
draft-zhang-i2nsf-info-model-monitoring-02, September, 2016.
[Alshaer] [Alshaer]
Al Shaer, E. and H. Hamed, "Modeling and management of firewall Al Shaer, E. and H. Hamed, "Modeling and management of firewall
policies", 2004. policies", 2004.
[Bas12] [Bas12]
Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access
Control Policy Analysis and Transformation", 2012. Control Policy Analysis and Transformation", 2012.
[Bas15] [Bas15]
Basile, C. and Lioy, A., "Analysis of application-layer filtering Basile, C. and Lioy, A., "Analysis of application-layer filtering
policies with application to HTTP", IEEE/ACM Transactions on policies with application to HTTP", IEEE/ACM Transactions on
Networking, Vol 23, Issue 1, February 2015. Networking, Vol 23, Issue 1, February 2015.
skipping to change at page 54, line 35 skipping to change at page 54, line 35
Conditions are typed predicates concerning a given selector. A Conditions are typed predicates concerning a given selector. A
selector describes the values that a protocol field may take. For selector describes the values that a protocol field may take. For
example, the IP source selector is the set of all possible IP 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 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 values come from (e.g., the IP source selector refers to the IP
source field in the IP header). Geometrically, a condition is the source field in the IP header). Geometrically, a condition is the
subset of its selector for which it evaluates to true. A condition 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 on a given selector matches a packet if the value of the field
referred to by the selector belongs to the condition. For instance, 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 in Figure 17 the conditions are s1 <= S1 (read as s1 subset of or
equal to S1) and s2 <= S2 (s1 of or equal to S2), both s1 and s2 equal to S1) and s2 <= S2 (s2 subset of or equal to S2), both s1 and
match the packet x1, while only s2 matches x2. s2 match the packet x1, while only s2 matches x2.
To consider conditions in different selectors, the decision space is To consider conditions in different selectors, the decision space is
extended using the Cartesian product because distinct selectors extended using the Cartesian product because distinct selectors
refer to different fields, possibly from different protocol headers. refer to different fields, possibly from different protocol headers.
Hence, given a policy-enabled element that allows the definition of Hence, given a policy-enabled element that allows the definition of
conditions on the selectors S1, S2,..., Sm (where m is the number conditions on the selectors S1, S2,..., Sm (where m is the number
of Selectors available at the security control we want to model), of Selectors available at the security control we want to model),
its selection space is: its selection space is:
S=S1 X S2 X ... X Sm S=S1 X S2 X ... X Sm
 End of changes. 61 change blocks. 
145 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/