draft-xibassnez-i2nsf-capability-00.txt   draft-xibassnez-i2nsf-capability-01.txt 
I2NSF L. Xia I2NSF L. Xia
Internet Draft J. Strassner Internet-Draft J. Strassner
Intended status: Standard Track D.Zhang Intended status: Standard Track Huawei
Huawei Expires: September 12, 2017 C. Basile
K. Li PoliTO
Alibaba D. Lopez
C. Basile TID
A. Lioy March 12, 2017
PoliTO
D. Lopez
TID
E. Lopez
Fortinet
N. BOUTHORS
Qosmos
Luyuan Fang
Microsoft
Expires: December 2017 November 1, 2016 Information Model of NSFs Capabilities
draft-xibassnez-i2nsf-capability-01.txt
Information Model of NSFs Capabilities Abstract
draft-xibassnez-i2nsf-capability-00.txt
This document defines the concept of an NSF (Network Security
Function) Capability, as well as its information model. Capabilities
are a set of features that are available from a managed entity, and
are represented as data that unambiguously characterizes an NSF.
Capabilities enable management entities to determine the set offer
features from available NSFs that will be used, and simplify the
management of NSFs.
Status of this Memo 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current
Drafts. 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 documents months and may be updated, replaced, or obsoleted by other
at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts
reference material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 1,2016. This Internet-Draft will expire on September 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided
warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Abstract Table of Contents
This draft aims at defining the concept of capability. Capabilities 1. Introduction ................................................... 4
are data that unambiguously characterize NSFs (Network Security 2. Conventions used in this document .............................. 5
Functions). Their correct definition will ease all the management 2.1. Acronyms .................................................. 5
and automation that can be. Moreover, it allows the definition of 3. Capability Information Model Design ............................ 6
Interfaces to manage NSFs. 3.1. Design Principles and ECA Policy Model Overview ........... 6
3.2. Relation with the External Information Model .............. 8
3.3. I2NSF Capability Information Model Theory of Operation ... 10
3.3.1. I2NSF Condition Clause Operator Types ............... 11
3.3.2 Capability Selection and Usage ...................... 12
3.3.3. Capability Algebra ................................. 13
3.4. Initial NSFs Capability Categories ....................... 16
3.4.1. Network Security Capabilities ....................... 16
3.4.2. Content Security Capabilities ....................... 17
3.4.3. Attack Mitigation Capabilities ...................... 17
4. Information Sub-Model for Network Security Capabilities ....... 18
4.1. Information Sub-Model for Network Security ............... 18
4.1.1. Network Security Policy Rule Extensions ............. 19
4.1.2. Network Security Policy Rule Operation .............. 20
4.1.3. Network Security Event Sub-Model .................... 22
4.1.4. Network Security Condition Sub-Model ................ 23
4.1.5. Network Security Action Sub-Model ................... 25
4.2. Information Model for I2NSF Capabilities ................. 26
4.3. Information Model for Content Security Capabilities ...... 27
4.4. Information Model for Attack Mitigation Capabilities ..... 28
5. Security Considerations ....................................... 29
6. IANA Considerations ........................................... 29
7. Contributors .................................................. 29
8. References .................................................... 29
8.1. Normative References ..................................... 29
8.2. Informative References ................................... 30
Appendix A. Network Security Capability Policy Rule Definitions .. 32
A.1. AuthenticationECAPolicyRule Class Definition ............. 32
A.2. AuthorizationECAPolicyRuleClass Definition ............... 34
A.3. AccountingECAPolicyRuleClass Definition .................. 35
A.4. TrafficInspectionECAPolicyRuleClass Definition ........... 37
A.5. ApplyProfileECAPolicyRuleClass Definition ................ 38
A.6. ApplySignatureECAPolicyRuleClass Definition .............. 40
Appendix B. Network Security Event Class Definitions ............. 42
B.1. UserSecurityEvent Class Description ...................... 42
B.1.1. The usrSecEventContent Attribute .................... 42
B.1.2. The usrSecEventFormat Attribute ..................... 42
B.1.3. The usrSecEventType Attribute ....................... 42
B.2. DeviceSecurityEvent Class Description .................... 43
B.2.1. The devSecEventContent Attribute .................... 43
B.2.2. The devSecEventFormat Attribute ..................... 43
B.2.3. The devSecEventType Attribute ....................... 44
B.2.4. The devSecEventTypeInfo[0..n] Attribute ............. 44
B.2.5. The devSecEventTypeSeverity Attribute ............... 44
This draft is the first trial to merge two previous existing drafts Table of Contents (continued)
on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on
the capability interface [I-D.draft-xia-i2nsf-capability-interface-
im-06]. Further work will be needed to homogenize all the concepts
and incorporate the feedback that will result after its publication.
Table of Contents B.3. SystemSecurityEvent Class Description .................... 44
B.3.1. The sysSecEventContent Attribute .................... 45
B.3.2. The sysSecEventFormat Attribute ..................... 45
B.3.3. The sysSecEventType Attribute ....................... 45
B.4. TimeSecurityEvent Class Description ...................... 45
B.4.1. The timeSecEventPeriodBegin Attribute ............... 46
B.4.2. The timeSecEventPeriodEnd Attribute ................. 46
B.4.3. The timeSecEventTimeZone Attribute .................. 46
Appendix C. Network Security Condition Class Definitions ......... 47
C.1. PacketSecurityCondition .................................. 47
C.1.1. PacketSecurityMACCondition .......................... 47
C.1.1.1. The pktSecCondMACDest Attribute ................ 47
C.1.1.2. The pktSecCondMACSrc Attribute ................. 47
C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48
C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48
C.1.1.5. The pktSecCondMACTCI Attribute ................. 48
C.1.2. PacketSecurityIPv4Condition ......................... 48
C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48
C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48
C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48
C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48
C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48
C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49
C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49
C.1.3. PacketSecurityIPv6Condition ......................... 49
C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49
C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49
C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49
C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49
C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49
C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49
C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50
C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50
C.1.4. PacketSecurityTCPCondition .......................... 50
C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50
C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50
C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50
C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50
C.1.5. PacketSecurityUDPCondition ....................... 50
C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50
C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51
C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51
C.2. PacketPayloadSecurityCondition ........................... 51
C.3. TargetSecurityCondition .................................. 51
C.4. UserSecurityCondition .................................... 51
C.5. SecurityContextCondition ................................. 52
C.6. GenericContextSecurityCondition .......................... 52
1. Introduction ................................................ 4 Table of Contents (continued)
2. Conventions used in this document ........................... 6
2.1. Terminology ............................................ 6
3. Management of NSFs: Design Principles towards a model of
Capabilities ................................................... 7
4. Information Model .......................................... 10
5. Capabilities for security policy enforcement ............... 12
5.1. The CA Policy Model ................................... 13
5.2. Geometric Model of CA Policies ........................ 14
5.3. Condition Types ....................................... 17
5.4. Model of Capabilities for Policy Specification and Enforcement
Purposes ................................................... 19
5.5. Algebra of capabilities ............................... 20
5.6. Examples of NSFs Categories ........................... 21
5.6.1. Network Security ................................. 22
5.6.2. Content Security .................................. 22
5.6.3. Attack Mitigation ................................. 22
6. Information Sub-Model for Network Security Capabilities ..... 23
6.1. Information Sub-Model for Network Security ............. 23
6.1.1. Network Security Policy Rule Extensions ........... 24
6.1.2. Network Security Policy Rule Operation ............ 26
6.1.3. Network Security Event Sub-Model .................. 27
6.1.3.1. UserSecurityEvent Class Description .......... 29
6.1.3.1.1. The usrSecEventContent Attribute ........ 29
6.1.3.1.2. The usrSecEventFormat Attribute.......... 29
6.1.3.1.3. The usrSecEventType Attribute ........... 30
6.1.3.2. DeviceSecurityEvent Class Description ........ 30
6.1.3.2.1. The devSecEventContent Attribute ........ 30
6.1.3.2.2. The devSecEventFormat Attribute.......... 31
6.1.3.2.3. The devSecEventType Attribute ........... 31
6.1.3.2.4. The devSecEventTypeInfo[0..n] Attribute . 31
6.1.3.2.5. The devSecEventTypeSeverity Attribute ... 32
6.1.3.3. SystemSecurityEvent Class Description ........ 32
6.1.3.3.1. The sysSecEventContent Attribute ........ 32
6.1.3.3.2. The sysSecEventFormat Attribute.......... 33
6.1.3.3.3. The sysSecEventType Attribute ........... 33
6.1.3.4. TimeSecurityEvent Class Description .......... 33
6.1.3.4.1. The timeSecEventPeriodBegin Attribute ... 34
6.1.3.4.2. The timeSecEventPeriodEnd Attribute ..... 34
6.1.3.4.3. The timeSecEventTimeZone Attribute ...... 34
6.1.4. Network Security Condition Sub-Model .............. 34
6.1.4.1. PacketSecurityCondition ...................... 36
6.1.4.1.1. PacketSecurityMACCondition .............. 36
6.1.4.1.1.1. The pktSecCondMACDest Attribute .... 37
6.1.4.1.1.2. The pktSecCondMACSrc Attribute ..... 37
6.1.4.1.1.3. The pktSecCondMAC8021Q Attribute ... 37
6.1.4.1.1.4. The pktSecCondMACEtherType Attribute 37
6.1.4.1.1.5. The pktSecCondMACTCI Attribute ..... 37
6.1.4.1.2. PacketSecurityIPv4Condition ............. 37
6.1.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute 37
6.1.4.1.2.2. The pktSecCondIPv4DestAddr Attribute 37
6.1.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute
................................................ 38
6.1.4.1.2.4. The pktSecCondIPv4DSCP Attribute ... 38
6.1.4.1.2.5. The pktSecCondIPv4ECN Attribute .... 38
6.1.4.1.2.6. The pktSecCondIPv4TotalLength Attribute
................................................ 38
6.1.4.1.2.7. The pktSecCondIPv4TTL Attribute .... 38
6.1.4.1.3. PacketSecurityIPv6Condition ............. 38
6.1.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute 38
6.1.4.1.3.2. The pktSecCondIPv6DestAddr Attribute 38
6.1.4.1.3.3. The pktSecCondIPv6DSCP Attribute ... 38
6.1.4.1.3.4. The pktSecCondIPv6ECN Attribute .... 39
6.1.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute39
6.1.4.1.3.6. The pktSecCondIPv6PayloadLength
Attribute ....................................... 39
6.1.4.1.3.7. The pktSecCondIPv6NextHeader Attribute39
6.1.4.1.3.8. The pktSecCondIPv6HopLimit Attribute 39
6.1.4.1.4. PacketSecurityTCPCondition .............. 39
6.1.4.1.4.1. The pktSecCondTPCSrcPort Attribute . 39
6.1.4.1.4.2. The pktSecCondTPCDestPort Attribute 39
6.1.4.1.4.3. The pktSecCondTPCSeqNum Attribute .. 40
6.1.4.1.4.4. The pktSecCondTPCFlags Attribute ... 40
6.1.4.1.5. PacketSecurityUDPCondition .............. 40
6.1.4.1.5.1. The pktSecCondUDPSrcPort Attribute . 40
6.1.4.1.5.2. The pktSecCondUDPDestPort Attribute 40
6.1.4.1.5.3. The pktSecCondUDPLength Attribute .. 40
6.1.4.2. PacketPayloadSecurityCondition ............... 40
6.1.4.3. TargetSecurityCondition ...................... 40
6.1.4.4. UserSecurityCondition ........................ 41
6.1.4.5. SecurityContextCondition ..................... 41
6.1.4.6. GenericContextSecurityCondition .............. 41
6.1.5. Network Security Action Sub-Model ................. 42
6.1.5.1. IngressAction ................................ 43
6.1.5.2. EgressAction ................................. 43
6.1.5.3. ApplyProfileAction ........................... 43
6.1.5.4. ApplySignatureAction ......................... 43
6.2. Information Model for Content Security Control ......... 43
6.3. Information Model for Attack Mitigation Control ........ 44
7. Security Considerations ..................................... 45
8. IANA Considerations ......................................... 46
9. References .................................................. 46
9.1. Normative References ................................... 46
9.2. Informative References ................................. 46
10. Acknowledgments ............................................ 47
Appendix A. .................................................... 48
A.1. AuthenticationECAPolicyRule Class Definition ........... 48
A.2. AuthorizationECAPolicyRuleClass Definition ............. 50
A.3. AccountingECAPolicyRuleClass Definition ................ 52
A.4. TrafficInspectionECAPolicyRuleClass Definition.......... 54
A.5. ApplyProfileECAPolicyRuleClass Definition .............. 56
A.6. ApplySignatureECAPolicyRuleClass Definition ............ 58
1. Introduction Appendix D. Network Security Action Class Definitions ............. 53
D.1. IngressAction ............................................ 53
D.2. EgressAction ............................................. 53
D.3. ApplyProfileAction ....................................... 53
Appendix E. Geometric Model ...................................... 54
Authors' Addresses ............................................... 57
The rapid development of virtualized systems, along with the demand 1. Introduction
of security services in 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 (UE) in a mobile devices in an enterprise network, User Equipment in a mobile network,
network, devices in the Internet of Things (IoT), or residential devices in the Internet of Things, or residential access users
access users [I-D.draft-ietf-i2nsf-problem-and-use-cases]. [I-D.draft-ietf-i2nsf-problem-and-use-cases].
Capabilities are precise information that characterize in an NSFs produced by multiple security vendors provide various security
unambiguous way (in a given virtualized system) what a NSF can do in Capabilities to customers. Multiple NSFs can be combined together to
terms of security policy enforcement and how a Controller can provide security services over the given network traffic, regardless
interact with it in order to enforce a security policy. Even if the of whether the NSFs are implemented as physical or virtual functions.
aim is a general of capabilities, the unambiguity of capabilities is
only assured in a given virtualized system.
According to [I-D.draft-ietf-i2nsf-framework], there are two types Security Capabilities describe the set of Network Security Functions
of I2NSF interfaces available for security rules provisioning: (NSFs) that are available to use for security policy enforcement
purposes. Security Capabilities are independent of the actual
security control mechanisms that will implement them. Every NSF
registers the set of Capabilities it offers. Security Capabilities
are a market enabler, providing a way to define customized security
protection by unambiguously describing the security features offered
by a given NSF. Moreover, Security Capabilities enable security
functionality to be described in a vendor-neutral manner. That is,
it is not needed to refer to a specific product when designing the
network; rather, the functions characterized by their Capabilities
are considered.
o Interface between I2NSF clients and a security controller (Client According to [I-D.draft-ietf-i2nsf-framework], there are two types
Facing Interface): This is a service-oriented interface, whose of I2NSF interfaces available for security policy provisioning:
main objective is to define a communication channel over which o Interface between I2NSF users and applications, and a security
information defining security services controlling client's controller (Consumer-Facing Interface): this is a service-
specific flow can be requested. This enables security information oriented interface that provides a communication channel
to be exchanged between various applications (e.g., OpenStack, or between consumers of NSF data and services and the network
various BSS/OSS components) and other components (e.g., security operator's security controller. This enables security
controllers). The design goal of the service interface is to information to be exchanged between various applications (e.g.,
decouple the security service in the application layer from OpenStack, or various BSS/OSS components) and the security
various kinds of security devices and their device-specific controller. The design goal of the Consumer-Facing Interface
security functions. is to decouple the specification of security services of
consumers requesting such services from their implementation.
Interface between NSFs (e.g., firewall, intrusion prevention, or o Interface between NSFs (e.g., firewall, intrusion prevention,
anti-virus) and a security controller (NSFs Facing Interface): or anti-virus) and the security controller (NSF-Facing
This interface is independent of how the NSFs are implemented Interface): The NSF-Facing Interface is used to decouple the
(e.g., run in Virtual Machines (VMs) or physical appliances). The security management scheme from the set of NSFs and their
NSFs Facing Interface is used to decouple the security management various implementations for this scheme, and is independent
scheme from the set of NSFs and their various implementations for of how the NSFs are implemented (e.g., run in Virtual
this scheme, so as to specify and monitor a number of flow based Machines or physical appliances). According to the definition
security policies to individual NSFs. According to the definition in [I-D.draft-ietf-i2nsf-framework], the NSF-Facing Interface
in [I-D.draft-ietf-i2nsf-framework], NSFs Facing Interface information model is made up of three sub-models: Capability,
includes sub-interfaces of Capability Interface, Registration Registration and Monitoring. This document defines the
Interface and Monitoring Interface. This document proposes the information model design for the first two parts (Capability
information model design for the first two interfaces (Capability and Registration); the Monitoring part information model is
and Registration), the Monitoring Interface information model is discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring].
discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring].
This document is organized as follows: Section 3 discusses the This document is organized as follows. Section 2 defines conventions
design principles for NSF capabilities and related ECA model. and acronyms used. Section 3 discusses the design principles for the
Section 4 further describes design principles for I2NSF capability I2NSF Capability information model and related ECA model. Section 4
information model. Section 5 provides more details about the design provides detailed information model design of I2NSF network security
of network security capability. Section 6 presents further Capability.
information on specific aspects of the information model.
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 references to [I-D.draft-ietf-i2nsf-terminology] for This document uses terminology defined in
more specific security related and I2NSF scoped terminology [I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF
definitions. scoped terminology.
2.1. Terminology
AAA -Access control, Authorization, Authentication
ACL - Access Control List
AD - Active Directory
ANSI - American National Standards Institute
DDoS - Distributed Deny of Services
FW - Firewall
I2NSF - Interface to Network Security Functions
INCITS - International Committee for Information Technology
Standards
IoT - Internet of Things
IPS - Intrusion Prevention System
LDAP - Lightweight Directory Access Protocol
NAT - Network Address Translation
NBI - North-bound Interface
NIST - National Institute of Standard Technology
NSF - Network Security Function
RBAC - Role Based Access Control
UE - User Equipment 2.1. Acronyms
URL - Uniform/Universal Resource Locator
VM - Virtual Machine AAA: Access control, Authorization, Authentication
ACL: Access Control List
(D)DoD: (Distributed) Denial of Service (attack)
ECA: Event-Condition-Action
FMR: First Matching Rule (resolution strategy)
FW: Firewall
GNSF: Generic Network Security Function
HTTP: HyperText Transfer Protocol
I2NSF: Interface to Network Security Functions
IPS: Intrusion Prevention System
LMR: Last Matching Rule (resolution strategy)
MIME: Multipurpose Internet Mail Extensions
NAT: Network Address Translation
NSF: Network Security Function
RPC: Remote Procedure Call
SMA: String Matching Algorithm
URL: Uniform Resource Locator
VPN: Virtual Private Network
WAF - Web Application Firewall 3. Capability Information Model Design
3. Management of NSFs: Design Principles towards a model of The starting point of the design of the Capability information model
Capabilities is the categorization of types of security functions. For instance,
experts agree on what is meant by the terms "NAT", "filtering", and
"VPN concentrator". Network security experts unequivocally refer to
"packet filters" as stateless devices able to allow or deny packet
forwarding based on various conditions (e.g., source and destination
IP addresses, source and destination ports, and IP protocol type
fields) [Alshaer].
Some basic principles for security capabilities and the systems that However, more information is required in case of other devices, like
have to manage them need to be considered: stateful firewalls or application layer filters. These devices
filter packets or communications, but there are differences in the
packets and communications that they can categorize and the states
they maintain. Analogous considerations can be applied for channel
protection protocols, where we all understand that they will protect
packets by means of symmetric algorithms whose keys could have been
negotiated with asymmetric cryptography, but they may work at
different layers and support different algorithms and protocols. To
ensure protection, these protocols apply integrity, optionally
confidentiality, anti-reply protections, and authenticate peers.
o Flexibility: each security capability should be an independent 3.1. Design Principles and ECA Policy Model Overview
function, with minimum overlap or dependency to other
capabilities. This enables each security capability to be
utilized and assembled together freely. More importantly, changes
to one capability will not affect other capabilities;
o High level of abstraction: each capability should be associated This document defines a model of security Capabilities that provides
to a unified interface to make it programmable; this in turn the foundation for automatic management of NSFs. This includes
provides a standardized ability to describe and report its enabling the security controller to properly identify and manage
processing results and corresponding statistics information. NSFs, and allow NSFs to properly declare their functionality, so
Furthermore, it facilitates the multi-vendor interoperability; that they can be used in the correct way.
o Automation: The system must have the ability to auto-discover, Some basic design principles for security Capabilities and the
auto-negotiate, and auto-update security capabilities. These systems that have to manage them are:
features are especially useful for the management of a large
number of NSFs. They are essential to add smart services
(refinement, analysis, capability reasoning, optimization) on top
of the virtual layer;
o Scalability: the management system must have the capability to o Independence: each security Capability should be an independent
function, with minimum overlap or dependency on other
Capabilities. This enables each security Capability to be
utilized and assembled together freely. More importantly,
changes to one Capability will not affect other Capabilities.
This follows the Single Responsibility Principle
[Martin] [OODSRP].
o Abstraction: each Capability should be defined in a vendor-
independent manner, and associated to a well-known interface
to provide a standardized ability to describe and report its
processing results. This facilitates multi-vendor
interoperability.
o Automation: the system must have the ability to auto-discover,
auto-negotiate, and auto-update its security Capabilities
(i.e., without human intervention). These features are
especially useful for the management of a large number of
NSFs. They are essential to add smart services (e.g., analysis,
refinement, Capability reasoning, and optimization) for the
security scheme employed. These features are supported by many
design patterns, including the Observer Pattern [OODOP], the
Mediator Pattern [OODMP], and a set of Message Exchange
Patterns [Hohpe].
o Scalability: the management system must have the Capability to
scale up/down or scale in/out. Thus, it can meet various scale up/down or scale in/out. Thus, it can meet various
performance requirements derived from changeable network traffic performancerequirements derived from changeable network traffic
or service requests. In addition, the security capability must or service requests. In addition, security Capabilities that are
support reporting statistics to the security controller to assist affected by scalability changes must support reporting statistics
its decision on whether it needs to invoke scaling or not. to the security controller to assist its decision on whether it
needs to invoke scaling or not. However, this requirement is for
information only, and is beyond the scope of this document.
Based on the above principles, a set of abstract and vendor-neutral Based on the above principles, a set of abstract and vendor-neutral
capabilities with standard interfaces is needed together with a Capabilities with standard interfaces is defined. This provides a
model of capabilities that allows to unambiguously determine what Capability model that enables a set of NSFs that are required at a
NSFs can do in terms of security policy enforcement. The security given time to be selected, as well as the unambiguous definition of
controller can compare the requirements of clients to the set of the security offered by the set of NSFs used. The security
capabilities that are currently available in order to choose which controller can compare the requirements of users and applications to
NSFs are needed to meet those requirements. Note that this choice is the set of Capabilities that are currently available in order to
independent of vendor, and instead relies specifically on the choose which NSFs are needed to meet those requirements. Note that
capabilities (i.e., the description) of the functions provided. This this choice is independent of vendor, and instead relies specifically
also facilitates the customization of the functionality of the on the Capabilities (i.e., the description) of the functions
selected NSFs by setting the parameters of their interfaces. provided. The security controller may also be able to customize the
functionality of selected NSFs.
Furthermore, when an unknown threat (e.g., zero-day exploits,
unknown malware, and APTs) is reported by a network security device,
new capabilities may be created, and/or existing capabilities may be
updated (e.g., signature and algorithm), to correspond to the new
functionality provided by the NSF to handle the threat. The new
capabilities are provided from different vendors after their
analysis of the new threats and subsequent installation of the
functions required to report on (and possibly mitigate) the threat.
New capabilities may be sent to and stored in a centralized
repository, or stored separately in a local repository. In either
cases, a standard interface is needed during this automated update
process.
In defining the capabilities of a NSF, the "Event-Condition-Action"
(ECA) policy rule set model in [I-D.draft-ietf-i2nsf-framework]
should be here as the basis for the design:
o Event: An Event is defined as any important occurrence in time of
a change in the system being managed, and/or in the environment
of the system being managed. When used in the context of policy
rules for I2NSF, it is used to determine whether the Condition
clause of the Policy Rule can be evaluated or not. Examples of an
I2NSF Event include time and user actions (e.g., logon, logoff,
and actions that violate an ACL);
o Condition: A set of attributes, features, and/or values that are
to be compared with a set of known attributes, features, and/or
values in order to make a decision. When used in the context of
policy rules for I2NSF, it is used to determine whether or not
the set of Actions in that Policy Rule can be executed or not.
The following are exemplary types of conditions:
? Packet content values: Refer to the kind of information or
attributes acquired directly from the packet headers or
payloads that can be used in the security policy. It can be
any fields or attributes in the packet L2/L3/L4 header, or
special segment of bytes in the packet payload;
? Context values: Refer to the context information for the
received packets. It can be (and not limited to):
* User: The user (or user group) information to which a
network flow is associated. A user has many attributes,
such as name, id, password, authentication mode, and so
on. The combination of name and id (where id could be a
password, a certificate, or other means of identifying
the user) is often used in the security policy to
identify the user. For example, if an NSF is aware of
the IP (or MAC) address associated with the user, the
NSF can use a pre-defined or dynamically learned name-
address association to enforce the security functions
for this given user (or user group);
* Schedule: Time or time range when packet or flow is
received;
* Region: The geographic location where network traffic is
received;
* Target: The target indicates the entity to which the
security services are applied. This can be a service,
application, or device. A service is identified by the
protocol type and/or port number. An application is a
computer program for a specific task or purpose. It
provides additional semantics (e.g., dependencies
between services) for matching traffic. A device is a
managed entity that is connected to the network. The
attributes that can identify a device include type (e.g.,
router, switch, pc) and operating system (e.g., Windows,
Linux, or Android), as well as the device's owner;
* State: It refers to various states to which the network
flow is associated. It can be either the TCP session
state (e.g., new, established, related, invalid, or
untracked), the session AAA state (e.g., authenticated
but not authorized), or the access mode of the device
(e.g., wireline, wireless, or cellular; these could be
augmented with additional attributes, such as the type
of VPN that is being used);
* Direction: the direction of the network flow.
o Action: NSFs provide security functions by executing various
Actions, which at least includes:
? Ingress actions, such as pass, drop, mirroring, etc; Furthermore, when an unknown threat (e.g., zero-day exploits and
? Egress actions, such as invoke signaling, tunnel unknown malware) is reported by a NSF, new Capabilities may be
encapsulation, packet forwarding and/or transformation; created, and/or existing Capabilities may be updated (e.g., by
updating its signature and algorithm). This results in enhancing
existing NSFs (and/or creating new NSFs) to address the new threats.
New Capabilities may be sent to and stored in a centralized
repository, or stored separately in a vendor's local repository.
In either case, a standard interface facilitates the update process.
? Applying a specific Functional Profile or signature - e.g., Note that most systems cannot dynamically create a new Capability
an IPS Profile, a signature file, an anti-virus file, or a without human interaction. This is an area for further study.
URL filtering file. It is one of the key properties that
determine the effectiveness of the NSF, and is mostly vendor-
specific today. One goal of I2NSF is to standardize the form
and functional interface of those security capabilities while
supporting vendor-specific implementations of each. However,
it is important to properly model the parts that are related
to the action (what is enforced) and the conditions (on what
it is enforced).
The above ECA ruleset is very general and easily extensible, thus In defining the Capabilities of a NSF, the "Event-Condition-Action"
can avoid any potential constraints which could limit the (ECA) policy model in [I-D.draft-ietf-i2nsf-framework] is used as
implementation of the network security control capability. the basis for the design; definitions of all I2NSF policy-related
terms are also defined in [I-D.draft-ietf-i2nsf-terminology]:
4. Information Model o Event: An Event is any important occurrence in time of a change
in the system being managed, and/or in the environment of the
system being managed. When used in the context of I2NSF
Policy Rules, it is used to determine whether the Condition
clause of the I2NSF Policy Rule can be evaluated or not.
Examples of an I2NSF Event include time and user actions (e.g.,
logon, logoff, and actions that violate an ACL).
An information model will be developed in order to describe in an o Condition: A condition is defined as a set of attributes,
abstract and vendor independent manner all the aspects related to features, and/or values that are to be compared with a set of
the capabilities of NSFs. A detailed information model will be known attributes, features, and/or values in order to determine
designed in the next versions of this draft as a consequence of the whether or not the set of Actions in that (imperative) I2NSF
discussions, feedback, and extensions that will originate after the Policy Rule can be executed or not. Examples of I2NSF Conditions
publication of this draft. In this version of the draft, we present include matching attributes of a packet or flow, and comparing
a simplified view that only highlights the most important concepts. the internal state of an NSF to a desired state.
o Action: An action is used to control and monitor aspects of
flow-based NSFs when the event and condition clauses are
satisfied. NSFs provide security functions by executing various
Actions. Examples of I2NSF Actions include providing intrusion
detection and/or protection, web and flow filtering, and deep
packet inspection for packets and flows.
The I2NSF capability interface is in charge of controlling and The above ECA policy model is very general and easily extensible,
managing the NSFs by means of the information about the capabilities and can avoid potential constraints that could limit the
each NSF owns. This is done using the following approach: implementation of generic security Capabilities.
1) User of the capability interface selects the set of capabilities 3.2. Relation with the External Information Model
required to meet the needs of the application;
2) A management entity uses the information model to match chosen Note: the symbology used from this point forward is taken from
capabilities to NSFs, independent of vendor; section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model].
3) A management entity takes the above information and creates or The I2NSF NSF-Facing Interface is in charge of selecting and
uses vendor-specific data models to install the NSFs identified by managing the NSFs using their Capabilities. This is done using
the chosen capabilities; the following approach:
4) Control and monitoring can then begin. 1) Each NSF registers its Capabilities with the management system
when it "joins", and hence makes its Capabilities available to
the management system;
2) The security controller selects the set of Capabilities
required to meet the needs of the security service from all
available NSFs that it manages;
3) The security controller uses the Capability information model
to match chosen Capabilities to NSFs, independent of vendor;
4) The security controller takes the above information and
creates or uses one or more data models from the Capability
information model to manage the NSFs;
5) Control and monitoring can then begin.
This assumes that an external model, or set of models, is used to This assumes that an external information model is used to define
define the concept of an ECA Policy Rule and its components (e.g., the concept of an ECA Policy Rule and its components (e.g., Event,
Event, Condition, and Action objects). Condition, and Action objects). This enables I2NSF Policy Rules
[I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external
information model.
Since Capabilities are unambiguous only within the same management Capabilities are defined as classes (e.g., a set of objects that
system, and are not inherent characteristics that differentiate exhibit a common set of characteristics and behavior
objects, it is also assumed that an external model (or set of models) [I-D.draft-ietf-supa-generic-policy-info-model].
will define a generic metadata concept.
The Capability is a general abstract concept. Currently, the most Each Capability is made up of at least one model element (e.g.,
promising approach for defining the information model of the attribute, method, or relationship) that differentiates it from all
Capabilities uses the sub-classing to define non-overlapping and other objects in the system. Capabilities are, generically, a type
independent concepts. For instance, the Capability model that will of metadata; hence, it is also assumed that an external information
be presented in the next sections that abstractly determines the model is used to define metadata (preferably, in the form of a class
security policies that a NSF can enforce does not overlap with an hierarchy). Therefore, it is assumed that Capabilities are subclassed
independent model that specifies how a NSF can be contacted by the from an external metadata model.
controller (i.e., the protocols and secure channels) and when (i.e.,
the events to which it reacts). Capabilities are sub-classed from an
appropriate class in the external metadata model.
The capability interface 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 capability 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, the vendor of the NSF is virtualized or hosted in a physical device, who the
the NSF, and which set of entities the NSF is communicating with vendor of the NSF is, and which set of entities the NSF is
(e.g., a firewall or an IPS). Instead, the user only cares about the communicating with (e.g., a firewall or an IPS). Instead, the user
set of capabilities that the NSF has, such as packet filtering or only cares about the set of Capabilities that the NSF has, such as
deep packet inspection. The overall structure is illustrated in the packet filtering or deep packet inspection. The overall structure
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 |
+----+-------+ +-----+------+
| 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 the Capability sub-Model shown in Figure 1. This This draft defines a set of extensions to a generic, external, ECA
model assumes that another, generic, information model for defining Policy Model to represent various NSF ECA Security Policy Rules. It
ECA policy rules (which includes a specific one for the CA part of also defines the Capability Sub-Model. Finally, it places
ECA policy rules) exists outside of I2NSF. requirements on what type of extensions are required to the generic,
external, ECA information model and metadata models, in order to
It also assumes that Capabilities are modeled as metadata, since a manage the lifecycle of I2NSF Capabilities.
Capability is something that describes and/or prescribes
functionality about an object, but is not an inherent part of that
object. Hence, the Security Capability Sub-Model extends the generic
external metadata model.
Both of these external models could, but do not have to, draw from Both of the external models shown in Figure 1 could, but do not have
the SUPA model [I-D.draft-ietf-supa-generic-policy-info-model]. to, be based on the SUPA information model
[I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in
the Capability Sub-Model will inherit the AggregatesMetadata
aggregation from the External Metadata Information Model.
The external ECA Information Model supplies at least a set of The external ECA Information Model supplies at least a set of objects
objects that represent a generic ECA Policy Rule, and a set of that represent a generic ECA Policy Rule, and a set of objects that
objects that represent Events, Conditions, and Actions that can be represent Events, Conditions, and Actions that can be aggregated by
aggregated by the generic ECA Policy Rule. This enables I2NSF to the generic ECA Policy Rule. This enables I2NSF to reuse this
reuse this generic model for different purposes. generic model for different purposes, as well as specialize it (i.e.,
create new model objects) 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.
5. Capabilities for security policy enforcement 3.3. I2NSF Capability Information Model: Theory of Operation
At present, a variety of NSFs produced by multiple security vendors
provide various security capabilities to customers. Multiple NSFs
can be combined together to provide security services over the given
network traffic, regardless of whether the NSFs are implemented as
physical or virtual functions.
Security Capabilities are intended to describe the potentiality that
Network Security Functions (NSFs) have for security policy
enforcement purposes. Security Capabilities are abstract concepts
that are independent of the actual security control that will
implement them. However, every NSF will be associated to the
capabilities it owns. Security Capabilities are required to allow
differentiating among network functions. It would be a market
enabler having a way to substitute a NSF with an equivalent one
(i.e., having the same functionality). Moreover, Security
Capabilities are very useful to reason about generic functions,
which may be needed at design time. That is, it is not needed to
refer to a specific product when designing the network; rather the
functions characterized by their capabilities are considered.
Therefore, we have developed another model where Security
Capabilities determine what a security control can do in terms of
conditions, actions, resolution strategies, external data, if it
supports default action, etc. That is, Security Capabilities define
without any ambiguity the actions a function can do in term of
security policy enforcement. The Security Capability model is built
on a predefined general policy model. The type of policies that a
NSF can enforce is obtained by customizing the general policy model
with the Security Capability information.
The Capability Model has been preliminarily validated by verifying
that is allows the correct description of several existing security
controls.
5.1. The CA Policy Model
The starting point of the design of our capability model is a simple
observation. As human beings, we all understand immediately each
other when we refer to security controls by just naming their
category. For instance, experts agree on what is a NAT, a filtering
control, or a VPN concentrator. Network security experts
unequivocally refer to "packet filters" as stateless devices able to
allow or deny packets forwarding based on conditions on source and
destination IP addresses, source and destination ports, and IP
protocol type fields [Alshaer]. Moreover, it is known that packet
filter rules are prioritized and it is possible to specify a default
action. More precisely, packet filters implement the First Matching
Rule (FMR) or Last Matching Rule (LMR) resolution strategies.
However, we feel the need for more information in case of other
devices, like stateful firewalls or application layer filters.
These devices filter packets or communications, but there are
differences among products in the packets and communications that
they can categorize and the states they maintain. Analogous
considerations can be applied for channel protection protocols,
where we all understand that they will protect packets by means of
symmetric algorithms whose keys could have been negotiated with
asymmetric cryptography, but they may work at different layers and
support different algorithms and protocols. To ensure protection,
these protocols apply integrity, optionally confidentiality, apply
anti-reply protections, and authenticate peers.
The purpose is to build a model of security capabilities that allow
automatic management of virtualized systems, where intelligent
components are able to properly identify and manage NSFs, and allow
NSFs to properly declare their functionality so that they can be
used in the correct way.
5.2. Geometric Model of CA Policies
We refer in this draft to the policy model defined in [Bas12] as
geometric model, which is summarized here. Policies are specified by
means of a set of rules in the "if condition then action" format
[RFC3198]. Rules are formed by a condition clause and an action
clause. This model can be further extended to support events, that
is, in the Event-Condition-Action paradigms. However, for our
purpose, the geometric model will only be used to define the CA part
of the ECA model that we have selected as reference.
All the actions available to the security function are well known
and organized in an action set A.
For filtering controls, the enforceable actions are either Allow and
Deny, thus A={Allow,Deny}. For channel protection controls, they may
be informally written as "enforce confidentiality", "enforce data
authentication and integrity", and "enforce confidentiality and data
authentication and integrity". However, these actions need to be
instantiated to the technology used, for instance AH-transport mode
and ESP-transport mode (and combinations thereof) are a more precise
and univocal definition of channel protection actions.
Conditions are typed predicates concerning a given selector. A
selector describes the values that a protocol field may take, e.g.,
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 values come
from, e.g., the IP source selector refers to the IP source field in
the IP header. Geometrically, a condition is the 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 referred to by
the selector belongs to the condition. For instance, in Figure 2
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 match the packet
x1, while only s2 matches x2.
S2 ^ Destination port
|
|
| x2
+......o
| .
| .
--+.............+------------------------------------+
| | . | |
s | . | |
e | . | (rectangle) |
g | . | condition clause (c) |
m | . | here the action a is applied |
e | . | |
n | . | x1=point=packet |
t +.............|.............o |
| | . | . |
--+.............+------------------------------------+
| . . . .
| . . . .
| . . . .
| . . . .
| . . . .
| . . . .
+------------+------+-------------+----------------------+------>
| |---- segment = condition in S1 -----| S1
+ IP source
Figure 2: Geometric representation of a rule r=(c,a) that matches x1
but does not match x2.
To consider conditions in different selectors, the decision space is
extended using the Cartesian product because distinct selectors
refer to different fields, possibly from different protocol headers.
Hence, given a policy-enabled element that allows the definition of
conditions on the selectors S1, S2,..., Sm (where m is the number of
Selectors available at the security control we want to model), its
selection space is:
S=S1 X S2 X ... X Sm
To consider conditions in different selectors, the decision space is
extended using the Cartesian product because distinct selectors
refer to different fields, possibly from different protocol headers.
Accordingly, the condition clause c is a subset of S:
c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S
S represents the totality of the packets that are individually
selectable by the security control to model when we use it to
enforce a policy. Unfortunately, not all its subsets are valid
condition clauses: only hyper-rectangles or union of hyper-
rectangles (as they are Cartesian product of conditions) are valid.
This is an intrinsic constraint of the policy languages as they
specify rules by defining a condition for each selector. Languages
that allow specification of conditions as relations over more fields
are modeled by the geometric model as more complex geometric shapes
determined by the equations. However, the algorithms to compute
intersections are much more sophisticated than intersection hyper-
rectangles. Figure 1 graphically represents a condition clause c in
a two-dimensional selection space.
In the geometric model, a rule is expressed as r=(c,a), where c <= S Capabilities are typically used to represent NSF functions that can
(the condition clause is a subset of the selection space), and the be invoked. Capabilities are objects, and hence, can be used in the
action a belongs to A. Rule condition clauses matche a packet (rules event, condition, and/or action clauses of an I2NSF ECA Policy Rule.
matche a packet), if all the conditions forming the clauses match The I2NSF Capability information model refines a predefined metadata
the packet: in Figure 1, the rule with condition clause c matches model; the application of I2NSF Capabilities is done by refining a
the packet x1 but not x2. predefined ECA Policy Rule information model that defines how to
use, manage, or otherwise manipulate a set of Capabilities. In this
approach, an I2NSF Policy Rule is a container that is made up of
three clauses: an event clause, a condition clause, and an action
clause. When the I2NSF policy engine receives a set of events, it
matches those events to events in active ECA Policy Rules. If the
event matches, then this triggers the evaluation of the condition
clause of the matched I2NSF Policy Rule. The condition clause is
then evaluated; if it matches, then the set of actions in the
matched I2NSF Policy Rule MAY be executed.
The rule set R is composed of n rules ri=(ci,ai). This document defines additional important extensions to both the
external ECA Policy Rule model and the external Metadata model that
are used by the I2NSF Information Model; examples include
resolution strategy, external data, and default action. All these
extensions come from the geometric model defined in [Bas12]. A more
detailed description is provided in Appendix E; a summary of the
important points follows.
The decision criteria for the action to apply when a packet matches Formally, given a set of actions in an I2NSF Policy Rule, the
two or more rules is abstracted by means of the resolution strategy resolution strategy maps all the possible subsets of actions to an
RS: Pow(R) -> A, where Pow(R) is the power set of rules in R. outcome. In other words, the resolution strategy is included in the
I2NSF Policy Rule to decide how to evaluate all the actions in a
particular I2NSF Policy Rule. This is then extended to include all
possible I2NSF Policy Rules that can be applied in a particular
scenario. Hence, the final action set from all I2NSF Policy Rules
is deduced.
Formally, given a set of rules, the resolution strategy maps all the Some concrete examples of resolution strategy are the First Matching
possible subsets of rules to an action a in A. When no rule matches Rule (FMR) or Last Matching Rule (LMR) resolution strategies. When
a packet, the security controls may select the default action d in A, no rule matches a packet, the NSFs may select a default action, if
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.,
condition clause and action clause), also ``external data'' event, condition, and action clauses), "external data" associated to
associated to each rule, such as priority, identity of the creator, each rule, such as priority, identity of the creator, and creation
and creation time. Formally, every rule ri is associated by means time. Two examples of this are attaching metadata to the policy
of the function e(.) to: action and/or policy rule, and associating the policy rule with
another class to convey such information.
e(ri) = (ri,f1(ri),f2(ri),...)
where E={fj:R -> Xj} (j=1,2,...) is the set that includes all the
functions that map rules to external attributes in Xj. However, E, e,
and all the Xj are determined by the resolution strategy used.
A policy is thus a function p: S -> A that connects each point of
the selection space to an action taken from the action set A
according to the rules in R. By also assuming RS(0)=d (where 0 is
the empty-set) and RS(ri)=ai, the policy p can be described with
this formula
p(x)=RS(match{R(x)}).
Therefore, in the geometric model, a policy is completely defined by
the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS,
the set E of mappings to the external attributes, and the default
action d.
Note that, the geometric model also supports ECA paradigms by simply
modeling events like an additional selector.
5.3. Condition Types 3.3.1. I2NSF Condition Clause Operator Types
After having analyzed the literature and the existing security After having analyzed the literature and some existing NSFs, the
controls, we have categorized the types of selectors in exact-match, types of selectors are categorized as exact-match, range-based,
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 a 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 numbers are maintained by the IANA (http://www.iana.org/assignments/
(http://www.iana.org/assignments/protocol-numbers/protocol- protocol-numbers/protocol-numbers.xhtml).
numbers.xhtml).
In this selector, it is only meaningful to specify conditions In this selector, it is only meaningful to specify condition clauses
that use either the "equals" or "not equals" operators:
proto = tcp, udp (protocol type field equals to TCP or UDP) proto = tcp, udp (protocol type field equals to TCP or UDP)
proto != tcp (protocol type field different from TCP) proto != tcp (protocol type field different from TCP)
No other operators are allowed on exact-match selectors, for No other operators are allowed on exact-match selectors. For example,
instance the following is an invalid condition clause, even if protocol types
map to integers:
proto < 62 (invalid condition) proto < 62 (invalid condition)
is not a valid condition, even if protocol types map to integers.
Range-based selectors are ordered sets where it is possible to Range-based selectors are ordered sets where it is possible to
naturally specify ranges as they can be easily mapped to integers. naturally specify ranges as they can be easily mapped to integers.
As an example, the ports in the TCP protocol may be represented with
As an example, the ports in the TCP protocol are well represented a range-based selector (e.g., 1024-65535). As another example, the
using a range-based selector (e.g., 1024-65535). As an example following are examples of valid condition clauses:
source_port = 80 source_port = 80
source_port < 1024 source_port < 1024
source_port < 30000 && source_port >= 1024 source_port < 30000 && source_port >= 1024
are valid conditions. We include, in range-based selectors, the category of selectors that
have been defined by Al-Shaer et al. as "prefix-match" [Alshaer].
These selectors allow the specification of ranges of values by means
of simple regular expressions. The typical case is the IP address
selector (e.g., 10.10.1.*).
We include in the range-based selectors all the category of There is no need to distinguish between prefix match and range-based
selectors that have been defined by Al-Shaer et al. as prefix match selectors; for example, the address range "10.10.1.*" maps to
[Alshaer]. These selectors allow the specification of ranges of "[10.10.1.0,10.10.1.255]".
values by means of simple regular expressions. The typical case is
the IP address selector (e.g., 10.10.1.*). There is no need to
distinguish between prefix match and range-based selectors as
10.10.1.* easily maps to [10.10.1.0, 10.10.1.255].
Another category of selector types includes the regex-based Another category of selector types includes those based on regular
selectors, where the matching is performed by using regular expressions. This selector type is used frequently at the application
expressions. This selector type is frequent at the application layer, layer, where data are often represented as strings of text. The
where data are often represented as strings of text. The regex-based regex-based selector type also includes string-based selectors, where
selector type also includes as sub-case the string-based selectors, matching is evaluated using string matching algorithms (SMA)
where matching is evaluated using string matching algorithms (SMA) [Cormen]. Indeed, for our purposes, string matching can be mapped to
[Cormen] Indeed, for our purposes, string matching can be mapped to
regular expressions, even if in practice SMA are much faster. For regular expressions, even if in practice SMA are much faster. For
instance, Squid (http://www.squid-cache.org/), a popular Web caching instance, Squid (http://www.squid-cache.org/), a popular Web caching
proxy that offers various access control capabilities, allows the proxy that offers various access control Capabilities, allows the
definition of conditions on URLs that can be evaluated with SMA definition of conditions on URLs that can be evaluated with SMA
(e.g., dstdomain) or regex matching (e.g., dstdom_regex). (e.g., dstdomain) or regex matching (e.g., dstdom_regex).
As an example, As an example, the condition clause:
URL = *.website.* "URL = *.website.*"
matches all the URLs that contain a domain, subdomain named website matches all the URLs that contain a subdomain named website and the
and the ones whose path contain the string .website. ones whose path contain the string ".website.". As another example,
the condition clause:
MIME_type = video/* "MIME_type = video/*"
matches all the MIME objects whose type is video. matches all MIME objects whose type is video.
Finally, we introduce the idea of custom check selectors. For Finally, the idea of a custom check selector is introduced. For
instance the malware analysis looks for specific patterns and instance, malware analysis can look for specific patterns, and
returns a Boolean value is an example of custom check selector, if returns a Boolean value if the pattern is found or not.
the logic of checking is not seen (nor really interesting) from the
outside.
In order to be properly used by high-level policy based processed In order to be properly used by high-level policy-based processing
(like reasoning systems, refinement systems) these custom check systems (such as reasoning systems and policy translation systems),
selector need at least to be described as black-boxes, that is, the these custom check selectors can be modeled as black-boxes (i.e., a
list of fields that they process (inputs) in order to return the function that has a defined set of inputs and outputs for a
Boolean verdict (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 example is already present in next versions of the draft. Some examples are already present in
Section 6. Section 6.
5.4. Model of Capabilities for Policy Specification and Enforcement 3.3.2. Capability Selection and Usage
Purposes
Our model of capabilities is based on actions and traffic
classification features. Indeed, the need for enforcing one of the
actions that a security control can apply to packets/flows is the
main reason to use a security control. Moreover, security controls
have classification features that permit the identification of the
target packets/flows of the actions enforced, i.e., the selectors
presented in Section 5.2. A security manager decides for a specific
security control depending on the actions and classification
features. If the security control can enforce the needed actions and
has the classification features needed to identify the packets flows
required by a policy, then the security control is capable of
enforcing the policy. Our refinement model needs to know NSFs
capabilities to perform its operations.
However, security controls may 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. We have ignored, to
simplify this presentation, options to generate configurations that
may have better performance, like the use of chains or ad hoc
structures [Taylor]. Adding support to these forms of optimization
is certainly feasible with a limited effort but it was outside the
scope of this paper, that is, to show that adding security awareness
to NFV management and orchestration features is possible. It is one
of the task for future work.
Capabilities can be used for two purposes: describing generic
security functions, and describing specific products. With the term
generic security function (GNSF) we denote known classes of security
functions. The idea is to have generic components whose behavior is
as well understood as for the network components (i.e., a switch is
a switch and we know to use it even if it may have some vendor-
specific functions). These generic functions can be substituted by
any product that owns the required capability at instantiation time.
We have analyzed several classes of NSFs to prove the validity of
our approach. We found the common features and defined a set of
generic NSFs, including packet filter, URL filter, HTTP filter, VPN
gateway, anti-virus, anti-malware, content filter, monitoring,
anonymity proxy that will be described in a data model TBD.
Moreover, we have also categorized common extensions of the generic
NSFs, packet filters that may decide based on time information.
Moreover, some other packet filters add stateful features at ISO/OSI
layer 4.
The next section will introduce our algebra to compose capabilities,
defined to associate NSFs to capabilities and to check whether a NSF
has the capabilities needed to enforce policies.
5.5. Algebra of capabilities
Our capabilities are defined by a 4-tuple, that is every NSF N will
be associated to a 4-tuple (Ac; Cc; RSc; Dc) such that:
(Ac; Cc; RSc; Dc) <= (XAC; XCC; XRSC; XDC)= K
where
o XAC is the set of all the supported actions, that is, the set of
all the actions supported by at least one of the existing NSFs;
o Ac <= XAC is a set of actions that determine the actions actually
available at the NSF N;
o XCC is set of all the supported conditions types, that is, the
set of all the conditions that can be to specify rules in at
least one of the existing NSFs;
o Cc <= XCC is the sef of conditions actually available at the NSF Capability selection and usage are based on the set of security
N; 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.
o XRSC is the set of all the existing resolutions strategies, 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.
o RSc <= XCC is the set of resolution strategies that can be used The Capability information model can be used for two purposes:
to specify solve conflicts of multiple matching rules at the NSF describing the features provided by generic security functions, and
N; describing the features provided by specific products. The term
Generic Network Security Function (GNSF) refers to the classes of
security functions that are known by a particular system. The idea
is to have generic components whose behavior is well understood, so
that the generic component can be used even if it has some vendor-
specific functions. These generic functions represent a point of
interoperability, and can be provided by any product that offers the
required Capabilities. GNSF examples include packet filter, URL
filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
filter, monitoring, and anonymity proxy; these will be described
later in a revision of this draft as well as in an upcoming data
model contribution.
o XDC={F} U XAC, is the set of all the existing actions plus a The next section will introduce the algebra to define the
dummy symbol F, a placeholder value that can be used to indicate information model of Capability registration. This associates
that the default action can be freely selected by the policy NSFs to Capabilities, and checks whether a NSF has the
editor; and Capabilities needed to enforce policies.
o Dc <= XDC, Dc may be {F}, to indicate that the default action can 3.3.3. Capability Algebra
be freely selected by the policy editor, thus it can vary in
every policy, or an explicit action {a<=XAC} to indicate that the
default action is fixed and the policy editor will not have the
possibility to choice it.
Given cap1=(Ac1,Cc1,RSc1,def1) and cap2=(Ac2,Cc2,RSc2,def2), we We introduce a Capability Algebra to ensure that the actions of
define two operations that are useful to manipulate capabilities: different policy rules do not conflict with each other.
o capability addition: cap1+cap2 = (Ac1 U Ac2, Cc1 U Cc2, RSc1,def1) Formally, two I2NSF Policy Actions conflict with each other if:
o capability subtraction: cap_1-cap_2 = (Ac1\Ac2,Cc1\Cc2,RSc1,def1) 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
Note that addition and subtraction do not alter the resolution For example, if we have two Policies:
strategy and the default action method, as our main intent was to
model addition of modules.
As an example, a generic packet filter that supports the first P1: During 8am-6pm, if traffic is external, then run through FW
matching rule resolution strategies, allows the explicit P2: During 7am-8pm, conduct anti-malware investigation
specification of default actions and also supports time-based
conditions. The description of its capabilities is the following:
Apf = {Allow, Deny} There is no conflict between P1 and P2, since the actions are
different. However, consider these two policies:
Cpf= {IPsrc,IPdst,Psrc,Pdst,protType} P3: During 8am-6pm, John gets GoldService
P4: During 10am-4pm, FTP from all users gets BronzeService
Ctime = {timestart,days,datestart,datestop} P3 and P4 are now in conflict, because between the hours of 10am and
4pm, the actions of P3 and P4 are different and apply to the same
user (i.e., John).
cap_pf=(Apf; Cpf; {FMR}; F) Let us define the concept of a "matched" policy rule as one in which
its event and condition clauses both evaluate to true. This enables
the actions in this policy rule to be evaluated. Then, the
information model is defined by a 5-tuple {Ac, Cc, Ec, RSc, Dc},
where:
cap_pf+time=cap_pf + Ctime o Ac is the set of Actions currently available from the NSF;
o Cc is the set of Conditions currently available from the NSF;
o Ec is the set of Events the NSF is able to respond to.
Therefore, the event clause of an I2NSF ECA Policy Rule that is
written for an NSF will only allow a set of designated events
in Ec. For compatibility purposes, we will assume that if Ec={}
(that is, Ec is empty), the NSF only accepts CA policies.
o RSc is the set of Resolution Strategies that can be used to
specify how to resolve conflicts that occur between the actions
of the same or different policy rules that are matched and
contained in this particular NSF;
o Dc defines the notion of a Default action that can be used to
specify a predefined action when no other alternative action
was matched by the currently executing I2NSF Policy Rule. An
analogy is the use of a default statement in a C switch
statement. This field of the Capability algebra can take the
following values:
- An explicit action (that has been predefined; typically,
this means that it is fixed and not configurable), denoted
as Dc ={a}. In this case, the NSF will always use the
action as as the default action.
- A set of explicit actions, denoted Dc={a1,a2, ...};
typically, this means that any **one** action can be used
as the default action. This enables the policy writer to
choose one of a predefined set of actions {a1, a2, ...} to
serve as the default action.
- A fully configurable default action, denoted as Dc={F}.
Here, F is a dummy symbol (i.e., a placeholder value) that
can be used to indicate that the default action can be
freely selected by the policy editor from the actions Ac
available at the NSF. In other words, one of the actions
Ac may be selected by the policy writer to act as the
default action.
- No default action, denoted as Dc={}, for cases where the
NSF does not allow the explicit selection of a default
action.
By abuse of notation, we have written cap_pf+time=cap_pf + Ctime to *** Note to WG: please review the following paragraphs
shorten the more correct expression cap_pf+time=cap_pf +(;Ctime;;). *
* Interesting Capability concepts that could be considered for a next
* version of the Capability model and algebra include:
*
* o Event clause representation (e.g., conjunctive vs. disjunctive
* normal form for Boolean clauses)
* o Event clause evaluation function, which would enable more
* complex expressions than simple Boolean expressions to be used
*
*
* o Condition clause representation (e.g., conjunctive vs.
* disjunctive normal form for Boolean clauses)
* o Condition clause evaluation function, which would enable more
* complex expressions than simple Boolean expressions to be used
* o Action clause evaluation strategies (e.g., execute first
* action only, execute last action only, execute all actions,
* execute all actions until an action fails)
* o The use of metadata, which can be associated to both an I2NSF
* Policy Rule as well as objects contained in the I2NSF Policy
* Rule (e.g., an action), that describe the object and/or
* prescribe behavior. Descriptive examples include adding
* authorship information and defining a time period when an NSF
* can be used to be defined; prescriptive examples include
* defining rule priorities and/or ordering.
*
* Given two sets of Capabilities, denoted as
*
* cap1=(Ac1,Cc1,Ec1,RSc1,Dc1) and
* cap2=(Ac2,Cc2,Ec2,RSc2,Dc2),
*
* two set operations are defined for manipulating Capabilities:
*
* o Capability addition:
* cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1}
* o Capability subtraction:
* cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1}
*
* In the above formulae, "U" is the set union operator and "\" is the
* set difference operator.
*
* The addition and subtraction of Capabilities are defined as the
* addition (set union) and subtraction (set difference) of both the
* Capabilities and their associated actions. Note that **only** the
* leftmost (in this case, the first matched policy rule) Resolution
* Strategy and Default Action are used.
*
* Note: actions, events, and conditions are **symmetric**. This means
* that when two matched policy rules are merged, the resultant actions
* and Capabilities are defined as the union of each individual matched
* policy rule. However, both resolution strategies and default actions
* are **asymmetric** (meaning that in general, they can **not** be
* combined, as one has to be chosen). In order to simplify this, we
* have chosen that the **leftmost** resolution strategy and the
* **leftmost** default action are chosen. This enables the developer
* to view the leftmost matched rule as the "base" to which other
* elements are added.
*
* As an example, assume that a packet filter Capability, Cpf, is
* defined. Further, assume that a second Capability, called Ctime,
* exists, and that it defines time-based conditions. Suppose we need
* to construct a new generic packet filter, Cpfgen, that adds
* time-based conditions to Cpf.
*
*
* Conceptually, this is simply the addition of the Cpf and Ctime
* Capabilities, as follows:
* Apf = {Allow, Deny}
* Cpf = {IPsrc,IPdst,Psrc,Pdst,protType}
* Epf = {}
* RSpf = {FMR}
* Dpf = {A1}
*
* Atime = {Allow, Deny, Log}
* Ctime = {timestart, timeend, datestart, datestop}
* Etime = {}
* RStime = {LMR}
* Dtime = {A2}
*
* Then, Cpfgen is defined as:
* Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf, Dpf}
* = {Allow, Deny, Log},
* {{IPsrc, IPdst, Psrc, Pdst, protType} U
* {timestart, timeend, datestart, datestop}},
* {},
* {FMR},
* {A1}
*
* In other words, Cpfgen provides three actions (Allow, Deny, Log),
* filters traffic based on a 5-tuple that is logically ANDed with a
* time period, and uses FMR; it provides A1 as a default action, and
* it does not react to events.
*
* Note: We are investigating, for a next revision of this draft, the
* possibility to add further operations that do not follow the
* symmetric vs. asymmetric properties presented in the previous note.
* We are looking for use cases that may justify the complexity added
* by the availability of more Capability manipulation operations.
*
*** End Note to WG
5.6. Examples of NSFs Categories 3.4. Initial NSFs Capability Categories
As an example of the application of the general capability model, we The following subsections define three common categories of
present in the next sections three examples of common categories: Capabilities: network security, content security, and attack
network security, content security, and attack mitigation. mitigation. Future versions of this document may expand both the
number of categories as well as the types of Capabilities within a
given category.
5.6.1. Network Security 3.4.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 pre-defined security policies. processing of network traffic based on the use of pre-defined
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 context to flows with which the packet is associated. From the in the context of flows with which the packet is associated. From
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.
5.6.2. Content Security 3.4.2. Content Security Capabilities
Content security is another category of security capabilities
applied to application layer. Through detecting the contents carried
over the traffic in application layer, these capabilities can
realize various security functions, such as defending against
intrusion, inspecting virus, filtering malicious URL or junk email,
blocking illegal web access or malicious data retrieval.
Generally, each type of threat in the application layer has a set of Content security is another category of security Capabilities
unique characteristics, and requires handling with a set of specific applied to the application layer. Through analyzing traffic contents
methods. Thus, these NSFs will be characterized by their own carried in, for example, the application layer, Capabilities can be
security capabilities. used to identify various security functions that are required, such
as defending against intrusion, inspecting for viruses, filtering
malicious URL or junk email, blocking illegal web access, or
preventing malicious data retrieval.
5.6.3. Attack Mitigation Generally, each type of threat in the content security category has
a set of unique characteristics, and requires handling using a set
of methods that are specific to that type of content. Thus, these
NSFs will be characterized by their own content- specific security
Capabilities.
This category of security capabilities is used to detect and 3.4.3. Attack Mitigation Capabilities
mitigate various types of network attacks. Today's common network
attacks can be classified into the following sets, and each set
further consists of a number of specific attacks:
o DDoS attacks: This category of security Capabilities is used to detect and mitigate
various types of network attacks. Today's common network attacks can
be classified into the following sets:
?Network layer DDoS attacks: Examples include SYN flood, UDP o DDoS attacks:
- 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, https flood, cache-bypass HTTP floods, WordPress XML RPC
https flood, cache-bypass http floods, WordPress XML RPC floods, and ssl DDoS.
floods, ssl DDoS. o Single-packet attacks:
- Scanning and sniffing attacks: IP sweep, port scanning, etc.
o Single-packet attack: - malformed packet attacks: Ping of Death, Teardrop, etc.
- special packet attacks: Oversized ICMP, Tracert, IP timestamp
?Scanning and sniffing attacks: IP sweep, port scanning, etc option packets, etc.
?malformed packet attacks: Ping of Death, Teardrop, etc
?special packet attacks: Oversized ICMP, Tracert, IP timestamp
option packets, etc
Each type of network attack has its own network behaviors and 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 capability, for special security function, which is advertised as a set of
detection and mitigation. Capabilities, for detection and mitigation. The implementation and
management of this category of security Capabilities of attack
Overall, the implementation and management of this category of mitigation control is very similar to content security control. A
security capabilities of attack mitigation control is very similar standard interface, through which the security controller can
to content security control. A standard interface, through which the choose and customize the given security Capabilities according to
security controller can choose and customize the given security specific requirements, is essential.
capabilities according to specific requirements, is essential.
6. Information Sub-Model for Network Security Capabilities 4. Information Sub-Model for Network Security Capabilities
The purpose of the Capability Framework Information Sub-Model is to The purpose of the Capability Information Sub-Model is to define the
define the concept of a Capability from an external metadata model, concept of a Capability, and enable Capabilities to be aggregated to
and enable Capabilities to be aggregated to appropriate objects. In appropriate objects. The following sections present the Network
the following sections we will present the cases of Network Security, Security, Content Security, and Attack Mitigation Capability
Content Security, and Attack Mitigation sub-models. sub-models.
6.1. Information Sub-Model for Network Security 4.1. Information Sub-Model for Network Security
The purpose of the Network Security Information Sub-Model is to The purpose of the Network Security Information Sub-Model is to
define how network traffic is defined and determine if one or more define how network traffic is defined, and determine if one or more
network security features need to be applied to the traffic or not. network security features need to be applied to the traffic or not.
Its basic structure is shown in the following figure: Its basic structure is shown in the following figure:
+---------------------+ +---------------------+
+---------------+ | | +---------------+ 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
such as InspectTraffic) for Network Security Control) with some extension, for Network Security)
such as InspectTraffic)
Figure 3. 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 Info Condition, and Action Objects, are defined in the external ECA
Model. The Network Security Sub-Model extends both to define Information Model. The Network Security Sub-Model extends all of
security-specific ECA policy rules, as well as Events, Conditions, these objects in order to define security-specific ECA policy rules,
and Actions. as well as extensions to the (generic) Events, Conditions, and
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, and actions), components of a Policy Rule (e.g., events, conditions, actions, and
and optionally, metadata. It can be applied to both uni-directional some extensions like resolution policy, default action and external
and bi-directional traffic across the NSF. data), and optionally, metadata. It can be applied to both uni- and
bi-directional traffic across the NSF.
Each rule is triggered by one or more events. If the set of events 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. true, enable a set of actions to be executed. This takes the
following conceptual form:
An example of an I2NSF Policy Rule is, in pseudo-code:
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**.
6.1.1. Network Security Policy Rule Extensions Note that Metadata, such as Capabilities, can be aggregated by I2NSF
ECA Policy Rules.
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
SecurityECAPolicyRule class. Any new kinds of specific Network SecurityECAPolicyRule class. Any new kinds of specific Network
Security Policy can be created by following the same pattern of Security Policy can be created by following the same pattern of
class design as below. class design as below.
+---------------+ +---------------+
| External | | External |
| ECAPolicyRule | | ECAPolicyRule |
+-------+-------+ +-------+-------+
/ \ / \
| |
| |
+------------+----------+ +------------+----------+
| SecurityECAPolicyRule | | SecurityECAPolicyRule |
+------------+----------+ +------------+----------+
| |
| |
+----+-----+--------+-----+----+---------+---------+--- ... +----+-----+--------+-----+----+---------+---------+--- ...
| | | | | | | | | | | |
| | | | | | | | | | | |
+------+-------+ | +-----+-------+ | +------+------+ | +------+-------+ | +-----+-------+ | +------+------+ |
|Authentication| | | Accounting | | |ApplyProfile | | |Authentication| | | Accounting | | |ApplyProfile | |
|ECAPolicyRule | | |ECAPolicyRule| | |ECAPolicyRule| | |ECAPolicyRule | | |ECAPolicyRule| | |ECAPolicyRule| |
+--------------+ | +-------------+ | +-------------+ | +--------------+ | +-------------+ | +-------------+ |
| | | | | |
+------+------+ +------+------+ +--------------+ +------+------+ +------+------+ +--------------+
|Authorization| | Traffic | |ApplySignature| |Authorization| | Traffic | |ApplySignature|
|ECAPolicyRule| | Inspection | |ECAPolicyRule | |ECAPolicyRule| | Inspection | |ECAPolicyRule |
+-------------+ |ECAPolicyRule| +--------------+ +-------------+ |ECAPolicyRule| +--------------+
+-------------+ +-------------+
Figure 4. Network Security Info Sub-Model ECAPolicyRule Extensions
Figure 3. Network Security Info Sub-Model ECAPolicyRule Extensions
The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule
hierarchy. It inherits from the (external) generic ECA Policy Rule hierarchy. It inherits from the (external) generic ECA Policy Rule,
to define Security ECA Policy Rules. The SecurityECAPolicyRule and represents the specialization of this generic ECA Policy Rule to
contains all of the attributes, methods, and relationships defined add security-specific ECA Policy Rules. The SecurityECAPolicyRule
in its superclass, and adds additional concepts that are required contains all of the attributes, methods, and relationships defined in
for Network Security (these will be defined in the next version of its superclass, and adds additional concepts that are required for
this draft). The six SecurityECAPolicyRule subclasses extend the Network Security (these will be defined in the next version of this
draft). The six SecurityECAPolicyRule subclasses extend the
SecurityECAPolicyRule class to represent six different types of SecurityECAPolicyRule class to represent six different types of
Network Security ECA Policy Rules. It is assumed that the (external) Network Security ECA Policy Rules. It is assumed that the (external)
generic ECAPolicyRule class defines basic information in the form of generic ECAPolicyRule class defines basic information in the form of
attributes, such as an unique object ID, as well as a description attributes, such as an unique object ID, as well as a description
and other basic, but necessary, information. and other necessary information.
*** Note to WG
*
* The design in Figure 3 represents the simplest conceptual design
* for network security. An alternative model would be to use a
* software pattern (e.g., the Decorator pattern); this would result
* in the SecurityECAPolicyRule class being "wrapped" by one or more
* of the six subclasses shown in Figure 3. 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 actions of different
* policy rules (e.g., inspect traffic and then apply a filter) into
* one. The disadvantage is that it is a more complex software design.
* The design team is requesting feedback from the WG regarding this.
*
*** End of Note to WG
It is assumed that the (external) generic ECA Policy Rule is It is assumed that the (external) generic ECA Policy Rule is
abstract; the SecurityECAPolicyRule is also abstract. This enables abstract; the SecurityECAPolicyRule is also abstract. This enables
data model optimizations to be made while making this information data model optimizations to be made while making this information
model detailed but flexible and extensible. model detailed but flexible and extensible. For example, abstract
classes may be collapsed into concrete classes.
The SecurityECAPolicyRule defines network security policy as a The SecurityECAPolicyRule defines network security policy as a
container that aggregates Event, Condition, and Action objects, container that aggregates Event, Condition, and Action objects,
which are described in Section 6.1.3, 6.1.4, and 6.1.5, respectively. which are described in Section 4.1.3, 4.1.4, and 4.1.5,
Events, Conditions, and Actions can be generic or security-specific. respectively. Events, Conditions, and Actions can be generic or
Section 4.6 defines the concept of default security Actions. 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 the Appendix A. in Appendix A.
6.1.2. Network Security Policy Rule Operation
Network security policy consists of a number of more granular ECA
Policy Rules formed from the information model described above. In
simpler cases, where the Event and Condition clauses remain
unchanged, then network security control may be performed by calling
additional network security actions. Network security policy
examines and performs basic processing of the traffic as follows:
1. For a given SecurityECAPolicyRule (which can be generic or
specific to security, such as those in Figure 3), the NSF
evaluates the Event clause. It may use security Event objects to
do all or part of this evaluation, which are defined in section
4.3.3. If the Event clause evaluates to TRUE, then the Condition
clause of this SecurityECAPolicyRule is evaluated; otherwise,
execution of this SecurityECAPolicyRule is stopped, and the next
SecurityECAPolicyRule (if one exists) is evaluated;
2. The Condition clause is then evaluated. It may use security
Condition objects to do all or part of this evaluation, which are
defined in section 4.3.4. If the Condition clause evaluates to
TRUE, then the set of Actions in this SecurityECAPolicyRule MUST
be executed. This is defined as "matching" the
SecurityECAPolicyRule; otherwise, execution of this
SecurityECAPolicyRule is stopped, and the next
SecurityECAPolicyRule (if one exists) is evaluated;
3. If none of the SecurityECAPolicyRules are matched, then the NSF
denies the traffic by default;
4. If the traffic matches a rule, the NSF performs the defined 4.1.2. Network Security Policy Rule Operation
Actions on the traffic. It may use security Action objects to do
all or part of this execution, which are defined in section 4.3.5.
If the action is "deny", the NSF blocks the traffic. If the basic
action is permit or mirror, the NSF firstly performs that
function, and then checks whether certain other security
capabilities are referenced in the rule. If yes, go to step 5. If
no, the traffic is permitted;
5. If other security capabilities (e.g., Anti-virus or IPS) are A Network Security Policy consists of one or more ECA Policy Rules
referenced in the SecurityECAPolicyRule, and the Action defined formed from the information model described above. In simpler cases,
in the rule is permit or mirror, the NSF performs the referenced where the Event and Condition clauses remain unchanged, then network
security capabilities. security may be performed by calling additional network security
actions. Network security policy examines and performs basic
processing of the traffic as follows:
Metadata attached to the SecurityECAPolicyRule MAY be used to 1. The NSF evaluates the Event clause of a given
control how the SecurityECAPolicyRule is evaluated. This is called a SecurityECAPolicyRule (which can be generic or specific to
Policy Rule Evaluation Strategy. For example, one strategy is to security, such as those in Figure 3). It may use security
match and execute the first SecurityECAPolicyRule, and then exit Event objects to do all or part of this evaluation, which are
without executing any other SecurityECAPolicyRules (even if they defined in section 4.1.3. If the Event clause evaluates to
matched). In contrast, a second strategy is to first collect all TRUE, then the Condition clause of this SecurityECAPolicyRule
SecurityECAPolicyRules that matched, and then execute them according is evaluated; otherwise, the execution of this
to a pre-defined order (e.g., the priority of each SecurityECAPolicyRule is stopped, and the next
SecurityECAPolicyRule). SecurityECAPolicyRule (if one exists) is evaluated.
2. The Condition clause is then evaluated. It may use security
Condition objects to do all or part of this evaluation, which
are defined in section 4.1.4. If the Condition clause
evaluates to TRUE, it is defined as "matching" the
SecurityECAPolicyRule; otherwise, execution of this
SecurityECAPolicyRule is stopped, and the next
SecurityECAPolicyRule (if one exists) is evaluated.
3. The set of actions to be executed are retrieved, and then the
resolution strategy is used to define their execution order.
This process includes using any optional external data
associated with the SecurityECAPolicyRule.
4. Execution then takes one of the following three forms:
a. If one or more actions is selected, then the NSF may
perform those actions as defined by the resolution
strategy. For example, the resolution strategy may only
allow a single action to be executed (e.g., FMR or LMR),
or it may allow all actions to be executed (optionally,
in a particular order). In these and other cases, the NSF
Capability MUST clearly define how execution will be done.
It may use security Action objects to do all or part of
this execution, which are defined in section 4.1.5. If the
basic Action is permit or mirror, the NSF firstly performs
that function, and then checks whether certain other
security Capabilities are referenced in the rule. If yes,
go to step 5. If no, the traffic is permitted.
b. If no actions are selected, and if a default action exists,
then the default action is performed. Otherwise, no actions
are performed.
c. Otherwise, the traffic is denied.
5. If other security Capabilities (e.g., the conditions and/or
actions implied by Anti-virus or IPS profile NSFs) are
referenced in the action set of the SecurityECAPolicyRule, the
NSF can be configured to use the referenced security
Capabilities (e.g., check conditions or enforce actions).
Execution then terminates.
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.
6.1.3. Network Security Event Sub-Model 4.1.3. Network Security Event Sub-Model
Figure 10 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.
+---------------------+ +---------------------+
+---------------+ 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 5. 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 5 extend the (external) The four Event classes shown in Figure 4 extend the (external)
generic Event class to represent Events that are of interest to generic Event class to represent Events that are of interest to
Network Security. It is assumed that the (external) generic Event Network Security. It is assumed that the (external) generic Event
class defines basic Event information in the form of attributes, class defines basic Event information in the form of attributes,
such as a unique event ID, a description, as well as the date and such as a unique event ID, a description, as well as the date and
time that the event occurred. 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 10). 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:
- The generic Event class is abstract
- 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
available (the four subclasses in Figure 10 would be available (the four subclasses in Figure 4 would be
subclasses of the Atomic Event) subclasses of the Atomic Event class); otherwise, a mechanism
is needed to be able to group Events into a collection
- The generic Event class has a mechanism to uniquely identify - The generic Event class has a mechanism to uniquely identify
the source of the Event the source of the Event
- The generic Event class has a mechanism to separate header - The generic Event class has a mechanism to separate header
information from its payload information from its payload
- The generic Event class has a mechanism to attach zero or more - The generic Event class has a mechanism to attach zero or more
metadata objects to it metadata objects to it
Brief class descriptions are provided in the following sub-sections. *** Note to WG:
*
* The design in Figure 4 represents the simplest conceptual design
* design for describing Security Events. An alternative model would
* be to use a software pattern (e.g., the Decorator pattern); this
* would result in the SecurityEvent class being "wrapped" by one or
* more of the four subclasses shown in Figure 4. 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 events of different
* types into one. The disadvantage is that it is a more complex
* software design.
*
*** End of Note to WG
6.1.3.1. UserSecurityEvent Class Description Brief class descriptions are provided in Appendix B.
4.1.4. Network Security Condition Sub-Model
Figure 5 shows a more detailed design of the Condition subclasses
that are contained in the Network Security Information Sub-Model.
The six Condition classes shown in Figure 5 extend the (external)
generic Condition class to represent Conditions that are of interest
to Network Security. It is assumed that the (external) generic
Condition class is abstract, so that data model optimizations may be
defined. It is also assumed that the generic Condition class defines
basic Condition information in the form of attributes, such as a
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
attributes in a SecurityCondition class (which would be a subclass
of the generic Condition class, and a superclass of the six
Condition classes shown in Figure 5), this makes it harder to use
any generic Condition model with the I2NSF conditions.
+---------------------+
+---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass |
| ECAPolicyRule+ A -------------+ for ECA Objects |
| |\ / /| |
+-------+-------+ +-----------+---------+
/ \
|
|
+--------------+----------+----+
| | |
| | |
+-----+----+ +------+------+ +-----+-----+
| An Event | | A Condition | | An Action |
| Class | | Class | | Class |
+----------+ +------+------+ +-----------+
/ \
|
|
+--------+----------+------+---+---------+--------+--- ...
| | | | | |
| | | | | |
+-----+-----+ | +-------+-------+ | +------+-----+ |
| Packet | | | PacketPayload | | | Target | |
| Security | | | Security | | | Security | |
| Condition | | | Condition | | | Condition | |
+-----------+ | +---------------+ | +------------+ |
| | |
+------+-------+ +----------+------+ +--------+-------+
| UserSecurity | | SecurityContext | | GenericContext |
| Condition | | Condition | | Condition |
+--------------+ +-----------------+ +----------------+
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.
4.1.5. Network Security Action Sub-Model
Figure 6 shows a more detailed design of the Action subclasses that
are contained in the Network Security Information Sub-Model.
+---------------------+
+---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass |
| ECAPolicyRule+ A -------------+ for ECA Objects |
| |\ / /| |
+---------------+ +-----------+---------+
/ \
|
|
+--------------+--------+------+
| | |
| | |
+-----+----+ +------+------+ +-----+-----+
| An Event | | A Condition | | An Action |
| Class | | Class | | Class |
+----------+ +-------------+ +-----+-----+
/ \
|
|
+-----------------+---------------+------- ...
| | |
| | |
+---+-----+ +----+---+ +------+-------+
| Ingress | | Egress | | ApplyProfile |
| Action | | Action | | Action |
+---------+ +--------+ +--------------+
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
Action information in the form of attributes, such as a 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
attributes in a SecurityAction class (which would be a subclass of
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
model with the I2NSF actions.
*** Note to WG
* The design in Figure 6 represents the simplest conceptual design
* for describing Security Actions. An alternative model would be to
* use a software pattern (e.g., the Decorator pattern); this would
* result in the SecurityAction class being "wrapped" by one or more
* 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
* well as offer the ability to combine multiple actions of different
* types into one. The disadvantage is that it is a more complex
* software design.
* The design team is requesting feedback from the WG regarding this.
*
*** End of Note to WG
Brief class descriptions are provided in Appendix D.
4.2. Information Model for I2NSF Capabilities
The I2NSF Capability Model is made up of a number of Capabilities
that represent various content security and attack mitigation
functions. Each Capability protects against a specific type of
threat in the application layer. This is shown in Figure 7.
+-------------------------+ 0..n 0..n +---------------+
| |/ \ \| External |
| External ECA Info Model + A ----------------+ Metadata |
| |\ / Aggregates /| Info Model |
+-------+-----------------+ Metadata +-----+---------+
| / \
| |
/ \ |
Subclasses +---------------------------------+--------------+
derived | Capability | |
for I2NSF | Sub-Model +----------+---------+ |
| | SecurityCapability | |
| +----------+---------+ |
| | |
| | |
| +----------------------+---+ |
| | | |
| +--------+---------+ +----------+--------+ |
| | Content Security | | Attack Mitigation | |
| + Capabilities | | Capabilities | |
| +------------------+ +-------------------+ |
+------------------------------------------------+
Figure 7. I2NSF Security Capability High-Level Model
Figure 7 shows a common I2NSF Security Capability class, called
SecurityCapability. This enables us to add common attributes,
relationships, and behavior to this class without affecting the
design of the external metadata information model.
All I2NSF Security Capabilities are then subclassed from the
SecuritCapability class.
Note: the SecurityCapability class will be defined in the next
version of this draft, after feedback from the WG is obtained.
4.3. Information Model for Content Security Capabilities
Content security is composed of a number of distinct security
functions; each such function protects against a specific type of
threat in the application layer. Content security is a type of
Generic Network Security Function, which summarizes a well-defined
set of security Capabilities, and was shown in Figure 7. Figure 8
shows exemplary types of content security Generic Network
Security Function.
+--------------------------------------------------------------+
| +--------------------+ |
| Capability | SecurityCapability | |
| Sub-Model: +---------+----------+ |
| Content Security / \ |
| | |
| | |
| +-------+----------+----------+---------------+ |
| | | | | |
| +-----+----+ | +-------+----+ +-------+------+ |
| |Anti-Virus| | | Intrusion | | Attack | |
| |Capability| | | Prevention | | Mitigation | |
| +----------+ | | Capability | | Capabilities | |
| | +------------+ +--------------+ |
| | |
| +--------+----+------------+-----------+--------+ |
| | | | | | |
| +----+-----+ +-----+----+ +-----+----+ +----+-----+ | |
| | URL | | Mail | | File | | Data | | |
| |Filtering | |Filtering | |Filtering | |Filtering | | |
| |Capability| |Capability| |Capability| |Capability| | |
| +----------+ +----------+ +----------+ +----------+ | |
| | |
| +----------------+------------------+----+ |
| | | | |
| +------+------+ +------+------+ +---------+---------+ |
| |PacketCapture| |FileIsolation| |ApplicationBehavior| |
| | Capability | | Capability | | Capability | |
| +-------------+ +-------------+ +-------------------+ |
+--------------------------------------------------------------+
Figure 8. Network Security Capability Information Model
The detailed description about a standard interface, and the
parameters for all the security Capabilities of this category, will
be defined in a future version of this document.
4.4. Information Model for Attack Mitigation Capabilities
Attack mitigation is composed of a number of Generic Network Security
Functions; each one protects against a specific type of network
attack. Attack Mitigation security is a type of Generic Network
Security Function, which summarizes a well-defined set of security
Capabilities, and was shown in Figure 7. Figure 9 shows exemplary
types of Attack Mitigation Generic Network Security Functions.
+---------------------------------------------------------------+
| +--------------------+ |
| Capability | SecurityCapability | |
| Sub-Model: +---------+----------+ |
| Attack Mitigation / \ |
| | |
| | |
| +-------+--------+------------+-------------+ |
| | | | | |
| +-----+----+ | +-----+----+ +-------+------+ |
| | SSLDDoS | | | PortScan | | Content | |
| |Capability| | |Capability| | Security | |
| +----------+ | +----------+ | Capabilities | |
| | +--------------+ |
| | |
| +--------+----+------------+-----------+--------+ |
| | | | | | |
| +----+-----+ +-----+----+ +-----+----+ +----+-----+ | |
| | SYNFlood | | UDPFlood | |ICMPFlood | | WebFlood | | |
| |Capability| |Capability| |Capability| |Capability| | |
| +----------+ +----------+ +----------+ +----------+ | |
| | |
| +-----------------+--------------+-----------+ |
| | | | |
| +-------+-------+ +-------+------+ +-----+-----+ +-----+----+ |
| |IPFragmentFlood| |DNSAmplication| |PingOfDeath| | IPSweep | |
| | Capability | | Capability | |Capability | |Capability| |
| +---------------+ +--------------+ +-----------+ +----------+ |
+---------------------------------------------------------------+
Figure 9. Attack Mitigation Capability Information Model
The detailed description about a standard interface, and the
parameters for all the security Capabilities of this category, will
be defined in a future version of this document.
5. Security Considerations
The security Capability policy information sent to NSFs should be
protected by the secure communication channel, to ensure its
confidentiality and integrity. Note that the NSFs and security
controller can all be spoofed, which leads to undesirable results
(e.g., security policy leakage from security controller, or a spoofed
security controller sending false information to mislead the NSFs).
Hence, mutual authentication MUST be supported to protected against
this kind of attack. The current mainstream security technologies
(i.e., TLS, DTLS, and IPSEC) can be employed to protect against the
above threats.
In addition, to defend against DDoS attacks caused by a hostile
security controller sending too many configuration messages to the
NSFs, rate limiting or similar mechanisms should be considered.
6. IANA Considerations
TBD
7. 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)
8. References
8.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC3539]
Aboba, B., and Wood, J., "Authentication, Authorization, and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.
8.2. Informative References
[RFC2975]
Aboba, B., et al., "Introduction to Accounting Management",
RFC 2975, October 2000.
[I-D.draft-ietf-i2nsf-problem-and-use-cases]
Hares, S., et.al., "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-11, March 2017.
[I-D.draft-ietf-i2nsf-framework]
Lopez, E., et.al., "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-04, October, 2016.
[I-D.draft-ietf-i2nsf-terminology]
Hares, S., et.al., "Interface to Network Security Functions
(I2NSF) Terminology", draft-ietf-i2nsf-terminology-03,
March, 2017
[I-D.draft-ietf-supa-generic-policy-info-model]
Strassner, J., Halpern, J., van der Meer, S., "Generic Policy
Information Model for Simplified Use of Policy Abstractions
(SUPA)", Woaft-ietf-supa-generic-policy-info-model-02,
October, 2016.
[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]
Al Shaer, E. and H. Hamed, "Modeling and management of firewall
policies", 2004.
[Bas12]
Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access
Control Policy Analysis and Transformation", 2012.
[Bas15]
Basile, C. and Lioy, A., "Analysis of application-layer filtering
policies with application to HTTP", IEEE/ACM Transactions on
Networking, Vol 23, Issue 1, February 2015.
[Cormen]
Cormen, T., "Introduction to Algorithms", 2009.
[Hohpe]
Hohpe, G. and Woolf, B., "Enterprise Integration Patterns",
Addison-Wesley, 2003, ISBN 0-32-120068-3
[Lunt]
van Lunteren, J. and T. Engbersen, "Fast and scalable packet
classification", IEEE Journal on Selected Areas in Communication,
vol 21, Issue 4, September 2003.
[Martin]
Martin, R.C., "Agile Software Development, Principles, Patterns,
and Practices", Prentice-Hall, 2002, ISBN: 0-13-597444-5
[OODMP]
http://www.oodesign.com/mediator-pattern.html
[OODOP]
http://www.oodesign.com/observer-pattern.html
[OODSRP]
http://www.oodesign.com/single-responsibility-principle.html
Appendix A. Network Security Capability Policy Rule Definitions
Six exemplary Network Security Capability Policy Rules are
introduced in this Appendix to clarify how to create different kinds
of specific ECA policy rules to manage Network Security Capabilities.
Note that there is a common pattern that defines how these
ECAPolicyRules operate; this simplifies their implementation. All of
these six ECA Policy Rules are concrete classes.
In addition, none of these six subclasses define attributes. This
enables them to be viewed as simple object containers, and hence,
applicable to a wide variety of content. It also means that the
content of the function (e.g., how an entity is authenticated, what
specific traffic is inspected, or which particular signature is
applied) is defined solely by the set of events, conditions, and
actions that are contained by the particular subclass. This enables
the policy rule, with its aggregated set of events, conditions, and
actions, to be treated as a reusable object.
A.1. AuthenticationECAPolicyRule Class Definition
The purpose of an AuthenticationECAPolicyRule is to define an I2NSF
ECA Policy Rule that can verify whether an entity has an attribute
of a specific value. A high-level conceputal figure is shown below.
+----------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAuthenticationMethod \| Authentication |
| Authentication + A ----------+-----------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +----------------+
+----------------+ |
|
+------------+-------------+
| AuthenticationRuleDetail |
+------------+-------------+
/ \ 0..n
|
| PolicyControlsAuthentication
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 10. Modeling Authentication Mechanisms
This class does NOT define the authentication method used. This is
because this would effectively "enclose" this information within the
AuthenticationECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Authentication
class(es) could not; they would have to associate with the
AuthenticationECAPolicyRule class, and those other classes would not
likely be interested in the AuthenticationECAPolicyRule. Second, the
evolution of new authentication methods should be independent of the
AuthenticationECAPolicyRule; this cannot happen if the
Authentication class(es) are embedded in the
AuthenticationECAPolicyRule.
This document only defines the AuthenticationECAPolicyRule; all other
classes, and the aggregations, are defined in an external model. For
completeness, descriptions of how the two aggregations are used are
described below.
Figure 10 defines an aggregation between an external class, which
defines one or more authentication methods, and an
AuthenticationECAPolicyRule. This decouples the implementation of
authentication mechanisms from how authentication mechanisms are
managed and used.
Since different AuthenticationECAPolicyRules can use different
authentication mechanisms in different ways, the aggregation is
realized as an association class. This enables the attributes and
methods of the association class (i.e., AuthenticationRuleDetail) to
be used to define how a given AuthenticationMethod is used by a
particular AuthenticationECAPolicyRule.
Similarly, the PolicyControlsAuthentication aggregation defines
Policy Rules to control the configuration of the
AuthenticationRuleDetail association class. This enables the entire
authentication process to be managed by ECA PolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define two
attributes for the AuthenticationECAPolicyRule class (e.g., called
authenticationMethodCurrent and authenticationMethodSupported), to
represent the HasAuthenticationMethod aggregation and its
association class. The former would be a string attribute that
defines the current authentication method used by this
AuthenticationECAPolicyRule, while the latter would define a set of
authentication methods, in the form of an authentication Capability,
which this AuthenticationECAPolicyRule can advertise.
A.2. AuthorizationECAPolicyRuleClass Definition
The purpose of an AuthorizationECAPolicyRule is to define an I2NSF
ECA Policy Rule that can determine whether access to a resource
should be given and, if so, what permissions should be granted to
the entity that is accessing the resource.
This class does NOT define the authorization method(s) used. This
is because this would effectively "enclose" this information within
the AuthorizationECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Authorization
class(es) could not; they would have to associate with the
AuthorizationECAPolicyRule class, and those other classes would not
likely be interested in the AuthorizationECAPolicyRule. Second, the
evolution of new authorization methods should be independent of the
AuthorizationECAPolicyRule; this cannot happen if the Authorization
class(es) are embedded in the AuthorizationECAPolicyRule. Hence,
this document recommends the following design:
+---------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAuthorizationMethod \| Authorization |
| Authorization + A ----------+----------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +---------------+
+----------------+ |
|
+------------+------------+
| AuthorizationRuleDetail |
+------------+------------+
/ \ 0..n
|
| PolicyControlsAuthorization
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 11. Modeling Authorization Mechanisms
This document only defines the AuthorizationECAPolicyRule; all other
classes, and the aggregations, are defined in an external model. For
completeness, descriptions of how the two aggregations are used are
described below.
Figure 11 defines an aggregation between the
AuthorizationECAPolicyRule and an external class that defines one or
more authorization methods. This decouples the implementation of
authorization mechanisms from how authorization mechanisms are
managed and used.
Since different AuthorizationECAPolicyRules can use different
authorization mechanisms in different ways, the aggregation is
realized as an association class. This enables the attributes and
methods of the association class (i.e., AuthorizationRuleDetail)
to be used to define how a given AuthorizationMethod is used by a
particular AuthorizationECAPolicyRule.
Similarly, the PolicyControlsAuthorization aggregation defines
Policy Rules to control the configuration of the
AuthorizationRuleDetail association class. This enables the entire
authorization process to be managed by ECA PolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define
two attributes for the AuthorizationECAPolicyRule class, called
(for example) authorizationMethodCurrent and
authorizationMethodSupported, to represent the
HasAuthorizationMethod aggregation and its association class. The
former is a string attribute that defines the current authorization
method used by this AuthorizationECAPolicyRule, while the latter
defines a set of authorization methods, in the form of an
authorization Capability, which this AuthorizationECAPolicyRule
can advertise.
A.3. AccountingECAPolicyRuleClass Definition
The purpose of an AccountingECAPolicyRule is to define an I2NSF
ECA Policy Rule that can determine which information to collect,
and how to collect that information, from which set of resources
for the purpose of trend analysis, auditing, billing, or cost
allocation [RFC2975] [RFC3539].
This class does NOT define the accounting method(s) used. This is
because this would effectively "enclose" this information within
the AccountingECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Accounting class(es)
could not; they would have to associate with the
AccountingECAPolicyRule class, and those other classes would not
likely be interested in the AccountingECAPolicyRule. Second, the
evolution of new accounting methods should be independent of the
AccountingECAPolicyRule; this cannot happen if the Accounting
class(es) are embedded in the AccountingECAPolicyRule. Hence, this
document recommends the following design:
+-------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAccountingMethod \| Accounting |
| Accounting + A ----------+--------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +-------------+
+----------------+ |
|
+----------+-----------+
| AccountingRuleDetail |
+----------+-----------+
/ \ 0..n
|
| PolicyControlsAccounting
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 12. Modeling Accounting Mechanisms
This document only defines the AccountingECAPolicyRule; all other
classes, and the aggregations, are defined in an external model.
For completeness, descriptions of how the two aggregations are used
are described below.
Figure 12 defines an aggregation between the AccountingECAPolicyRule
and an external class that defines one or more accounting methods.
This decouples the implementation of accounting mechanisms from how
accounting mechanisms are managed and used.
Since different AccountingECAPolicyRules can use different
accounting mechanisms in different ways, the aggregation is realized
as an association class. This enables the attributes and methods of
the association class (i.e., AccountingRuleDetail) to be used to
define how a given AccountingMethod is used by a particular
AccountingECAPolicyRule.
Similarly, the PolicyControlsAccounting aggregation defines Policy
Rules to control the configuration of the AccountingRuleDetail
association class. This enables the entire accounting process to be
managed by ECA PolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define
two attributes for the AccountingECAPolicyRule class, called
(for example) accountingMethodCurrent and accountingMethodSupported,
to represent the HasAccountingMethod aggregation and its association
class.
The former is a string attribute that defines the current accounting
method used by this AccountingECAPolicyRule, while the latter
defines a set of accounting methods, in the form of an accounting
Capability, which this AccountingECAPolicyRule can advertise.
A.4. TrafficInspectionECAPolicyRuleClass Definition
The purpose of a TrafficInspectionECAPolicyRule is to define an I2NSF
ECA Policy Rule that, based on a given context, can determine which
traffic to examine on which devices, which information to collect
from those devices, and how to collect that information.
This class does NOT define the traffic inspection method(s) used.
This is because this would effectively "enclose" this information
within the TrafficInspectionECAPolicyRule. This has two drawbacks.
First, other entities that need to use information from the
TrafficInspection class(es) could not; they would have to associate
with the TrafficInspectionECAPolicyRule class, and those other
classes would not likely be interested in the
TrafficInspectionECAPolicyRule. Second, the evolution of new traffic
inspection methods should be independent of the
TrafficInspectionECAPolicyRule; this cannot happen if the
TrafficInspection class(es) are embedded in the
TrafficInspectionECAPolicyRule. Hence, this document recommends the
following design:
+------------------+
+-------------------+1..n 1..n| |
| |/ \ HasTrafficInspection \| Traffic |
| TrafficInspection + A ----------+-------------+ InspectionMethod |
| ECAPolicyRule |\ / ^ / | |
| | | +------------------+
+-------------------+ |
|
+------------+------------+
| TrafficInspectionDetail |
+------------+------------+
/ \ 0..n
|
| PolicyControlsTrafficInspection
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 13. Modeling Traffic Inspection Mechanisms
This document only defines the TrafficInspectionECAPolicyRule; all
other classes, and the aggregations, are defined in an external
model. For completeness, descriptions of how the two aggregations
are used are described below.
Figure 13 defines an aggregation between the
TrafficInspectionECAPolicyRule and an external class that defines
one or more traffic inspection mechanisms. This decouples the
implementation of traffic inspection mechanisms from how traffic
inspection mechanisms are managed and used.
Since different TrafficInspectionECAPolicyRules can use different
traffic inspection mechanisms in different ways, the aggregation is
realized as an association class. This enables the attributes and
methods of the association class (i.e., TrafficInspectionDetail) to
be used to define how a given TrafficInspectionMethod is used by a
particular TrafficInspectionECAPolicyRule.
Similarly, the PolicyControlsTrafficInspection aggregation defines
Policy Rules to control the configuration of the
TrafficInspectionDetail association class. This enables the entire
traffic inspection process to be managed by ECA PolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define
two attributes for the TrafficInspectionECAPolicyRule class, called
(for example) trafficInspectionMethodCurrent and
trafficInspectionMethodSupported, to represent the
HasTrafficInspectionMethod aggregation and its association class.
The former is a string attribute that defines the current traffic
inspection method used by this TrafficInspectionECAPolicyRule,
while the latter defines a set of traffic inspection methods, in
the form of a traffic inspection Capability, which this
TrafficInspectionECAPolicyRule can advertise.
A.5. ApplyProfileECAPolicyRuleClass Definition
The purpose of an ApplyProfileECAPolicyRule is to define an I2NSF
ECA Policy Rule that, based on a given context, can apply a
particular profile to specific traffic. The profile defines the
security Capabilities for content security control and/or attack
mitigation control; these will be described in sections 4.4 and
4.5, respectively.
This class does NOT define the set of Profiles used. This is
because this would effectively "enclose" this information within
the ApplyProfileECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Profile class(es)
could not; they would have to associate with the
ApplyProfileECAPolicyRule class, and those other classes would not
likely be interested in the ApplyProfileECAPolicyRule. Second, the
evolution of new Profile classes should be independent of the
ApplyProfileECAPolicyRule; this cannot happen if the Profile
class(es) are embedded in the ApplyProfileECAPolicyRule. Hence,
this document recommends the following design:
+-------------+
+-------------------+ 1..n 1..n | |
| |/ \ ProfileApplied \| |
| ApplyProfile + A -----------+-------------+ Profile |
| ECAPolicyRule |\ / ^ /| |
| | | +-------------+
+-------------------+ |
|
+------------+---------+
| ProfileAppliedDetail |
+------------+---------+
/ \ 0..n
|
|
PolicyControlsProfileApplication |
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 14. Modeling Profile ApplicationMechanisms
This document only defines the ApplyProfileECAPolicyRule; all other
classes, and the aggregations, are defined in an external model.
For completeness, descriptions of how the two aggregations are used
are described below.
Figure 14 defines an aggregation between the
ApplyProfileECAPolicyRule and an external Profile class. This
decouples the implementation of Profiles from how Profiles are used.
Since different ApplyProfileECAPolicyRules can use different
Profiles in different ways, the aggregation is realized as an
association class. This enables the attributes and methods of the
association class (i.e., ProfileAppliedDetail) to be used to define
how a given Profile is used by a particular
ApplyProfileECAPolicyRule.
Similarly, the PolicyControlsProfileApplication aggregation defines
policies to control the configuration of the ProfileAppliedDetail
association class. This enables the application of Profiles to be
managed and used by ECA PolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define two
attributes for the ApplyProfileECAPolicyRuleclass, called (for
example) profileAppliedCurrent and profileAppliedSupported, to
represent the ProfileApplied aggregation and its association class.
The former is a string attribute that defines the current Profile
used by this ApplyProfileECAPolicyRule, while the latter defines a
set of Profiles, in the form of a Profile Capability, which this
ApplyProfileECAPolicyRule can advertise.
A.6. ApplySignatureECAPolicyRuleClass Definition
The purpose of an ApplySignatureECAPolicyRule is to define an I2NSF
ECA Policy Rule that, based on a given context, can determine which
Signature object (e.g., an anti-virus file, or aURL filtering file,
or a script) to apply to which traffic. The Signature object defines
the security Capabilities for content security control and/or attack
mitigation control; these will be described in sections 4.4 and 4.5,
respectively.
This class does NOT define the set of Signature objects used. This
is because this would effectively "enclose" this information within
the ApplySignatureECAPolicyRule. This has two drawbacks. First,
other entities that need to use information from the Signature
object class(es) could not; they would have to associate with the
ApplySignatureECAPolicyRule class, and those other classes would not
likely be interested in the ApplySignatureECAPolicyRule. Second, the
evolution of new Signature object classes should be independent of
the ApplySignatureECAPolicyRule; this cannot happen if the Signature
object class(es) are embedded in the ApplySignatureECAPolicyRule.
Hence, this document recommends the following design:
This document only defines the ApplySignatureECAPolicyRule; all
other classes, and the aggregations, are defined in an external
model. For completeness, descriptions of how the two aggregations
are used are described below.
Figure 15 defines an aggregation between the
ApplySignatureECAPolicyRule and an external Signature object class.
This decouples the implementation of signature objects from how
Signature objects are used.
Since different ApplySignatureECAPolicyRules can use different
Signature objects in different ways, the aggregation is realized as
an association class. This enables the attributes and methods of the
association class (i.e., SignatureAppliedDetail) to be used to
define how a given Signature object is used by a particular
ApplySignatureECAPolicyRule.
+-------------+
+---------------+ 1..n 1..n | |
| |/ \ SignatureApplied \| |
| ApplySignature+ A ----------+--------------+ Signature |
| ECAPolicyRule |\ / ^ /| |
| | | +-------------+
+---------------+ |
|
+------------+-----------+
| SignatureAppliedDetail |
+------------+-----------+
/ \ 0..n
|
| PolicyControlsSignatureApplication
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 15. Modeling Sginature Application Mechanisms
Similarly, the PolicyControlsSignatureApplication aggregation
defines policies to control the configuration of the
SignatureAppliedDetail association class. This enables the
application of the Signature object to be managed by policy.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define
two attributes for the ApplySignatureECAPolicyRule class, called
(for example) signature signatureAppliedCurrent and
signatureAppliedSupported, to represent the SignatureApplied
aggregation and its association class. The former is a string
attribute that defines the current Signature object used by this
ApplySignatureECAPolicyRule, while the latter defines a set of
Signature objects, in the form of a Signature Capability, which
this ApplySignatureECAPolicyRule can advertise.
Appendix B. Network Security Event Class Definitions
This Appendix defines a preliminary set of Network Security Event
classes, along with their attributes.
B.1. UserSecurityEvent Class Description
The purpose of this class is to represent Events that are initiated The purpose of this class is to represent Events that are initiated
by a user, such as logon and logoff Events. Information in this by a user, such as logon and logoff Events. Information in this
Event may be used as part of a test to determine if the Condition Event may be used as part of a test to determine if the Condition
clause in this ECA Policy Rule should be evaluated or not. Examples clause in this ECA Policy Rule should be evaluated or not. Examples
include user identification data and the type of connection used by include user identification data and the type of connection used by
the user. the user.
The UserSecurityEvent class defines the following attributes: The UserSecurityEvent class defines the following attributes.
6.1.3.1.1. The usrSecEventContent Attribute B.1.1. The usrSecEventContent Attribute
This is a mandatory string that contains the content of the This is a mandatory string that contains the content of the
UserSecurityEvent. The format of the content is specified in the UserSecurityEvent. The format of the content is specified in the
usrSecEventFormat class attribute, and the type of Event is defined usrSecEventFormat class attribute, and the type of Event is defined
in the usrSecEventType class attribute. An example of the in the usrSecEventType class attribute. An example of the
usrSecEventContent attribute is the string "hrAdmin", with the usrSecEventContent attribute is the string "hrAdmin", with the
usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute
set to 5 (new logon). set to 5 (new logon).
6.1.3.1.2. The usrSecEventFormat Attribute B.1.2. The usrSecEventFormat Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the data type of the usrSecEventContent attribute. The to specify the data type of the usrSecEventContent attribute. The
content is specified in the usrSecEventContent class attribute, and content is specified in the usrSecEventContent class attribute, and
the type of Event is defined in the usrSecEventType class attribute. the type of Event is defined in the usrSecEventType class attribute.
An example of the usrSecEventContent attribute is the string An example of the usrSecEventContent attribute is the string
"hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and
the usrSecEventType attribute set to 5 (new logon). Values include: the usrSecEventType attribute set to 5 (new logon). Values include:
0: unknown 0: unknown
1: GUID (Generic Unique IDentifier) 1: GUID (Generic Unique IDentifier)
2: UUID (Universal Unique IDentifier) 2: UUID (Universal Unique IDentifier)
3: URI (Uniform Resource Identifier) 3: URI (Uniform Resource Identifier)
4: FQDN (Fully Qualified Domain Name) 4: FQDN (Fully Qualified Domain Name)
5: FQPN (Fully Qualified Path Name) 5: FQPN (Fully Qualified Path Name)
6.1.3.1.3. The usrSecEventType Attribute B.1.3. The usrSecEventType Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the type of Event that involves this user. The content to specify the type of Event that involves this user. The content
and format are specified in the usrSecEventContent and and format are specified in the usrSecEventContent and
usrSecEventFormat class attributes, respectively. An example of the usrSecEventFormat class attributes, respectively.
usrSecEventContent attribute is the string "hrAdmin", with the
usrSecEventFormat attribute set to 1 (GUID) and the usrSecEventType An example of the usrSecEventContent attribute is the string
attribute set to 5 (new logon). Values include: "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID), and
the usrSecEventType attribute set to 5 (new logon). Values include:
0: unknown 0: unknown
1: new user created 1: new user created
2: new user group created 2: new user group created
3: user deleted 3: user deleted
4: user group deleted 4: user group deleted
5: user logon 5: user logon
6: user logoff 6: user logoff
7: user access request 7: user access request
8: user access granted 8: user access granted
9: user access violation 9: user access violation
6.1.3.2. DeviceSecurityEvent Class Description B.2. DeviceSecurityEvent Class Description
The purpose of a DeviceSecurityEvent is to represent Events that The purpose of a DeviceSecurityEvent is to represent Events that
provide information from the Device that are important to I2NSF provide information from the Device that are important to I2NSF
Security. Information in this Event may be used as part of a test to Security. Information in this Event may be used as part of a test
determine if the Condition clause in this ECA Policy Rule should be to determine if the Condition clause in this ECA Policy Rule should
evaluated or not. Examples include alarms and various device be evaluated or not. Examples include alarms and various device
statistics (e.g., a type of threshold that was exceeded), which may statistics (e.g., a type of threshold that was exceeded), which may
signal the need for further action. signal the need for further action.
The DeviceSecurityEvent class defines the following attributes: The DeviceSecurityEvent class defines the following attributes.
6.1.3.2.1. The devSecEventContent Attribute B.2.1. The devSecEventContent Attribute
This is a mandatory string that contains the content of the This is a mandatory string that contains the content of the
DeviceSecurityEvent. The format of the content is specified in the DeviceSecurityEvent. The format of the content is specified in the
devSecEventFormat class attribute, and the type of Event is defined devSecEventFormat class attribute, and the type of Event is defined
in the devSecEventType class attribute. An example of the in the devSecEventType class attribute. An example of the
devSecEventContent attribute is "alarm", with the devSecEventFormat devSecEventContent attribute is "alarm", with the devSecEventFormat
attribute set to 1 (GUID), the devSecEventType attribute set to 5 attribute set to 1 (GUID), the devSecEventType attribute set to
(new logon). 5 (new logon).
6.1.3.2.2. The devSecEventFormat Attribute B.2.2. The devSecEventFormat Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the data type of the devSecEventContent attribute. Values to specify the data type of the devSecEventContent attribute.
include: Values include:
0: unknown 0: unknown
1: GUID (Generic Unique IDentifier) 1: GUID (Generic Unique IDentifier)
2: UUID (Universal Unique IDentifier) 2: UUID (Universal Unique IDentifier)
3: URI (Uniform Resource Identifier) 3: URI (Uniform Resource Identifier)
4: FQDN (Fully Qualified Domain Name) 4: FQDN (Fully Qualified Domain Name)
5: FQPN (Fully Qualified Path Name) 5: FQPN (Fully Qualified Path Name)
6.1.3.2.3. The devSecEventType Attribute B.2.3. The devSecEventType Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the type of Event that was generated by this device. to specify the type of Event that was generated by this device.
Values include: Values include:
0: unknown 0: unknown
1: communications alarm 1: communications alarm
2: quality of service alarm 2: quality of service alarm
3: processing error alarm 3: processing error alarm
4: equipment error alarm 4: equipment error alarm
5: environmental error alarm 5: environmental error alarm
Values 1-5 are defined in X.733. Additional types of errors may also Values 1-5 are defined in X.733. Additional types of errors may also
be defined. be defined.
6.1.3.2.4. The devSecEventTypeInfo[0..n] Attribute B.2.4. The devSecEventTypeInfo[0..n] Attribute
This is an optional array of strings, which is used to provide This is an optional array of strings, which is used to provide
additional information describing the specifics of the Event additional information describing the specifics of the Event
generated by this Device. For example, this attribute could contain generated by this Device. For example, this attribute could contain
probable cause information in the first array, trend information in probable cause information in the first array, trend information in
the second array, proposed repair actions in the third array, and the second array, proposed repair actions in the third array, and
additional information in the fourth array. additional information in the fourth array.
6.1.3.2.5. The devSecEventTypeSeverity Attribute B.2.5. The devSecEventTypeSeverity Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the perceived severity of the Event generated by this to specify the perceived severity of the Event generated by this
Device. Values include: Device. Values (which are defined in X.733) include:
0: unknown 0: unknown
1: cleared 1: cleared
2: indeterminate 2: indeterminate
3: critical 3: critical
4: major 4: major
5: minor 5: minor
6: warning 6: warning
Values 1-6 are from X.733. B.3. SystemSecurityEvent Class Description
6.1.3.3. SystemSecurityEvent Class Description
The purpose of a SystemSecurityEvent is to represent Events that are The purpose of a SystemSecurityEvent is to represent Events that
detected by the management system, instead of Events that are are detected by the management system, instead of Events that are
generated by a user or a device. Information in this Event may be generated by a user or a device. Information in this Event may be
used as part of a test to determine if the Condition clause in this used as part of a test to determine if the Condition clause in
ECA Policy Rule should be evaluated or not. Examples include an this ECA Policy Rule should be evaluated or not. Examples include
event issued by an analytics system that warns against a particular an event issued by an analytics system that warns against a
pattern of unknown user accesses, or an Event issued by a management particular pattern of unknown user accesses, or an Event issued by
system that represents a set of correlated and/or filtered Events. a management system that represents a set of correlated and/or
filtered Events.
The SystemSecurityEvent class defines the following attributes: The SystemSecurityEvent class defines the following attributes.
6.1.3.3.1. The sysSecEventContent Attribute B.3.1. The sysSecEventContent Attribute
This is a mandatory string that contains the content of the This is a mandatory string that contains the content of the
SystemSecurityEvent. The format of the content is specified in the SystemSecurityEvent. The format of the content is specified in the
sysSecEventFormat class attribute, and the type of Event is defined sysSecEventFormat class attribute, and the type of Event is defined
in the sysSecEventType class attribute. An example of the in the sysSecEventType class attribute. An example of the
sysSecEventContent attribute is the string "sysadmin3", with the sysSecEventContent attribute is the string "sysadmin3", with the
sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType
attribute set to 2 (audit log cleared). attribute set to 2 (audit log cleared).
6.1.3.3.2. The sysSecEventFormat Attribute B.3.2. The sysSecEventFormat Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the data type of the sysSecEventContent attribute. Values to specify the data type of the sysSecEventContent attribute.
include: Values include:
0: unknown 0: unknown
1: GUID (Generic Unique IDentifier) 1: GUID (Generic Unique IDentifier)
2: UUID (Universal Unique IDentifier) 2: UUID (Universal Unique IDentifier)
3: URI (Uniform Resource Identifier) 3: URI (Uniform Resource Identifier)
4: FQDN (Fully Qualified Domain Name) 4: FQDN (Fully Qualified Domain Name)
5: FQPN (Fully Qualified Path Name) 5: FQPN (Fully Qualified Path Name)
6.1.3.3.3. The sysSecEventType Attribute B.3.3. The sysSecEventType Attribute
This is a mandatory non-negative enumerated integer, which is used This is a mandatory non-negative enumerated integer, which is used
to specify the type of Event that involves this device. Values to specify the type of Event that involves this device.
include: Values include:
0: unknown 0: unknown
1: audit log written to 1: audit log written to
2: audit log cleared 2: audit log cleared
3: policy created 3: policy created
4: policy edited 4: policy edited
5: policy deleted 5: policy deleted
6: policy executed 6: policy executed
6.1.3.4. TimeSecurityEvent Class Description B.4. TimeSecurityEvent Class Description
The purpose of a TimeSecurityEvent is to represent Events that are The purpose of a TimeSecurityEvent is to represent Events that are
temporal in nature (e.g., the start or end of a period of time). temporal in nature (e.g., the start or end of a period of time).
Time events signify an individual occurrence, or a time period, in Time events signify an individual occurrence, or a time period, in
which a significant event happened. Information in this Event may be which a significant event happened. Information in this Event may be
used as part of a test to determine if the Condition clause in this used as part of a test to determine if the Condition clause in this
ECA Policy Rule should be evaluated or not. Examples include issuing ECA Policy Rule should be evaluated or not. Examples include issuing
an Event at a specific time to indicate that a particular resource an Event at a specific time to indicate that a particular resource
should not be accessed, or that different authentication and should not be accessed, or that different authentication and
authorization mechanisms should now be used (e.g., because it is now authorization mechanisms should now be used (e.g., because it is now
past regular business hours). past regular business hours).
The TimeSecurityEvent class defines the following attributes: The TimeSecurityEvent class defines the following attributes.
6.1.3.4.1. The timeSecEventPeriodBegin Attribute B.4.1. The timeSecEventPeriodBegin Attribute
This is a mandatory DateTime attribute, and represents the beginning This is a mandatory DateTime attribute, and represents the beginning
of a time period. It has a value that has a date and/or a time of a time period. It has a value that has a date and/or a time
component (as in the Java or Python libraries). component (as in the Java or Python libraries).
6.1.3.4.2. The timeSecEventPeriodEnd Attribute B.4.2. The timeSecEventPeriodEnd Attribute
This is a mandatory DateTime attribute, and represents the end of a This is a mandatory DateTime attribute, and represents the end of a
time period. It has a value that has a date and/or a time component time period. It has a value that has a date and/or a time component
(as in the Java or Python libraries). If this is a single Event (as in the Java or Python libraries). If this is a single Event
occurence, and not a time period when the Event can occur, then the occurence, and not a time period when the Event can occur, then the
timeSecEventPeriodEnd attribute may be ignored. timeSecEventPeriodEnd attribute may be ignored.
6.1.3.4.3. The timeSecEventTimeZone Attribute B.4.3. The timeSecEventTimeZone Attribute
This is a mandatory string attribute, and defines the time zone that This is a mandatory string attribute, and defines the time zone that
this Event occurred in using the format specified in ISO8601. this Event occurred in using the format specified in ISO8601.
6.1.4. Network Security Condition Sub-Model Appendix C. Network Security Condition Class Definitions
Figure 6 shows a more detailed design of the Condition subclasses
that are contained in the Network Security Information Sub-Model.
+---------------------+
+---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass |
| ECAPolicyRule+ A ----------+ for ECA Objects |
| |\ / /| |
+-------+-------+ +-----------+---------+
/ \
|
|
+--------------+----------+----+
| | |
| | |
+-----+----+ +------+------+ +-----+-----+
| An Event | | A Condition | | An Action |
| Class | | Class | | Class |
+----------+ +------+------+ +-----------+
/ \
|
|
+--------+----------+------+---+---------+--------+--- ...
| | | | | |
| | | | | |
+-----+-----+ | +-------+-------+ | +------+-----+ |
| Packet | | | PacketPayload | | | Target | |
| Security | | | Security | | | Security | |
| Condition | | | Condition | | | Condition | |
+-----------+ | +---------------+ | +------------+ |
| | |
+------+-------+ +----------+------+ +--------+-------+
| UserSecurity | | SecurityContext | | GenericContext |
| Condition | | Condition | | Condition |
+--------------+ +-----------------+ +----------------+
Figure 6. Network Security Info Sub-Model Condition Class
Extensions
The six Condition classes shown in Figure 6 extend the (external)
generic Condition class to represent Conditions that are of interest
to Network Security. It is assumed that the (external) generic
Condition class is abstract, so that data model optimizations may be
defined. It is also assumed that the generic Condition class defines
basic Condition information in the form of attributes, such as a
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
attributes in a SecurityCondition class (which would be a subclass
of the generic Condition class, and a superclass of the six
Condition classes shown in Figure 11), this makes it harder to use
any generic Condition model with the I2NSF conditions.
Brief class descriptions are provided in the following sub-sections. This Appendix defines a preliminary set of Network Security Condition
classes, along with their attributes.
6.1.4.1. PacketSecurityCondition C.1. PacketSecurityCondition
The purpose of this Class is to represent packet header information The purpose of this Class is to represent packet header information
that can be used as part of a test to determine if the set of Policy that can be used as part of a test to determine if the set of Policy
Actions in this ECA Policy Rule should be executed or not. This Actions in this ECA Policy Rule should be executed or not. This class
class is abstract, and serves as the superclass of more detailed is abstract, and serves as the superclass of more detailed conditions
conditions that involve different types of packet formats. Its that act on different types of packet formats. Its subclasses are
subclasses are shown in Figure 7, and are defined in the following shown in Figure 16, and are defined in the following sections.
sections.
+-------------------------+ +-------------------------+
| PacketSecurityCondition | | PacketSecurityCondition |
+------------+------------+ +------------+------------+
/ \ / \
| |
| |
+---------+----------+---+-----+----------+ +---------+----------+---+-----+----------+
| | | | | | | | | |
| | | | | | | | | |
+--------+-------+ | +--------+-------+ | +--------+-------+ +--------+-------+ | +--------+-------+ | +--------+-------+
| PacketSecurity | | | PacketSecurity | | | PacketSecurity | | PacketSecurity | | | PacketSecurity | | | PacketSecurity |
| MACCondition | | | IPv4Condition | | | IPv6Condition | | MACCondition | | | IPv4Condition | | | IPv6Condition |
+----------------+ | +----------------+ | +----------------+ +----------------+ | +----------------+ | +----------------+
| | | |
+--------+-------+ +--------+-------+ +--------+-------+ +--------+-------+
| TCPCondition | | UDPCondition | | TCPCondition | | UDPCondition |
+----------------+ +----------------+ +----------------+ +----------------+
Figure 7. Network Security Info Sub-Model PacketSecurityCondition Figure 16. Network Security Info Sub-Model PacketSecurityCondition
Class Extensions Class Extensions
6.1.4.1.1. PacketSecurityMACCondition C.1.1. PacketSecurityMACCondition
The purpose of this Class is to represent packet MAC packet header The purpose of this Class is to represent packet MAC packet header
information that can be used as part of a test to determine if the information that can be used as part of a test to determine if the
set of Policy Actions in this ECA Policy Rule should be executed or set of Policy Actions in this ECA Policy Rule should be executed or
not. This class is concrete, and defines the following attributes: not. This class is concrete, and defines the following attributes.
6.1.4.1.1.1. The pktSecCondMACDest Attribute C.1.1.1. The pktSecCondMACDest Attribute
This is a mandatory string attribute, and defines the MAC This is a mandatory string attribute, and defines the MAC
destination address (6 octets long). destination address (6 octets long).
6.1.4.1.1.2. The pktSecCondMACSrc Attribute C.1.1.2. The pktSecCondMACSrc Attribute
This is a mandatory string attribute, and defines the MAC source This is a mandatory string attribute, and defines the MAC source
address (6 octets long). address (6 octets long).
6.1.4.1.1.3. The pktSecCondMAC8021Q Attribute C.1.1.3. The pktSecCondMAC8021Q Attribute
This is an optional string attribute, and defines the 802.1Q tag This is an optional string attribute, and defines the 802.1Q tag
value (2 octets long). This defines VLAN membership and 802.1p value (2 octets long). This defines VLAN membership and 802.1p
priority values. priority values.
6.1.4.1.1.4. The pktSecCondMACEtherType Attribute C.1.1.4. The pktSecCondMACEtherType Attribute
This is a mandatory string attribute, and defines the EtherType This is a mandatory string attribute, and defines the EtherType
field (2 octets long). Values up to and including 1500 indicate the field (2 octets long). Values up to and including 1500 indicate the
size of the payload in octets; values of 1536 and above define which size of the payload in octets; values of 1536 and above define
protocol is encapsulated in the payload of the frame. which protocol is encapsulated in the payload of the frame.
6.1.4.1.1.5. The pktSecCondMACTCI Attribute C.1.1.5. The pktSecCondMACTCI Attribute
This is an optional string attribute, and defines the Tag Control This is an optional string attribute, and defines the Tag Control
Information. This consists of a 3 bit user priority field, a drop Information. This consists of a 3 bit user priority field, a drop
eligible indicator (1 bit), and a VLAN identifier (12 bits). eligible indicator (1 bit), and a VLAN identifier (12 bits).
6.1.4.1.2. PacketSecurityIPv4Condition C.1.2. PacketSecurityIPv4Condition
The purpose of this Class is to represent packet IPv4 packet header The purpose of this Class is to represent packet IPv4 packet header
information that can be used as part of a test to determine if the information that can be used as part of a test to determine if the
set of Policy Actions in this ECA Policy Rule should be executed or set of Policy Actions in this ECA Policy Rule should be executed or
not. This class is concrete, and defines the following attributes: not. This class is concrete, and defines the following attributes.
6.1.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute C.1.2.1. The pktSecCondIPv4SrcAddr Attribute
This is a mandatory string attribute, and defines the IPv4 Source This is a mandatory string attribute, and defines the IPv4 Source
Address (32 bits). Address (32 bits).
6.1.4.1.2.2. The pktSecCondIPv4DestAddr Attribute C.1.2.2. The pktSecCondIPv4DestAddr Attribute
This is a mandatory string attribute, and defines the IPv4 This is a mandatory string attribute, and defines the IPv4
Destination Address (32 bits). Destination Address (32 bits).
6.1.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute
This is a mandatory string attribute, and defines the protocol used This is a mandatory string attribute, and defines the protocol used
in the data portion of the IP datagram (8 bits). in the data portion of the IP datagram (8 bits).
6.1.4.1.2.4. The pktSecCondIPv4DSCP Attribute C.1.2.4. The pktSecCondIPv4DSCP Attribute
This is a mandatory string attribute, and defines the Differentiated This is a mandatory string attribute, and defines the Differentiated
Services Code Point field (6 bits). Services Code Point field (6 bits).
6.1.4.1.2.5. The pktSecCondIPv4ECN Attribute C.1.2.5. The pktSecCondIPv4ECN Attribute
This is an optional string attribute, and defines the Explicit This is an optional string attribute, and defines the Explicit
Congestion Notification field (2 bits). Congestion Notification field (2 bits).
6.1.4.1.2.6. The pktSecCondIPv4TotalLength Attribute C.1.2.6. The pktSecCondIPv4TotalLength Attribute
This is a mandatory string attribute, and defines the total length This is a mandatory string attribute, and defines the total length
of the packet (including header and data) in bytes (16 bits). of the packet (including header and data) in bytes (16 bits).
6.1.4.1.2.7. The pktSecCondIPv4TTL Attribute C.1.2.7. The pktSecCondIPv4TTL Attribute
This is a mandatory string attribute, and defines the Time To Live This is a mandatory string attribute, and defines the Time To Live
in seconds (8 bits). in seconds (8 bits).
6.1.4.1.3. PacketSecurityIPv6Condition C.1.3. PacketSecurityIPv6Condition
The purpose of this Class is to represent packet IPv6 packet header The purpose of this Class is to represent packet IPv6 packet header
information that can be used as part of a test to determine if the information that can be used as part of a test to determine if the
set of Policy Actions in this ECA Policy Rule should be executed or set of Policy Actions in this ECA Policy Rule should be executed or
not. This class is concrete, and defines the following attributes: not. This class is concrete, and defines the following attributes.
6.1.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute C.1.3.1. The pktSecCondIPv6SrcAddr Attribute
This is a mandatory string attribute, and defines the IPv6 Source This is a mandatory string attribute, and defines the IPv6 Source
Address (128 bits). Address (128 bits).
6.1.4.1.3.2. The pktSecCondIPv6DestAddr Attribute C.1.3.2. The pktSecCondIPv6DestAddr Attribute
This is a mandatory string attribute, and defines the IPv6 This is a mandatory string attribute, and defines the IPv6
Destination Address (128 bits). Destination Address (128 bits).
6.1.4.1.3.3. The pktSecCondIPv6DSCP Attribute C.1.3.3. The pktSecCondIPv6DSCP Attribute
This is a mandatory string attribute, and defines the Differentiated This is a mandatory string attribute, and defines the Differentiated
Services Code Point field (6 bits). It consists of the six most Services Code Point field (6 bits). It consists of the six most
significant bits of the Traffic Class field in the IPv6 header. significant bits of the Traffic Class field in the IPv6 header.
6.1.4.1.3.4. The pktSecCondIPv6ECN Attribute C.1.3.4. The pktSecCondIPv6ECN Attribute
This is a mandatory string attribute, and defines the Explicit This is a mandatory string attribute, and defines the Explicit
Congestion Notification field (2 bits). It consists of the two least Congestion Notification field (2 bits). It consists of the two least
significant bits of the Traffic Class field in the IPv6 header. significant bits of the Traffic Class field in the IPv6 header.
6.1.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute C.1.3.5. The pktSecCondIPv6FlowLabel Attribute
This is a mandatory string attribute, and defines an IPv6 flow label. This is a mandatory string attribute, and defines an IPv6 flow
This, in combination with the Source and Destination Address fields, label. This, in combination with the Source and Destination Address
enables efficient IPv6 flow classification by using only the IPv6 fields, enables efficient IPv6 flow classification by using only the
main header fields (20 bits). IPv6 main header fields (20 bits).
6.1.4.1.3.6. The pktSecCondIPv6PayloadLength Attribute C.1.3.6. The pktSecCondIPv6PayloadLength Attribute
This is a mandatory string attribute, and defines the total length This is a mandatory string attribute, and defines the total length
of the packet (including the fixed and any extension headers, and of the packet (including the fixed and any extension headers, and
data) in bytes (16 bits). data) in bytes (16 bits).
6.1.4.1.3.7. The pktSecCondIPv6NextHeader Attribute C.1.3.7. The pktSecCondIPv6NextHeader Attribute
This is a mandatory string attribute, and defines the type of the This is a mandatory string attribute, and defines the type of the
next header (e.g., which extension header to use) (8 bits). next header (e.g., which extension header to use) (8 bits).
6.1.4.1.3.8. The pktSecCondIPv6HopLimit Attribute C.1.3.8. The pktSecCondIPv6HopLimit Attribute
This is a mandatory string attribute, and defines the maximum number This is a mandatory string attribute, and defines the maximum
of hops that this packet can traverse (8 bits). number of hops that this packet can traverse (8 bits).
6.1.4.1.4. PacketSecurityTCPCondition C.1.4. PacketSecurityTCPCondition
The purpose of this Class is to represent packet TCP packet header The purpose of this Class is to represent packet TCP packet header
information that can be used as part of a test to determine if the information that can be used as part of a test to determine if the
set of Policy Actions in this ECA Policy Rule should be executed or set of Policy Actions in this ECA Policy Rule should be executed or
not. This class is concrete, and defines the following attributes: not. This class is concrete, and defines the following attributes.
6.1.4.1.4.1. The pktSecCondTPCSrcPort Attribute C.1.4.1. The pktSecCondTPCSrcPort Attribute
This is a mandatory string attribute, and defines the Source Port This is a mandatory string attribute, and defines the Source Port
(16 bits). number (16 bits).
6.1.4.1.4.2. The pktSecCondTPCDestPort Attribute C.1.4.2. The pktSecCondTPCDestPort Attribute
This is a mandatory string attribute, and defines the Destination This is a mandatory string attribute, and defines the Destination
Port (16 bits). Port number (16 bits).
6.1.4.1.4.3. The pktSecCondTPCSeqNum Attribute C.1.4.3. The pktSecCondTCPSeqNum Attribute
This is a mandatory string attribute, and defines the sequence This is a mandatory string attribute, and defines the sequence
number (32 bits). number (32 bits).
6.1.4.1.4.4. The pktSecCondTPCFlags Attribute C.1.4.4. The pktSecCondTCPFlags Attribute
This is a mandatory string attribute, and defines the nine Control This is a mandatory string attribute, and defines the nine Control
bit flags (9 bits). bit flags (9 bits).
6.1.4.1.5. PacketSecurityUDPCondition C.1.5. PacketSecurityUDPCondition
The purpose of this Class is to represent packet UDP packet header The purpose of this Class is to represent packet UDP packet header
information that can be used as part of a test to determine if the information that can be used as part of a test to determine if the
set of Policy Actions in this ECA Policy Rule should be executed or set of Policy Actions in this ECA Policy Rule should be executed or
not. This class is concrete, and defines the following attributes: not. This class is concrete, and defines the following attributes.
6.1.4.1.5.1. The pktSecCondUDPSrcPort Attribute C.1.5.1.1. The pktSecCondUDPSrcPort Attribute
This is a mandatory string attribute, and defines the UDP Source This is a mandatory string attribute, and defines the UDP Source
Port (16 bits). Port number (16 bits).
6.1.4.1.5.2. The pktSecCondUDPDestPort Attribute C.1.5.1.2. The pktSecCondUDPDestPort Attribute
This is a mandatory string attribute, and defines the UDP This is a mandatory string attribute, and defines the UDP
Destination Port (16 bits). Destination Port number (16 bits).
6.1.4.1.5.3. The pktSecCondUDPLength Attribute C.1.5.1.3. The pktSecCondUDPLength Attribute
This is a mandatory string attribute, and defines the length in This is a mandatory string attribute, and defines the length in
bytes of the UDP header and data (16 bits). bytes of the UDP header and data (16 bits).
6.1.4.2. PacketPayloadSecurityCondition C.2. PacketPayloadSecurityCondition
The purpose of this Class is to represent packet payload data that The purpose of this Class is to represent packet payload data that
can be used as part of a test to determine if the set of Policy can be used as part of a test to determine if the set of Policy
Actions in this ECA Policy Rule should be executed or not. Examples Actions in this ECA Policy Rule should be executed or not. Examples
include a specific set of bytes in the packet payload. include a specific set of bytes in the packet payload.
6.1.4.3. TargetSecurityCondition C.3. TargetSecurityCondition
The purpose of this Class is to represent information about The purpose of this Class is to represent information about
different targets of this policy (i.e., entities to which this different targets of this policy (i.e., entities to which this
policy rule should be applied), which can be used as part of a test Policy Rule should be applied), which can be used as part of a
to determine if the set of Policy Actions in this ECA Policy Rule test to determine if the set of Policy Actions in this ECA Policy
should be executed or not. Examples include whether the targeted Rule should be executed or not. Examples include whether the
entities are playing the same role, or whether each device is targeted entities are playing the same role, or whether each
administered by the same set of users, groups, or roles. device is administered by the same set of users, groups, or roles.
This Class has several important subclasses, including: This Class has several important subclasses, including:
a. ServiceSecurityContextCondition is the superclass for all a. ServiceSecurityContextCondition is the superclass for all
information that can be used in an ECA Policy Rule that specifies information that can be used in an ECA Policy Rule that
data about the type of service to be analyzed (e.g., the protocol specifies data about the type of service to be analyzed
type and port number) (e.g., the protocol type and port number)
b. ApplicationSecurityContextCondition is the superclass for all
b. ApplicationSecurityContextCondition is the superclass for all information that can be used in a ECA Policy Rule that
information that can be used in a ECA Policy Rule that specifies specifies data that identifies a particular application
data that identifies a particular application (including metadata, (including metadata, such as risk level)
such as risk level) c. DeviceSecurityContextCondition is the superclass for all
information that can be used in a ECA Policy Rule that
c. DeviceSecurityContextCondition is the superclass for all specifies data about a device type and/or device OS that is
information that can be used in a ECA Policy Rule that specifies being used
data about a device type and/or device OS that is being used
6.1.4.4. UserSecurityCondition C.4. UserSecurityCondition
The purpose of this Class is to represent data about the user or The purpose of this Class is to represent data about the user or
group referenced in this ECA Policy Rule that can be used as part of group referenced in this ECA Policy Rule that can be used as part of
a test to determine if the set of Policy Actions in this ECA Policy a test to determine if the set of Policy Actions in this ECA Policy
Rule should be evaluated or not. Examples include the user or group Rule should be evaluated or not. Examples include the user or group
id used, the type of connection used, whether a given user or group id used, the type of connection used, whether a given user or group
is playing a particular role, or whether a given user or group has is playing a particular role, or whether a given user or group has
failed to login a particular number of times. failed to login a particular number of times.
6.1.4.5. SecurityContextCondition C.5. SecurityContextCondition
The purpose of this Class is to represent security conditions that The purpose of this Class is to represent security conditions that
are part of a specific context, which can be used as part of a test are part of a specific context, which can be used as part of a test
to determine if the set of Policy Actions in this ECA Policy Rule to determine if the set of Policy Actions in this ECA Policy Rule
should be evaluated or not. Examples include testing to determine if should be evaluated or not. Examples include testing to determine
a particular pattern of security-related data have occurred, or if if a particular pattern of security-related data have occurred, or
the current session state matches the expected session state. if the current session state matches the expected session state.
6.1.4.6. GenericContextSecurityCondition C.6. GenericContextSecurityCondition
The purpose of this Class is to represent generic contextual The purpose of this Class is to represent generic contextual
information in which this ECA Policy Rule is being executed, which information in which this ECA Policy Rule is being executed, which
can be used as part of a test to determine if the set of Policy can be used as part of a test to determine if the set of Policy
Actions in this ECA Policy Rule should be evaluated or not. Examples Actions in this ECA Policy Rule should be evaluated or not.
include geographic location and temporal information. Examples include geographic location and temporal information.
6.1.5. Network Security Action Sub-Model
Figure 7 shows a more detailed design of the Action subclasses that
are contained in the Network Security Information Sub-Model.
+---------------------+
+---------------+ 1..n 1..n | |
| |/ \ \| A Common Superclass |
| ECAPolicyRule+ A ----------+ for ECA Objects |
| |\ / /| |
+---------------+ +-----------+---------+
/ \
|
|
+--------------+--------+------+
| | |
| | |
+-----+----+ +------+------+ +-----+-----+
| An Event | | A Condition | | An Action |
| Class | | Class | | Class |
+----------+ +-------------+ +-----+-----+
/ \
|
|
+------------+-------------+------------------+-------- ...
| | | |
| | | |
+----+----+ +----+---+ +------+-------+ +-------+--------+
| Ingress | | Egress | | ApplyProfile | | ApplySignature |
| Action | | Action | | Action | | Action |
+---------+ +--------+ +--------------+ +----------------+
Figure 7. Network Security Info Sub-Model Action Extensions Appendix D. Network Security Action Class Definitions
The four Action classes shown in Figure 7 extend the (external) This Appendix defines a preliminary set of Network Security Action
generic Action class to represent Actions that perform a Network classes, along with their attributes.
Security Control function. Brief class descriptions are provided in
the following sub-sections.
6.1.5.1. IngressAction D.1. IngressAction
The purpose of this Class is to represent actions performed on The purpose of this Class is to represent actions performed on
packets that enter an NSF. Examples include pass, drop, mirror packets that enter an NSF. Examples include pass, dropp, or
traffic. mirror traffic.
6.1.5.2. EgressAction D.2. EgressAction
The purpose of this Class is to represent actions performed on The purpose of this Class is to represent actions performed on
packets that exit an NSF. Examples include pass, drop, mirror packets that exit an NSF. Examples include pass, drop, or mirror
traffic, signal, encapsulate. traffic, signal, and encapsulate.
6.1.5.3. ApplyProfileAction
The purpose of this Class is to represent applying a profile to
packets to perform content security and/or attack mitigation control.
6.1.5.4. ApplySignatureAction D.3. ApplyProfileAction
The purpose of this Class is to represent applying a signature file The purpose of this Class is to define the application of a profile
to packets to perform content security and/or attack mitigation to packets to perform content security and/or attack mitigation
control. control.
6.2. Information Model for Content Security Control Appendix E. Geometric Model
The block for content security control is composed of a number of
security capabilities, while each one aims for protecting against a
specific type of threat in the application layer.
Following figure shows a basic structure of the information model:
+----------------------------------+
| |
| |
| Anti-Virus |
| Intrusion Prevention |
| URL Filtering |
| File Blocking |
| Data Filtering |
| Application Behavior Control |
| Mail Filtering |
| Packet Capturing |
| File Isolation |
| ... |
| |
| |
| |
| |
| Information model |
| for content security|
| control |
+----------------------------------+
Figure 8. The basic structure of information model for content
security control
The detailed description about the standard interface and the
parameters for all the security capabilities of this category are
TBD.
6.3. Information Model for Attack Mitigation Control
The block for attack mitigation control is composed of a number of
security capabilities, while each one aims for mitigating a specific
type of network attack.
Following figure shows a basic structure of the information model:
Please view in a fixed-width font such as Courier.
+-------------------------------------------------+
| |
| +---------------------+ +---------------+ |
| |Attack mitigation | | General Shared| |
| |capabilites: | | Parameters: | |
| | SYN flood, | | | |
| | UDP flood, | | | |
| | ICMP flood, | | | |
| | IP fragment flood, | | | |
| | IPv6 related attacks| | | |
| | HTTP flood, | | | |
| | HTTPS flood, | | | |
| | DNS flood, | | | |
| | DNS amplification, | | | |
| | SSL DDoS, | | | |
| | IP sweep, | | | |
| | Port scanning, | | | |
| | Ping of Death, | | | |
| | Oversized ICMP | | | |
| | | | | |
| | ... | | | |
| | | | | |
| +---------------------+ +---------------+ |
| |
| Information model |
| for attack mitigation|
| control |
+-------------------------------------------------+
Figure 9. The basic structure of information model for attack
mitigation control
The detailed description about the standard interface and the
general shared parameters for all the security capabilities of this
category are TBD.
7. Security Considerations
The security capability policy information sent to NSFs should be
protected by the secure communication channel, to ensure the
confidentiality and integrity. In another side, the NSFs and
security controller can all be faked, which lead to undesirable
results, i.e., security policy leakage from security controller,
faked security controller sending false information to mislead the
NSFs. The mutual authentication is essential to protected against
this kind of attack. The current mainstream security technologies
(i.e., TLS, DTLS, IPSEC, X.509 PKI) can be employed appropriately to
provide the above security functionalities.
In addition, to defend against the DDoS attack caused by the
security controller sending too much configuration messages to the
NSFs, the rate limiting or similar mechanisms should be considered
in NSF, whether in advance or just in the process of DDoS attack.
8. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198,
November 2001, <http://www.rfc-editor.org/info/rfc3198>.
9.2. Informative References
[INCITS359 RBAC] NIST/INCITS, "American National Standard for
Information Technology - Role Based Access Control",
INCITS 359, April, 2003
[I-D.draft-ietf-i2nsf-problem-and-use-cases] Hares, S., et.al.,
"I2NSF Problem Statement and Use cases", Work in Progress,
February, 2016.
[I-D.draft-ietf-i2nsf-framework] Lopez, E., et.al., "Framework for
Interface to Network Security Functions", Work in Progress,
October, 2016.
[I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to
Network Security Functions (I2NSF) Terminology", Work in
Progress, April, 2016
[I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J.,
Halpern, J., Coleman, J., "Generic Policy Information
Model for Simplified Use of Policy Abstractions (SUPA)",
Work in Progress, June, 2016.
[I-D.draft-baspez-i2nsf-capabilities-00] Basile C., Lopez D. R., "A
Model of Security Capabilities for Network Security
Functions", July 2016
[I-D.draft-xia-i2nsf-capability-interface-im-06] Xia L., et al.,
"Information Model of Interface to Network Security
Functions Capability Interface", June 2016
[Alshaer] Al Shaer, E. and H. Hamed, "Modeling and management of
firewall policies", 2004.
[Bas12] Basile, C., Cappadonia, A., and A. Lioy, "Network-Level
Access Control Policy Analysis and Transformation", 2012.
[Bas15] Basile, C. and A. Lioy, "Analysis of application-layer
filtering policies with application to HTTP", 2015.
[Cormen] Cormen, T., "Introduction to Algorithms", 2009.
[Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable
packet classification", 2003.
[Taylor] Taylor, D. and J. Turner, "Scalable packet classification
using distributed crossproducting of field labels", 2004.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Appendix A.
Six exemplary policy rules of Network Security Capability are
introduced in this Appendix to clarify how to create different kinds
of specific ECA policy rules.
Note that there is a common pattern that defines how these
ECAPolicyRules operate; this simplifies their implementation. All of
these six ECA Policy Rules are concrete classes.
In addition, none of these six subclasses define attributes. This
enables them to be viewed as simple object containers, and hence,
applicable to a wide variety of content. It also means that the
content of the function (e.g., how an entity is authenticated, what
specific traffic is inspected, or which particular signature is
applied) is defined solely by the set of events, conditions, and
actions that are contained by the particular subclass. This enables
the policy rule, with its aggregated set of events, conditions, and
actions, to be treated as a reusable object.
A.1. AuthenticationECAPolicyRule Class Definition
The purpose of an AuthenticationECAPolicyRule is to define an ECA
Policy Rule that can verify whether an entity has an attribute of a
specific value.
This class does NOT define the authentication method used. This is
because this would effectively "enclose" this information within the
AuthenticationECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Authentication
class(es) could not; they would have to associate with the
AuthenticationECAPolicyRule class, and those other classes would not
likely be interested in the AuthenticationECAPolicyRule. Second, the
evolution of new authentication methods should be independent of the
AuthenticationECAPolicyRule; this cannot happen if the
Authentication class(es) are embedded in the
AuthenticationECAPolicyRule. Hence, this document recommends the
following design:
+----------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAuthenticationMethod \| Authentication |
| Authentication + A ----------+-----------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +----------------+
+----------------+ |
|
+------------+-------------+
| AuthenticationRuleDetail |
+------------+-------------+
/ \ 0..n
|
| PolicyControlsAuthentication
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 10. Modeling Authentication Mechanisms
This document only defines the AuthenticationECAPolicyRule; all
other classes, and the aggregations, are defined in an external
model. For completeness, descriptions of how the two aggregations
are used are below.
Figure 10 defines an aggregation between the
AuthenticationECAPolicyRule and an externalAuthenticationMethod
class (which is likely a superclass for different types of
authentication mechanisms). This decouples the implementation of
authentication mechanisms from how authentication mechanisms are
used.
Since different AuthenticationECAPolicyRules can use different
authentication mechanisms in different ways, the aggregation is
realized as an association class. This enables the attributes and
methods of the association class (i.e., AuthenticationRuleDetail) to
be used to define how a given AuthenticationMethod is used by a
particular AuthenticationECAPolicyRule.
Similarly, the PolicyControlsAuthentication aggregation defines
policies to control the configuration of the
AuthenticationRuleDetail association class. This enables the entire
authentication process to be managed by ECAPolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define two
attributes for the AuthenticationECAPolicyRule class, called (for
example) authenticationMethodCurrent and
authenticationMethodSupported, to represent the
HasAuthenticationMethod aggregation and its association class. The
former is a string attribute that defines the current authentication
method used by this AuthenticationECAPolicyRule, while the latter
defines a set of authentication methods, in the form of an
authentication capability, which this AuthenticationECAPolicyRule
can advertise.
A.2. AuthorizationECAPolicyRuleClass Definition
The purpose of an AuthorizationECAPolicyRule is to define an ECA
Policy Rule that can determine whether access to a resource should
be given and, if so, what permissions should be granted to the
entity that is accessing the resource.
This class does NOT define the authorization method(s) used. This is
because this would effectively "enclose" this information within the
AuthorizationECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Authorization
class(es) could not; they would have to associate with the
AuthorizationECAPolicyRule class, and those other classes would not
likely be interested in the AuthorizationECAPolicyRule. Second, the
evolution of new authorization methods should be independent of the
AuthorizationECAPolicyRule; this cannot happen if the Authorization
class(es) are embedded in the AuthorizationECAPolicyRule. Hence,
this document recommends the following design:
+---------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAuthorizationMethod \| Authorization |
| Authorization + A ----------+----------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +---------------+
+----------------+ |
|
+------------+------------+
| AuthorizationRuleDetail |
+------------+------------+
/ \ 0..n
|
| PolicyControlsAuthorization
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 11. Modeling Authorization Mechanisms
This document only defines the AuthorizationECAPolicyRule; all other
classes, and the aggregations, are defined in an external model. For
completeness, descriptions of how the two aggregations are used are
below.
Figure 11 defines an aggregation between the
AuthorizationECAPolicyRule and an external AuthorizationMethod class
(which is likely a superclass for different types of authorization
mechanisms). This decouples the implementation of authorization
mechanisms from how authorization mechanisms are used.
Since different AuthorizationECAPolicyRules can use different
authorization mechanisms in different ways, the aggregation is
realized as an association class. This enables the attributes and
methods of the association class (i.e., AuthorizationRuleDetail) to
be used to define how a given AuthorizationMethod is used by a
particular AuthorizationECAPolicyRule.
Similarly, the PolicyControlsAuthorization aggregation defines
policies to control the configuration of the AuthorizationRuleDetail
association class. This enables the entire authorization process to
be managed by ECAPolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define two
attributes for the AuthorizationECAPolicyRule class, called (for
example) authorizationMethodCurrent and authorizationMethodSupported,
to represent the HasAuthorizationMethod aggregation and its
association class. The former is a string attribute that defines the
current authorization method used by this AuthorizationECAPolicyRule,
while the latter defines a set of authorization methods, in the form
of an authorization capability, which this
AuthorizationECAPolicyRule can advertise.
A.3. AccountingECAPolicyRuleClass Definition
The purpose of an AccountingECAPolicyRule is to define an ECA Policy
Rule that can determine which information to collect, and how to
collect that information, from which set of resources for the
purpose of trend analysis, auditing, billing, or cost allocation
[RFC2975] [RFC3539].
This class does NOT define the accounting method(s) used. This is
because this would effectively "enclose" this information within the
AccountingECAPolicyRule. This has two drawbacks. First, other
entities that need to use information from the Accounting class(es)
could not; they would have to associate with the
AccountingECAPolicyRule class, and those other classes would not
likely be interested in the AccountingECAPolicyRule. Second, the
evolution of new accounting methods should be independent of the
AccountingECAPolicyRule; this cannot happen if the Accounting
class(es) are embedded in the AccountingECAPolicyRule. Hence, this
document recommends the following design:
+-------------+
+----------------+ 1..n 1...n | |
| |/ \ HasAccountingMethod \| Accounting |
| Accounting + A ----------+--------------+ Method |
| ECAPolicyRule |\ / ^ /| |
| | | +-------------+
+----------------+ |
|
+----------+-----------+
| AccountingRuleDetail |
+----------+-----------+
/ \ 0..n
|
| PolicyControlsAccounting
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 12. Modeling Accounting Mechanisms
This document only defines the AccountingECAPolicyRule; all other
classes, and the aggregations, are defined in an external model. For
completeness, descriptions of how the two aggregations are used are
below.
Figure 12 defines an aggregation between the AccountingECAPolicyRule
and an external AccountingMethod class (which is likely a superclass
for different types of accounting mechanisms). This decouples the
implementation of accounting mechanisms from how accounting
mechanisms are used.
Since different AccountingECAPolicyRules can use different
accounting mechanisms in different ways, the aggregation is realized
as an association class. This enables the attributes and methods of
the association class (i.e., AccountingRuleDetail) to be used to
define how a given AccountingMethod is used by a particular
AccountingECAPolicyRule.
Similarly, the PolicyControlsAccounting aggregation defines policies
to control the configuration of the AccountingRuleDetail association
class. This enables the entire accounting process to be managed by
ECAPolicyRules.
Note: a data model MAY choose to collapse this design into a more
efficient implementation. For example, a data model could define two
attributes for the AccountingECAPolicyRule class, called (for
example) accountingMethodCurrent and accountingMethodSupported, to
represent the HasAccountingMethod aggregation and its association
class. The former is a string attribute that defines the current
accounting method used by this AccountingECAPolicyRule, while the
latter defines a set of accounting methods, in the form of an
authorization capability, which this AccountingECAPolicyRule can
advertise.
A.4. TrafficInspectionECAPolicyRuleClass Definition
The purpose of a TrafficInspectionECAPolicyRule is to define an ECA
Policy Rule that, based on a given context, can determine which
traffic to examine on which devices, which information to collect
from those devices, and how to collect that information.
This class does NOT define the traffic inspection method(s) used.
This is because this would effectively "enclose" this information
within the TrafficInspectionECAPolicyRule. This has two drawbacks.
First, other entities that need to use information from the
TrafficInspection class(es) could not; they would have to associate
with the TrafficInspectionECAPolicyRule class, and those other
classes would not likely be interested in the
TrafficInspectionECAPolicyRule. Second, the evolution of new traffic
inspection methods should be independent of the
TrafficInspectionECAPolicyRule; this cannot happen if the
TrafficInspection class(es) are embedded in the
TrafficInspectionECAPolicyRule. Hence, this document recommends the
following design:
+------------------+
+-------------------+1..n 1..n| |
| |/ \ HasTrafficInspection \| Traffic |
| TrafficInspection + A ----------+-------------+ InspectionMethod |
| ECAPolicyRule |\ / ^ / | |
| | | +------------------+
+-------------------+ |
|
+------------+------------+
| TrafficInspectionDetail |
+------------+------------+
/ \ 0..n
|
| PolicyControlsTrafficInspection
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 13. Modeling Traffic Inspection Mechanisms
This document only defines the TrafficInspectionECAPolicyRule; all The geometric model defined in [Bas12] is summarized here. Note that
other classes, and the aggregations, are defined in an external our work has extended the work of [Bas12] to model ECA Policy Rules,
model. For completeness, descriptions of how the two aggregations instead of just condition-action Policy Rules. However, the
are used are below. geometric model in this Appendix is simplified in this version of
this I-D, and is used to define just the CA part of the ECA model.
Figure 13 defines an aggregation between the All the actions available to the security function are well known
TrafficInspectionECAPolicyRule and an external TrafficInspection and organized in an action set A.
class (which is likely a superclass for different types of traffic
inspection mechanisms). This decouples the implementation of traffic
inspection mechanisms from how traffic inspection mechanisms are
used.
Since different TrafficInspectionECAPolicyRules can use different For filtering controls, the enforceable actions are either Allow or
traffic inspection mechanisms in different ways, the aggregation is Deny, thus A={Allow,Deny}. For channel protection controls, they may
realized as an association class. This enables the attributes and be informally written as "enforce confidentiality", "enforce data
methods of the association class (i.e., TrafficInspectionDetail) to authentication and integrity", and "enforce confidentiality and data
be used to define how a given TrafficInspectionMethod is used by a authentication and integrity". However, these actions need to be
particular TrafficInspectionECAPolicyRule. instantiated to the technology used. For example, AH-transport mode
and ESP-transport mode (and combinations thereof) are a more precise
definition of channel protection actions.
Similarly, the PolicyControlsTrafficInspection aggregation defines Conditions are typed predicates concerning a given selector. A
policies to control the configuration of the TrafficInspectionDetail selector describes the values that a protocol field may take. For
association class. This enables the entire traffic inspection example, the IP source selector is the set of all possible IP
process to be managed by ECAPolicyRules. 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
source field in the IP header). Geometrically, a condition is the
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
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
equal to S1) and s2 <= S2 (s1 of or equal to S2), both s1 and s2
match the packet x1, while only s2 matches x2.
Note: a data model MAY choose to collapse this design into a more To consider conditions in different selectors, the decision space is
efficient implementation. For example, a data model could define two extended using the Cartesian product because distinct selectors
attributes for the TrafficInspectionECAPolicyRule class, called (for refer to different fields, possibly from different protocol headers.
example) trafficInspectionMethodCurrent and Hence, given a policy-enabled element that allows the definition of
trafficInspectionMethodSupported, to represent the conditions on the selectors S1, S2,..., Sm (where m is the number
HasTrafficInspectionMethod aggregation and its association class. of Selectors available at the security control we want to model),
The former is a string attribute that defines the current traffic its selection space is:
inspection method used by this TrafficInspectionECAPolicyRule, while
the latter defines a set of traffic inspection methods, in the form
of a traffic inspection capability, which this
TrafficInspectionECAPolicyRule can advertise.
A.5. ApplyProfileECAPolicyRuleClass Definition S=S1 X S2 X ... X Sm
The purpose of an ApplyProfileECAPolicyRule is to define an ECA To consider conditions in different selectors, the decision space is
Policy Rule that, based on a given context, can apply a particular extended using the Cartesian product because distinct selectors
profile to specific traffic. The profile defines the security refer to different fields, possibly from different protocol headers.
capabilities for content security control and/or attack mitigation
control; these will be described in sections 4.4 and 4.5,
respectively.
This class does NOT define the set of Profiles used. This is because S2 ^ Destination port
this would effectively "enclose" this information within the |
ApplyProfileECAPolicyRule. This has two drawbacks. First, other | x2
entities that need to use information from the Profile class(es) +......o
could not; they would have to associate with the | .
ApplyProfileECAPolicyRule class, and those other classes would not | .
likely be interested in the ApplyProfileECAPolicyRule. Second, the --+.............+------------------------------------+
evolution of new Profile classes should be independent of the | | . | |
ApplyProfileECAPolicyRule; this cannot happen if the Profile s | . | |
class(es) are embedded in the ApplyProfileECAPolicyRule. Hence, this e | . | (rectangle) |
document recommends the following design: g | . | condition clause (c) |
m | . | here the action a is applied |
e | . | |
n | . | x1=point=packet |
t +.............|.............o |
| | . | . |
--+.............+------------------------------------+
| . . . .
| . . . .
+------------+------+-------------+----------------------+------>
| |---- segment = condition in S1 -----| S1
+ IP source
+-------------+ Figure 17: Geometric representation of a rule r=(c,a) that
+-------------------+ 1..n 1..n | | matches x1, but does not match x2.
| |/ \ ProfileApplied \| |
| ApplyProfile + A -----------+-------------+ Profile |
| ECAPolicyRule |\ / ^ /| |
| | | +-------------+
+-------------------+ |
|
+------------+---------+
| ProfileAppliedDetail |
+------------+---------+
/ \ 0..n
|
|
PolicyControlsProfileApplication |
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 14. Modeling Profile ApplicationMechanisms Accordingly, the condition clause c is a subset of S:
This document only defines the ApplyProfileECAPolicyRule; all other c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S
classes, and the aggregations, are defined in an external model. For
completeness, descriptions of how the two aggregations are used are
below.
Figure 14 defines an aggregation between the S represents the totality of the packets that are individually
ApplyProfileECAPolicyRule and an external Profile class (which is selectable by the security control to model when we use it to
likely a superclass for different types of Profiles). This decouples enforce a policy. Unfortunately, not all its subsets are valid
the implementation of Profiles from how Profiles are used. condition clauses: only hyper-rectangles, or the union of
hyper-rectangles (as they are Cartesian product of conditions),
are valid. This is an intrinsic constraint of the policy
language, as it specifies rules by defining a condition for each
selector. Languages that allow specification of conditions as
relations over more fields are modeled by the geometric model as
more complex geometric shapes determined by the equations. However,
the algorithms to compute intersections are much more sophisticated
than intersection hyper-rectangles. Figure 17 graphically represents
a condition clause c in a two-dimensional selection space.
Since different ApplyProfileECAPolicyRules can use different In the geometric model, a rule is expressed as r=(c,a), where c <= S
Profiles in different ways, the aggregation is realized as an (the condition clause is a subset of the selection space), and the
association class. This enables the attributes and methods of the action a belongs to A. Rule condition clauses match a packet (rules
association class (i.e., ProfileAppliedDetail) to be used to define match a packet), if all the conditions forming the clauses match the
how a given Profileis used by a particular ApplyProfileECAPolicyRule. packet. In Figure 17, the rule with condition clause c matches the
packet x1 but not x2.
Similarly, the PolicyControlsProfileApplication aggregation defines The rule set R is composed of n rules ri=(ci,ai).
policies to control the configuration of the ProfileAppliedDetail
association class. This enables the application of Profiles to be
managed by ECAPolicyRules.
Note: a data model MAY choose to collapse this design into a more The decision criteria for the action to apply when a packet matches
efficient implementation. For example, a data model could define two two or more rules is abstracted by means of the resolution strategy
attributes for the ApplyProfileECAPolicyRuleclass, called (for
example) profileAppliedCurrent and profileAppliedSupported, to
represent the ProfileApplied aggregation and its association class.
The former is a string attribute that defines the current Profile
used by this ApplyProfileECAPolicyRule, while the latter defines a
set of Profiles, in the form of a Profile capability, which this
ApplyProfileECAPolicyRule can advertise.
A.6. ApplySignatureECAPolicyRuleClass Definition RS: Pow(R) -> A
The purpose of an ApplySignatureECAPolicyRule is to define an ECA where Pow(R) is the power set of rules in R.
Policy Rule that, based on a given context, can determine which
Signature object (e.g., an anti-virus file, or aURL filtering file,
or a script) to apply to which traffic. The Signature object defines
the security capabilities for content security control and/or attack
mitigation control; these will be described in sections 4.4 and 4.5,
respectively.
This class does NOT define the set of Signature objects used. This Formally, given a set of rules, the resolution strategy maps all the
is because this would effectively "enclose" this information within possible subsets of rules to an action a in A. When no rule matches a
the ApplySignatureECAPolicyRule. This has two drawbacks. First, packet, the security controls may select the default action d in A,
other entities that need to use information from the Signature if they support one.
object class(es) could not; they would have to associate with the
ApplySignatureECAPolicyRule class, and those other classes would not
likely be interested in the ApplySignatureECAPolicyRule. Second, the
evolution of new Signature object classes should be independent of
the ApplySignatureECAPolicyRule; this cannot happen if the Signature
object class(es) are embedded in the ApplySignatureECAPolicyRule.
Hence, this document recommends the following design:
+-------------+ Resolution strategies may use, besides intrinsic rule data (i.e.,
+---------------+ 1..n 1..n | | condition clause and action clause), also external data associated to
| |/ \ SignatureApplied \| | each rule, such as priority, identity of the creator, and creation
| ApplySignature+ A ----------+--------------+ Signature | time. Formally, every rule ri is associated by means of the
| ECAPolicyRule |\ / ^ /| | function e(.):
| | | +-------------+
+---------------+ |
|
+------------+-----------+
| SignatureAppliedDetail |
+------------+-----------+
/ \ 0..n
|
| PolicyControlsSignatureApplication
|
/ \
A
\ / 0..n
+----------+--------------+
| ManagementECAPolicyRule |
+-------------------------+
Figure 15. Modeling Sginature Application Mechanisms e(ri) = (ri,f1(ri),f2(ri),...)
This document only defines the ApplySignatureECAPolicyRule; all where E={fj:R -> Xj} (j=1,2,...) is the set that includes all
other classes, and the aggregations, are defined in an external functions that map rules to external attributes in Xj. However,
model. For completeness, descriptions of how the two aggregations E, e, and all the Xj are determined by the resolution strategy used.
are used are below.
Figure 15 defines an aggregation between the A policy is thus a function p: S -> A that connects each point of
ApplySignatureECAPolicyRule and an external Signature object class the selection space to an action taken from the action set A
(which is likely a superclass for different types of Signature according to the rules in R. By also assuming RS(0)=d (where 0 is
objects). This decouples the implementation of signature objects the empty-set) and RS(ri)=ai, the policy p can be described as:
from how Signature objects are used.
Since different ApplySignatureECAPolicyRules can use different p(x)=RS(match{R(x)}).
Signature objects in different ways, the aggregation is realized as
an association class. This enables the attributes and methods of the
association class (i.e., SignatureAppliedDetail) to be used to
define how a given Signature object is used by a particular
ApplySignatureECAPolicyRule.
Similarly, the PolicyControlsSignatureApplication aggregation Therefore, in the geometric model, a policy is completely defined by
defines policies to control the configuration of the the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS,
SignatureAppliedDetail association class. This enables the the set E of mappings to the external attributes, and the default
application of the Signature object to be managed by policy. action d.
Note: a data model MAY choose to collapse this design into a more Note that, the geometric model also supports ECA paradigms by simply
efficient implementation. For example, a data model could define two modeling events like an additional selector.
attributes for the ApplySignatureECAPolicyRule class, called (for
example) signature signatureAppliedCurrent and
signatureAppliedSupported, to represent the SignatureApplied
aggregation and its association class. The former is a string
attribute that defines the current Signature object used by this
ApplySignatureECAPolicyRule, while the latter defines a set of
Signature objects, in the form of a Signature capability, which this
ApplySignatureECAPolicyRule can advertise.
Authors' Addresses Authors' Addresses
Liang Xia (Frank)
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: Frank.xialiang@huawei.com
Liang Xia (Frank) John Strassner
Huawei Huawei
Email: John.sc.Strassner@huawei.com
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: Frank.xialiang@huawei.com
John Strassner
Huawei
Email: John.sc.Strassner@huawei.com
DaCheng Zhang
Huawei
Email: dacheng.zhang@huawei.com
Kepeng Li
Alibaba
Email: kepeng.lkp@alibaba-inc.com
Cataldo Basile, Antonio Lioy
Politecnico di Torino
Corso Duca degli Abruzzi, 34
Torino, 10129
Italy
Email: cataldo.basile@polito.it
Antonio Lioy
Politecnico di Torino
Corso Duca degli Abruzzi, 34
Torino, 10129
Italy
Email: lioy@polito.it
Diego R. Lopez
Telefonica I+D
Zurbaran, 12
Madrid, 28010
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Edward Lopez
Fortinet
899 Kifer Road
Sunnyvale, CA 94086
Phone: +1 703 220 0988
EMail: elopez@fortinet.com
Nicolas BOUTHORS
Qosmos
Email: Nicolas.BOUTHORS@qosmos.com Cataldo Basile
Politecnico di Torino
Corso Duca degli Abruzzi, 34
Torino, 10129
Italy
Email: cataldo.basile@polito.it
Luyuan Fang Diego R. Lopez
Microsoft Telefonica I+D
15590 NE 31st St Zurbaran, 12
Redmond, WA 98052 Madrid, 28010
Email: lufang@microsoft.com Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
 End of changes. 270 change blocks. 
1961 lines changed or deleted 2038 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/