idnits 2.17.1 

draft-ietf-i2nsf-capability-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (Sep 29, 2017) is 2395 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-10) exists of
     draft-ietf-i2nsf-framework-06

  == Outdated reference: A later version (-08) exists of
     draft-ietf-i2nsf-terminology-03


     Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

1	I2NSF                                                             L. Xia
2	Internet-Draft                                              J. Strassner
3	Intended status: Standard Track                                   Huawei
4	Expires:  March 29, 2018                                      C. Basile
5	                                                                  PoliTO
6	                                                                D. Lopez
7	                                                                     TID
8	                                                            Sep 29, 2017

10	                 Information Model of NSFs Capabilities
11	                   draft-ietf-i2nsf-capability-00.txt

13	Abstract

15	   This document defines the concept of an NSF (Network Security
16	   Function) Capability, as well as its information model. Capabilities
17	   are a set of features that are available from a managed entity, and
18	   are represented as data that unambiguously characterizes an NSF.
19	   Capabilities enable management entities to determine the set offer
20	   features from available NSFs that will be used, and simplify the
21	   management of NSFs.

23	Status of this Memo

25	   This Internet-Draft is submitted in full conformance with the
26	   provisions of BCP 78 and BCP 79.

28	   Internet-Drafts are working documents of the Internet Engineering
29	   Task Force (IETF).  Note that other groups may also distribute
30	   working documents as Internet-Drafts.  The list of current
31	   Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

33	   Internet-Drafts are draft documents valid for a maximum of six
34	   months and may be updated, replaced, or obsoleted by other
35	   documents at any time.  It is inappropriate to use Internet-Drafts
36	   as reference material or to cite them other than as "work in
37	   progress."

39	   This Internet-Draft will expire on March 29, 2018.

41	Copyright Notice

43	   Copyright (c) 2017 IETF Trust and the persons identified as the
44	   document authors. All rights reserved.

46	   This document is subject to BCP 78 and the IETF Trust's Legal
47	   Provisions Relating to IETF Documents
48	   (http://trustee.ietf.org/license-info) in effect on the date of
49	   publication of this document. Please review these documents
50	   carefully, as they describe your rights and restrictions with
51	   respect to this document. Code Components extracted from this
52	   document must include Simplified BSD License text as described in
53	   Section 4.e of the Trust Legal Provisions and are provided
54	   without warranty as described in the Simplified BSD License.

56	Table of Contents

58	   1. Introduction ................................................... 4
59	   2. Conventions used in this document .............................. 5
60	      2.1. Acronyms .................................................. 5
61	   3. Capability Information Model Design ............................ 6
62	      3.1. Design Principles and ECA Policy Model Overview ........... 6
63	      3.2. Relation with the External Information Model .............. 8
64	      3.3. I2NSF Capability Information Model Theory of Operation ... 10
65	         3.3.1. I2NSF Condition Clause Operator Types ............... 11
66	         3.3.2  Capability Selection and Usage ...................... 12
67	         3.3.3.  Capability Algebra ................................. 13
68	      3.4. Initial NSFs Capability Categories ....................... 16
69	         3.4.1. Network Security Capabilities ....................... 16
70	         3.4.2. Content Security Capabilities ....................... 17
71	         3.4.3. Attack Mitigation Capabilities ...................... 17
72	   4. Information Sub-Model for Network Security Capabilities ....... 18
73	      4.1. Information Sub-Model for Network Security ............... 18
74	         4.1.1. Network Security Policy Rule Extensions ............. 19
75	         4.1.2. Network Security Policy Rule Operation .............. 20
76	         4.1.3. Network Security Event Sub-Model .................... 22
77	         4.1.4. Network Security Condition Sub-Model ................ 23
78	         4.1.5. Network Security Action Sub-Model ................... 25
79	      4.2. Information Model for I2NSF Capabilities ................. 26
80	      4.3. Information Model for Content Security Capabilities ...... 27
81	      4.4. Information Model for Attack Mitigation Capabilities ..... 28
82	   5. Security Considerations ....................................... 29
83	   6. IANA Considerations ........................................... 29
84	   7. Contributors .................................................. 29
85	   8. References .................................................... 29
86	      8.1. Normative References ..................................... 29
87	      8.2. Informative References ................................... 30
88	   Appendix A. Network Security Capability Policy Rule Definitions .. 32
89	      A.1. AuthenticationECAPolicyRule Class Definition ............. 32
90	      A.2. AuthorizationECAPolicyRuleClass Definition ............... 34
91	      A.3. AccountingECAPolicyRuleClass Definition .................. 35
92	      A.4. TrafficInspectionECAPolicyRuleClass Definition ........... 37
93	      A.5. ApplyProfileECAPolicyRuleClass Definition ................ 38
94	      A.6. ApplySignatureECAPolicyRuleClass Definition .............. 40
95	   Appendix B. Network Security Event Class Definitions ............. 42
96	      B.1. UserSecurityEvent Class Description ...................... 42
97	         B.1.1. The usrSecEventContent Attribute .................... 42
98	         B.1.2. The usrSecEventFormat Attribute ..................... 42
99	         B.1.3. The usrSecEventType Attribute ....................... 42
100	      B.2. DeviceSecurityEvent Class Description .................... 43
101	         B.2.1. The devSecEventContent Attribute .................... 43
102	         B.2.2. The devSecEventFormat Attribute ..................... 43
103	         B.2.3. The devSecEventType Attribute ....................... 44
104	         B.2.4. The devSecEventTypeInfo[0..n] Attribute ............. 44
105	         B.2.5. The devSecEventTypeSeverity Attribute ............... 44

107	Table of Contents (continued)

109	      B.3. SystemSecurityEvent Class Description .................... 44
110	         B.3.1. The sysSecEventContent Attribute .................... 45
111	         B.3.2. The sysSecEventFormat Attribute ..................... 45
112	         B.3.3. The sysSecEventType Attribute ....................... 45
113	      B.4. TimeSecurityEvent Class Description ...................... 45
114	         B.4.1. The timeSecEventPeriodBegin Attribute ............... 46
115	         B.4.2. The timeSecEventPeriodEnd Attribute ................. 46
116	         B.4.3. The timeSecEventTimeZone Attribute .................. 46
117	   Appendix C. Network Security Condition Class Definitions ......... 47
118	      C.1. PacketSecurityCondition .................................. 47
119	         C.1.1. PacketSecurityMACCondition .......................... 47
120	            C.1.1.1. The pktSecCondMACDest Attribute ................ 47
121	            C.1.1.2. The pktSecCondMACSrc Attribute ................. 47
122	            C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48
123	            C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48
124	            C.1.1.5. The pktSecCondMACTCI Attribute ................. 48
125	         C.1.2. PacketSecurityIPv4Condition ......................... 48
126	            C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48
127	            C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48
128	            C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48
129	            C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48
130	            C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48
131	            C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49
132	            C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49
133	         C.1.3. PacketSecurityIPv6Condition ......................... 49
134	            C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49
135	            C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49
136	            C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49
137	            C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49
138	            C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49
139	            C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49
140	            C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50
141	            C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50
142	         C.1.4. PacketSecurityTCPCondition .......................... 50
143	            C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50
144	            C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50
145	            C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50
146	            C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50
147	            C.1.5. PacketSecurityUDPCondition ....................... 50
148	               C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50
149	               C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51
150	               C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51
151	      C.2. PacketPayloadSecurityCondition ........................... 51
152	      C.3. TargetSecurityCondition .................................. 51
153	      C.4. UserSecurityCondition .................................... 51
154	      C.5. SecurityContextCondition ................................. 52
155	      C.6. GenericContextSecurityCondition .......................... 52

157	Table of Contents (continued)

159	  Appendix D. Network Security Action Class Definitions ............. 53
160	      D.1. IngressAction ............................................ 53
161	      D.2. EgressAction ............................................. 53
162	      D.3. ApplyProfileAction ....................................... 53
163	   Appendix E. Geometric Model ...................................... 54
164	   Authors' Addresses ............................................... 57

166	1.  Introduction

168	   The rapid development of virtualized systems requires advanced
169	   security protection in various scenarios. Examples include network
170	   devices in an enterprise network, User Equipment in a mobile network,
171	   devices in the Internet of Things, or residential access users
172	   [I-D.draft-ietf-i2nsf-problem-and-use-cases].

174	   NSFs produced by multiple security vendors provide various security
175	   Capabilities to customers. Multiple NSFs can be combined together to
176	   provide security services over the given network traffic, regardless
177	   of whether the NSFs are implemented as physical or virtual functions.

179	   Security Capabilities describe the set of network security-related
180	   features that are available to use for security policy enforcement
181	   purposes. Security Capabilities are independent of the actual
182	   security control mechanisms that will implement them. Every NSF
183	   registers the set of Capabilities it offers. Security Capabilities
184	   are a market enabler, providing a way to define customized security
185	   protection by unambiguously describing the security features offered
186	   by a given NSF. Moreover, Security Capabilities enable security
187	   functionality to be described in a vendor-neutral manner. That is,
188	   it is not required to refer to a specific product when designing the
189	   network; rather, the functionality characterized by their
190	   Capabilities are considered.

192	   According to [I-D.draft-ietf-i2nsf-framework], there are two types
193	   of I2NSF interfaces available for security policy provisioning:

195	      o Interface between I2NSF users and applications, and a security
196	        controller (Consumer-Facing Interface): this is a service-
197	        oriented interface that provides a communication channel
198	        between consumers of NSF data and services and the network
199	        operator's security controller. This enables security
200	        information to be exchanged between various applications (e.g.,
201	        OpenStack, or various BSS/OSS components) and the security
202	        controller. The design goal of the Consumer-Facing Interface
203	        is to decouple the specification of security services from
204	        their implementation.

206	      o Interface between NSFs (e.g., firewall, intrusion prevention,
207	        or anti-virus) and the security controller (NSF-Facing
208	        Interface): The NSF-Facing Interface is used to decouple the
209	        security management scheme from the set of NSFs and their
210	        various implementations for this scheme, and is independent
211	        of how the NSFs are implemented (e.g., run in Virtual
212	        Machines or physical appliances). This document defines an
213	        object-oriented information model for network security, content
214	        security, and attack mitigation Capabilities, along with
215	        associated I2NSF Policy objects.

217	   This document is organized as follows. Section 2 defines conventions
218	   and acronyms used. Section 3 discusses the design principles for the
219	   I2NSF Capability information model and related policy model objects.
220	   Section 4 defines the structure of the information model, which
221	   describes the policy and capability objects design; details of the
222	   model elements are contained in the appendices.

224	2.  Conventions used in this document

226	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
227	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
228	   document are to be interpreted as described in RFC-2119 [RFC2119].

230	   This document uses terminology defined in
231	   [I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF
232	   scoped terminology.

234	2.1.  Acronyms

236	   AAA:     Access control, Authorization, Authentication
237	   ACL:     Access Control List
238	   (D)DoD:  (Distributed) Denial of Service (attack)
239	   ECA:     Event-Condition-Action
240	   FMR:     First Matching Rule (resolution strategy)
241	   FW:      Firewall
242	   GNSF:    Generic Network Security Function
243	   HTTP:    HyperText Transfer Protocol
244	   I2NSF:   Interface to Network Security Functions
245	   IPS:     Intrusion Prevention System
246	   LMR:     Last Matching Rule (resolution strategy)
247	   MIME:    Multipurpose Internet Mail Extensions
248	   NAT:     Network Address Translation
249	   NSF:     Network Security Function
250	   RPC:     Remote Procedure Call
251	   SMA:     String Matching Algorithm
252	   URL:     Uniform Resource Locator
253	   VPN:     Virtual Private Network

255	3.  Information Model Design

257	   The starting point of the design of the Capability information model
258	   is the categorization of types of security functions.  For instance,
259	   experts agree on what is meant by the terms "IPS", "Anti-Virus", and
260	   "VPN concentrator".  Network security experts unequivocally refer to
261	   "packet filters" as stateless devices able to allow or deny packet
262	   forwarding based on various conditions (e.g., source and destination
263	   IP addresses, source and destination ports, and IP protocol type
264	   fields) [Alshaer].

266	   However, more information is required in case of other devices, like
267	   stateful firewalls or application layer filters.  These devices
268	   filter packets or communications, but there are differences in the
269	   packets and communications that they can categorize and the states
270	   they maintain. Analogous considerations can be applied for channel
271	   protection protocols, where we all understand that they will protect
272	   packets by means of symmetric algorithms whose keys could have been
273	   negotiated with asymmetric cryptography, but they may work at
274	   different layers and support different algorithms and protocols. To
275	   ensure protection, these protocols apply integrity, optionally
276	   confidentiality, anti-reply protections, and authenticate peers.

278	3.1.  Capability Information Model Overview

280	   This document defines a model of security Capabilities that provides
281	   the foundation for automatic management of NSFs. This includes
282	   enabling the security controller to properly identify and manage
283	   NSFs, and allow NSFs to properly declare their functionality, so
284	   that they can be used in the correct way.

286	   Some basic design principles for security Capabilities and the
287	   systems that have to manage them are:

289	   o Independence: each security Capability should be an independent
290	      function, with minimum overlap or dependency on other
291	      Capabilities. This enables each security Capability to be
292	      utilized and assembled together freely. More importantly,
293	      changes to one Capability will not affect other Capabilities.
294	      This follows the Single Responsibility Principle
295	      [Martin] [OODSRP].
296	   o Abstraction: each Capability should be defined in a vendor-
297	      independent manner, and associated to a well-known interface
298	      to provide a standardized ability to describe and report its
299	      processing results. This facilitates multi-vendor
300	      interoperability.
301	   o Automation: the system must have the ability to auto-discover,
302	      auto-negotiate, and auto-update its security Capabilities
303	      (i.e., without human intervention). These features are
304	      especially useful for the management of a large number of
305	      NSFs. They are essential to add smart services (e.g., analysis,
306	      refinement, Capability reasoning, and optimization) for the
307	      security scheme employed. These features are supported by many
308	      design patterns, including the Observer Pattern [OODOP], the
309	      Mediator Pattern [OODMP], and a set of Message Exchange
310	      Patterns [Hohpe].
311	    o Scalability: the management system must have the Capability to
312	      scale up/down or scale in/out. Thus, it can meet various
313	      performancerequirements derived from changeable network traffic
314	      or service requests. In addition, security Capabilities that are
315	      affected by scalability changes must support reporting statistics
316	      to the security controller to assist its decision on whether it
317	      needs to invoke scaling or not. However, this requirement is for
318	      information only, and is beyond the scope of this document.

320	   Based on the above principles, a set of abstract and vendor-neutral
321	   Capabilities with standard interfaces is defined. This provides a
322	   Capability model that enables a set of NSFs that are required at a
323	   given time to be selected, as well as the unambiguous definition of
324	   the security offered by the set of NSFs used. The security
325	   controller can compare the requirements of users and applications to
326	   the set of Capabilities that are currently available in order to
327	   choose which NSFs are needed to meet those requirements. Note that
328	   this choice is independent of vendor, and instead relies specifically
329	   on the Capabilities (i.e., the description) of the functions
330	   provided. The security controller may also be able to customize the
331	   functionality of selected NSFs.

333	   Furthermore, when an unknown threat (e.g., zero-day exploits and
334	   unknown malware) is reported by a NSF, new Capabilities may be
335	   created, and/or existing Capabilities may be updated (e.g., by
336	   updating its signature and algorithm). This results in enhancing
337	   existing NSFs (and/or creating new NSFs) to address the new threats.
338	   New Capabilities may be sent to and stored in a centralized
339	   repository, or stored separately in a vendor's local repository.
340	   In either case, a standard interface facilitates the update process.

342	   Note that most systems cannot dynamically create a new Capability
343	   without human interaction. This is an area for further study.

345	3.2.  ECA Policy Model Overview

347	   The "Event-Condition-Action" (ECA) policy model is used as the basis
348	   for the design of I2NSF Policy Rules; definitions of all I2NSF
349	   policy-related terms are also defined in
350	   [I-D.draft-ietf-i2nsf-terminology]:

352	      o Event: An Event is any important occurrence in time of a change
353	        in the system being managed, and/or in the environment of the
354	        system being managed. When used in the context of I2NSF
355	        Policy Rules, it is used to determine whether the Condition
356	        clause of the I2NSF Policy Rule can be evaluated or not.

358	        Examples of an I2NSF Event include time and user actions (e.g.,
359	        logon, logoff, and actions that violate an ACL).
360	      o Condition: A condition is defined as a set of attributes,
361	        features, and/or values that are to be compared with a set of
362	        known attributes, features, and/or values in order to determine
363	        whether or not the set of Actions in that (imperative) I2NSF
364	        Policy Rule can be executed or not. Examples of I2NSF Conditions
365	        include matching attributes of a packet or flow, and comparing
366	        the internal state of an NSF to a desired state.
367	      o Action: An action is used to control and monitor aspects of
368	        flow-based NSFs when the event and condition clauses are
369	        satisfied. NSFs provide security functions by executing various
370	        Actions. Examples of I2NSF Actions include providing intrusion
371	        detection and/or protection, web and flow filtering, and deep
372	        packet inspection for packets and flows.

374	   An I2NSF Policy Rule is made up of three Boolean clauses: an Event
375	   clause, a Condition clause, and an Action clause. A Boolean clause
376	   is a logical statement that evaluates to either TRUE or FALSE. It
377	   may be made up of one or more terms; if more than one term, then a
378	   Boolean clause connects the terms using logical connectives (i.e.,
379	   AND, OR, and NOT). It has the following semantics:

381	         IF <event-clause> is TRUE
382	            IF <condition-clause> is TRUE
383	               THEN execute <action-clause>
384	            END-IF
385	         END-IF

387	   Technically, the "Policy Rule" is really a container that aggregates
388	   the above three clauses, as well as metadata.

390	   The above ECA policy model is very general and easily extensible,
391	   and can avoid potential constraints that could limit the
392	   implementation of generic security Capabilities.

394	3.3.  Relation with the External Information Model

396	   Note: the symbology used from this point forward is taken from
397	   section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model].

399	   The I2NSF NSF-Facing Interface is in charge of selecting and
400	   managing the NSFs using their Capabilities. This is done using
401	   the following approach:

403	      1) Each NSF registers its Capabilities with the management system
404	         when it "joins", and hence makes its Capabilities available to
405	         the management system;
406	      2) The security controller selects the set of Capabilities
407	         required to meet the needs of the security service from all
408	         available NSFs that it manages;

410	      3) The security controller uses the Capability information model
411	         to match chosen Capabilities to NSFs, independent of vendor;
412	      4) The security controller takes the above information and
413	         creates or uses one or more data models from the Capability
414	         information model to manage the NSFs;
415	      5) Control and monitoring can then begin.

417	   This assumes that an external information model is used to define
418	   the concept of an ECA Policy Rule and its components (e.g., Event,
419	   Condition, and Action objects). This enables I2NSF Policy Rules
420	   [I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external
421	   information model.

423	   Capabilities are defined as classes (e.g., a set of objects that
424	   exhibit a common set of characteristics and behavior
425	   [I-D.draft-ietf-supa-generic-policy-info-model].

427	   Each Capability is made up of at least one model element (e.g.,
428	   attribute, method, or relationship) that differentiates it from all
429	   other objects in the system. Capabilities are, generically, a type
430	   of metadata (i.e., information that describes, and/or prescribes,
431	   the behavior of objects); hence, it is also assumed that an external
432	   information model is used to define metadata (preferably, in the
433	   form of a class hierarchy). Therefore, it is assumed that
434	   Capabilities are subclassed from an external metadata model.

436	   The Capability sub-model is used for advertising, creating,
437	   selecting, and managing a set of specific security Capabilities
438	   independent of the type and vendor of device that contains the NSF.
439	   That is, the user of the NSF-Facing Interface does not care whether
440	   the NSF is virtualized or hosted in a physical device, who the
441	   vendor of the NSF is, and which set of entities the NSF is
442	   communicating with (e.g., a firewall or an IPS). Instead, the user
443	   only cares about the set of Capabilities that the NSF has, such as
444	   packet filtering or deep packet inspection. The overall structure
445	   is illustrated in the figure below:

447	   +-------------------------+ 0..n         0..n +---------------+
448	   |                         |/ \               \|   External    |
449	   | External ECA Info Model + A ----------------+   Metadata    |
450	   |                         |\ /  Aggregates   /|  Info Model   |
451	   +-----------+------------+      Metadata      +-------+-------+
452	               |                                        / \
453	               |                                         |
454	              / \                                        |
455	   Subclasses derived for I2NSF                    +-----+------+
456	        Security Policies                          | Capability |
457	                                                   | Sub-Model  |
458	                                                   +------------+

460	          Figure 1. The Overall I2NSF Information Model Design

462	   This draft defines a set of extensions to a generic, external, ECA
463	   Policy Model to represent various NSF ECA Security Policy Rules. It
464	   also defines the Capability Sub-Model; this enables ECA Policy
465	   Rules to control which Capabilities are seen by which actors, and
466	   used by the I2NSF system. Finally, it places requirements on what
467	   type of extensions are required to the generic, external, ECA
468	   information model and metadata models, in order to manage the
469	   lifecycle of I2NSF Capabilities.

471	   Both of the external models shown in Figure 1 could, but do not have
472	   to, be based on the SUPA information model
473	   [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in
474	   the Capability Sub-Model will inherit the AggregatesMetadata
475	   aggregation from the External Metadata Information Model.

477	   The external ECA Information Model supplies at least a set of classes
478	   that represent a generic ECA Policy Rule, and a set of classes that
479	   represent Events, Conditions, and Actions that can be aggregated by
480	   the generic ECA Policy Rule. This enables I2NSF to reuse this
481	   generic model for different purposes, as well as refine it (i.e.,
482	   create new subclasses, or add attributes and relationships) to
483	   represent I2NSF-specific concepts.

485	   It is assumed that the external ECA Information Model has the
486	   ability to aggregate metadata. Capabilities are then sub-classed
487	   from an appropriate class in the external Metadata Information Model;
488	   this enables the ECA objects to use the existing aggregation between
489	   them and Metadata to add Metadata to appropriate ECA objects.

491	   Detailed descriptions of each portion of the information model are
492	   given in the following sections.

494	3.4.  I2NSF Capability Information Model: Theory of Operation

496	   Capabilities are typically used to represent NSF functions that can
497	   be invoked. Capabilities are objects, and hence, can be used in the
498	   event, condition, and/or action clauses of an I2NSF ECA Policy Rule.
499	   The I2NSF Capability information model refines a predefined metadata
500	   model; the application of I2NSF Capabilities is done by refining a
501	   predefined ECA Policy Rule information model that defines how to
502	   use, manage, or otherwise manipulate a set of Capabilities. In this
503	   approach, an I2NSF Policy Rule is a container that is made up of
504	   three clauses: an event clause, a condition clause, and an action
505	   clause. When the I2NSF policy engine receives a set of events, it
506	   matches those events to events in active ECA Policy Rules. If the
507	   event matches, then this triggers the evaluation of the condition
508	   clause of the matched I2NSF Policy Rule. The condition clause is
509	   then evaluated; if it matches, then the set of actions in the
510	   matched I2NSF Policy Rule MAY be executed.

512	   This document defines additional important extensions to both the
513	   external ECA Policy Rule model and the external Metadata model that
514	   are used by the I2NSF Information Model; examples include
515	   resolution strategy, external data, and default action. All these
516	   extensions come from the geometric model defined in [Bas12]. A more
517	   detailed description is provided in Appendix E; a summary of the
518	   important points follows.

520	   Formally, given a set of actions in an I2NSF Policy Rule, the
521	   resolution strategy maps all the possible subsets of actions to an
522	   outcome. In other words, the resolution strategy is included in the
523	   I2NSF Policy Rule to decide how to evaluate all the actions in a
524	   particular I2NSF Policy Rule. This is then extended to include all
525	   possible I2NSF Policy Rules that can be applied in a particular
526	   scenario. Hence, the final action set from all I2NSF Policy Rules
527	   is deduced.

529	   Some concrete examples of resolution strategy are the First Matching
530	   Rule (FMR) or Last Matching Rule (LMR) resolution strategies. When
531	   no rule matches a packet, the NSFs may select a default action, if
532	   they support one.

534	   Resolution strategies may use, besides intrinsic rule data (i.e.,
535	   event, condition, and action clauses), "external data" associated to
536	   each rule, such as priority, identity of the creator, and creation
537	   time. Two examples of this are attaching metadata to the policy
538	   action and/or policy rule, and associating the policy rule with
539	   another class to convey such information.

541	3.4.1.  I2NSF Condition Clause Operator Types

543	   After having analyzed the literature and some existing NSFs, the
544	   types of selectors are categorized as exact-match, range-based,
545	   regex-based, and custom-match [Bas15][Lunt].

547	   Exact-match selectors are (unstructured) sets: elements can only be
548	   checked for equality, as no order is defined on them. As an example,
549	   the protocol type field of the IP header is an unordered set of
550	   integer values associated to protocols. The assigned protocol
551	   numbers are maintained by the IANA (http://www.iana.org/assignments/
552	   protocol-numbers/protocol-numbers.xhtml).

554	   In this selector, it is only meaningful to specify condition clauses
555	   that use either the "equals" or "not equals" operators:

557	      proto = tcp, udp       (protocol type field equals to TCP or UDP)
558	      proto != tcp           (protocol type field different from TCP)

560	   No other operators are allowed on exact-match selectors. For example,
561	   the following is an invalid condition clause, even if protocol types
562	   map to integers:

564	      proto < 62             (invalid condition)

566	   Range-based selectors are ordered sets where it is possible to
567	   naturally specify ranges as they can be easily mapped to integers.
568	   As an example, the ports in the TCP protocol may be represented with
569	   a range-based selector (e.g., 1024-65535). As another example, the
570	   following are examples of valid condition clauses:

572	      source_port = 80
573	      source_port < 1024
574	      source_port < 30000 && source_port >= 1024

576	   We include, in range-based selectors, the category of selectors that
577	   have been defined by Al-Shaer et al. as "prefix-match" [Alshaer].
578	   These selectors allow the specification of ranges of values by means
579	   of simple regular expressions. The typical case is the IP address
580	   selector (e.g., 10.10.1.*).

582	   There is no need to distinguish between prefix match and range-based
583	   selectors; for example, the address range "10.10.1.*" maps to
584	   "[10.10.1.0,10.10.1.255]".

586	   Another category of selector types includes those based on regular
587	   expressions. This selector type is used frequently at the application
588	   layer, where data are often represented as strings of text. The
589	   regex-based selector type also includes string-based selectors, where
590	   matching is evaluated using string matching algorithms (SMA)
591	   [Cormen]. Indeed, for our purposes, string matching can be mapped to
592	   regular expressions, even if in practice SMA are much faster. For
593	   instance, Squid (http://www.squid-cache.org/), a popular Web caching
594	   proxy that offers various access control Capabilities, allows the
595	   definition of conditions on URLs that can be evaluated with SMA
596	   (e.g., dstdomain) or regex matching (e.g., dstdom_regex).

598	   As an example, the condition clause:

600	      "URL = *.website.*"

602	   matches all the URLs that contain a subdomain named website and the
603	   ones whose path contain the string ".website.". As another example,
604	   the condition clause:

606	      "MIME_type = video/*"

608	   matches all MIME objects whose type is video.

610	   Finally, the idea of a custom check selector is introduced. For
611	   instance, malware analysis can look for specific patterns, and
612	   returns a Boolean value if the pattern is found or not.

614	   In order to be properly used by high-level policy-based processing
615	   systems (such as reasoning systems and policy translation systems),
616	   these custom check selectors can be modeled as black-boxes (i.e., a
617	   function that has a defined set of inputs and outputs for a
618	   particular state), which provide an associated Boolean output.

620	   More examples of custom check selectors will be presented in the
621	   next versions of the draft. Some examples are already present in
622	   Section 6.

624	3.4.2.  Capability Selection and Usage

626	   Capability selection and usage are based on the set of security
627	   traffic classification and action features that an NSF provides;
628	   these are defined by the Capability model. If the NSF has the
629	   classification features needed to identify the packets/flows
630	   required by a policy, and can enforce the needed actions, then
631	   that particular NSF is capable of enforcing the policy.

633	   NSFs may also have specific characteristics that automatic processes
634	   or administrators need to know when they have to generate
635	   configurations, like the available resolution strategies and the
636	   possibility to set default actions.

638	   The Capability information model can be used for two purposes:
639	   describing the features provided by generic security functions, and
640	   describing the features provided by specific products. The term
641	   Generic Network Security Function (GNSF) refers to the classes of
642	   security functions that are known by a particular system. The idea
643	   is to have generic components whose behavior is well understood, so
644	   that the generic component can be used even if it has some vendor-
645	   specific functions. These generic functions represent a point of
646	   interoperability, and can be provided by any product that offers the
647	   required Capabilities. GNSF examples include packet filter, URL
648	   filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content
649	   filter, monitoring, and anonymity proxy; these will be described
650	   later in a revision of this draft as well as in an upcoming data
651	   model contribution.

653	   The next section will introduce the algebra to define the
654	   information model of Capability registration. This associates
655	   NSFs to Capabilities, and checks whether a NSF has the
656	   Capabilities needed to enforce policies.

658	3.4.3.  Capability Algebra

660	   We introduce a Capability Algebra to ensure that the actions of
661	   different policy rules do not conflict with each other.

663	   Formally, two I2NSF Policy Actions conflict with each other if:

665	      o the event clauses of each evaluate to TRUE
666	      o the condition clauses of each evaluate to TRUE
667	      o the action clauses affect the same object in different ways

669	   For example, if we have two Policies:

671	      P1: During 8am-6pm, if traffic is external, then run through FW
672	      P2: During 7am-8pm, conduct anti-malware investigation

674	   There is no conflict between P1 and P2, since the actions are
675	   different. However, consider these two policies:

677	      P3: During 8am-6pm, John gets GoldService
678	      P4: During 10am-4pm, FTP from all users gets BronzeService

680	   P3 and P4 are now in conflict, because between the hours of 10am and
681	   4pm, the actions of P3 and P4 are different and apply to the same
682	   user (i.e., John).

684	   Let us define the concept of a "matched" policy rule as one in which
685	   its event and condition clauses both evaluate to true. This enables
686	   the actions in this policy rule to be evaluated. Then, the
687	   conflict matrix is defined by a 5-tuple {Ac, Cc, Ec, RSc, Dc},
688	   where:

690	      o Ac is the set of Actions currently available from the NSF;
691	      o Cc is the set of Conditions currently available from the NSF;
692	      o Ec is the set of Events the NSF is able to respond to.
693	        Therefore, the event clause of an I2NSF ECA Policy Rule that is
694	        written for an NSF will only allow a set of designated events
695	        in Ec. For compatibility purposes, we will assume that if Ec={}
696	        (that is, Ec is empty), the NSF only accepts CA policies.
697	      o RSc is the set of Resolution Strategies that can be used to
698	        specify how to resolve conflicts that occur between the actions
699	        of the same or different policy rules that are matched and
700	        contained in this particular NSF;
701	      o Dc defines the notion of a Default action that can be used to
702	        specify a predefined action when no other alternative action
703	        was matched by the currently executing I2NSF Policy Rule. An
704	        analogy is the use of a default statement in a C switch
705	        statement. This field of the Capability algebra can take the
706	        following values:
707	           - An explicit action (that has been predefined; typically,
708	             this means that it is fixed and not configurable), denoted
709	             as Dc ={a}. In this case, the NSF will always use the
710	             action as as the default action.
711	           - A set of explicit actions, denoted Dc={a1,a2, ...};
712	             typically, this means that any **one** action can be used
713	             as the default action. This enables the policy writer to
714	             choose one of a predefined set of actions {a1, a2, ...} to
715	             serve as the default action.

717	           - A fully configurable default action, denoted as Dc={F}.
718	             Here, F is a dummy symbol (i.e., a placeholder value) that
719	             can be used to indicate that the default action can be
720	             freely selected by the policy editor from the actions Ac
721	             available at the NSF. In other words, one of the actions
722	             Ac may be selected by the policy writer to act as the
723	             default action.
724	           - No default action, denoted as Dc={}, for cases where the
725	             NSF does not allow the explicit selection of a default
726	             action.

728	*** Note to WG: please review the following paragraphs
729	*
730	*  Interesting Capability concepts that could be considered for a next
731	*  version of the Capability model and algebra include:
732	*
733	*     o Event clause representation (e.g., conjunctive vs. disjunctive
734	*       normal form for Boolean clauses)
735	*     o Event clause evaluation function, which would enable more
736	*       complex expressions than simple Boolean expressions to be used
737	*
738	*
739	*     o Condition clause representation (e.g., conjunctive vs.
740	*       disjunctive normal form for Boolean clauses)
741	*     o Condition clause evaluation function, which would enable more
742	*       complex expressions than simple Boolean expressions to be used
743	*     o Action clause evaluation strategies (e.g., execute first
744	*       action only, execute last action only, execute all actions,
745	*       execute all actions until an action fails)
746	*     o The use of metadata, which can be associated to both an I2NSF
747	*       Policy Rule as well as objects contained in the I2NSF Policy
748	*       Rule (e.g., an action), that describe the object and/or
749	*       prescribe behavior. Descriptive examples include adding
750	*       authorship information and defining a time period when an NSF
751	*       can be used to be defined; prescriptive examples include
752	*       defining rule priorities and/or ordering.
753	*
754	*  Given two sets of Capabilities, denoted as
755	*
756	*     cap1=(Ac1,Cc1,Ec1,RSc1,Dc1) and
757	*     cap2=(Ac2,Cc2,Ec2,RSc2,Dc2),
758	*
759	*  two set operations are defined for manipulating Capabilities:
760	*
761	*     o Capability addition:
762	*          cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1}
763	*     o Capability subtraction:
764	*          cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1}
765	*
766	*  In the above formulae, "U" is the set union operator and "\" is the
767	*  set difference operator.

769	*  The addition and subtraction of Capabilities are defined as the
770	*  addition (set union) and subtraction (set difference) of both the
771	*  Capabilities and their associated actions. Note that **only** the
772	*  leftmost (in this case, the first matched policy rule) Resolution
773	*  Strategy and Default Action are used.
774	*
775	*  Note: actions, events, and conditions are **symmetric**. This means
776	*  that when two matched policy rules are merged, the resultant actions
777	*  and Capabilities are defined as the union of each individual matched
778	*  policy rule. However, both resolution strategies and default actions
779	*  are **asymmetric** (meaning that in general, they can **not** be
780	*  combined, as one has to be chosen). In order to simplify this, we
781	*  have chosen that the **leftmost** resolution strategy and the
782	*  **leftmost** default action are chosen. This enables the developer
783	*  to view the leftmost matched rule as the "base" to which other
784	*  elements are added.
785	*
786	*  As an example, assume that a packet filter Capability, Cpf, is
787	*  defined. Further, assume that a second Capability, called Ctime,
788	*  exists, and that it defines time-based conditions. Suppose we need
789	*  to construct a new generic packet filter, Cpfgen, that adds
790	*  time-based conditions to Cpf.
791	*
792	*
793	*  Conceptually, this is simply the addition of the Cpf and Ctime
794	*  Capabilities, as follows:
795	*     Apf   =  {Allow, Deny}
796	*     Cpf   =  {IPsrc,IPdst,Psrc,Pdst,protType}
797	*     Epf   =  {}
798	*     RSpf  =  {FMR}
799	*     Dpf   =  {A1}
800	*
801	*     Atime =  {Allow, Deny, Log}
802	*     Ctime =  {timestart, timeend, datestart, datestop}
803	*     Etime =  {}
804	*     RStime = {LMR}
805	*     Dtime =  {A2}
806	*
807	*  Then, Cpfgen is defined as:
808	*     Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf, Dpf}
809	*            = {Allow, Deny, Log},
810	*              {{IPsrc, IPdst, Psrc, Pdst, protType} U
811	*               {timestart, timeend, datestart, datestop}},
812	*              {},
813	*              {FMR},
814	*              {A1}
815	*
816	*  In other words, Cpfgen provides three actions (Allow, Deny, Log),
817	*  filters traffic based on a 5-tuple that is logically ANDed with a
818	*  time period, and uses FMR; it provides A1 as a default action, and
819	*  it does not react to events.

821	*  Note: We are investigating, for a next revision of this draft, the
822	*  possibility to add further operations that do not follow the
823	*  symmetric vs. asymmetric properties presented in the previous note.
824	*  We are looking for use cases that may justify the complexity added
825	*  by the availability of more Capability manipulation operations.
826	*
827	*** End Note to WG

829	3.5.  Initial NSFs Capability Categories

831	   The following subsections define three common categories of
832	   Capabilities: network security, content security, and attack
833	   mitigation. Future versions of this document may expand both the
834	   number of categories as well as the types of Capabilities within a
835	   given category.

837	3.5.1.  Network Security Capabilities

839	   Network security is a category that describes the inspecting and
840	   processing of network traffic based on the use of pre-defined
841	   security policies.

843	   The inspecting portion may be thought of as a packet-processing
844	   engine that inspects packets traversing networks, either directly or
845	   in the context of flows with which the packet is associated. From
846	   the perspective of packet-processing, implementations differ in the
847	   depths of packet headers and/or payloads they can inspect, the
848	   various flow and context states they can maintain, and the actions
849	   that can be applied to the packets or flows.

851	3.5.2.  Content Security Capabilities

853	   Content security is another category of security Capabilities
854	   applied to the application layer. Through analyzing traffic contents
855	   carried in, for example, the application layer, content security
856	   Capabilities can be used to identify various security functions that
857	   are required. These include defending against intrusion, inspecting
858	   for viruses, filtering malicious URL or junk email, blocking illegal
859	   web access, or preventing malicious data retrieval.

861	   Generally, each type of threat in the content security category has
862	   a set of unique characteristics, and requires handling using a set
863	   of methods that are specific to that type of content. Thus, these
864	   Capabilities will be characterized by their own content-specific
865	   security functions.

867	3.5.3.  Attack Mitigation Capabilities

869	   This category of security Capabilities is used to detect and mitigate
870	   various types of network attacks. Today's common network attacks can
871	   be classified into the following sets:

873	      o DDoS attacks:
874	        - Network layer DDoS attacks: Examples include SYN flood, UDP
875	          flood, ICMP flood, IP fragment flood, IPv6 Routing header
876	          attack, and IPv6 duplicate address detection attack;
877	        - Application layer DDoS attacks: Examples include HTTP flood,
878	          https flood, cache-bypass HTTP floods, WordPress XML RPC
879	          floods, and ssl DDoS.
880	      o Single-packet attacks:
881	        - Scanning and sniffing attacks: IP sweep, port scanning, etc.
882	        - malformed packet attacks: Ping of Death, Teardrop, etc.
883	        - special packet attacks: Oversized ICMP, Tracert, IP timestamp
884	          option packets, etc.

886	   Each type of network attack has its own network behaviors and
887	   packet/flow characteristics. Therefore, each type of attack needs a
888	   special security function, which is advertised as a set of
889	   Capabilities, for detection and mitigation. The implementation and
890	   management of this category of security Capabilities of attack
891	   mitigation control is very similar to the content security control
892	   category. A standard interface, through which the security controller
893	   can choose and customize the given security Capabilities according to
894	   specific requirements, is essential.

896	4.  Information Sub-Model for Network Security Capabilities

898	   The purpose of the Capability Information Sub-Model is to define the
899	   concept of a Capability, and enable Capabilities to be aggregated to
900	   appropriate objects. The following sections present the Network
901	   Security, Content Security, and Attack Mitigation Capability
902	   sub-models.

904	4.1.  Information Sub-Model for Network Security

906	   The purpose of the Network Security Information Sub-Model is to
907	   define how network traffic is defined, and determine if one or more
908	   network security features need to be applied to the traffic or not.
909	   Its basic structure is shown in the following figure:

911	                                      +---------------------+
912	     +---------------+ 1..n      1..n |                     |
913	     |               |/ \            \| A Common Superclass |
914	     | ECAPolicyRule + A -------------+   for ECA Objects   |
915	     |               |\ /            /|                     |
916	     +-------+-------+                +---------+-----------+
917	            / \                                / \
918	             |                                  |
919	             |                                  |
920	  (subclasses to define Network         (subclasses of Event,
921	    Security ECA Policy Rules       Condition, and Action Objects
922	    extensibly, so that other           for Network Security
923	    Policy Rules can be added)              Policy Rules)

925	       Figure 2. Network Security Information Sub-Model Overview

927	   In the above figure, the ECAPolicyRule, along with the Event,
928	   Condition, and Action Objects, are defined in the external ECA
929	   Information Model. The Network Security Sub-Model extends all of
930	   these objects in order to define security-specific ECA Policy Rules,
931	   as well as extensions to the (generic) Event, Condition, and
932	   Action objects.

934	   An I2NSF Policy Rule is a special type of Policy Rule that is in
935	   event-condition-action (ECA) form. It consists of the Policy Rule,
936	   components of a Policy Rule (e.g., events, conditions, actions, and
937	   some extensions like resolution policy, default action and external
938	   data), and optionally, metadata. It can be applied to both uni- and
939	   bi-directional traffic across the NSF.

941	   Each rule is triggered by one or more events. If the set of events
942	   evaluates to true, then a set of conditions are evaluated and, if
943	   true, enable a set of actions to be executed. This takes the
944	   following conceptual form:

946	      IF <event-clause> is TRUE
947	         IF <condition-clause> is TRUE
948	            THEN execute <action-clause>
949	         END-IF
950	      END-IF

952	   In the above example, the Event, Condition, and Action portions of a
953	   Policy Rule are all **Boolean Clauses**. Hence, they can contain
954	   combinations of terms connected by the three logical connectives
955	   operators (i.e., AND, OR, NOT). An example is:

957	      ((SLA==GOLD) AND ((numPackets>burstRate) OR NOT(bwAvail<minBW)))

959	   Note that Metadata, such as Capabilities, can be aggregated by I2NSF
960	   ECA Policy Rules.

962	4.1.1.  Network Security Policy Rule Extensions

964	   Figure 3 shows an example of more detailed design of the ECA Policy
965	   Rule subclasses that are contained in the Network Security
966	   Information Sub-Model, which just illustrates how more specific
967	   Network Security Policies are inherited and extended from the
968	   SecurityECAPolicyRule class. Any new kinds of specific Network
969	   Security Policy can be created by following the same pattern of
970	   class design as below.

972	                            +---------------+
973	                            |    External   |
974	                            | ECAPolicyRule |
975	                            +-------+-------+
976	                                   / \
977	                                    |
978	                                    |
979	                       +------------+----------+
980	                       | SecurityECAPolicyRule |
981	                       +------------+----------+
982	                                    |
983	                                    |
984	          +----+-----+--------+-----+----+---------+---------+--- ...
985	          |          |        |          |         |         |
986	          |          |        |          |         |         |
987	   +------+-------+  |  +-----+-------+  |  +------+------+  |
988	   |Authentication|  |  |  Accounting |  |  |ApplyProfile |  |
989	   |ECAPolicyRule |  |  |ECAPolicyRule|  |  |ECAPolicyRule|  |
990	   +--------------+  |  +-------------+  |  +-------------+  |
991	                     |                   |                   |
992	              +------+------+     +------+------+     +--------------+
993	              |Authorization|     |   Traffic   |     |ApplySignature|
994	              |ECAPolicyRule|     | Inspection  |     |ECAPolicyRule |
995	              +-------------+     |ECAPolicyRule|     +--------------+
996	                                  +-------------+

998	   Figure 3. Network Security Info Sub-Model ECAPolicyRule Extensions

1000	   The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule
1001	   hierarchy. It inherits from the (external) generic ECA Policy Rule,
1002	   and represents the specialization of this generic ECA Policy Rule to
1003	   add security-specific ECA Policy Rules. The SecurityECAPolicyRule
1004	   contains all of the attributes, methods, and relationships defined in
1005	   its superclass, and adds additional concepts that are required for
1006	   Network Security (these will be defined in the next version of this
1007	   draft). The six SecurityECAPolicyRule subclasses extend the
1008	   SecurityECAPolicyRule class to represent six different types of
1009	   Network Security ECA Policy Rules. It is assumed that the (external)
1010	   generic ECAPolicyRule class defines basic information in the form of
1011	   attributes, such as an unique object ID, as well as a description
1012	   and other necessary information.

1014	*** Note to WG
1015	*
1016	*   The design in Figure 3 represents the simplest conceptual design
1017	*   for network security. An alternative model would be to use a
1018	*   software pattern (e.g., the Decorator pattern); this would result
1019	*   in the SecurityECAPolicyRule class being "wrapped" by one or more
1020	*   of the six subclasses shown in Figure 3. The advantage of such a
1021	*   pattern is to reduce the number of active objects at runtime, as
1022	*   well as offer the ability to combine multiple actions of different
1023	*   policy rules (e.g., inspect traffic and then apply a filter) into
1024	*   one. The disadvantage is that it is a more complex software design.
1025	*   The design team is requesting feedback from the WG regarding this.
1026	*
1027	*** End of Note to WG

1029	   It is assumed that the (external) generic ECA Policy Rule is
1030	   abstract; the SecurityECAPolicyRule is also abstract. This enables
1031	   data model optimizations to be made while making this information
1032	   model detailed but flexible and extensible. For example, abstract
1033	   classes may be collapsed into concrete classes.

1035	   The SecurityECAPolicyRule defines network security policy as a
1036	   container that aggregates Event, Condition, and Action objects,
1037	   which are described in Section 4.1.3, 4.1.4, and 4.1.5,
1038	   respectively. Events, Conditions, and Actions can be generic or
1039	   security-specific.

1041	   Brief class descriptions of these six ECA Policy Rules are provided
1042	   in Appendix A.

1044	4.1.2.  Network Security Policy Rule Operation

1046	   A Network Security Policy consists of one or more ECA Policy Rules
1047	   formed from the information model described above. In simpler cases,
1048	   where the Event and Condition clauses remain unchanged, then the
1049	   action of one Policy Rule may invoke additional network security
1050	   actions from other Policy Rules. Network security policy examines
1051	   and performs basic processing of the traffic as follows:

1053	      1. The NSF evaluates the Event clause of a given
1054	         SecurityECAPolicyRule (which can be generic or specific to
1055	         security, such as those in Figure 3). It may use security
1056	         Event objects to do all or part of this evaluation, which are
1057	         defined in section 4.1.3. If the Event clause evaluates to
1058	         TRUE, then the Condition clause of this SecurityECAPolicyRule
1059	         is evaluated; otherwise, the execution of this
1060	         SecurityECAPolicyRule is stopped, and the next
1061	         SecurityECAPolicyRule (if one exists) is evaluated.

1063	      2. The Condition clause is then evaluated.  It may use security
1064	         Condition objects to do all or part of this evaluation, which
1065	         are defined in section 4.1.4. If the Condition clause
1066	         evaluates to TRUE, it is defined as "matching" the
1067	         SecurityECAPolicyRule; otherwise, execution of this
1068	         SecurityECAPolicyRule is stopped, and the next
1069	         SecurityECAPolicyRule (if one exists) is evaluated.
1070	      3. The set of actions to be executed are retrieved, and then the
1071	         resolution strategy is used to define their execution order.
1072	         This process includes using any optional external data
1073	         associated with the SecurityECAPolicyRule.
1074	      4. Execution then takes one of the following three forms:
1075	         a. If one or more actions is selected, then the NSF may
1076	            perform those actions as defined by the resolution
1077	            strategy. For example, the resolution strategy may only
1078	            allow a single action to be executed (e.g., FMR or LMR),
1079	            or it may allow all actions to be executed (optionally,
1080	            in a particular order). In these and other cases, the NSF
1081	            Capability MUST clearly define how execution will be done.
1082	            It may use security Action objects to do all or part of
1083	            this execution, which are defined in section 4.1.5. If the
1084	            basic Action is permit or mirror, the NSF firstly performs
1085	            that function, and then checks whether certain other
1086	            security Capabilities are referenced in the rule. If yes,
1087	            go to step 5. If no, the traffic is permitted.
1088	         b. If no actions are selected, and if a default action exists,
1089	            then the default action is performed. Otherwise, no actions
1090	            are performed.
1091	         c. Otherwise, the traffic is denied.
1092	      5. If other security Capabilities (e.g., the conditions and/or
1093	         actions implied by Anti-virus or IPS profile NSFs) are
1094	         referenced in the action set of the SecurityECAPolicyRule, the
1095	         NSF can be configured to use the referenced security
1096	         Capabilities (e.g., check conditions or enforce actions).
1097	         Execution then terminates.

1099	   One policy or rule can be applied multiple times to different
1100	   managed objects (e.g., links, devices, networks, VPNS). This not
1101	   only guarantees consistent policy enforcement, but also decreases
1102	   the configuration workload.

1104	4.1.3.  Network Security Event Sub-Model

1106	   Figure 4 shows a more detailed design of the Event subclasses that
1107	   are contained in the Network Security Information Sub-Model.

1109	   The four Event classes shown in Figure 4 extend the (external)
1110	   generic Event class to represent Events that are of interest to
1111	   Network Security. It is assumed that the (external) generic Event
1112	   class defines basic Event information in the form of attributes,
1113	   such as a unique event ID, a description, as well as the date and
1114	   time that the event occurred.

1116	                                     +---------------------+
1117	        +---------------+ 1..n   1..n|                     |
1118	        |               |/ \        \| A Common Superclass |
1119	        | ECAPolicyRule + A ---------+   for ECA Objects   |
1120	        |               |\ /        /|                     |
1121	        +---------------+            +---------+-----------+
1122	                                              / \
1123	                                               |
1124	                                               |
1125	                   +---------------+-----------+------+
1126	                   |               |                  |
1127	                   |               |                  |
1128	             +-----+----+   +------+------+     +-----+-----+
1129	             | An Event |   | A Condition |     | An Action |
1130	             |   Class  |   |    Class    |     |   Class   |
1131	             +-----+----+   +-------------+     +-----------+
1132	                  / \
1133	                   |
1134	                   |
1135	             +-----+---------+----------------+--------------+-- ...
1136	             |               |                |              |
1137	             |               |                |              |
1138	     +-------+----+ +--------+-----+ +--------+-----+ +------+-----+
1139	     |UserSecurity| |    Device    | |    System    | |TimeSecurity|
1140	     |   Event    | | SecurityEvent| | SecurityEvent| |     Event  |
1141	     +------------+ +--------------+ +--------------+ +------------+

1143	    Figure 4. Network Security Info Sub-Model Event Class Extensions

1145	   The following are assumptions that define the functionality of the
1146	   generic Event class. If desired, these could be defined as
1147	   attributes in a SecurityEvent class (which would be a subclass of
1148	   the generic Event class, and a superclass of the four Event classes
1149	   shown in Figure 4). However, this makes it harder to use any
1150	   generic Event model with the I2NSF events. Assumptions are:

1152	      - All four SecurityEvent subclasses are concrete
1153	      - The generic Event class uses the composite pattern, so
1154	        individual Events as well as hierarchies of Events are
1155	        available (the four subclasses in Figure 4 would be
1156	        subclasses of the Atomic Event class); otherwise, a mechanism
1157	        is needed to be able to group Events into a collection
1158	      - The generic Event class has a mechanism to uniquely identify
1159	        the source of the Event
1160	      - The generic Event class has a mechanism to separate header
1161	        information from its payload
1162	      - The generic Event class has a mechanism to attach zero or more
1163	        metadata objects to it

1165	*** Note to WG:
1166	*
1167	*   The design in Figure 4 represents the simplest conceptual design
1168	*   design for describing Security Events. An alternative model would
1169	*   be to use a software pattern (e.g., the Decorator pattern); this
1170	*   would result in the SecurityEvent class being "wrapped" by one or
1171	*   more of the four subclasses shown in Figure 4. The advantage of
1172	*   such a pattern is to reduce the number of active objects at runtime,
1173	*   as well as offer the ability to combine multiple events of different
1174	*   types into one. The disadvantage is that it is a more complex
1175	*   software design.
1176	*
1177	*** End of Note to WG

1179	   Brief class descriptions are provided in Appendix B.

1181	4.1.4.  Network Security Condition Sub-Model

1183	   Figure 5 shows a more detailed design of the Condition subclasses
1184	   that are contained in the Network Security Information Sub-Model.
1185	   The six Condition classes shown in Figure 5 extend the (external)
1186	   generic Condition class to represent Conditions that are of interest
1187	   to Network Security. It is assumed that the (external) generic
1188	   Condition class is abstract, so that data model optimizations may be
1189	   defined. It is also assumed that the generic Condition class defines
1190	   basic Condition information in the form of attributes, such as a
1191	   unique object ID, a description, as well as a mechanism to attach
1192	   zero or more metadata objects to it. While this could be defined as
1193	   attributes in a SecurityCondition class (which would be a subclass
1194	   of the generic Condition class, and a superclass of the six
1195	   Condition classes shown in Figure 5), this makes it harder to use
1196	   any generic Condition model with the I2NSF conditions.

1198	*** Note to WG:
1199	*
1200	*   The design in Figure 5 represents the simplest conceptual design
1201	*   for describing Security Conditions. An alternative model would be
1202	*   to use a software pattern (e.g., the Decorator pattern); this would
1203	*   result in the SecurityCondition class being "wrapped" by one or
1204	*   more of the six subclasses shown in Figure 5. The advantage of such
1205	*   a pattern is to reduce the number of active objects at runtime, as
1206	*   well as offer the ability to combine multiple conditions of
1207	*   different types into one. The disadvantage is that it is a more
1208	*   complex software design.
1209	*   The design team is requesting feedback from he WG regarding this.
1210	*
1211	*** End of Note to WG
1212	                                     +---------------------+
1213	     +---------------+ 1..n     1..n |                     |
1214	     |               |/ \           \| A Common Superclass |
1215	     | ECAPolicyRule+ A -------------+   for ECA Objects   |
1216	     |               |\ /           /|                     |
1217	     +-------+-------+               +-----------+---------+
1218	                                                / \
1219	                                                 |
1220	                                                 |
1221	                       +--------------+----------+----+
1222	                       |              |               |
1223	                       |              |               |
1224	                 +-----+----+  +------+------+  +-----+-----+
1225	                 | An Event |  | A Condition |  | An Action |
1226	                 |   Class  |  |    Class    |  |   Class   |
1227	                 +----------+  +------+------+  +-----------+
1228	                                     / \
1229	                                      |
1230	                                      |
1231	           +--------+----------+------+---+---------+--------+--- ...
1232	           |        |          |          |         |        |
1233	           |        |          |          |         |        |
1234	     +-----+-----+  |  +-------+-------+  |  +------+-----+  |
1235	     |   Packet  |  |  | PacketPayload |  |  |    Target  |  |
1236	     |  Security |  |  |    Security   |  |  |  Security  |  |
1237	     | Condition |  |  |   Condition   |  |  |  Condition |  |
1238	     +-----------+  |  +---------------+  |  +------------+  |
1239	                    |                     |                  |
1240	             +------+-------+  +----------+------+  +--------+-------+
1241	             | UserSecurity |  | SecurityContext |  | GenericContext |
1242	             |   Condition  |  |    Condition    |  |    Condition   |
1243	             +--------------+  +-----------------+  +----------------+

1245	  Figure 5. Network Security Info Sub-Model Condition Class Extensions

1247	   Brief class descriptions are provided in Appendix C.

1249	4.1.5.  Network Security Action Sub-Model

1251	   Figure 6 shows a more detailed design of the Action subclasses that
1252	   are contained in the Network Security Information Sub-Model.

1254	   The four Action classes shown in Figure 6 extend the (external)
1255	   generic Action class to represent Actions that perform a Network
1256	   Security Control function.

1258	   The three Action classes shown in Figure 6 extend the (external)
1259	   generic Action class to represent Actions that are of interest to
1260	   Network Security. It is assumed that the (external) generic Action
1261	   class is abstract, so that data model optimizations may be defined.

1263	                                      +---------------------+
1264	      +---------------+ 1..n     1..n |                     |
1265	      |               |/ \           \| A Common Superclass |
1266	      | ECAPolicyRule+ A -------------+   for ECA Objects   |
1267	      |               |\ /           /|                     |
1268	      +---------------+               +-----------+---------+
1269	                                                 / \
1270	                                                  |
1271	                                                  |
1272	                          +--------------+--------+------+
1273	                          |              |               |
1274	                          |              |               |
1275	                    +-----+----+  +------+------+  +-----+-----+
1276	                    | An Event |  | A Condition |  | An Action |
1277	                    |   Class  |  |    Class    |  |   Class   |
1278	                    +----------+  +-------------+  +-----+-----+
1279	                                                        / \
1280	                                                         |
1281	                                                         |
1282	                       +-----------------+---------------+------- ...
1283	                       |                 |               |
1284	                       |                 |               |
1285	                   +---+-----+      +----+---+    +------+-------+
1286	                   | Ingress |      | Egress |    | ApplyProfile |
1287	                   | Action  |      | Action |    |     Action   |
1288	                   +---------+      +--------+    +--------------+

1290	      Figure 6. Network Security Info Sub-Model Action Extensions

1292	   It is also assumed that the generic Action class defines basic
1293	   Action information in the form of attributes, such as a unique
1294	   object ID, a description, as well as a mechanism to attach zero or
1295	   more metadata objects to it. While this could be defined as
1296	   attributes in a SecurityAction class (which would be a subclass of
1297	   the generic Action class, and a superclass of the six Action classes
1298	   shown in Figure 6), this makes it harder to use any generic Action
1299	   model with the I2NSF actions.

1301	*** Note to WG
1302	*   The design in Figure 6 represents the simplest conceptual design
1303	*   for describing Security Actions. An alternative model would be to
1304	*   use a software pattern (e.g., the Decorator pattern); this would
1305	*   result in the SecurityAction class being "wrapped" by one or more
1306	*   of the three subclasses shown in Figure 6. The advantage of such a
1307	*   pattern is to reduce the number of active objects at runtime, as
1308	*   well as offer the ability to combine multiple actions of different
1309	*   types into one. The disadvantage is that it is a more complex
1310	*   software design.
1311	*   The design team is requesting feedback from the WG regarding this.
1312	*** End of Note to WG

1314	   Brief class descriptions are provided in Appendix D.

1316	4.2.  Information Model for I2NSF Capabilities

1318	   The I2NSF Capability Model is made up of a number of Capabilities
1319	   that represent various content security and attack mitigation
1320	   functions. Each Capability protects against a specific type of
1321	   threat in the application layer. This is shown in Figure 7.

1323	   +-------------------------+ 0..n         0..n +---------------+
1324	   |                         |/ \               \|   External    |
1325	   | External ECA Info Model + A ----------------+   Metadata    |
1326	   |                         |\ /  Aggregates   /|  Info Model   |
1327	   +----+--------------------+      Metadata     +-----+---------+
1328	        |                                             / \
1329	        |                                              |
1330	       / \                                             |
1331	    Subclasses    +------------------------------------+-----------+
1332	     derived      | Capability                      |              |
1333	    for I2NSF     | Sub-Model            +----------+---------+    |
1334	   Policy Rules   |                      | SecurityCapability |    |
1335	                  |                      +----------+---------+    |
1336	                  |                                 |              |
1337	                  |                                 |              |
1338	                  |          +----------------------+---+          |
1339	                  |          |                          |          |
1340	                  | +--------+---------+     +----------+--------+ |
1341	                  | | Content Security |     | Attack Mitigation | |
1342	                  | |   Capabilities   |     |    Capabilities   | |
1343	                  | +------------------+     +-------------------+ |
1344	                  +------------------------------------------------+

1346	        Figure 7. I2NSF Security Capability High-Level Model

1348	   Figure 7 shows a common I2NSF Security Capability class, called
1349	   SecurityCapability. This enables us to add common attributes,
1350	   relationships, and behavior to this class without affecting the
1351	   design of the external metadata information model. All I2NSF
1352	   Security Capabilities are then subclassed from the
1353	   SecuritCapability class.

1355	   Note: the SecurityCapability class will be defined in the next
1356	   version of this draft, after feedback from the WG is obtained.

1358	4.3.  Information Model for Content Security Capabilities

1360	   Content security is composed of a number of distinct security
1361	   Capabilities; each such Capability protects against a specific type
1362	   of threat in the application layer. Content security is a type of
1363	   Generic Network Security Function (GNSF), which summarizes a
1364	   well-defined set of security Capabilities, and was shown in Figure 7.

1366	   Figure 8 shows exemplary types of the content security GNSF.

1368	     +--------------------------------------------------------------+
1369	     |                             +--------------------+           |
1370	     |   Capability                | SecurityCapability |           |
1371	     |   Sub-Model:                +---------+----------+           |
1372	     | Content Security                   / \                       |
1373	     |                                     |                        |
1374	     |                                     |                        |
1375	     |       +-------+----------+----------+---------------+        |
1376	     |       |       |          |                          |        |
1377	     | +-----+----+  |  +-------+----+             +-------+------+ |
1378	     | |Anti-Virus|  |  | Intrusion  |             |    Attack    | |
1379	     | |Capability|  |  | Prevention |             |  Mitigation  | |
1380	     | +----------+  |  | Capability |             | Capabilities | |
1381	     |               |  +------------+             +--------------+ |
1382	     |               |                                              |
1383	     |      +--------+----+------------+-----------+--------+       |
1384	     |      |             |            |           |        |       |
1385	     | +----+-----+ +-----+----+ +-----+----+ +----+-----+  |       |
1386	     | |   URL    | |   Mail   | |   File   | |  Data    |  |       |
1387	     | |Filtering | |Filtering | |Filtering | |Filtering |  |       |
1388	     | |Capability| |Capability| |Capability| |Capability|  |       |
1389	     | +----------+ +----------+ +----------+ +----------+  |       |
1390	     |                                                      |       |
1391	     |             +----------------+------------------+----+       |
1392	     |             |                |                  |            |
1393	     |      +------+------+  +------+------+ +---------+---------+  |
1394	     |      |PacketCapture|  |FileIsolation| |ApplicationBehavior|  |
1395	     |      | Capability  |  | Capability  | |    Capability     |  |
1396	     |      +-------------+  +-------------+ +-------------------+  |
1397	     +--------------------------------------------------------------+

1399	          Figure 8. Network Security Capability Information Model

1401	   The detailed description about a standard interface, and the
1402	   parameters for all the security Capabilities of this category, will
1403	   be defined in a future version of this document.

1405	4.4.  Information Model for Attack Mitigation Capabilities

1407	   Attack mitigation is composed of a number of GNSFs; each one
1408	   protects against a specific type of network attack. Attack
1409	   Mitigation security is a type of GNSF, which summarizes a
1410	   well-defined set of security Capabilities, and was shown in
1411	   Figure 7. Figure 9 shows exemplary types of Attack Mitigation GNSFs.

1413	     +---------------------------------------------------------------+
1414	     |                           +--------------------+              |
1415	     |    Capability             | SecurityCapability |              |
1416	     |    Sub-Model:             +---------+----------+              |
1417	     | Attack Mitigation                  / \                        |
1418	     |                                     |                         |
1419	     |                                     |                         |
1420	     |       +-------+--------+------------+-------------+           |
1421	     |       |       |        |                          |           |
1422	     | +-----+----+  |  +-----+----+             +-------+------+    |
1423	     | | SSLDDoS  |  |  | PortScan |             |    Content   |    |
1424	     | |Capability|  |  |Capability|             |   Security   |    |
1425	     | +----------+  |  +----------+             | Capabilities |    |
1426	     |               |                           +--------------+    |
1427	     |               |                                               |
1428	     |      +--------+----+------------+-----------+--------+        |
1429	     |      |             |            |           |        |        |
1430	     | +----+-----+ +-----+----+ +-----+----+ +----+-----+  |        |
1431	     | | SYNFlood | | UDPFlood | |ICMPFlood | | WebFlood |  |        |
1432	     | |Capability| |Capability| |Capability| |Capability|  |        |
1433	     | +----------+ +----------+ +----------+ +----------+  |        |
1434	     |                                                      |        |
1435	     |         +-----------------+--------------+-----------+        |
1436	     |         |                 |              |                    |
1437	     | +-------+-------+ +-------+------+ +-----+-----+ +-----+----+ |
1438	     | |IPFragmentFlood| |DNSAmplication| |PingOfDeath| | IPSweep  | |
1439	     | |  Capability   | |  Capability  | |Capability | |Capability| |
1440	     | +---------------+ +--------------+ +-----------+ +----------+ |
1441	     +---------------------------------------------------------------+

1443	        Figure 9. Attack Mitigation Capability Information Model

1445	   The detailed description about a standard interface, and the
1446	   parameters for all the security Capabilities of this category, will
1447	   be defined in a future version of this document.

1449	5.  Security Considerations

1451	   The security Capability policy information sent to NSFs should be
1452	   protected by a secure communication channel, to ensure its
1453	   confidentiality and integrity. Note that the NSFs and security
1454	   controller can all be spoofed, which leads to undesirable results
1455	   (e.g., security policy leakage from security controller, or a spoofed
1456	   security controller sending false information to mislead the NSFs).
1457	   Hence, mutual authentication MUST be supported to protected against
1458	   this kind of threat.  The current mainstream security technologies
1459	   (i.e., TLS, DTLS, and IPSEC) can be employed to protect against the
1460	   above threats.

1462	   In addition, to defend against DDoS attacks caused by a hostile
1463	   security controller sending too many configuration messages to the
1464	   NSFs, rate limiting or similar mechanisms should be considered.

1466	6.  IANA Considerations

1468	   TBD

1470	7.  Contributors

1472	   The following people contributed to creating this document, and are
1473	   listed below in alphabetical order:

1475	      Antonio Lioy (Politecnico di Torino)
1476	      Dacheng Zhang (Huawei)
1477	      Edward Lopez (Fortinet)
1478	      Fulvio Valenza (Politecnico di Torino)
1479	      Kepeng Li (Alibaba)
1480	      Luyuan Fang (Microsoft)
1481	      Nicolas Bouthors (QoSmos)

1483	8.  References

1485	8.1.  Normative References

1487	   [RFC2119]
1488	      Bradner, S., "Key words for use in RFCs to Indicate Requirement
1489	      Levels", BCP 14, RFC 2119, March 1997.
1490	   [RFC3539]
1491	      Aboba, B., and Wood, J., "Authentication, Authorization, and
1492	      Accounting (AAA) Transport Profile", RFC 3539, June 2003.

1494	8.2.  Informative References

1496	   [RFC2975]
1497	      Aboba, B., et al., "Introduction to Accounting Management",
1498	      RFC 2975, October 2000.
1499	   [I-D.draft-ietf-i2nsf-problem-and-use-cases]
1500	      Hares, S., et.al., "I2NSF Problem Statement and Use cases",
1501	      draft-ietf-i2nsf-problem-and-use-cases-16, May 2017.
1502	   [I-D.draft-ietf-i2nsf-framework]
1503	      Lopez, E., et.al., "Framework for Interface to Network Security
1504	      Functions", draft-ietf-i2nsf-framework-06, July, 2017.
1505	   [I-D.draft-ietf-i2nsf-terminology]
1506	      Hares, S., et.al., "Interface to Network Security Functions
1507	      (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03,
1508	      March, 2017
1509	   [I-D.draft-ietf-supa-generic-policy-info-model]
1510	      Strassner, J., Halpern, J., van der Meer, S., "Generic Policy
1511	      Information Model for Simplified Use of Policy Abstractions
1512	      (SUPA)", draft-ietf-supa-generic-policy-info-model-03,
1513	      May, 2017.
1514	   [Alshaer]
1515	      Al Shaer, E. and H. Hamed, "Modeling and management of firewall
1516	      policies", 2004.
1517	   [Bas12]
1518	      Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access
1519	      Control Policy Analysis and Transformation", 2012.
1520	   [Bas15]
1521	      Basile, C. and Lioy, A., "Analysis of application-layer filtering
1522	      policies with application to HTTP", IEEE/ACM Transactions on
1523	      Networking, Vol 23, Issue 1, February 2015.
1524	   [Cormen]
1525	      Cormen, T., "Introduction to Algorithms", 2009.
1526	   [Hohpe]
1527	      Hohpe, G. and Woolf, B., "Enterprise Integration Patterns",
1528	      Addison-Wesley, 2003, ISBN 0-32-120068-3
1529	   [Lunt]
1530	      van Lunteren, J. and T. Engbersen, "Fast and scalable packet
1531	      classification", IEEE Journal on Selected Areas in Communication,
1532	      vol 21, Issue 4, September 2003.
1533	   [Martin]
1534	      Martin, R.C., "Agile Software Development, Principles, Patterns,
1535	      and Practices", Prentice-Hall, 2002, ISBN: 0-13-597444-5
1536	   [OODMP]
1537	      http://www.oodesign.com/mediator-pattern.html
1538	   [OODOP]
1539	      http://www.oodesign.com/observer-pattern.html
1540	   [OODSRP]
1541	      http://www.oodesign.com/single-responsibility-principle.html

1543	Appendix A.  Network Security Capability Policy Rule Definitions

1545	   Six exemplary Network Security Capability Policy Rules are
1546	   introduced in this Appendix to clarify how to create different kinds
1547	   of specific ECA policy rules to manage Network Security Capabilities.

1549	   Note that there is a common pattern that defines how these
1550	   ECAPolicyRules operate; this simplifies their implementation. All of
1551	   these six ECA Policy Rules are concrete classes.

1553	   In addition, none of these six subclasses define attributes. This
1554	   enables them to be viewed as simple object containers, and hence,
1555	   applicable to a wide variety of content. It also means that the
1556	   content of the function (e.g., how an entity is authenticated, what
1557	   specific traffic is inspected, or which particular signature is
1558	   applied) is defined solely by the set of events, conditions, and
1559	   actions that are contained by the particular subclass. This enables
1560	   the policy rule, with its aggregated set of events, conditions, and
1561	   actions, to be treated as a reusable object.

1563	A.1.  AuthenticationECAPolicyRule Class Definition

1565	   The purpose of an AuthenticationECAPolicyRule is to define an I2NSF
1566	   ECA Policy Rule that can verify whether an entity has an attribute
1567	   of a specific value. A high-level conceputal figure is shown below.

1569	                                                    +----------------+
1570	   +----------------+ 1..n                    1...n |                |
1571	   |                |/ \  HasAuthenticationMethod  \| Authentication |
1572	   | Authentication + A ----------+-----------------+     Method     |
1573	   | ECAPolicyRule  |\ /          ^                /|                |
1574	   |                |             |                 +----------------+
1575	   +----------------+             |
1576	                                  |
1577	                     +------------+-------------+
1578	                     | AuthenticationRuleDetail |
1579	                     +------------+-------------+
1580	                                 / \ 0..n
1581	                                  |
1582	                                  | PolicyControlsAuthentication
1583	                                  |
1584	                                 / \
1585	                                  A
1586	                                 \ / 0..n
1587	                       +----------+--------------+
1588	                       | ManagementECAPolicyRule |
1589	                       +-------------------------+

1591	            Figure 10.  Modeling Authentication Mechanisms

1593	   This class does NOT define the authentication method used. This is
1594	   because this would effectively "enclose" this information within the
1595	   AuthenticationECAPolicyRule. This has two drawbacks. First, other
1596	   entities that need to use information from the Authentication
1597	   class(es) could not; they would have to associate with the
1598	   AuthenticationECAPolicyRule class, and those other classes would not
1599	   likely be interested in the AuthenticationECAPolicyRule. Second, the
1600	   evolution of new authentication methods should be independent of the
1601	   AuthenticationECAPolicyRule; this cannot happen if the
1602	   Authentication class(es) are embedded in the
1603	   AuthenticationECAPolicyRule.

1605	   This document only defines the AuthenticationECAPolicyRule; all other
1606	   classes, and the aggregations, are defined in an external model. For
1607	   completeness, descriptions of how the two aggregations are used are
1608	   described below.

1610	   Figure 10 defines an aggregation between an external class, which
1611	   defines one or more authentication methods, and an
1612	   AuthenticationECAPolicyRule. This decouples the implementation of
1613	   authentication mechanisms from how authentication mechanisms are
1614	   managed and used.

1616	   Since different AuthenticationECAPolicyRules can use different
1617	   authentication mechanisms in different ways, the aggregation is
1618	   realized as an association class. This enables the attributes and
1619	   methods of the association class (i.e., AuthenticationRuleDetail) to
1620	   be used to define how a given AuthenticationMethod is used by a
1621	   particular AuthenticationECAPolicyRule.

1623	   Similarly, the PolicyControlsAuthentication aggregation defines
1624	   Policy Rules to control the configuration of the
1625	   AuthenticationRuleDetail association class. This enables the entire
1626	   authentication process to be managed by ECA PolicyRules.

1628	   Note: a data model MAY choose to collapse this design into a more
1629	   efficient implementation. For example, a data model could define two
1630	   attributes for the AuthenticationECAPolicyRule class (e.g., called
1631	   authenticationMethodCurrent and authenticationMethodSupported), to
1632	   represent the HasAuthenticationMethod aggregation and its
1633	   association class. The former would be a string attribute that
1634	   defines the current authentication method used by this
1635	   AuthenticationECAPolicyRule, while the latter would define a set of
1636	   authentication methods, in the form of an authentication Capability,
1637	   which this AuthenticationECAPolicyRule can advertise.

1639	A.2.  AuthorizationECAPolicyRuleClass Definition

1641	   The purpose of an AuthorizationECAPolicyRule is to define an I2NSF
1642	   ECA Policy Rule that can determine whether access to a resource
1643	   should be given and, if so, what permissions should be granted to
1644	   the entity that is accessing the resource.

1646	   This class does NOT define the authorization method(s) used. This
1647	   is because this would effectively "enclose" this information within
1648	   the AuthorizationECAPolicyRule. This has two drawbacks. First, other
1649	   entities that need to use information from the Authorization
1650	   class(es) could not; they would have to associate with the
1651	   AuthorizationECAPolicyRule class, and those other classes would not
1652	   likely be interested in the AuthorizationECAPolicyRule. Second, the
1653	   evolution of new authorization methods should be independent of the
1654	   AuthorizationECAPolicyRule; this cannot happen if the Authorization
1655	   class(es) are embedded in the AuthorizationECAPolicyRule. Hence,
1656	   this document recommends the following design:

1658	                                                    +---------------+
1659	    +----------------+ 1..n                   1...n |               |
1660	    |                |/ \   HasAuthorizationMethod \| Authorization |
1661	    | Authorization  + A ----------+----------------+     Method    |
1662	    | ECAPolicyRule  |\ /          ^               /|               |
1663	    |                |             |                +---------------+
1664	    +----------------+             |
1665	                                   |
1666	                      +------------+------------+
1667	                      | AuthorizationRuleDetail |
1668	                      +------------+------------+
1669	                                  / \ 0..n
1670	                                   |
1671	                                   | PolicyControlsAuthorization
1672	                                   |
1673	                                  / \
1674	                                   A
1675	                                  \ / 0..n
1676	                        +----------+--------------+
1677	                        | ManagementECAPolicyRule |
1678	                        +-------------------------+

1680	             Figure 11.  Modeling Authorization Mechanisms

1682	   This document only defines the AuthorizationECAPolicyRule; all other
1683	   classes, and the aggregations, are defined in an external model. For
1684	   completeness, descriptions of how the two aggregations are used are
1685	   described below.

1687	   Figure 11 defines an aggregation between the
1688	   AuthorizationECAPolicyRule and an external class that defines one or
1689	   more authorization methods. This decouples the implementation of
1690	   authorization mechanisms from how authorization mechanisms are
1691	   managed and used.

1693	   Since different AuthorizationECAPolicyRules can use different
1694	   authorization mechanisms in different ways, the aggregation is
1695	   realized as an association class. This enables the attributes and
1696	   methods of the association class (i.e., AuthorizationRuleDetail)
1697	   to be used to define how a given AuthorizationMethod is used by a
1698	   particular AuthorizationECAPolicyRule.

1700	   Similarly, the PolicyControlsAuthorization aggregation defines
1701	   Policy Rules to control the configuration of the
1702	   AuthorizationRuleDetail association class. This enables the entire
1703	   authorization process to be managed by ECA PolicyRules.

1705	   Note: a data model MAY choose to collapse this design into a more
1706	   efficient implementation. For example, a data model could define
1707	   two attributes for the AuthorizationECAPolicyRule class, called
1708	   (for example) authorizationMethodCurrent and
1709	   authorizationMethodSupported, to represent the
1710	   HasAuthorizationMethod aggregation and its association class. The
1711	   former is a string attribute that defines the current authorization
1712	   method used by this AuthorizationECAPolicyRule, while the latter
1713	   defines a set of authorization methods, in the form of an
1714	   authorization Capability, which this AuthorizationECAPolicyRule
1715	   can advertise.

1717	A.3.  AccountingECAPolicyRuleClass Definition

1719	   The purpose of an AccountingECAPolicyRule is to define an I2NSF
1720	   ECA Policy Rule that can determine which information to collect,
1721	   and how to collect that information, from which set of resources
1722	   for the purpose of trend analysis, auditing, billing, or cost
1723	   allocation [RFC2975] [RFC3539].

1725	   This class does NOT define the accounting method(s) used. This is
1726	   because this would effectively "enclose" this information within
1727	   the AccountingECAPolicyRule. This has two drawbacks. First, other
1728	   entities that need to use information from the Accounting class(es)
1729	   could not; they would have to associate with the
1730	   AccountingECAPolicyRule class, and those other classes would not
1731	   likely be interested in the AccountingECAPolicyRule. Second, the
1732	   evolution of new accounting methods should be independent of the
1733	   AccountingECAPolicyRule; this cannot happen if the Accounting
1734	   class(es) are embedded in the AccountingECAPolicyRule. Hence, this
1735	   document recommends the following design:

1737	                                                    +-------------+
1738	      +----------------+ 1..n                 1...n |             |
1739	      |                |/ \   HasAccountingMethod  \| Accounting  |
1740	      |  Accounting    + A ----------+--------------+   Method    |
1741	      | ECAPolicyRule  |\ /          ^             /|             |
1742	      |                |             |              +-------------+
1743	      +----------------+             |
1744	                                     |
1745	                          +----------+-----------+
1746	                          | AccountingRuleDetail |
1747	                          +----------+-----------+
1748	                                    / \ 0..n
1749	                                     |
1750	                                     | PolicyControlsAccounting
1751	                                     |
1752	                                    / \
1753	                                     A
1754	                                    \ / 0..n
1755	                          +----------+--------------+
1756	                          | ManagementECAPolicyRule |
1757	                          +-------------------------+

1759	              Figure 12.  Modeling Accounting Mechanisms

1761	   This document only defines the AccountingECAPolicyRule; all other
1762	   classes, and the aggregations, are defined in an external model.
1763	   For completeness, descriptions of how the two aggregations are used
1764	   are described below.

1766	   Figure 12 defines an aggregation between the AccountingECAPolicyRule
1767	   and an external class that defines one or more accounting methods.
1768	   This decouples the implementation of accounting mechanisms from how
1769	   accounting mechanisms are managed and used.

1771	   Since different AccountingECAPolicyRules can use different
1772	   accounting mechanisms in different ways, the aggregation is realized
1773	   as an association class. This enables the attributes and methods of
1774	   the association class (i.e., AccountingRuleDetail) to be used to
1775	   define how a given AccountingMethod is used by a particular
1776	   AccountingECAPolicyRule.

1778	   Similarly, the PolicyControlsAccounting aggregation defines Policy
1779	   Rules to control the configuration of the AccountingRuleDetail
1780	   association class. This enables the entire accounting process to be
1781	   managed by ECA PolicyRules.

1783	   Note: a data model MAY choose to collapse this design into a more
1784	   efficient implementation. For example, a data model could define
1785	   two attributes for the AccountingECAPolicyRule class, called
1786	   (for example) accountingMethodCurrent and accountingMethodSupported,
1787	   to represent the HasAccountingMethod aggregation and its association
1788	   class.

1790	   The former is a string attribute that defines the current accounting
1791	   method used by this AccountingECAPolicyRule, while the latter
1792	   defines a set of accounting methods, in the form of an accounting
1793	   Capability, which this AccountingECAPolicyRule can advertise.

1795	A.4.  TrafficInspectionECAPolicyRuleClass Definition

1797	   The purpose of a TrafficInspectionECAPolicyRule is to define an I2NSF
1798	   ECA Policy Rule that, based on a given context, can determine which
1799	   traffic to examine on which devices, which information to collect
1800	   from those devices, and how to collect that information.

1802	   This class does NOT define the traffic inspection method(s) used.
1803	   This is because this would effectively "enclose" this information
1804	   within the TrafficInspectionECAPolicyRule. This has two drawbacks.
1805	   First, other entities that need to use information from the
1806	   TrafficInspection class(es) could not; they would have to associate
1807	   with the TrafficInspectionECAPolicyRule class, and those other
1808	   classes would not likely be interested in the
1809	   TrafficInspectionECAPolicyRule. Second, the evolution of new traffic
1810	   inspection methods should be independent of the
1811	   TrafficInspectionECAPolicyRule; this cannot happen if the
1812	   TrafficInspection class(es) are embedded in the
1813	   TrafficInspectionECAPolicyRule. Hence, this document recommends the
1814	   following design:

1816	                                                  +------------------+
1817	   +-------------------+1..n                   1..n|                  |
1818	   |                   |/ \ HasTrafficInspection  \|      Traffic     |
1819	   | TrafficInspection + A ----------+-------------+ InspectionMethod |
1820	   |   ECAPolicyRule   |\ /          ^           / |                  |
1821	   |                   |             |             +------------------+
1822	   +-------------------+             |
1823	                                     |
1824	                        +------------+------------+
1825	                        | TrafficInspectionDetail |
1826	                        +------------+------------+
1827	                                    / \ 0..n
1828	                                     |
1829	                                     | PolicyControlsTrafficInspection
1830	                                     |
1831	                                    / \
1832	                                     A
1833	                                    \ / 0..n
1834	                          +----------+--------------+
1835	                          | ManagementECAPolicyRule |
1836	                          +-------------------------+

1838	           Figure 13.  Modeling Traffic Inspection Mechanisms

1840	   This document only defines the TrafficInspectionECAPolicyRule; all
1841	   other classes, and the aggregations, are defined in an external
1842	   model. For completeness, descriptions of how the two aggregations
1843	   are used are described below.

1845	   Figure 13 defines an aggregation between the
1846	   TrafficInspectionECAPolicyRule and an external class that defines
1847	   one or more traffic inspection mechanisms. This decouples the
1848	   implementation of traffic inspection mechanisms from how traffic
1849	   inspection mechanisms are managed and used.

1851	   Since different TrafficInspectionECAPolicyRules can use different
1852	   traffic inspection mechanisms in different ways, the aggregation is
1853	   realized as an association class. This enables the attributes and
1854	   methods of the association class (i.e., TrafficInspectionDetail) to
1855	   be used to define how a given TrafficInspectionMethod is used by a
1856	   particular TrafficInspectionECAPolicyRule.

1858	   Similarly, the PolicyControlsTrafficInspection aggregation defines
1859	   Policy Rules to control the configuration of the
1860	   TrafficInspectionDetail association class. This enables the entire
1861	   traffic inspection process to be managed by ECA PolicyRules.

1863	   Note: a data model MAY choose to collapse this design into a more
1864	   efficient implementation. For example, a data model could define
1865	   two attributes for the TrafficInspectionECAPolicyRule class, called
1866	   (for example) trafficInspectionMethodCurrent and
1867	   trafficInspectionMethodSupported, to represent the
1868	   HasTrafficInspectionMethod aggregation and its association class.
1869	   The former is a string attribute that defines the current traffic
1870	   inspection method used by this TrafficInspectionECAPolicyRule,
1871	   while the latter defines a set of traffic inspection methods, in
1872	   the form of a traffic inspection Capability, which this
1873	   TrafficInspectionECAPolicyRule can advertise.

1875	A.5.  ApplyProfileECAPolicyRuleClass Definition

1877	   The purpose of an ApplyProfileECAPolicyRule is to define an I2NSF
1878	   ECA Policy Rule that, based on a given context, can apply a
1879	   particular profile to specific traffic. The profile defines the
1880	   security Capabilities for content security control and/or attack
1881	   mitigation control; these will be described in sections 4.4 and
1882	   4.5, respectively.

1884	   This class does NOT define the set of Profiles used. This is
1885	   because this would effectively "enclose" this information within
1886	   the ApplyProfileECAPolicyRule. This has two drawbacks. First, other
1887	   entities that need to use information from the Profile class(es)
1888	   could not; they would have to associate with the
1889	   ApplyProfileECAPolicyRule class, and those other classes would not
1890	   likely be interested in the ApplyProfileECAPolicyRule. Second, the
1891	   evolution of new Profile classes should be independent of the
1892	   ApplyProfileECAPolicyRule; this cannot happen if the Profile
1893	   class(es) are embedded in the ApplyProfileECAPolicyRule. Hence,
1894	   this document recommends the following design:

1896	                                                       +-------------+
1897	      +-------------------+ 1..n                  1..n |             |
1898	      |                   |/ \  ProfileApplied        \|             |
1899	      | ApplyProfile      + A -----------+-------------+   Profile   |
1900	      |   ECAPolicyRule   |\ /           ^            /|             |
1901	      |                   |              |             +-------------+
1902	      +-------------------+              |
1903	                                         |
1904	                            +------------+---------+
1905	                            | ProfileAppliedDetail |
1906	                            +------------+---------+
1907	                                        / \ 0..n
1908	                                         |
1909	                                         |
1910	        PolicyControlsProfileApplication |
1911	                                         |
1912	                                        / \
1913	                                         A
1914	                                        \ / 0..n
1915	                              +----------+--------------+
1916	                              | ManagementECAPolicyRule |
1917	                              +-------------------------+

1919	           Figure 14.  Modeling Profile ApplicationMechanisms

1921	   This document only defines the ApplyProfileECAPolicyRule; all other
1922	   classes, and the aggregations, are defined in an external model.
1923	   For completeness, descriptions of how the two aggregations are used
1924	   are described below.

1926	   Figure 14 defines an aggregation between the
1927	   ApplyProfileECAPolicyRule and an external Profile class. This
1928	   decouples the implementation of Profiles from how Profiles are used.

1930	   Since different ApplyProfileECAPolicyRules can use different
1931	   Profiles in different ways, the aggregation is realized as an
1932	   association class. This enables the attributes and methods of the
1933	   association class (i.e., ProfileAppliedDetail) to be used to define
1934	   how a given Profile is used by a particular
1935	   ApplyProfileECAPolicyRule.

1937	   Similarly, the PolicyControlsProfileApplication aggregation defines
1938	   policies to control the configuration of the ProfileAppliedDetail
1939	   association class. This enables the application of Profiles to be
1940	   managed and used by ECA PolicyRules.

1942	   Note: a data model MAY choose to collapse this design into a more
1943	   efficient implementation. For example, a data model could define two
1944	   attributes for the ApplyProfileECAPolicyRuleclass, called (for
1945	   example) profileAppliedCurrent and profileAppliedSupported, to
1946	   represent the ProfileApplied aggregation and its association class.
1947	   The former is a string attribute that defines the current Profile
1948	   used by this ApplyProfileECAPolicyRule, while the latter defines a
1949	   set of Profiles, in the form of a Profile Capability, which this
1950	   ApplyProfileECAPolicyRule can advertise.

1952	A.6.  ApplySignatureECAPolicyRuleClass Definition

1954	   The purpose of an ApplySignatureECAPolicyRule is to define an I2NSF
1955	   ECA Policy Rule that, based on a given context, can determine which
1956	   Signature object (e.g., an anti-virus file, or aURL filtering file,
1957	   or a script) to apply to which traffic. The Signature object defines
1958	   the security Capabilities for content security control and/or attack
1959	   mitigation control; these will be described in sections 4.4 and 4.5,
1960	   respectively.

1962	   This class does NOT define the set of Signature objects used. This
1963	   is because this would effectively "enclose" this information within
1964	   the ApplySignatureECAPolicyRule. This has two drawbacks. First,
1965	   other entities that need to use information from the Signature
1966	   object class(es) could not; they would have to associate with the
1967	   ApplySignatureECAPolicyRule class, and those other classes would not
1968	   likely be interested in the ApplySignatureECAPolicyRule. Second, the
1969	   evolution of new Signature object classes should be independent of
1970	   the ApplySignatureECAPolicyRule; this cannot happen if the Signature
1971	   object class(es) are embedded in the ApplySignatureECAPolicyRule.
1972	   Hence, this document recommends the following design:

1974	   This document only defines the ApplySignatureECAPolicyRule; all
1975	   other classes, and the aggregations, are defined in an external
1976	   model. For completeness, descriptions of how the two aggregations
1977	   are used are described below.

1979	   Figure 15 defines an aggregation between the
1980	   ApplySignatureECAPolicyRule and an external Signature object class.
1981	   This decouples the implementation of signature objects from how
1982	   Signature objects are used.

1984	   Since different ApplySignatureECAPolicyRules can use different
1985	   Signature objects in different ways, the aggregation is realized as
1986	   an association class. This enables the attributes and methods of the
1987	   association class (i.e., SignatureAppliedDetail) to be used to
1988	   define how a given Signature object is used by a particular
1989	   ApplySignatureECAPolicyRule.

1991	                                                 +-------------+
1992	    +---------------+ 1..n                  1..n |             |
1993	    |               |/ \   SignatureApplied     \|             |
1994	    | ApplySignature+ A ----------+--------------+  Signature  |
1995	    | ECAPolicyRule |\ /          ^             /|             |
1996	    |               |             |              +-------------+
1997	    +---------------+             |
1998	                                  |
1999	                     +------------+-----------+
2000	                     | SignatureAppliedDetail |
2001	                     +------------+-----------+
2002	                                 / \ 0..n
2003	                                  |
2004	                                  | PolicyControlsSignatureApplication
2005	                                  |
2006	                                 / \
2007	                                  A
2008	                                 \ / 0..n
2009	                       +----------+--------------+
2010	                       | ManagementECAPolicyRule |
2011	                       +-------------------------+

2013	         Figure 15.  Modeling Sginature Application Mechanisms

2015	   Similarly, the PolicyControlsSignatureApplication aggregation
2016	   defines policies to control the configuration of the
2017	   SignatureAppliedDetail association class. This enables the
2018	   application of the Signature object to be managed by policy.

2020	   Note: a data model MAY choose to collapse this design into a more
2021	   efficient implementation. For example, a data model could define
2022	   two attributes for the ApplySignatureECAPolicyRule class, called
2023	   (for example) signature signatureAppliedCurrent and
2024	   signatureAppliedSupported, to represent the SignatureApplied
2025	   aggregation and its association class. The former is a string
2026	   attribute that defines the current Signature object used by this
2027	   ApplySignatureECAPolicyRule, while the latter defines a set of
2028	   Signature objects, in the form of a Signature Capability, which
2029	   this ApplySignatureECAPolicyRule can advertise.

2031	Appendix B. Network Security Event Class Definitions

2033	   This Appendix defines a preliminary set of Network Security Event
2034	   classes, along with their attributes.

2036	B.1.  UserSecurityEvent Class Description

2038	   The purpose of this class is to represent Events that are initiated
2039	   by a user, such as logon and logoff Events. Information in this
2040	   Event may be used as part of a test to determine if the Condition
2041	   clause in this ECA Policy Rule should be evaluated or not. Examples
2042	   include user identification data and the type of connection used by
2043	   the user.

2045	   The UserSecurityEvent class defines the following attributes.

2047	B.1.1.  The usrSecEventContent Attribute

2049	   This is a mandatory string that contains the content of the
2050	   UserSecurityEvent. The format of the content is specified in the
2051	   usrSecEventFormat class attribute, and the type of Event is defined
2052	   in the usrSecEventType class attribute. An example of the
2053	   usrSecEventContent attribute is the string "hrAdmin", with the
2054	   usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute
2055	   set to 5 (new logon).

2057	B.1.2.  The usrSecEventFormat Attribute

2059	   This is a mandatory non-negative enumerated integer, which is used
2060	   to specify the data type of the usrSecEventContent attribute. The
2061	   content is specified in the usrSecEventContent class attribute, and
2062	   the type of Event is defined in the usrSecEventType class attribute.
2063	   An example of the usrSecEventContent attribute is the string
2064	   "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and
2065	   the usrSecEventType attribute set to 5 (new logon). Values include:

2067	      0:  unknown
2068	      1:  GUID (Generic Unique IDentifier)
2069	      2:  UUID (Universal Unique IDentifier)
2070	      3:  URI (Uniform Resource Identifier)
2071	      4:  FQDN (Fully Qualified Domain Name)
2072	      5:  FQPN (Fully Qualified Path Name)

2074	B.1.3.  The usrSecEventType Attribute

2076	   This is a mandatory non-negative enumerated integer, which is used
2077	   to specify the type of Event that involves this user. The content
2078	   and format are specified in the usrSecEventContent and
2079	   usrSecEventFormat class attributes, respectively.

2081	   An example of the usrSecEventContent attribute is the string
2082	   "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID), and
2083	   the usrSecEventType attribute set to 5 (new logon). Values include:

2085	      0:  unknown
2086	      1:  new user created
2087	      2:  new user group created
2088	      3:  user deleted
2089	      4:  user group deleted
2090	      5:  user logon
2091	      6:  user logoff
2092	      7:  user access request
2093	      8:  user access granted
2094	      9:  user access violation

2096	B.2.  DeviceSecurityEvent Class Description

2098	   The purpose of a DeviceSecurityEvent is to represent Events that
2099	   provide information from the Device that are important to I2NSF
2100	   Security. Information in this Event may be used as part of a test
2101	   to determine if the Condition clause in this ECA Policy Rule should
2102	   be evaluated or not. Examples include alarms and various device
2103	   statistics (e.g., a type of threshold that was exceeded), which may
2104	   signal the need for further action.

2106	   The DeviceSecurityEvent class defines the following attributes.

2108	B.2.1.  The devSecEventContent Attribute

2110	   This is a mandatory string that contains the content of the
2111	   DeviceSecurityEvent. The format of the content is specified in the
2112	   devSecEventFormat class attribute, and the type of Event is defined
2113	   in the devSecEventType class attribute. An example of the
2114	   devSecEventContent attribute is "alarm", with the devSecEventFormat
2115	   attribute set to 1 (GUID), the devSecEventType attribute set to
2116	   5 (new logon).

2118	B.2.2.  The devSecEventFormat Attribute

2120	   This is a mandatory non-negative enumerated integer, which is used
2121	   to specify the data type of the devSecEventContent attribute.
2122	   Values include:

2124	      0:  unknown
2125	      1:  GUID (Generic Unique IDentifier)
2126	      2:  UUID (Universal Unique IDentifier)
2127	      3:  URI (Uniform Resource Identifier)
2128	      4:  FQDN (Fully Qualified Domain Name)
2129	      5:  FQPN (Fully Qualified Path Name)

2131	B.2.3.  The devSecEventType Attribute

2133	   This is a mandatory non-negative enumerated integer, which is used
2134	   to specify the type of Event that was generated by this device.
2135	   Values include:

2137	      0:  unknown
2138	      1:  communications alarm
2139	      2:  quality of service alarm
2140	      3:  processing error alarm
2141	      4:  equipment error alarm
2142	      5:  environmental error alarm

2144	   Values 1-5 are defined in X.733. Additional types of errors may also
2145	   be defined.

2147	B.2.4.  The devSecEventTypeInfo[0..n] Attribute

2149	   This is an optional array of strings, which is used to provide
2150	   additional information describing the specifics of the Event
2151	   generated by this Device. For example, this attribute could contain
2152	   probable cause information in the first array, trend information in
2153	   the second array, proposed repair actions in the third array, and
2154	   additional information in the fourth array.

2156	B.2.5.  The devSecEventTypeSeverity Attribute

2158	   This is a mandatory non-negative enumerated integer, which is used
2159	   to specify the perceived severity of the Event generated by this
2160	   Device. Values (which are defined in X.733) include:

2162	      0:  unknown
2163	      1:  cleared
2164	      2:  indeterminate
2165	      3:  critical
2166	      4:  major
2167	      5:  minor
2168	      6:  warning

2170	B.3.  SystemSecurityEvent Class Description

2172	   The purpose of a SystemSecurityEvent is to represent Events that
2173	   are detected by the management system, instead of Events that are
2174	   generated by a user or a device. Information in this Event may be
2175	   used as part of a test to determine if the Condition clause in
2176	   this ECA Policy Rule should be evaluated or not. Examples include
2177	   an event issued by an analytics system that warns against a
2178	   particular pattern of unknown user accesses, or an Event issued by
2179	   a management system that represents a set of correlated and/or
2180	   filtered Events.

2182	   The SystemSecurityEvent class defines the following attributes.

2184	B.3.1.  The sysSecEventContent Attribute

2186	   This is a mandatory string that contains the content of the
2187	   SystemSecurityEvent. The format of the content is specified in the
2188	   sysSecEventFormat class attribute, and the type of Event is defined
2189	   in the sysSecEventType class attribute. An example of the
2190	   sysSecEventContent attribute is the string "sysadmin3", with the
2191	   sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType
2192	   attribute set to 2 (audit log cleared).

2194	B.3.2.  The sysSecEventFormat Attribute

2196	   This is a mandatory non-negative enumerated integer, which is used
2197	   to specify the data type of the sysSecEventContent attribute.
2198	   Values include:

2200	      0:  unknown
2201	      1:  GUID (Generic Unique IDentifier)
2202	      2:  UUID (Universal Unique IDentifier)
2203	      3:  URI (Uniform Resource Identifier)
2204	      4:  FQDN (Fully Qualified Domain Name)
2205	      5:  FQPN (Fully Qualified Path Name)

2207	B.3.3.  The sysSecEventType Attribute

2209	   This is a mandatory non-negative enumerated integer, which is used
2210	   to specify the type of Event that involves this device.
2211	   Values include:

2213	      0:  unknown
2214	      1:  audit log written to
2215	      2:  audit log cleared
2216	      3:  policy created
2217	      4:  policy edited
2218	      5:  policy deleted
2219	      6:  policy executed

2221	B.4.  TimeSecurityEvent Class Description

2223	   The purpose of a TimeSecurityEvent is to represent Events that are
2224	   temporal in nature (e.g., the start or end of a period of time).
2225	   Time events signify an individual occurrence, or a time period, in
2226	   which a significant event happened. Information in this Event may be
2227	   used as part of a test to determine if the Condition clause in this
2228	   ECA Policy Rule should be evaluated or not. Examples include issuing
2229	   an Event at a specific time to indicate that a particular resource
2230	   should not be accessed, or that different authentication and
2231	   authorization mechanisms should now be used (e.g., because it is now
2232	   past regular business hours).

2234	   The TimeSecurityEvent class defines the following attributes.

2236	B.4.1.  The timeSecEventPeriodBegin Attribute

2238	   This is a mandatory DateTime attribute, and represents the beginning
2239	   of a time period. It has a value that has a date and/or a time
2240	   component (as in the Java or Python libraries).

2242	B.4.2.  The timeSecEventPeriodEnd Attribute

2244	   This is a mandatory DateTime attribute, and represents the end of a
2245	   time period. It has a value that has a date and/or a time component
2246	   (as in the Java or Python libraries). If this is a single Event
2247	   occurence, and not a time period when the Event can occur, then the
2248	   timeSecEventPeriodEnd attribute may be ignored.

2250	B.4.3.  The timeSecEventTimeZone Attribute

2252	   This is a mandatory string attribute, and defines the time zone that
2253	   this Event occurred in using the format specified in ISO8601.

2255	Appendix C. Network Security Condition Class Definitions

2257	   This Appendix defines a preliminary set of Network Security Condition
2258	   classes, along with their attributes.

2260	C.1.  PacketSecurityCondition

2262	   The purpose of this Class is to represent packet header information
2263	   that can be used as part of a test to determine if the set of Policy
2264	   Actions in this ECA Policy Rule should be executed or not. This class
2265	   is abstract, and serves as the superclass of more detailed conditions
2266	   that act on different types of packet formats. Its subclasses are
2267	   shown in Figure 16, and are defined in the following sections.

2269	                             +-------------------------+
2270	                             | PacketSecurityCondition |
2271	                             +------------+------------+
2272	                                         / \
2273	                                          |
2274	                                          |
2275	                 +---------+----------+---+-----+----------+
2276	                 |         |          |         |          |
2277	                 |         |          |         |          |
2278	        +--------+-------+ | +--------+-------+ | +--------+-------+
2279	        | PacketSecurity | | | PacketSecurity | | | PacketSecurity |
2280	        |  MACCondition  | | | IPv4Condition  | | | IPv6Condition  |
2281	        +----------------+ | +----------------+ | +----------------+
2282	                           |                    |
2283	                  +--------+-------+   +--------+-------+
2284	                  |  TCPCondition  |   |  UDPCondition  |
2285	                  +----------------+   +----------------+

2287	   Figure 16. Network Security Info Sub-Model PacketSecurityCondition
2288	              Class Extensions

2290	C.1.1.  PacketSecurityMACCondition

2292	   The purpose of this Class is to represent packet MAC packet header
2293	   information that can be used as part of a test to determine if the
2294	   set of Policy Actions in this ECA Policy Rule should be executed or
2295	   not. This class is concrete, and defines the following attributes.

2297	C.1.1.1.  The pktSecCondMACDest Attribute

2299	   This is a mandatory string attribute, and defines the MAC
2300	   destination address (6 octets long).

2302	C.1.1.2.  The pktSecCondMACSrc Attribute

2304	   This is a mandatory string attribute, and defines the MAC source
2305	   address (6 octets long).

2307	C.1.1.3.  The pktSecCondMAC8021Q Attribute

2309	   This is an optional string attribute, and defines the 802.1Q tag
2310	   value (2 octets long). This defines VLAN membership and 802.1p
2311	   priority values.

2313	C.1.1.4.  The pktSecCondMACEtherType Attribute

2315	   This is a mandatory string attribute, and defines the EtherType
2316	   field (2 octets long). Values up to and including 1500 indicate the
2317	   size of the payload in octets; values of 1536 and above define
2318	   which protocol is encapsulated in the payload of the frame.

2320	C.1.1.5.  The pktSecCondMACTCI Attribute

2322	   This is an optional string attribute, and defines the Tag Control
2323	   Information. This consists of a 3 bit user priority field, a drop
2324	   eligible indicator (1 bit), and a VLAN identifier (12 bits).

2326	C.1.2.  PacketSecurityIPv4Condition

2328	   The purpose of this Class is to represent packet IPv4 packet header
2329	   information that can be used as part of a test to determine if the
2330	   set of Policy Actions in this ECA Policy Rule should be executed or
2331	   not. This class is concrete, and defines the following attributes.

2333	C.1.2.1.  The pktSecCondIPv4SrcAddr Attribute

2335	   This is a mandatory string attribute, and defines the IPv4 Source
2336	   Address (32 bits).

2338	C.1.2.2.  The pktSecCondIPv4DestAddr Attribute

2340	   This is a mandatory string attribute, and defines the IPv4
2341	   Destination Address (32 bits).

2343	C.1.2.3.  The pktSecCondIPv4ProtocolUsed Attribute

2345	   This is a mandatory string attribute, and defines the protocol used
2346	   in the data portion of the IP datagram (8 bits).

2348	C.1.2.4.  The pktSecCondIPv4DSCP Attribute

2350	   This is a mandatory string attribute, and defines the Differentiated
2351	   Services Code Point field (6 bits).

2353	C.1.2.5.  The pktSecCondIPv4ECN Attribute

2355	   This is an optional string attribute, and defines the Explicit
2356	   Congestion Notification field (2 bits).

2358	C.1.2.6.  The pktSecCondIPv4TotalLength Attribute

2360	   This is a mandatory string attribute, and defines the total length
2361	   of the packet (including header and data) in bytes (16 bits).

2363	C.1.2.7.  The pktSecCondIPv4TTL Attribute

2365	   This is a mandatory string attribute, and defines the Time To Live
2366	   in seconds (8 bits).

2368	C.1.3.  PacketSecurityIPv6Condition

2370	   The purpose of this Class is to represent packet IPv6 packet header
2371	   information that can be used as part of a test to determine if the
2372	   set of Policy Actions in this ECA Policy Rule should be executed or
2373	   not. This class is concrete, and defines the following attributes.

2375	C.1.3.1.  The pktSecCondIPv6SrcAddr Attribute

2377	   This is a mandatory string attribute, and defines the IPv6 Source
2378	   Address (128 bits).

2380	C.1.3.2.  The pktSecCondIPv6DestAddr Attribute

2382	   This is a mandatory string attribute, and defines the IPv6
2383	   Destination Address (128 bits).

2385	C.1.3.3.  The pktSecCondIPv6DSCP Attribute

2387	   This is a mandatory string attribute, and defines the Differentiated
2388	   Services Code Point field (6 bits). It consists of the six most
2389	   significant bits of the Traffic Class field in the IPv6 header.

2391	C.1.3.4.  The pktSecCondIPv6ECN Attribute

2393	   This is a mandatory string attribute, and defines the Explicit
2394	   Congestion Notification field (2 bits). It consists of the two least
2395	   significant bits of the Traffic Class field in the IPv6 header.

2397	C.1.3.5.  The pktSecCondIPv6FlowLabel Attribute

2399	   This is a mandatory string attribute, and defines an IPv6 flow
2400	   label. This, in combination with the Source and Destination Address
2401	   fields, enables efficient IPv6 flow classification by using only the
2402	   IPv6 main header fields (20 bits).

2404	C.1.3.6.  The pktSecCondIPv6PayloadLength Attribute

2406	   This is a mandatory string attribute, and defines the total length
2407	   of the packet (including the fixed and any extension headers, and
2408	   data) in bytes (16 bits).

2410	C.1.3.7.  The pktSecCondIPv6NextHeader Attribute

2412	   This is a mandatory string attribute, and defines the type of the
2413	   next header (e.g., which extension header to use) (8 bits).

2415	C.1.3.8.  The pktSecCondIPv6HopLimit Attribute

2417	   This is a mandatory string attribute, and defines the maximum
2418	   number of hops that this packet can traverse (8 bits).

2420	C.1.4.  PacketSecurityTCPCondition

2422	   The purpose of this Class is to represent packet TCP packet header
2423	   information that can be used as part of a test to determine if the
2424	   set of Policy Actions in this ECA Policy Rule should be executed or
2425	   not. This class is concrete, and defines the following attributes.

2427	C.1.4.1.  The pktSecCondTPCSrcPort Attribute

2429	   This is a mandatory string attribute, and defines the Source Port
2430	   number (16 bits).

2432	C.1.4.2.  The pktSecCondTPCDestPort Attribute

2434	   This is a mandatory string attribute, and defines the Destination
2435	   Port number (16 bits).

2437	C.1.4.3.  The pktSecCondTCPSeqNum Attribute

2439	   This is a mandatory string attribute, and defines the sequence
2440	   number (32 bits).

2442	C.1.4.4.  The pktSecCondTCPFlags Attribute

2444	   This is a mandatory string attribute, and defines the nine Control
2445	   bit flags (9 bits).

2447	C.1.5.  PacketSecurityUDPCondition

2449	   The purpose of this Class is to represent packet UDP packet header
2450	   information that can be used as part of a test to determine if the
2451	   set of Policy Actions in this ECA Policy Rule should be executed or
2452	   not. This class is concrete, and defines the following attributes.

2454	C.1.5.1.1.  The pktSecCondUDPSrcPort Attribute

2456	   This is a mandatory string attribute, and defines the UDP Source
2457	   Port number (16 bits).

2459	C.1.5.1.2.  The pktSecCondUDPDestPort Attribute

2461	   This is a mandatory string attribute, and defines the UDP
2462	   Destination Port number (16 bits).

2464	C.1.5.1.3.  The pktSecCondUDPLength Attribute

2466	   This is a mandatory string attribute, and defines the length in
2467	   bytes of the UDP header and data (16 bits).

2469	C.2.  PacketPayloadSecurityCondition

2471	   The purpose of this Class is to represent packet payload data that
2472	   can be used as part of a test to determine if the set of Policy
2473	   Actions in this ECA Policy Rule should be executed or not. Examples
2474	   include a specific set of bytes in the packet payload.

2476	C.3.  TargetSecurityCondition

2478	   The purpose of this Class is to represent information about
2479	   different targets of this policy (i.e., entities to which this
2480	   Policy Rule should be applied), which can be used as part of a
2481	   test to determine if the set of Policy Actions in this ECA Policy
2482	   Rule should be executed or not. Examples include whether the
2483	   targeted entities are playing the same role, or whether each
2484	   device is administered by the same set of users, groups, or roles.
2485	   This Class has several important subclasses, including:

2487	      a. ServiceSecurityContextCondition is the superclass for all
2488	         information that can be used in an ECA Policy Rule that
2489	         specifies data about the type of service to be analyzed
2490	         (e.g., the protocol type and port number)
2491	      b. ApplicationSecurityContextCondition is the superclass for all
2492	         information that can be used in a ECA Policy Rule that
2493	         specifies data that identifies a particular application
2494	         (including metadata, such as risk level)
2495	      c. DeviceSecurityContextCondition is the superclass for all
2496	         information that can be used in a ECA Policy Rule that
2497	         specifies data about a device type and/or device OS that is
2498	         being used

2500	C.4.  UserSecurityCondition

2502	   The purpose of this Class is to represent data about the user or
2503	   group referenced in this ECA Policy Rule that can be used as part of
2504	   a test to determine if the set of Policy Actions in this ECA Policy
2505	   Rule should be evaluated or not. Examples include the user or group
2506	   id used, the type of connection used, whether a given user or group
2507	   is playing a particular role, or whether a given user or group has
2508	   failed to login a particular number of times.

2510	C.5.  SecurityContextCondition

2512	   The purpose of this Class is to represent security conditions that
2513	   are part of a specific context, which can be used as part of a test
2514	   to determine if the set of Policy Actions in this ECA Policy Rule
2515	   should be evaluated or not. Examples include testing to determine
2516	   if a particular pattern of security-related data have occurred, or
2517	   if the current session state matches the expected session state.

2519	C.6.  GenericContextSecurityCondition

2521	   The purpose of this Class is to represent generic contextual
2522	   information in which this ECA Policy Rule is being executed, which
2523	   can be used as part of a test to determine if the set of Policy
2524	   Actions in this ECA Policy Rule should be evaluated or not.
2525	   Examples include geographic location and temporal information.

2527	Appendix D. Network Security Action Class Definitions

2529	   This Appendix defines a preliminary set of Network Security Action
2530	   classes, along with their attributes.

2532	D.1.  IngressAction

2534	   The purpose of this Class is to represent actions performed on
2535	   packets that enter an NSF. Examples include pass, dropp, or
2536	   mirror traffic.

2538	D.2.  EgressAction

2540	   The purpose of this Class is to represent actions performed on
2541	   packets that exit an NSF. Examples include pass, drop, or mirror
2542	   traffic, signal, and encapsulate.

2544	D.3.  ApplyProfileAction

2546	   The purpose of this Class is to define the application of a profile
2547	   to packets to perform content security and/or attack mitigation
2548	   control.

2550	Appendix E. Geometric Model

2552	   The geometric model defined in [Bas12] is summarized here. Note that
2553	   our work has extended the work of [Bas12] to model ECA Policy Rules,
2554	   instead of just condition-action Policy Rules. However, the
2555	   geometric model in this Appendix is simplified in this version of
2556	   this I-D, and is used to define just the CA part of the ECA model.

2558	   All the actions available to the security function are well known
2559	   and organized in an action set A.

2561	   For filtering controls, the enforceable actions are either Allow or
2562	   Deny, thus A={Allow,Deny}. For channel protection controls, they may
2563	   be informally written as "enforce confidentiality", "enforce data
2564	   authentication and integrity", and "enforce confidentiality and data
2565	   authentication and integrity". However, these actions need to be
2566	   instantiated to the technology used. For example, AH-transport mode
2567	   and ESP-transport mode (and combinations thereof) are a more precise
2568	   definition of channel protection actions.

2570	   Conditions are typed predicates concerning a given selector. A
2571	   selector describes the values that a protocol field may take. For
2572	   example, the IP source selector is the set of all possible IP
2573	   addresses, and it may also refer to the part of the packet where the
2574	   values come from (e.g., the IP source selector refers to the IP
2575	   source field in the IP header). Geometrically, a condition is the
2576	   subset of its selector for which it evaluates to true. A condition
2577	   on a given selector matches a packet if the value of the field
2578	   referred to by the selector belongs to the condition.  For instance,
2579	   in Figure 17 the conditions are s1 <= S1 (read as s1 subset of or
2580	   equal to S1) and s2 <= S2 (s2 subset of or equal to S2), both s1 and
2581	   s2 match the packet x1, while only s2 matches x2.

2583	   To consider conditions in different selectors, the decision space is
2584	   extended using the Cartesian product because distinct selectors
2585	   refer to different fields, possibly from different protocol headers.
2586	   Hence, given a policy-enabled element that allows the definition of
2587	   conditions on the selectors S1, S2,..., Sm (where m is the number
2588	   of Selectors available at the security control we want to model),
2589	   its selection space is:

2591	      S=S1 X S2 X ...  X Sm

2593	   To consider conditions in different selectors, the decision space is
2594	   extended using the Cartesian product because distinct selectors
2595	   refer to different fields, possibly from different protocol headers.

2597	        S2 ^ Destination port
2598	           |
2599	           |      x2
2600	           +......o
2601	           |      .
2602	           |      .
2603	         --+.............+------------------------------------+
2604	         | |      .      |                                    |
2605	         s |      .      |                                    |
2606	         e |      .      |            (rectangle)             |
2607	         g |      .      |        condition clause (c)        |
2608	         m |      .      |   here the action a is applied     |
2609	         e |      .      |                                    |
2610	         n |      .      |             x1=point=packet        |
2611	         t +.............|.............o                      |
2612	         | |      .      |             .                      |
2613	         --+.............+------------------------------------+
2614	           |      .      .             .                      .
2615	           |      .      .             .                      .
2616	     +------------+------+-------------+----------------------+------>
2617	           |             |---- segment = condition in S1 -----|     S1
2618	           +                                                 IP source

2620	      Figure 17: Geometric representation of a rule r=(c,a) that
2621	                 matches x1, but does not match x2.

2623	   Accordingly, the condition clause c is a subset of S:

2625	      c = s1 X s2 X ...  X sm <= S1 X S2 X ...  X Sm = S

2627	   S represents the totality of the packets that are individually
2628	   selectable by the security control to model when we use it to
2629	   enforce a policy. Unfortunately, not all its subsets are valid
2630	   condition clauses: only hyper-rectangles, or the union of
2631	   hyper-rectangles (as they are Cartesian product of conditions),
2632	   are valid. This is an intrinsic constraint of the policy
2633	   language, as it specifies rules by defining a condition for each
2634	   selector. Languages that allow specification of conditions as
2635	   relations over more fields are modeled by the geometric model as
2636	   more complex geometric shapes determined by the equations. However,
2637	   the algorithms to compute intersections are much more sophisticated
2638	   than intersection hyper-rectangles. Figure 17 graphically represents
2639	   a condition clause c in a two-dimensional selection space.

2641	   In the geometric model, a rule is expressed as r=(c,a), where c <= S
2642	   (the condition clause is a subset of the selection space), and the
2643	   action a belongs to A. Rule condition clauses match a packet (rules
2644	   match a packet), if all the conditions forming the clauses match the
2645	   packet. In Figure 17, the rule with condition clause c matches the
2646	   packet x1 but not x2.

2648	   The rule set R is composed of n rules ri=(ci,ai).

2650	   The decision criteria for the action to apply when a packet matches
2651	   two or more rules is abstracted by means of the resolution strategy

2653	      RS: Pow(R) -> A

2655	   where Pow(R) is the power set of rules in R.

2657	   Formally, given a set of rules, the resolution strategy maps all the
2658	   possible subsets of rules to an action a in A. When no rule matches a
2659	   packet, the security controls may select the default action d in A,
2660	   if they support one.

2662	   Resolution strategies may use, besides intrinsic rule data (i.e.,
2663	   condition clause and action clause), also external data associated to
2664	   each rule, such as priority, identity of the creator, and creation
2665	   time.  Formally, every rule ri is associated by means of the
2666	   function e(.):

2668	      e(ri) = (ri,f1(ri),f2(ri),...)

2670	   where E={fj:R -> Xj} (j=1,2,...) is the set that includes all
2671	   functions that map rules to external attributes in Xj. However,
2672	   E, e, and all the Xj are determined by the resolution strategy used.

2674	   A policy is thus a function p: S -> A that connects each point of
2675	   the selection space to an action taken from the action set A
2676	   according to the rules in R. By also assuming RS(0)=d (where 0 is
2677	   the empty-set) and RS(ri)=ai, the policy p can be described as:

2679	      p(x)=RS(match{R(x)}).

2681	   Therefore, in the geometric model, a policy is completely defined by
2682	   the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS,
2683	   the set E of mappings to the external attributes, and the default
2684	   action d.

2686	   Note that, the geometric model also supports ECA paradigms by simply
2687	   modeling events like an additional selector.

2689	Authors' Addresses
2690	Liang Xia (Frank)
2691	Huawei
2692	101 Software Avenue, Yuhuatai District
2693	Nanjing, Jiangsu  210012
2694	China
2695	Email: Frank.xialiang@huawei.com

2697	John Strassner
2698	Huawei
2699	Email: John.sc.Strassner@huawei.com

2701	Cataldo Basile
2702	Politecnico di Torino
2703	Corso Duca degli Abruzzi, 34
2704	Torino, 10129
2705	Italy
2706	Email: cataldo.basile@polito.it

2708	Diego R. Lopez
2709	Telefonica I+D
2710	Zurbaran, 12
2711	Madrid,   28010
2712	Spain
2713	Phone: +34 913 129 041
2714	Email: diego.r.lopez@telefonica.com