draft-ietf-i2nsf-capability-02.txt   draft-ietf-i2nsf-capability-03.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: January 02, 2019 C. Basile Expires: April 22, 2019 C. Basile
PoliTO PoliTO
D. Lopez D. Lopez
TID TID
July 02, 2018 October 22, 2018
Information Model of NSFs Capabilities Information Model of NSFs Capabilities
draft-ietf-i2nsf-capability-02.txt draft-ietf-i2nsf-capability-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 02, 2019. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 22 skipping to change at page 2, line 22
This draft defines the concept of an NSF (Network Security Function) This draft defines the concept of an NSF (Network Security Function)
capability, as well as its information model. Capabilities are a set capability, as well as its information model. Capabilities are a set
of features that are available from a managed entity, and are of features that are available from a managed entity, and are
represented as data that unambiguously characterizes an NSF. represented as data that unambiguously characterizes an NSF.
Capabilities enable management entities to determine the set of Capabilities enable management entities to determine the set of
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.
Table of Contents Table of Contents
1. Introduction ................................................. 2 1. Introduction ................................................ 3
2. Conventions used in this document ............................ 3 2. Conventions used in this document ........................... 3
2.1. Acronyms ................................................ 3 2.1. Acronyms ............................................... 4
3. Capability Information Model Design .......................... 4 3. Capability Information Model Design ......................... 4
3.1. Design Principles and ECA Policy Model Overview ......... 5 3.1. Design Principles and ECA Policy Model Overview ........ 5
3.2. Relation with the External Information Model ............ 8 3.2. Relation with the External Information Model ........... 8
3.3. I2NSF Capability Information Model Theory of Operation .. 9 3.3. I2NSF Capability Information Model Theory of Operation . 9
3.3.1. I2NSF Capability Information Model ................ 11 3.3.1. I2NSF Capability Information Model ............... 11
3.3.2. The SecurityCapability class ...................... 13 3.3.2. The SecurityCapability class ..................... 14
3.3.3. I2NSF Condition Clause Operator Types ............. 14 3.4. Modelling NSF Features as Security Capabilities ....... 15
3.3.4. Capability Selection and Usage .................... 16 3.4.1. Matched Policy Rule .............................. 15
3.3.5. Capability Algebra ............................... 17 3.4.2. Conflict, Resolution Strategy and Default Action . 16
4. IANA Considerations ......................................... 19 3.4.3. I2NSF Condition Clause Operator Types ............ 17
5. References .................................................. 19 3.4.4. Uses of the capability information model ......... 19
5.1. Normative References ................................... 19 3.4.5. A Syntax to Describe the Capability of an NSF .... 19
5.2. Informative References ................................. 20 3.4.6. Capability Algebra ............................... 20
6. Acknowledgments ............................................. 22 4. Considerations on the Practical Use of the CapIM ........... 21
5. Security Considerations .................................... 22
6. Contributors ............................................... 22
7. Acknowledgements ........................................... 23
8. References ................................................. 23
8.1. Normative References .................................. 23
8.2. Informative References ................................ 24
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 devices in an enterprise network, User Equipment in a mobile
network, devices in the Internet of Things, or residential access network, devices in the Internet of Things, or residential access
users [RFC8192]. users [RFC8192].
NSFs produced by multiple security vendors provide various security NSFs produced by multiple security vendors provide various security
skipping to change at page 3, line 38 skipping to change at page 3, line 43
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 and acronyms used. Section 3 discusses the design principles for
I2NSF capability information model, the related ECA model, and I2NSF capability information model, the related ECA model, and
provides detailed information model design of I2NSF network security provides detailed information model design of I2NSF network security
capability. capability.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC-2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terminology defined in [I-D.draft-ietf-i2nsf- This document uses terminology defined in [I-D.draft-ietf-i2nsf-
terminology] for security related and I2NSF scoped terminology. terminology] for security related and I2NSF scoped terminology.
2.1. Acronyms 2.1. Acronyms
I2NSF - Interface to Network Security Functions I2NSF - Interface to Network Security Functions
NSF - Network Security Function NSF - Network Security Function
skipping to change at page 8, line 46 skipping to change at page 9, line 8
NSFs to be used; NSFs to be used;
4) The security controller takes the above information and creates or 4) The security controller takes the above information and creates or
uses one or more data models from the CapIM to manage the NSFs; uses one or more data models from the CapIM 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 [I- Condition, and Action objects). This enables I2NSF Policy Rules [I-
D.draft-ietf-i2nsf-terminology] to be subclassed from an external D.draft-ietf-i2nsf-terminology] to be sub-classed from an external
information model. information model.
The external ECA Information Model supplies at least a set of The external ECA Information Model supplies at least a set of
objects that represent a generic ECA Policy Rule, and a set of objects that represent a generic ECA Policy Rule, and a set of
objects that represent Events, Conditions, and Actions that can be objects that represent Events, Conditions, and Actions that can be
aggregated by the generic ECA Policy Rule. This enables appropriate aggregated by the generic ECA Policy Rule. This enables appropriate
I2NSF Components to reuse this generic model for different purposes, I2NSF Components to reuse this generic model for different purposes,
as well as specialize it (i.e., create new model objects) to as well as specialize it (i.e., create new model objects) to
represent concepts that are specific to I2NSF and/or an application represent concepts that are specific to I2NSF and/or an application
that is using I2NSF. that is using I2NSF.
It is assumed that the external ECA Information Model also has the It is assumed that the external ECA Information Model also has the
ability to aggregate metadata. This enables metadata to be used to ability to aggregate metadata. This enables metadata to be used to
prescribe and/or describe characteristics and behavior of the ECA prescribe and/or describe characteristics and behavior of the ECA
Policy Rule. Specifically, Capabilities are subclassed from this Policy Rule. Specifically, Capabilities are sub-classed from this
external metadata model. If the desired Capabilities are already external metadata model. If the desired Capabilities are already
defined in the CapIM, then no further action is necessary. defined in the CapIM, then no further action is necessary.
Otherwise, new Capabilities SHOULD be defined either by defining new Otherwise, new Capabilities SHOULD be defined either by defining new
classes that can wrap existing classes using the decorator pattern classes that can wrap existing classes using the decorator pattern
[Gamma] or by another mechanism (e.g., through subclassing); the [Gamma] or by another mechanism (e.g., through sub-classing); the
parent class of the new Capability SHOULD be either an existing parent class of the new Capability SHOULD be either an existing
CapIM metadata class or a class defined in the external metadata CapIM metadata class or a class defined in the external metadata
information model. In either case, the ECA objects can use the information model. In either case, the ECA objects can use the
existing aggregation between them and the Metadata class to add existing aggregation between them and the Metadata class to add
metadata to appropriate ECA objects. 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.3. I2NSF Capability Information Model Theory of Operation
skipping to change at page 10, line 23 skipping to change at page 10, line 30
conjunctive or disjunctive normal form. Informally, conjunctive conjunctive or disjunctive normal form. Informally, conjunctive
normal form expresses a clause as a set of sub-clauses that are normal form expresses a clause as a set of sub-clauses that are
logically ANDed together, where each sub-clause contains only terms logically ANDed together, where each sub-clause contains only terms
that use OR and/or NOT operators). Similarly, disjunctive normal that use OR and/or NOT operators). Similarly, disjunctive normal
form is a set of sub-clauses that are logically ORed together, where form is a set of sub-clauses that are logically ORed together, where
each sub-clause contains only terms that use AND and/or NOT each sub-clause contains only terms that use AND and/or NOT
operators. operators.
This document defines additional important extensions to both the This document defines additional important extensions to both the
external ECA Policy Rule model and the external Metadata model that external ECA Policy Rule model and the external Metadata model that
are used by the I2NSF CapIM; examples include resolution strategy, are used by the I2NSF CapIM; examples include resolution strategy,
external data, and default actions. All these extensions come from external data, and default actions. All these extensions come from
the geometric model defined in [Bas12]. A more detailed description the geometric model defined in [Bas12]. A summary of the important
is provided in Appendix E; a summary of the important points of this points of this geometric model follows.
geometric model follows.
Formally, given a set of actions in an I2NSF Policy Rule, the Formally, given a set of actions in an I2NSF Policy Rule, the
resolution strategy maps all the possible subsets of actions to an resolution strategy maps all the possible subsets of actions to an
outcome. In other words, the resolution strategy is included in an outcome. In other words, the resolution strategy is included in an
I2NSF Policy to decide how to evaluate all the actions from the I2NSF Policy Rule to decide how to evaluate all the actions from the
matching I2NSF Policy Rule. matching I2NSF Policy Rule.
Some concrete examples of resolution strategy are: Some concrete examples of resolution strategy are:
o First Matching Rule (FMR) o First Matching Rule (FMR)
o Last Matching Rule (LMR) o Last Matching Rule (LMR)
o Prioritized Matching Rule (PMR) with Errors (PMRE) o Prioritized Matching Rule (PMR) with Errors (PMRE)
skipping to change at page 10, line 44 skipping to change at page 11, line 4
Some concrete examples of resolution strategy are: Some concrete examples of resolution strategy are:
o First Matching Rule (FMR) o First Matching Rule (FMR)
o Last Matching Rule (LMR) o Last Matching Rule (LMR)
o Prioritized Matching Rule (PMR) with Errors (PMRE) o Prioritized Matching Rule (PMR) with Errors (PMRE)
o Prioritized Matching Rule with No Errors (PMRN) o Prioritized Matching Rule with No Errors (PMRN)
In the above, a PMR strategy is defined as follows: In the above, a PMR strategy is defined as follows:
1. Order all actions by their Priority (highest is first, no 1. Order all actions by their Priority (highest is first, no
priority is last); actions that have the same priority may be priority is last); actions that have the same priority may be
appear in any order in their relative location. appear in any order in their relative location.
2. For PMRE: if any action fails to execute properly, temporarily 2. For PMRE: if any action fails to execute properly, temporarily
stop execution of all actions. Invoke the error handler of the stop execution of all actions. Invoke the error handler of the
failed action. If the error handler is able to recover from the failed action. If the error handler is able to recover from the
error, then continue execution of any remaining actions; else, error, then continue execution of any remaining actions; else,
terminate execution of the ECA Policy Rule. terminate execution of the ECA Policy Rule.
3. For PMRN: if any action fails to execute properly, stop 3. For PMRN: if any action fails to execute properly, stop
execution of all actions. Invoke the error handler of the failed execution of all actions. Invoke the error handler of the failed
action, but regardless of the result, execution of the ECA action, but regardless of the result, execution of the ECA
Policy Rule MUST be terminated. Policy Rule MUST be terminated.
Regardless of the resolution strategy, when no rule matches a Regardless of the resolution strategy, when no rule matches a
packet, a default action MAY be executed. packet, a default action MAY be executed.
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 rule
action and/or policy rule, and associating the policy rule with and/or its action, and associating the policy rule with another
another class to convey such information. class to convey such information.
3.3.1. I2NSF Capability Information Model 3.3.1. I2NSF Capability Information Model
Figure 1 below shows one example of an external model. This is a Figure 1 below shows one example of an external model. This is a
simplified version of the MEF Policy model [PDO]. For our purposes: simplified version of the MEF Policy model [PDO]. For our purposes:
o MCMPolicyObject is an abstract class, and is derived from o MCMPolicyObject is an abstract class, and is derived from
MCMManagedEntity [MCM] MCMManagedEntity [MCM]
o MCMPolicyStructure is an abstract superclass for building o MCMPolicyStructure is an abstract superclass for building
skipping to change at page 13, line 50 skipping to change at page 14, line 48
This enables the HasSecurityCapabilityDetail association class to be This enables the HasSecurityCapabilityDetail association class to be
the target of a Policy Rule. That is, the the target of a Policy Rule. That is, the
HasSecurityCapabilityDetail class has attributes and methods that HasSecurityCapabilityDetail class has attributes and methods that
define which I2NSFSecurityCapabilities of this NSF are visible and define which I2NSFSecurityCapabilities of this NSF are visible and
can be used [MCM]. can be used [MCM].
3.3.2. The SecurityCapability class 3.3.2. The SecurityCapability class
The SecurityCapability class defines the concept of metadata that The SecurityCapability class defines the concept of metadata that
define security-related capabilities. It is subclassed from an define security-related capabilities. It is subclassed from an
appropriate class of an external metadata information appropriate class of an external metadata information model.
model.Subclasses of the SecurityCapability class can be used to Subclasses of the SecurityCapability class can be used to answer the
answer the following questions: following questions:
o What are the events that are caught by the NSF to trigger the o What are the events that are caught by the NSF to trigger the
condition clause evaluation (Event subclass)? condition clause evaluation (Event subclass)?
o What kind of condition clauses can be specified on the NSF to o What kind of condition clauses can be specified on the NSF to
define valid rules? This question splits into two questions: define valid rules? This question splits into two questions:
(1) what are the conditions that can be specified (Condition (1) what are the conditions that can be specified (Condition
subclass), and (2) how to build a valid condition clause from a subclass), and (2) how to build a valid condition clause from a
set of individual conditions (ClauseEvaluation class). set of individual conditions (ClauseEvaluation class).
o What are the actions that the NSF can enforce (Action class)? o What are the actions that the NSF can enforce (Action class)?
o How to define a correct policy on the NSF? o How to define a correct policy on the NSF?
3.3.3. I2NSF Condition Clause Operator Types 3.4. Modelling NSF Features as Security Capabilities
The capability model proposed in this document is intended to
provide a formal framework to describe and process the features of
NSFs, and to evaluate their fitness to a particular purpose,
expressed in terms of a (possibly complex) policy statement. Using
the capability model, NSF providers and users can declare and
manipulate the features of a function or a combination of them.
Specifically, if the NSF has the classification features needed to
identify the packets/flows required by a policy, and can enforce the
needed actions, then that particular NSF is capable of enforcing the
policy. Therefore, capability selection and usage are based on the
set of security traffic classification and action features that an
NSF provides.
NSFs may also have specific characteristics that automatic processes
or administrators need to know when they have to generate
configurations, like the available resolution strategies and the
possibility to set default actions, which are described in Sections
3.4.3.
3.4.1. Matched Policy Rule
The concept of a "matched" policy rule is defined as one in which
its event and condition clauses both evaluate to true. To precisely
describe what an NSF can do in terms of security, the things need to
describe are the events it can catch, the conditions it can
evaluate, and the actions it can enforce.
Therefore, the properties that to characterize the capabilities of a
NSF are as below:
o Ac is the set of Actions currently available from the NSF;
o Ec is the set of Events that an NSF can catch. Note that for NSF
(e.g., a packet filter) that are not able to react to events,
this set will be empty;
o Cc is the set of Conditions currently available from the NSF;
o EVc defines the set of Condition Clause Evaluation Rules that can
be used at the NSF to decide when the Condition Clause is true
given the result of the evaluation of the individual Conditions.
3.4.2. Conflict, Resolution Strategy and Default Action
Formally, two I2NSF Policy Rules conflict with each other if:
o the Event Clauses of each evaluate to TRUE;
o the Condition Clauses of each evaluate to TRUE;
o the Action Clauses affect the same object in different ways.
For example, if we have two Policy Rules in the same Policy:
R1: During 8am-6pm, if traffic is external, then run through FW
R2: During 7am-8pm, conduct anti-malware investigation
There is no conflict between R1 and R2, since the actions are
different. However, consider these two rules:
R3: During 8am-6pm, John gets GoldService
R4: During 10am-4pm, FTP from all users gets BronzeService
R3 and R4 are now in conflict, between the hours of 10am and 4pm,
because the actions of R3 and R4 are different and apply to the same
user (i.e., John).
Conflicts theoretically compromise the correct functioning of
devices (as happened for routers several year ago). However, NSFs
have been designed to cope with these issues. Since conflicts are
originated by simultaneously matching rules, an additional process
decides the action to be applied, e.g., among the ones the matching
rule would have enforced. This process is described by means of a
resolution strategy
On the other hand, it may happen that, if an event is caught, none
of the policy rules matches. As a simple case, no rules may match a
packet arriving at border firewall. In this case, the packet is
usually dropped, that is, the firewall has a default behavior to
manage cases that are not covered by specific rules.
Therefore, we introduce another security capability that serves to
characterize valid policies for an NSF that solve conflicts with
resolution strategies and enforce default actions if no rules match:
o RSc is the set of Resolution Strategy that can be used to specify
how to resolve conflicts that occur between the actions of the
same or different policy rules that are matched and contained in
this particular NSF;
o Dc defines the notion of a Default action. This action can be
either an explicit action that has been chosen {a}, or a set of
actions {F}, where F is a dummy symbol (i.e., a placeholder
value) that can be used to indicate that the default action can
be freely selected by the policy editor. This is denoted as {F} U
{a}.
3.4.3. 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 Condition clause operators/selectors are categorized as
regex-based, and custom-match [Bas15][Lunt]. exact-match, range-based, 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 checked for equality, as no order is defined on them. As an
example, the protocol type field of the IP header is an unordered example, the protocol type field of the IP header is an unordered
set of integer values associated to protocols. The assigned protocol set of integer values associated to protocols. The assigned protocol
numbers are maintained by the IANA numbers are maintained by the IANA
(http://www.iana.org/assignments/protocol-numbers/protocol- (http://www.iana.org/assignments/protocol-numbers/protocol-
numbers.xhtml). numbers.xhtml).
In this selector, it is only meaningful to specify condition clauses In this selector, it is only meaningful to specify condition clauses
skipping to change at page 16, line 11 skipping to change at page 19, line 15
Finally, the idea of a custom check selector is introduced. For Finally, the idea of a custom check selector is introduced. For
instance, malware analysis can look for specific patterns, and instance, malware analysis can look for specific patterns, and
returns a Boolean value if the pattern is found or not. returns a Boolean value if the pattern is found or not.
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 3.4.4. Uses of the capability information model
next versions of the draft. Some examples are already present in
Section 6.
3.3.4. Capability Selection and Usage
Capability selection and usage are based on the set of security
traffic classification and action features that an NSF provides;
these are defined by the capability model. If the NSF has the
classification features needed to identify the packets/flows
required by a policy, and can enforce the needed actions, then that
particular NSF is capable of enforcing the policy.
NSFs may also have specific characteristics that automatic processes
or administrators need to know when they have to generate
configurations, like the available resolution strategies and the
possibility to set default actions.
The capability information model can be used for two purposes: The capability information model can be used for two purposes:
describing the features provided by generic security functions, and describing the features provided by generic security functions, and
describing the features provided by specific products. The term describing the features provided by specific products. The term
Generic Network Security Function (GNSF) refers to the classes of Generic Network Security Function (GNSF) has been used to define
security functions that are known by a particular system. The idea generalized categories of NSFs. The idea is to have generic
is to have generic components whose behavior is well understood, so components whose behavior is well understood, so that the generic
that the generic component can be used even if it has some vendor- component can be used even if it has some vendor-specific functions.
specific functions. These generic functions represent a point of
interoperability, and can be provided by any product that offers the
required capabilities. GNSF examples include packet filter, URL
filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
filter, monitoring, and anonymity proxy; these will be described
later in a revision of this draft as well as in an upcoming data
model contribution.
The next section will introduce the algebra to compose the
information model of capability registration, defined to associate
NSFs to capabilities and to check whether a NSF has the capabilities
needed to enforce policies.
3.3.5. Capability Algebra
We introduce a Capability Algebra to ensure that the actions of
different policy rules do not conflict with each.
Formally, two I2NSF Policy Rules conflict with each other if:
o the event clauses of each evaluate to TRUE
o the condition clauses of each evaluate to TRUE
o the action clauses affect the same object in different ways
For example, if we have two Policy Rules in the same Policy:
R1: During 8am-6pm, if traffic is external, then run through FW
R2: During 7am-8pm, conduct anti-malware investigation
There is no conflict between R1 and R2, since the actions are These generic functions represent a point of interoperability, and
different. However, consider these two rules: can be provided by any product that offers the required
capabilities. GNSF examples include packet filter, URL filter, HTTP
filter, VPN gateway, anti-virus, anti-malware, content filter,
monitoring, and anonymity proxy; these will be described later in a
revision of this draft.
R3: During 8am-6pm, John gets GoldService 3.4.5. A Syntax to Describe the Capability of an NSF
R4: During 10am-4pm, FTP from all users gets BronzeService
R3 and R4 are now in conflict, between the hours of 10am and 4pm, To characterize the behavior of the Policy Rule as specified by the
because the actions of R3 and R4 are different and apply to the same CapIM, a NSF can be associated to its security capabilities by means
user (i.e., John). of a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where Ac, Cc, Ec, RSc, Dc,
and EVc have been described in the previous sections.
Let us define the concept of a "matched" policy rule as one in which As an example, assume that a packet filter capability, Cap_pf, is
its event and condition clauses both evaluate to true. Then, the defined, its, capabilities can be defined as
behavior of the Policy Rule, as specified by the CapIM, is defined
by a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where:
o Ac is the set of Actions currently available from the NSF; Cap_pf = (Apf, Cpf, Epf, RSpf, Dpf, EVpf)
o Cc is the set of Capabilities currently available from the NSF; where:
o Ec is the set of Events that an NSF can catch. Note that for NSF Apf = {Allow, Deny}
(e.g., a packet filter) that are not able to react to events, Cpf = {IPsrc,IPdst,Psrc,Pdst,protType}
this set will be empty; Epf = {}
RSpf = {FMR}
Dpf = {A1}
EVpf = {DNF}
o RSc is the set of Resolution Strategies that can be used to 3.4.6. Capability Algebra
specify how to resolve conflicts that occur between the actions
of the same or different policy rules that are matched and
contained in this particular NSF;
o Dc defines the notion of a Default action. This action can be Assigning capabilities to a large number of NSFs can be a complex
either an explicit action that has been chosen {a}, or a set of (and boring) operation, therefore, this document presents a formal
actions {F}, where F is a dummy symbol (i.e., a placeholder way (Capability Algebra) to define templates and manipulate them for
value) that can be used to indicate that the default action can NSF.
be freely selected by the policy editor. This is denoted as {F} U
{a}.
EVc defines the set of Condition Clause Evaluation Rules that can be Before introducing the capability algebra, we will introduce the
used at the NSF to decide when the condition clause is true given
the result of the evaluation of the individual conditions. Before
introducing the rest of the capability model, we will introduce the
symbols that we will use to represent set operations: symbols that we will use to represent set operations:
o "U" is the union operation, A U B returns a new set that includes o "U" is the union operation, A U B returns a new set that includes
all the elements in A and all the elements in B all the elements in A and all the elements in B
o "\" is the set minus operation, A \ B returns all the elements o "\" is the set minus operation, A \ B returns all the elements
that are in A but not in B. that are in A but not in B.
Given two sets of capabilities, denoted as cap1=(Ac1,Cc1, Given two sets of capabilities, denoted as cap1=(Ac1,Cc1,
Ec1,RSc1,Dc1,EVc1) and cap2=(Ac2,Cc2,Ec2,RSc2,Dc2,EVc2) Ec1,RSc1,Dc1,EVc1) and cap2=(Ac2,Cc2,Ec2,RSc2,Dc2,EVc2)
skipping to change at page 18, line 42 skipping to change at page 20, line 41
\ Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2} \ Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2}
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 the Resolution capabilities and their associated actions. Note that the Resolution
Strategies and Default Actions are added in both cases. Strategies and Default Actions are added in both cases.
As an example, assume that a packet filter capability, Cpf, is As an example, assume that a packet filter capability, Cap_pf, is
defined. Further, assume that a second capability, called Ctime, defined as in a previous section. Further, assume that a second
exists, and that it defines time-based conditions. Suppose we need capability, called Cap_time, exists, and that it defines time-based
to construct a new generic packet filter, Cpfgen, that adds time- conditions. Suppose we need to construct a new generic packet
based conditions to Cpf. Conceptually, this is simply the addition filter, Cap_pfgen, that adds time-based conditions to Cap_pf.
of the Cpf and Ctime capabilities, as follows:
Conceptually, this is simply the addition of the Cap_pf and Cap_time
capabilities, as follows:
Apf = {Allow, Deny} Apf = {Allow, Deny}
Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} Cpf = {IPsrc,IPdst,Psrc,Pdst,protType}
Epf = {} Epf = {}
RSpf = {FMR} RSpf = {FMR}
Dpf = {A1} Dpf = {A1}
EVpf = {DNF} EVpf = {DNF}
Atime = {Allow, Deny, Log} Atime = {Allow, Deny, Log}
Ctime = {timestart, timeend, datestart, datestop} Ctime = {timestart, timeend, datestart, datestop}
Etime = {} Etime = {}
RStime = {LMR} RStime = {LMR}
Dtime = {A2} Dtime = {A2}
EVtime = {} EVtime = {}
Then, Cpfgen is defined as: Then, Cap_pfgen is defined as:
Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf U RStime, Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf U RStime,
Dpf U Time, EVpf U EVtime} Dpf U Time, EVpf U EVtime}
= {Allow, Deny, Log}, = { {Allow, Deny, Log},
{{IPsrc,IPdst,Psrc,Pdst,protType} U {timestart, timeend, {IPsrc,IPdst,Psrc,Pdst,protType} U {timestart,
datestart, datestop}} timeend, datestart, datestop},
{} {},
{FMR, LMR} {FMR, LMR},
{A1, A2} {A1, A2},
{DNF} {DNF} }
In other words, Cpfgen provides three actions (Allow, Deny, Log), In other words, Cap_pfgen 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, can use either FMR or LMR (but obviously not both), and time period, can use either FMR or LMR (but obviously not both), and
can provide either A1 or A2 (but again, not both) as a default can provide either A1 or A2 (but again, not both) as a default
action. In any case, multiple conditions will be processed with DNF action. In any case, multiple conditions will be processed with DNF
when evaluating the condition clause. when evaluating the condition clause.
4. IANA Considerations 4. Considerations on the Practical Use of the CapIM
TBD CapIM is a solid basis for the data models that may serve in I2NSF.
Nevertheless, a partial re-organization of the data models already
produced by the WG is expected.
5. References Currently (A survey on the existing data models in the I2NSF world
with a couple of lines about it and a list of things that can be
inherited).
5.1. Normative References The CapIM can benefit from the definition of lists of elements to
help to easily build the description of the capabilities which
mainly consists in listing the things it can do:
o the actions that NSFs can enforce;
o the conditions that can be specified by at least one NSF.
Knowing all actions and conditions would be desirable, but covering
all of them is actually unreasonable. For instance, one-of-the-YANG-
models lists a high number of protocols that can be a solid basis to
build this list.
On the other hand, resolution strategies, and condition clause
evaluation methods are limited and listing all of them seems
feasible.
Finally, Events are too bounded to the systems/domain/architectures,
therefore, compiling a list is simply impossible.
5. Security Considerations
This document defines an object-oriented information model for
describing policy information that is independent of any specific
repository, language, or protocol. This document does not define any
particular system implementation, including a protocol. Hence, it
does not have any specific security requirements.
6. Contributors
The following people contributed to creating this document, and are
listed below in alphabetical order:
Antonio Lioy (Politecnico di Torino)
Dacheng Zhang (Huawei)
Edward Lopez (Fortinet)
Fulvio Valenza (Politecnico di Torino)
Kepeng Li (Alibaba)
Luyuan Fang (Microsoft)
Nicolas Bouthors (QoSmos)
7. Acknowledgements
Thanks to Linda Dunbar, Susan Hares and Jaehoon Paul Jeong for the
discussion and comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997. Consortium and Demon Internet Ltd., November 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
skipping to change at page 20, line 33 skipping to change at page 24, line 5
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar,
R., and J. Jeong, "Interface to Network Security Functions R., and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192, (I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017, DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>. <https://www.rfc-editor.org/info/rfc8192>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
5.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC8174, May 2017.
8.2. Informative References
[INCITS359 RBAC] NIST/INCITS, "American National Standard for [INCITS359 RBAC] NIST/INCITS, "American National Standard for
Information Technology - Role Based Access Control", Information Technology - Role Based Access Control",
INCITS 359, April, 2003 INCITS 359, April, 2003
[I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to
Network Security Functions (I2NSF) Terminology", Work in Network Security Functions (I2NSF) Terminology", Work in
Progress, January, 2018 Progress, January, 2018
[I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J.,
skipping to change at page 21, line 22 skipping to change at page 24, line 43
[Galitsky] Galitsky, B. and Pampapathi, R., "Can many agents answer [Galitsky] Galitsky, B. and Pampapathi, R., "Can many agents answer
questions better than one", First Monday, 2005; questions better than one", First Monday, 2005;
http://dx.doi.org/10.5210/fm.v10i1.1204 http://dx.doi.org/10.5210/fm.v10i1.1204
[Gamma] Gamma, E., Helm, R. Johnson, R., Vlissides, J., "Design [Gamma] Gamma, E., Helm, R. Johnson, R., Vlissides, J., "Design
Patterns: Elements of Reusable Object-Oriented Patterns: Elements of Reusable Object-Oriented
Software", Addison-Wesley, Nov, 1994. Software", Addison-Wesley, Nov, 1994.
ISBN 978-0201633610 ISBN 978-0201633610
[Hirschman]Hirschman, L., and Gaizauskas, R., "Natural Language [Hirschman] Hirschman, L., and Gaizauskas, R., "Natural Language
Question Answering: The View from Here", Natural Language Question Answering: The View from Here", Natural Language
Engineering 7:4, pgs 275-300, Cambridge University Press, Engineering 7:4, pgs 275-300, Cambridge University Press,
2001 2001
[Hohpe] Hohpe, G. and Woolf, B., "Enterprise Integration [Hohpe] Hohpe, G. and Woolf, B., "Enterprise Integration
Patterns", Addison-Wesley, 2003, ISBN 0-32-120068-3 Patterns", Addison-Wesley, 2003, ISBN 0-32-120068-3
[Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable [Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable
packet classification", 2003. packet classification", 2003.
skipping to change at page 22, line 5 skipping to change at page 26, line 5
[OODSRP] http://www.oodesign.com/single-responsibility- [OODSRP] http://www.oodesign.com/single-responsibility-
principle.html principle.html
[PDO] MEF, "Policy Driven Orchestration", Technical [PDO] MEF, "Policy Driven Orchestration", Technical
Specification MEF Y, January 2018 Specification MEF Y, January 2018
[Taylor] Taylor, D. and J. Turner, "Scalable packet classification [Taylor] Taylor, D. and J. Turner, "Scalable packet classification
using distributed crossproducting of field labels", 2004. using distributed crossproducting of field labels", 2004.
6. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Cataldo Basile Cataldo Basile
Politecnico di Torino Politecnico di Torino
Corso Duca degli Abruzzi, 34 Corso Duca degli Abruzzi, 34
Torino, 10129 Torino, 10129
Italy Italy
Email: cataldo.basile@polito.it Email: cataldo.basile@polito.it
Liang Xia (Frank) Liang Xia (Frank)
 End of changes. 43 change blocks. 
152 lines changed or deleted 268 lines changed or added

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