draft-ietf-i2nsf-capability-00.txt   draft-ietf-i2nsf-capability-01.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: March 29, 2018 C. Basile Expires: October 3, 2018 C. Basile
PoliTO PoliTO
D. Lopez D. Lopez
TID TID
Sep 29, 2017 April 3, 2018
Information Model of NSFs Capabilities Information Model of NSFs Capabilities
draft-ietf-i2nsf-capability-00.txt draft-ietf-i2nsf-capability-01.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 March 29, 2018. This Internet-Draft will expire on October 3, 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 18 skipping to change at page 4, line 18
D.1. IngressAction ............................................ 53 D.1. IngressAction ............................................ 53
D.2. EgressAction ............................................. 53 D.2. EgressAction ............................................. 53
D.3. ApplyProfileAction ....................................... 53 D.3. ApplyProfileAction ....................................... 53
Appendix E. Geometric Model ...................................... 54 Appendix E. Geometric Model ...................................... 54
Authors' Addresses ............................................... 57 Authors' Addresses ............................................... 57
1. Introduction 1. Introduction
The rapid development of virtualized systems requires advanced The rapid development of virtualized systems requires advanced
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 equipments 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]. [RFC8192].
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-related Security Capabilities describe the set of network security-related
features 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 required 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 functionality characterized by their network; rather, the functionality characterized by their
Capabilities are considered. Capabilities are considered.
According to [I-D.draft-ietf-i2nsf-framework], there are two types According to [RFC8329], there are two types of I2NSF interfaces
of I2NSF interfaces available for security policy provisioning: 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 from is to decouple the specification of security services from
their implementation. their implementations.
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). This document defines an Machines or physical appliances). This document defines an
object-oriented information model for network security, content object-oriented information model for network security, content
security, and attack mitigation Capabilities, along with security, and attack mitigation Capabilities, along with
skipping to change at page 6, line 33 skipping to change at page 6, line 33
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. Capability Information 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 functionalities, 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:
o Independence: each security Capability should be an independent o Independence: each security Capability should be an independent
function, with minimum overlap or dependency on other function, with minimum overlap or dependency on other
Capabilities. This enables each security Capability to be Capabilities. This enables each security Capability to be
utilized and assembled together freely. More importantly, utilized and assembled together freely. More importantly,
changes to one Capability will not affect other Capabilities. changes to a Capability will not affect other Capabilities.
This follows the Single Responsibility Principle This follows the Single Responsibility Principle
[Martin] [OODSRP]. [Martin] [OODSRP].
o Abstraction: each Capability should be defined in a vendor- o Abstraction: each Capability should be defined in a vendor-
independent manner, and associated to a well-known interface independent manner, and associated to a well-known interface
to provide a standardized ability to describe and report its to provide a standardized ability to describe and report its
processing results. This facilitates multi-vendor processing results. This facilitates multi-vendor
interoperability. interoperability.
o Automation: the system must have the ability to auto-discover, o Automation: the system has to discover, negotiate, and update its
auto-negotiate, and auto-update its security Capabilities security Capabilities automatically (i.e., without human
(i.e., without human intervention). These features are intervention). These features are useful especially for the
especially useful for the management of a large number of management of a large number of NSFs. They are essential to add
NSFs. They are essential to add smart services (e.g., analysis, smart services (e.g., analysis, refinement, Capability reasoning,
refinement, Capability reasoning, and optimization) for the and optimization) for the security scheme employed. These
security scheme employed. These features are supported by many features are supported by many design patterns, including the
design patterns, including the Observer Pattern [OODOP], the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a set
Mediator Pattern [OODMP], and a set of Message Exchange of Message Exchange Patterns [Hohpe].
Patterns [Hohpe].
o Scalability: the management system must have the Capability to o Scalability: the management system must have the Capability to
scale up/down or scale in/out. Thus, it can meet various scale up/down or scale in/out. Thus, it can meet various
performancerequirements derived from changeable network traffic performance requirements derived from changeable network traffic
or service requests. In addition, security Capabilities that are or service requests. In addition, security Capabilities that are
affected by scalability changes must support reporting statistics affected by scalability changes must support reporting statistics
to the security controller to assist its decision on whether it to the security controller to assist its decision on whether it
needs to invoke scaling or not. However, this requirement is for needs to invoke scaling or not. However, this requirement is for
information only, and is beyond the scope of this document. information only, and is beyond the scope of this document.
Based on the above principles, a set of abstract and vendor-neutral Based on the above principles, a set of abstract and vendor-neutral
Capabilities with standard interfaces is defined. This provides a Capabilities with standard interfaces is defined. This provides a
Capability model that enables a set of NSFs that are required at a Capability model that enables a set of NSFs that are required at a
given time to be selected, as well as the unambiguous definition of given time to be selected, as well as the unambiguous definition of
the security offered by the set of NSFs used. The security the security offered by the set of NSFs used. The security
controller can compare the requirements of users and applications to controller can compare the requirements of users and applications to
the set of Capabilities that are currently available in order to the set of Capabilities that are currently available in order to
choose which NSFs are needed to meet those requirements. Note that choose which NSFs are needed to meet those requirements. Note that
this choice is independent of vendor, and instead relies specifically this choice is independent of vendor, and instead relies specifically
on the Capabilities (i.e., the description) of the functions on the Capabilities (i.e., the description) of the functions
provided. The security controller may also be able to customize the provided. The security controller may also be able to customize the
functionality of selected NSFs. functionality of selected NSFs.
Furthermore, when an unknown threat (e.g., zero-day exploits and Furthermore, when an unknown threat (e.g., zero-day exploits and
unknown malware) is reported by a NSF, new Capabilities may be unknown malware) is reported by an NSF, new Capabilities may be
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.
3.2. ECA Policy Model Overview 3.2. ECA Policy Model Overview
The "Event-Condition-Action" (ECA) policy model is used as the basis The "Event-Condition-Action" (ECA) policy model is used as the basis
for the design of I2NSF Policy Rules; definitions of all I2NSF for the design of I2NSF Policy Rules; the definitions of the following
policy-related terms are also defined in I2NSF policy-related terms are also specified in
[I-D.draft-ietf-i2nsf-terminology]: [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 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 An I2NSF Policy Rule is made up of three Boolean clauses: an Event
clause, a Condition clause, and an Action clause. A Boolean clause clause, a Condition clause, and an Action clause. A Boolean clause
is a logical statement that evaluates to either TRUE or FALSE. It 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 may be made up of one or more terms; if more than one term, then a
skipping to change at page 8, line 47 skipping to change at page 8, line 47
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.3. 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 by using
the following approach: the following approaches:
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
the management system; the management system;
2) The security controller selects the set of Capabilities 2) The security controller selects the set of Capabilities
required to meet the needs of the security service from all required to meet the needs of the security service from all
available NSFs that it manages; available NSFs that it manages;
3) The security controller uses the Capability information model 3) The security controller uses the Capability information model
to match chosen Capabilities to NSFs, independent of vendor; to match chosen Capabilities to NSFs, independent of vendor;
skipping to change at page 9, line 18 skipping to change at page 9, line 18
creates or uses one or more data models from the Capability creates or uses one or more data models from the Capability
information model to manage the NSFs; information model to manage the NSFs;
5) Control and monitoring can then begin. 5) Control and monitoring can then begin.
This assumes that an external information model is used to define This assumes that an external information model is used to define
the concept of an ECA Policy Rule and its components (e.g., Event, the concept of an ECA Policy Rule and its components (e.g., Event,
Condition, and Action objects). This enables I2NSF Policy Rules Condition, and Action objects). This enables I2NSF Policy Rules
[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 (i.e., information that describes, and/or prescribes, of metadata (i.e., information that describes, and/or prescribes,
the behavior of objects); hence, it is also assumed that an external the behavior of objects); hence, it is also assumed that an external
information model is used to define metadata (preferably, in the information model is used to define metadata (preferably, in the
form of a class hierarchy). Therefore, it is assumed that form of a class hierarchy). Therefore, it is assumed that
skipping to change at page 10, line 20 skipping to change at page 10, line 20
type of extensions are required to the generic, external, ECA type of extensions are required to the generic, external, ECA
information model and metadata models, in order to manage the information model and metadata models, in order to manage the
lifecycle of I2NSF Capabilities. 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 classes The external ECA Information Model supplies at least one set of classes
that represent a generic ECA Policy Rule, and a set of classes that 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 refine it (i.e., generic model for different purposes, as well as refine it (i.e.,
create new subclasses, or add attributes and relationships) to create new subclasses, or add attributes and relationships) to
represent I2NSF-specific concepts. 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;
skipping to change at page 13, line 46 skipping to change at page 13, line 46
specific functions. These generic functions represent a point of specific functions. These generic functions represent a point of
interoperability, and can be provided by any product that offers the interoperability, and can be provided by any product that offers the
required Capabilities. GNSF examples include packet filter, URL required Capabilities. GNSF examples include packet filter, URL
filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content filter, 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 an NSF has the
Capabilities needed to enforce policies. Capabilities needed to enforce policies.
3.4.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
skipping to change at page 14, line 25 skipping to change at page 14, line 25
different. However, consider these two policies: different. However, consider these two policies:
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 are 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
conflict matrix 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={}
skipping to change at page 19, line 37 skipping to change at page 19, line 37
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
evaluates to true, then a set of conditions are evaluated and, if evaluates to true, then a set of conditions are evaluated and, if
true, enable a set of actions to be executed. This takes the true, then 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**. Hence, they can contain Policy Rule are all **Boolean Clauses**. Hence, they can contain
skipping to change at page 21, line 49 skipping to change at page 21, line 49
where the Event and Condition clauses remain unchanged, then the where the Event and Condition clauses remain unchanged, then the
action of one Policy Rule may invoke additional network security action of one Policy Rule may invoke additional network security
actions from other Policy Rules. Network security policy examines actions from other Policy Rules. Network security policy examines
and performs basic 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 be 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.
2. The Condition clause is then evaluated. It may use security 2. The Condition clause is then evaluated. It may use security
Condition objects to do all or part of this evaluation, which Condition objects to do all or part of this evaluation, which
are defined in section 4.1.4. If the Condition clause are defined in section 4.1.4. If the Condition clause
evaluates to TRUE, it is defined as "matching" the evaluates to TRUE, it is defined as "matching" the
SecurityECAPolicyRule; otherwise, execution of this SecurityECAPolicyRule; otherwise, execution of this
SecurityECAPolicyRule is stopped, and the next SecurityECAPolicyRule is stopped, and the next
skipping to change at page 31, line 10 skipping to change at page 31, line 10
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[RFC3539] [RFC3539]
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] [RFC8192]
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-16, May 2017. RFC8192, July 2017.
[I-D.draft-ietf-i2nsf-framework] [RFC8329]
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-06, July, 2017. Functions", RFC 8329, February 2018.
[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)", draft-ietf-supa-generic-policy-info-model-03, (SUPA)", draft-ietf-supa-generic-policy-info-model-03,
May, 2017. May, 2017.
[Alshaer] [Alshaer]
 End of changes. 25 change blocks. 
38 lines changed or deleted 37 lines changed or added

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