idnits 2.17.1 

draft-ietf-i2nsf-capability-01.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 :
  ----------------------------------------------------------------------------

  ** There are 5 instances of too long lines in the document, the longest one
     being 2 characters in excess of 72.


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

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

  -- The document date (April 3, 2018) is 2216 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 (-08) exists of
     draft-ietf-i2nsf-terminology-03


     Summary: 1 error (**), 0 flaws (~~), 2 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:  October 3, 2018                                      C. Basile
5	                                                                  PoliTO
6	                                                                D. Lopez
7	                                                                     TID
8	                                                           April 3, 2018

10	                 Information Model of NSFs Capabilities
11	                   draft-ietf-i2nsf-capability-01.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 October 3, 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 equipments in a mobile network,
171	   devices in the Internet of Things, or residential access users
172	   [RFC8192].

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 [RFC8329], there are two types of I2NSF interfaces
193	   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 implementations.

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 functionalities, 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 a 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 has to discover, negotiate, and update its
302	      security Capabilities automatically (i.e., without human
303	      intervention). These features are useful especially for the
304	      management of a large number of NSFs. They are essential to add
305	      smart services (e.g., analysis, refinement, Capability reasoning,
306	      and optimization) for the security scheme employed. These
307	      features are supported by many design patterns, including the
308	      Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a set
309	      of Message Exchange Patterns [Hohpe].
310	    o Scalability: the management system must have the Capability to
311	      scale up/down or scale in/out. Thus, it can meet various
312	      performance requirements derived from changeable network traffic
313	      or service requests. In addition, security Capabilities that are
314	      affected by scalability changes must support reporting statistics
315	      to the security controller to assist its decision on whether it
316	      needs to invoke scaling or not. However, this requirement is for
317	      information only, and is beyond the scope of this document.

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

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

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

344	3.2.  ECA Policy Model Overview

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

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

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

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

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

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

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

393	3.3.  Relation with the External Information Model

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

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

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

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

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

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

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

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

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

459	          Figure 1. The Overall I2NSF Information Model Design

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

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

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

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

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

493	3.4.  I2NSF Capability Information Model: Theory of Operation

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

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

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

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

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

540	3.4.1.  I2NSF Condition Clause Operator Types

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

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

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

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

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

563	      proto < 62             (invalid condition)

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

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

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

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

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

597	   As an example, the condition clause:

599	      "URL = *.website.*"

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

605	      "MIME_type = video/*"

607	   matches all MIME objects whose type is video.

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

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

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

623	3.4.2.  Capability Selection and Usage

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

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

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

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

657	3.4.3.  Capability Algebra

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

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

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

668	   For example, if we have two Policies:

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

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

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

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

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

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

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

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

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

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

828	3.5.  Initial NSFs Capability Categories

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

836	3.5.1.  Network Security Capabilities

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

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

850	3.5.2.  Content Security Capabilities

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

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

866	3.5.3.  Attack Mitigation Capabilities

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

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

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

895	4.  Information Sub-Model for Network Security Capabilities

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

903	4.1.  Information Sub-Model for Network Security

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

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

924	       Figure 2. Network Security Information Sub-Model Overview

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

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

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

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

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

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

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

961	4.1.1.  Network Security Policy Rule Extensions

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

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

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

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

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

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

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

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

1043	4.1.2.  Network Security Policy Rule Operation

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

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

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

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

1103	4.1.3.  Network Security Event Sub-Model

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

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

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

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

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

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

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

1178	   Brief class descriptions are provided in Appendix B.

1180	4.1.4.  Network Security Condition Sub-Model

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

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

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

1246	   Brief class descriptions are provided in Appendix C.

1248	4.1.5.  Network Security Action Sub-Model

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

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

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

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

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

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

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

1313	   Brief class descriptions are provided in Appendix D.

1315	4.2.  Information Model for I2NSF Capabilities

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

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

1345	        Figure 7. I2NSF Security Capability High-Level Model

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

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

1357	4.3.  Information Model for Content Security Capabilities

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

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

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

1398	          Figure 8. Network Security Capability Information Model

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

1404	4.4.  Information Model for Attack Mitigation Capabilities

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

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

1442	        Figure 9. Attack Mitigation Capability Information Model

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

1448	5.  Security Considerations

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

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

1465	6.  IANA Considerations

1467	   TBD

1469	7.  Contributors

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

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

1482	8.  References

1484	8.1.  Normative References

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

1493	8.2.  Informative References

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

1542	Appendix A.  Network Security Capability Policy Rule Definitions

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

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

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

1562	A.1.  AuthenticationECAPolicyRule Class Definition

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

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

1590	            Figure 10.  Modeling Authentication Mechanisms

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

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

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

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

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

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

1638	A.2.  AuthorizationECAPolicyRuleClass Definition

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

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

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

1679	             Figure 11.  Modeling Authorization Mechanisms

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

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

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

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

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

1716	A.3.  AccountingECAPolicyRuleClass Definition

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

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

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

1758	              Figure 12.  Modeling Accounting Mechanisms

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

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

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

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

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

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

1794	A.4.  TrafficInspectionECAPolicyRuleClass Definition

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

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

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

1837	           Figure 13.  Modeling Traffic Inspection Mechanisms

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

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

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

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

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

1874	A.5.  ApplyProfileECAPolicyRuleClass Definition

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

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

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

1918	           Figure 14.  Modeling Profile ApplicationMechanisms

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

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

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

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

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

1951	A.6.  ApplySignatureECAPolicyRuleClass Definition

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

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

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

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

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

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

2012	         Figure 15.  Modeling Sginature Application Mechanisms

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

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

2030	Appendix B. Network Security Event Class Definitions

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

2035	B.1.  UserSecurityEvent Class Description

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

2044	   The UserSecurityEvent class defines the following attributes.

2046	B.1.1.  The usrSecEventContent Attribute

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

2056	B.1.2.  The usrSecEventFormat Attribute

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

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

2073	B.1.3.  The usrSecEventType Attribute

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

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

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

2095	B.2.  DeviceSecurityEvent Class Description

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

2105	   The DeviceSecurityEvent class defines the following attributes.

2107	B.2.1.  The devSecEventContent Attribute

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

2117	B.2.2.  The devSecEventFormat Attribute

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

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

2130	B.2.3.  The devSecEventType Attribute

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

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

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

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

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

2155	B.2.5.  The devSecEventTypeSeverity Attribute

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

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

2169	B.3.  SystemSecurityEvent Class Description

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

2181	   The SystemSecurityEvent class defines the following attributes.

2183	B.3.1.  The sysSecEventContent Attribute

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

2193	B.3.2.  The sysSecEventFormat Attribute

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

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

2206	B.3.3.  The sysSecEventType Attribute

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

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

2220	B.4.  TimeSecurityEvent Class Description

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

2233	   The TimeSecurityEvent class defines the following attributes.

2235	B.4.1.  The timeSecEventPeriodBegin Attribute

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

2241	B.4.2.  The timeSecEventPeriodEnd Attribute

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

2249	B.4.3.  The timeSecEventTimeZone Attribute

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

2254	Appendix C. Network Security Condition Class Definitions

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

2259	C.1.  PacketSecurityCondition

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

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

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

2289	C.1.1.  PacketSecurityMACCondition

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

2296	C.1.1.1.  The pktSecCondMACDest Attribute

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

2301	C.1.1.2.  The pktSecCondMACSrc Attribute

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

2306	C.1.1.3.  The pktSecCondMAC8021Q Attribute

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

2312	C.1.1.4.  The pktSecCondMACEtherType Attribute

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

2319	C.1.1.5.  The pktSecCondMACTCI Attribute

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

2325	C.1.2.  PacketSecurityIPv4Condition

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

2332	C.1.2.1.  The pktSecCondIPv4SrcAddr Attribute

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

2337	C.1.2.2.  The pktSecCondIPv4DestAddr Attribute

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

2342	C.1.2.3.  The pktSecCondIPv4ProtocolUsed Attribute

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

2347	C.1.2.4.  The pktSecCondIPv4DSCP Attribute

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

2352	C.1.2.5.  The pktSecCondIPv4ECN Attribute

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

2357	C.1.2.6.  The pktSecCondIPv4TotalLength Attribute

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

2362	C.1.2.7.  The pktSecCondIPv4TTL Attribute

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

2367	C.1.3.  PacketSecurityIPv6Condition

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

2374	C.1.3.1.  The pktSecCondIPv6SrcAddr Attribute

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

2379	C.1.3.2.  The pktSecCondIPv6DestAddr Attribute

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

2384	C.1.3.3.  The pktSecCondIPv6DSCP Attribute

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

2390	C.1.3.4.  The pktSecCondIPv6ECN Attribute

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

2396	C.1.3.5.  The pktSecCondIPv6FlowLabel Attribute

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

2403	C.1.3.6.  The pktSecCondIPv6PayloadLength Attribute

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

2409	C.1.3.7.  The pktSecCondIPv6NextHeader Attribute

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

2414	C.1.3.8.  The pktSecCondIPv6HopLimit Attribute

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

2419	C.1.4.  PacketSecurityTCPCondition

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

2426	C.1.4.1.  The pktSecCondTPCSrcPort Attribute

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

2431	C.1.4.2.  The pktSecCondTPCDestPort Attribute

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

2436	C.1.4.3.  The pktSecCondTCPSeqNum Attribute

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

2441	C.1.4.4.  The pktSecCondTCPFlags Attribute

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

2446	C.1.5.  PacketSecurityUDPCondition

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

2453	C.1.5.1.1.  The pktSecCondUDPSrcPort Attribute

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

2458	C.1.5.1.2.  The pktSecCondUDPDestPort Attribute

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

2463	C.1.5.1.3.  The pktSecCondUDPLength Attribute

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

2468	C.2.  PacketPayloadSecurityCondition

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

2475	C.3.  TargetSecurityCondition

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

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

2499	C.4.  UserSecurityCondition

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

2509	C.5.  SecurityContextCondition

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

2518	C.6.  GenericContextSecurityCondition

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

2526	Appendix D. Network Security Action Class Definitions

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

2531	D.1.  IngressAction

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

2537	D.2.  EgressAction

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

2543	D.3.  ApplyProfileAction

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

2549	Appendix E. Geometric Model

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

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

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

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

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

2590	      S=S1 X S2 X ...  X Sm

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

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

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

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

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

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

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

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

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

2652	      RS: Pow(R) -> A

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

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

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

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

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

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

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

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

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

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

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

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

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