idnits 2.17.1 draft-xibassnez-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2017) is 2601 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 '' and '' 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 (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-11 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-04 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 == Outdated reference: A later version (-07) exists of draft-zhang-i2nsf-info-model-monitoring-02 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 12, 2017 C. Basile 5 PoliTO 6 D. Lopez 7 TID 8 March 12, 2017 10 Information Model of NSFs Capabilities 11 draft-xibassnez-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 September 12, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided 54 without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ................................................... 4 59 2. Conventions used in this document .............................. 5 60 2.1. Acronyms .................................................. 5 61 3. Capability Information Model Design ............................ 6 62 3.1. Design Principles and ECA Policy Model Overview ........... 6 63 3.2. Relation with the External Information Model .............. 8 64 3.3. I2NSF Capability Information Model Theory of Operation ... 10 65 3.3.1. I2NSF Condition Clause Operator Types ............... 11 66 3.3.2 Capability Selection and Usage ...................... 12 67 3.3.3. Capability Algebra ................................. 13 68 3.4. Initial NSFs Capability Categories ....................... 16 69 3.4.1. Network Security Capabilities ....................... 16 70 3.4.2. Content Security Capabilities ....................... 17 71 3.4.3. Attack Mitigation Capabilities ...................... 17 72 4. Information Sub-Model for Network Security Capabilities ....... 18 73 4.1. Information Sub-Model for Network Security ............... 18 74 4.1.1. Network Security Policy Rule Extensions ............. 19 75 4.1.2. Network Security Policy Rule Operation .............. 20 76 4.1.3. Network Security Event Sub-Model .................... 22 77 4.1.4. Network Security Condition Sub-Model ................ 23 78 4.1.5. Network Security Action Sub-Model ................... 25 79 4.2. Information Model for I2NSF Capabilities ................. 26 80 4.3. Information Model for Content Security Capabilities ...... 27 81 4.4. Information Model for Attack Mitigation Capabilities ..... 28 82 5. Security Considerations ....................................... 29 83 6. IANA Considerations ........................................... 29 84 7. Contributors .................................................. 29 85 8. References .................................................... 29 86 8.1. Normative References ..................................... 29 87 8.2. Informative References ................................... 30 88 Appendix A. Network Security Capability Policy Rule Definitions .. 32 89 A.1. AuthenticationECAPolicyRule Class Definition ............. 32 90 A.2. AuthorizationECAPolicyRuleClass Definition ............... 34 91 A.3. AccountingECAPolicyRuleClass Definition .................. 35 92 A.4. TrafficInspectionECAPolicyRuleClass Definition ........... 37 93 A.5. ApplyProfileECAPolicyRuleClass Definition ................ 38 94 A.6. ApplySignatureECAPolicyRuleClass Definition .............. 40 95 Appendix B. Network Security Event Class Definitions ............. 42 96 B.1. UserSecurityEvent Class Description ...................... 42 97 B.1.1. The usrSecEventContent Attribute .................... 42 98 B.1.2. The usrSecEventFormat Attribute ..................... 42 99 B.1.3. The usrSecEventType Attribute ....................... 42 100 B.2. DeviceSecurityEvent Class Description .................... 43 101 B.2.1. The devSecEventContent Attribute .................... 43 102 B.2.2. The devSecEventFormat Attribute ..................... 43 103 B.2.3. The devSecEventType Attribute ....................... 44 104 B.2.4. The devSecEventTypeInfo[0..n] Attribute ............. 44 105 B.2.5. The devSecEventTypeSeverity Attribute ............... 44 107 Table of Contents (continued) 109 B.3. SystemSecurityEvent Class Description .................... 44 110 B.3.1. The sysSecEventContent Attribute .................... 45 111 B.3.2. The sysSecEventFormat Attribute ..................... 45 112 B.3.3. The sysSecEventType Attribute ....................... 45 113 B.4. TimeSecurityEvent Class Description ...................... 45 114 B.4.1. The timeSecEventPeriodBegin Attribute ............... 46 115 B.4.2. The timeSecEventPeriodEnd Attribute ................. 46 116 B.4.3. The timeSecEventTimeZone Attribute .................. 46 117 Appendix C. Network Security Condition Class Definitions ......... 47 118 C.1. PacketSecurityCondition .................................. 47 119 C.1.1. PacketSecurityMACCondition .......................... 47 120 C.1.1.1. The pktSecCondMACDest Attribute ................ 47 121 C.1.1.2. The pktSecCondMACSrc Attribute ................. 47 122 C.1.1.3. The pktSecCondMAC8021Q Attribute ............... 48 123 C.1.1.4. The pktSecCondMACEtherType Attribute ........... 48 124 C.1.1.5. The pktSecCondMACTCI Attribute ................. 48 125 C.1.2. PacketSecurityIPv4Condition ......................... 48 126 C.1.2.1. The pktSecCondIPv4SrcAddr Attribute ............ 48 127 C.1.2.2. The pktSecCondIPv4DestAddr Attribute ........... 48 128 C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute ....... 48 129 C.1.2.4. The pktSecCondIPv4DSCP Attribute ............... 48 130 C.1.2.5. The pktSecCondIPv4ECN Attribute ................ 48 131 C.1.2.6. The pktSecCondIPv4TotalLength Attribute ........ 49 132 C.1.2.7. The pktSecCondIPv4TTL Attribute ................ 49 133 C.1.3. PacketSecurityIPv6Condition ......................... 49 134 C.1.3.1. The pktSecCondIPv6SrcAddr Attribute ............ 49 135 C.1.3.2. The pktSecCondIPv6DestAddr Attribute ........... 49 136 C.1.3.3. The pktSecCondIPv6DSCP Attribute ............... 49 137 C.1.3.4. The pktSecCondIPv6ECN Attribute ................ 49 138 C.1.3.5. The pktSecCondIPv6FlowLabel Attribute .......... 49 139 C.1.3.6. The pktSecCondIPv6PayloadLength Attribute ...... 49 140 C.1.3.7. The pktSecCondIPv6NextHeader Attribute ......... 50 141 C.1.3.8. The pktSecCondIPv6HopLimit Attribute ........... 50 142 C.1.4. PacketSecurityTCPCondition .......................... 50 143 C.1.4.1. The pktSecCondTCPSrcPort Attribute ............. 50 144 C.1.4.2. The pktSecCondTCPDestPort Attribute ............ 50 145 C.1.4.3. The pktSecCondTCPSeqNum Attribute .............. 50 146 C.1.4.4. The pktSecCondTCPFlags Attribute ............... 50 147 C.1.5. PacketSecurityUDPCondition ....................... 50 148 C.1.5.1.1. The pktSecCondUDPSrcPort Attribute ........ 50 149 C.1.5.1.2. The pktSecCondUDPDestPort Attribute ....... 51 150 C.1.5.1.3. The pktSecCondUDPLength Attribute ......... 51 151 C.2. PacketPayloadSecurityCondition ........................... 51 152 C.3. TargetSecurityCondition .................................. 51 153 C.4. UserSecurityCondition .................................... 51 154 C.5. SecurityContextCondition ................................. 52 155 C.6. GenericContextSecurityCondition .......................... 52 157 Table of Contents (continued) 159 Appendix D. Network Security Action Class Definitions ............. 53 160 D.1. IngressAction ............................................ 53 161 D.2. EgressAction ............................................. 53 162 D.3. ApplyProfileAction ....................................... 53 163 Appendix E. Geometric Model ...................................... 54 164 Authors' Addresses ............................................... 57 166 1. Introduction 168 The rapid development of virtualized systems requires advanced 169 security protection in various scenarios. Examples include network 170 devices in an enterprise network, User Equipment in a mobile network, 171 devices in the Internet of Things, or residential access users 172 [I-D.draft-ietf-i2nsf-problem-and-use-cases]. 174 NSFs produced by multiple security vendors provide various security 175 Capabilities to customers. Multiple NSFs can be combined together to 176 provide security services over the given network traffic, regardless 177 of whether the NSFs are implemented as physical or virtual functions. 179 Security Capabilities describe the set of Network Security Functions 180 (NSFs) 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 needed to refer to a specific product when designing the 189 network; rather, the functions characterized by their Capabilities 190 are considered. 192 According to [I-D.draft-ietf-i2nsf-framework], there are two types 193 of I2NSF interfaces available for security policy provisioning: 194 o Interface between I2NSF users and applications, and a security 195 controller (Consumer-Facing Interface): this is a service- 196 oriented interface that provides a communication channel 197 between consumers of NSF data and services and the network 198 operator's security controller. This enables security 199 information to be exchanged between various applications (e.g., 200 OpenStack, or various BSS/OSS components) and the security 201 controller. The design goal of the Consumer-Facing Interface 202 is to decouple the specification of security services of 203 consumers requesting such services from their implementation. 205 o Interface between NSFs (e.g., firewall, intrusion prevention, 206 or anti-virus) and the security controller (NSF-Facing 207 Interface): The NSF-Facing Interface is used to decouple the 208 security management scheme from the set of NSFs and their 209 various implementations for this scheme, and is independent 210 of how the NSFs are implemented (e.g., run in Virtual 211 Machines or physical appliances). According to the definition 212 in [I-D.draft-ietf-i2nsf-framework], the NSF-Facing Interface 213 information model is made up of three sub-models: Capability, 214 Registration and Monitoring. This document defines the 215 information model design for the first two parts (Capability 216 and Registration); the Monitoring part information model is 217 discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring]. 219 This document is organized as follows. Section 2 defines conventions 220 and acronyms used. Section 3 discusses the design principles for the 221 I2NSF Capability information model and related ECA model. Section 4 222 provides detailed information model design of I2NSF network security 223 Capability. 225 2. Conventions used in this document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC-2119 [RFC2119]. 231 This document uses terminology defined in 232 [I-D.draft-ietf-i2nsf-terminology] for security related and I2NSF 233 scoped terminology. 235 2.1. Acronyms 237 AAA: Access control, Authorization, Authentication 238 ACL: Access Control List 239 (D)DoD: (Distributed) Denial of Service (attack) 240 ECA: Event-Condition-Action 241 FMR: First Matching Rule (resolution strategy) 242 FW: Firewall 243 GNSF: Generic Network Security Function 244 HTTP: HyperText Transfer Protocol 245 I2NSF: Interface to Network Security Functions 246 IPS: Intrusion Prevention System 247 LMR: Last Matching Rule (resolution strategy) 248 MIME: Multipurpose Internet Mail Extensions 249 NAT: Network Address Translation 250 NSF: Network Security Function 251 RPC: Remote Procedure Call 252 SMA: String Matching Algorithm 253 URL: Uniform Resource Locator 254 VPN: Virtual Private Network 256 3. Capability Information Model Design 258 The starting point of the design of the Capability information model 259 is the categorization of types of security functions. For instance, 260 experts agree on what is meant by the terms "NAT", "filtering", and 261 "VPN concentrator". Network security experts unequivocally refer to 262 "packet filters" as stateless devices able to allow or deny packet 263 forwarding based on various conditions (e.g., source and destination 264 IP addresses, source and destination ports, and IP protocol type 265 fields) [Alshaer]. 267 However, more information is required in case of other devices, like 268 stateful firewalls or application layer filters. These devices 269 filter packets or communications, but there are differences in the 270 packets and communications that they can categorize and the states 271 they maintain. Analogous considerations can be applied for channel 272 protection protocols, where we all understand that they will protect 273 packets by means of symmetric algorithms whose keys could have been 274 negotiated with asymmetric cryptography, but they may work at 275 different layers and support different algorithms and protocols. To 276 ensure protection, these protocols apply integrity, optionally 277 confidentiality, anti-reply protections, and authenticate peers. 279 3.1. Design Principles and ECA Policy Model Overview 281 This document defines a model of security Capabilities that provides 282 the foundation for automatic management of NSFs. This includes 283 enabling the security controller to properly identify and manage 284 NSFs, and allow NSFs to properly declare their functionality, so 285 that they can be used in the correct way. 287 Some basic design principles for security Capabilities and the 288 systems that have to manage them are: 290 o Independence: each security Capability should be an independent 291 function, with minimum overlap or dependency on other 292 Capabilities. This enables each security Capability to be 293 utilized and assembled together freely. More importantly, 294 changes to one Capability will not affect other Capabilities. 295 This follows the Single Responsibility Principle 296 [Martin] [OODSRP]. 297 o Abstraction: each Capability should be defined in a vendor- 298 independent manner, and associated to a well-known interface 299 to provide a standardized ability to describe and report its 300 processing results. This facilitates multi-vendor 301 interoperability. 302 o Automation: the system must have the ability to auto-discover, 303 auto-negotiate, and auto-update its security Capabilities 304 (i.e., without human intervention). These features are 305 especially useful for the management of a large number of 306 NSFs. They are essential to add smart services (e.g., analysis, 307 refinement, Capability reasoning, and optimization) for the 308 security scheme employed. These features are supported by many 309 design patterns, including the Observer Pattern [OODOP], the 310 Mediator Pattern [OODMP], and a set of Message Exchange 311 Patterns [Hohpe]. 312 o Scalability: the management system must have the Capability to 313 scale up/down or scale in/out. Thus, it can meet various 314 performancerequirements derived from changeable network traffic 315 or service requests. In addition, security Capabilities that are 316 affected by scalability changes must support reporting statistics 317 to the security controller to assist its decision on whether it 318 needs to invoke scaling or not. However, this requirement is for 319 information only, and is beyond the scope of this document. 321 Based on the above principles, a set of abstract and vendor-neutral 322 Capabilities with standard interfaces is defined. This provides a 323 Capability model that enables a set of NSFs that are required at a 324 given time to be selected, as well as the unambiguous definition of 325 the security offered by the set of NSFs used. The security 326 controller can compare the requirements of users and applications to 327 the set of Capabilities that are currently available in order to 328 choose which NSFs are needed to meet those requirements. Note that 329 this choice is independent of vendor, and instead relies specifically 330 on the Capabilities (i.e., the description) of the functions 331 provided. The security controller may also be able to customize the 332 functionality of selected NSFs. 334 Furthermore, when an unknown threat (e.g., zero-day exploits and 335 unknown malware) is reported by a NSF, new Capabilities may be 336 created, and/or existing Capabilities may be updated (e.g., by 337 updating its signature and algorithm). This results in enhancing 338 existing NSFs (and/or creating new NSFs) to address the new threats. 339 New Capabilities may be sent to and stored in a centralized 340 repository, or stored separately in a vendor's local repository. 341 In either case, a standard interface facilitates the update process. 343 Note that most systems cannot dynamically create a new Capability 344 without human interaction. This is an area for further study. 346 In defining the Capabilities of a NSF, the "Event-Condition-Action" 347 (ECA) policy model in [I-D.draft-ietf-i2nsf-framework] is used as 348 the basis for the design; definitions of all I2NSF policy-related 349 terms are also defined in [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. 356 Examples of an I2NSF Event include time and user actions (e.g., 357 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 aspects 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 The above ECA policy model is very general and easily extensible, 374 and can avoid potential constraints that could limit the 375 implementation of generic security Capabilities. 377 3.2. Relation with the External Information Model 379 Note: the symbology used from this point forward is taken from 380 section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model]. 382 The I2NSF NSF-Facing Interface is in charge of selecting and 383 managing the NSFs using their Capabilities. This is done using 384 the following approach: 386 1) Each NSF registers its Capabilities with the management system 387 when it "joins", and hence makes its Capabilities available to 388 the management system; 389 2) The security controller selects the set of Capabilities 390 required to meet the needs of the security service from all 391 available NSFs that it manages; 392 3) The security controller uses the Capability information model 393 to match chosen Capabilities to NSFs, independent of vendor; 394 4) The security controller takes the above information and 395 creates or uses one or more data models from the Capability 396 information model to manage the NSFs; 397 5) Control and monitoring can then begin. 399 This assumes that an external information model is used to define 400 the concept of an ECA Policy Rule and its components (e.g., Event, 401 Condition, and Action objects). This enables I2NSF Policy Rules 402 [I-D.draft-ietf-i2nsf-terminology] to be subclassed from an external 403 information model. 405 Capabilities are defined as classes (e.g., a set of objects that 406 exhibit a common set of characteristics and behavior 407 [I-D.draft-ietf-supa-generic-policy-info-model]. 409 Each Capability is made up of at least one model element (e.g., 410 attribute, method, or relationship) that differentiates it from all 411 other objects in the system. Capabilities are, generically, a type 412 of metadata; hence, it is also assumed that an external information 413 model is used to define metadata (preferably, in the form of a class 414 hierarchy). Therefore, it is assumed that Capabilities are subclassed 415 from an external metadata model. 417 The Capability sub-model is used for advertising, creating, 418 selecting, and managing a set of specific security Capabilities 419 independent of the type and vendor of device that contains the NSF. 420 That is, the user of the NSF-Facing Interface does not care whether 421 the NSF is virtualized or hosted in a physical device, who the 422 vendor of the NSF is, and which set of entities the NSF is 423 communicating with (e.g., a firewall or an IPS). Instead, the user 424 only cares about the set of Capabilities that the NSF has, such as 425 packet filtering or deep packet inspection. The overall structure 426 is illustrated in the figure below: 428 +-------------------------+ 0..n 0..n +---------------+ 429 | |/ \ \| External | 430 | External ECA Info Model + A ----------------+ Metadata | 431 | |\ / Aggregates /| Info Model | 432 +-----------+------------+ Metadata +-------+-------+ 433 | / \ 434 | | 435 / \ | 436 Subclasses derived for I2NSF | 437 +-----+------+ 438 | Capability | 439 | Sub-Model | 440 +------------+ 442 Figure 1. The Overall I2NSF Information Model Design 444 This draft defines a set of extensions to a generic, external, ECA 445 Policy Model to represent various NSF ECA Security Policy Rules. It 446 also defines the Capability Sub-Model. Finally, it places 447 requirements on what type of extensions are required to the generic, 448 external, ECA information model and metadata models, in order to 449 manage the lifecycle of I2NSF Capabilities. 451 Both of the external models shown in Figure 1 could, but do not have 452 to, be based on the SUPA information model 453 [I-D.draft-ietf-supa-generic-policy-info-model]. Note that classes in 454 the Capability Sub-Model will inherit the AggregatesMetadata 455 aggregation from the External Metadata Information Model. 457 The external ECA Information Model supplies at least a set of objects 458 that represent a generic ECA Policy Rule, and a set of objects that 459 represent Events, Conditions, and Actions that can be aggregated by 460 the generic ECA Policy Rule. This enables I2NSF to reuse this 461 generic model for different purposes, as well as specialize it (i.e., 462 create new model objects) to represent I2NSF-specific concepts. 464 It is assumed that the external ECA Information Model has the 465 ability to aggregate metadata. Capabilities are then sub-classed 466 from an appropriate class in the external Metadata Information Model; 467 this enables the ECA objects to use the existing aggregation between 468 them and Metadata to add Metadata to appropriate ECA objects. 470 Detailed descriptions of each portion of the information model are 471 given in the following sections. 473 3.3. I2NSF Capability Information Model: Theory of Operation 475 Capabilities are typically used to represent NSF functions that can 476 be invoked. Capabilities are objects, and hence, can be used in the 477 event, condition, and/or action clauses of an I2NSF ECA Policy Rule. 478 The I2NSF Capability information model refines a predefined metadata 479 model; the application of I2NSF Capabilities is done by refining a 480 predefined ECA Policy Rule information model that defines how to 481 use, manage, or otherwise manipulate a set of Capabilities. In this 482 approach, an I2NSF Policy Rule is a container that is made up of 483 three clauses: an event clause, a condition clause, and an action 484 clause. When the I2NSF policy engine receives a set of events, it 485 matches those events to events in active ECA Policy Rules. If the 486 event matches, then this triggers the evaluation of the condition 487 clause of the matched I2NSF Policy Rule. The condition clause is 488 then evaluated; if it matches, then the set of actions in the 489 matched I2NSF Policy Rule MAY be executed. 491 This document defines additional important extensions to both the 492 external ECA Policy Rule model and the external Metadata model that 493 are used by the I2NSF Information Model; examples include 494 resolution strategy, external data, and default action. All these 495 extensions come from the geometric model defined in [Bas12]. A more 496 detailed description is provided in Appendix E; a summary of the 497 important points follows. 499 Formally, given a set of actions in an I2NSF Policy Rule, the 500 resolution strategy maps all the possible subsets of actions to an 501 outcome. In other words, the resolution strategy is included in the 502 I2NSF Policy Rule to decide how to evaluate all the actions in a 503 particular I2NSF Policy Rule. This is then extended to include all 504 possible I2NSF Policy Rules that can be applied in a particular 505 scenario. Hence, the final action set from all I2NSF Policy Rules 506 is deduced. 508 Some concrete examples of resolution strategy are the First Matching 509 Rule (FMR) or Last Matching Rule (LMR) resolution strategies. When 510 no rule matches a packet, the NSFs may select a default action, if 511 they support one. 513 Resolution strategies may use, besides intrinsic rule data (i.e., 514 event, condition, and action clauses), "external data" associated to 515 each rule, such as priority, identity of the creator, and creation 516 time. Two examples of this are attaching metadata to the policy 517 action and/or policy rule, and associating the policy rule with 518 another class to convey such information. 520 3.3.1. I2NSF Condition Clause Operator Types 522 After having analyzed the literature and some existing NSFs, the 523 types of selectors are categorized as exact-match, range-based, 524 regex-based, and custom-match [Bas15][Lunt]. 526 Exact-match selectors are (unstructured) sets: elements can only be 527 checked for equality, as no order is defined on them. As an example, 528 the protocol type field of the IP header is an unordered set of 529 integer values associated to protocols. The assigned protocol 530 numbers are maintained by the IANA (http://www.iana.org/assignments/ 531 protocol-numbers/protocol-numbers.xhtml). 533 In this selector, it is only meaningful to specify condition clauses 534 that use either the "equals" or "not equals" operators: 536 proto = tcp, udp (protocol type field equals to TCP or UDP) 537 proto != tcp (protocol type field different from TCP) 539 No other operators are allowed on exact-match selectors. For example, 540 the following is an invalid condition clause, even if protocol types 541 map to integers: 543 proto < 62 (invalid condition) 545 Range-based selectors are ordered sets where it is possible to 546 naturally specify ranges as they can be easily mapped to integers. 547 As an example, the ports in the TCP protocol may be represented with 548 a range-based selector (e.g., 1024-65535). As another example, the 549 following are examples of valid condition clauses: 551 source_port = 80 552 source_port < 1024 553 source_port < 30000 && source_port >= 1024 555 We include, in range-based selectors, the category of selectors that 556 have been defined by Al-Shaer et al. as "prefix-match" [Alshaer]. 557 These selectors allow the specification of ranges of values by means 558 of simple regular expressions. The typical case is the IP address 559 selector (e.g., 10.10.1.*). 561 There is no need to distinguish between prefix match and range-based 562 selectors; for example, the address range "10.10.1.*" maps to 563 "[10.10.1.0,10.10.1.255]". 565 Another category of selector types includes those based on regular 566 expressions. This selector type is used frequently at the application 567 layer, where data are often represented as strings of text. The 568 regex-based selector type also includes string-based selectors, where 569 matching is evaluated using string matching algorithms (SMA) 570 [Cormen]. Indeed, for our purposes, string matching can be mapped to 571 regular expressions, even if in practice SMA are much faster. For 572 instance, Squid (http://www.squid-cache.org/), a popular Web caching 573 proxy that offers various access control Capabilities, allows the 574 definition of conditions on URLs that can be evaluated with SMA 575 (e.g., dstdomain) or regex matching (e.g., dstdom_regex). 577 As an example, the condition clause: 579 "URL = *.website.*" 581 matches all the URLs that contain a subdomain named website and the 582 ones whose path contain the string ".website.". As another example, 583 the condition clause: 585 "MIME_type = video/*" 587 matches all MIME objects whose type is video. 589 Finally, the idea of a custom check selector is introduced. For 590 instance, malware analysis can look for specific patterns, and 591 returns a Boolean value if the pattern is found or not. 593 In order to be properly used by high-level policy-based processing 594 systems (such as reasoning systems and policy translation systems), 595 these custom check selectors can be modeled as black-boxes (i.e., a 596 function that has a defined set of inputs and outputs for a 597 particular state), which provide an associated Boolean output. 599 More examples of custom check selectors will be presented in the 600 next versions of the draft. Some examples are already present in 601 Section 6. 603 3.3.2. Capability Selection and Usage 605 Capability selection and usage are based on the set of security 606 traffic classification and action features that an NSF provides; 607 these are defined by the Capability model. If the NSF has the 608 classification features needed to identify the packets/flows 609 required by a policy, and can enforce the needed actions, then 610 that particular NSF is capable of enforcing the policy. 612 NSFs may also have specific characteristics that automatic processes 613 or administrators need to know when they have to generate 614 configurations, like the available resolution strategies and the 615 possibility to set default actions. 617 The Capability information model can be used for two purposes: 618 describing the features provided by generic security functions, and 619 describing the features provided by specific products. The term 620 Generic Network Security Function (GNSF) refers to the classes of 621 security functions that are known by a particular system. The idea 622 is to have generic components whose behavior is well understood, so 623 that the generic component can be used even if it has some vendor- 624 specific functions. These generic functions represent a point of 625 interoperability, and can be provided by any product that offers the 626 required Capabilities. GNSF examples include packet filter, URL 627 filter, HTTP filter, VPN gateway, anti-virus, anti-malware, content 628 filter, monitoring, and anonymity proxy; these will be described 629 later in a revision of this draft as well as in an upcoming data 630 model contribution. 632 The next section will introduce the algebra to define the 633 information model of Capability registration. This associates 634 NSFs to Capabilities, and checks whether a NSF has the 635 Capabilities needed to enforce policies. 637 3.3.3. Capability Algebra 639 We introduce a Capability Algebra to ensure that the actions of 640 different policy rules do not conflict with each other. 642 Formally, two I2NSF Policy Actions conflict with each other if: 644 o the event clauses of each evaluate to TRUE 645 o the condition clauses of each evaluate to TRUE 646 o the action clauses affect the same object in different ways 648 For example, if we have two Policies: 650 P1: During 8am-6pm, if traffic is external, then run through FW 651 P2: During 7am-8pm, conduct anti-malware investigation 653 There is no conflict between P1 and P2, since the actions are 654 different. However, consider these two policies: 656 P3: During 8am-6pm, John gets GoldService 657 P4: During 10am-4pm, FTP from all users gets BronzeService 659 P3 and P4 are now in conflict, because between the hours of 10am and 660 4pm, the actions of P3 and P4 are different and apply to the same 661 user (i.e., John). 663 Let us define the concept of a "matched" policy rule as one in which 664 its event and condition clauses both evaluate to true. This enables 665 the actions in this policy rule to be evaluated. Then, the 666 information model is defined by a 5-tuple {Ac, Cc, Ec, RSc, Dc}, 667 where: 669 o Ac is the set of Actions currently available from the NSF; 670 o Cc is the set of Conditions currently available from the NSF; 671 o Ec is the set of Events the NSF is able to respond to. 672 Therefore, the event clause of an I2NSF ECA Policy Rule that is 673 written for an NSF will only allow a set of designated events 674 in Ec. For compatibility purposes, we will assume that if Ec={} 675 (that is, Ec is empty), the NSF only accepts CA policies. 676 o RSc is the set of Resolution Strategies that can be used to 677 specify how to resolve conflicts that occur between the actions 678 of the same or different policy rules that are matched and 679 contained in this particular NSF; 680 o Dc defines the notion of a Default action that can be used to 681 specify a predefined action when no other alternative action 682 was matched by the currently executing I2NSF Policy Rule. An 683 analogy is the use of a default statement in a C switch 684 statement. This field of the Capability algebra can take the 685 following values: 686 - An explicit action (that has been predefined; typically, 687 this means that it is fixed and not configurable), denoted 688 as Dc ={a}. In this case, the NSF will always use the 689 action as as the default action. 690 - A set of explicit actions, denoted Dc={a1,a2, ...}; 691 typically, this means that any **one** action can be used 692 as the default action. This enables the policy writer to 693 choose one of a predefined set of actions {a1, a2, ...} to 694 serve as the default action. 695 - A fully configurable default action, denoted as Dc={F}. 696 Here, F is a dummy symbol (i.e., a placeholder value) that 697 can be used to indicate that the default action can be 698 freely selected by the policy editor from the actions Ac 699 available at the NSF. In other words, one of the actions 700 Ac may be selected by the policy writer to act as the 701 default action. 702 - No default action, denoted as Dc={}, for cases where the 703 NSF does not allow the explicit selection of a default 704 action. 706 *** Note to WG: please review the following paragraphs 707 * 708 * Interesting Capability concepts that could be considered for a next 709 * version of the Capability model and algebra include: 710 * 711 * o Event clause representation (e.g., conjunctive vs. disjunctive 712 * normal form for Boolean clauses) 713 * o Event clause evaluation function, which would enable more 714 * complex expressions than simple Boolean expressions to be used 715 * 716 * 717 * o Condition clause representation (e.g., conjunctive vs. 718 * disjunctive normal form for Boolean clauses) 719 * o Condition clause evaluation function, which would enable more 720 * complex expressions than simple Boolean expressions to be used 721 * o Action clause evaluation strategies (e.g., execute first 722 * action only, execute last action only, execute all actions, 723 * execute all actions until an action fails) 724 * o The use of metadata, which can be associated to both an I2NSF 725 * Policy Rule as well as objects contained in the I2NSF Policy 726 * Rule (e.g., an action), that describe the object and/or 727 * prescribe behavior. Descriptive examples include adding 728 * authorship information and defining a time period when an NSF 729 * can be used to be defined; prescriptive examples include 730 * defining rule priorities and/or ordering. 731 * 732 * Given two sets of Capabilities, denoted as 733 * 734 * cap1=(Ac1,Cc1,Ec1,RSc1,Dc1) and 735 * cap2=(Ac2,Cc2,Ec2,RSc2,Dc2), 736 * 737 * two set operations are defined for manipulating Capabilities: 738 * 739 * o Capability addition: 740 * cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U Ec2, RSc1, Dc1} 741 * o Capability subtraction: 742 * cap1-cap2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 \ Ec2, RSc1, Dc1} 743 * 744 * In the above formulae, "U" is the set union operator and "\" is the 745 * set difference operator. 746 * 747 * The addition and subtraction of Capabilities are defined as the 748 * addition (set union) and subtraction (set difference) of both the 749 * Capabilities and their associated actions. Note that **only** the 750 * leftmost (in this case, the first matched policy rule) Resolution 751 * Strategy and Default Action are used. 752 * 753 * Note: actions, events, and conditions are **symmetric**. This means 754 * that when two matched policy rules are merged, the resultant actions 755 * and Capabilities are defined as the union of each individual matched 756 * policy rule. However, both resolution strategies and default actions 757 * are **asymmetric** (meaning that in general, they can **not** be 758 * combined, as one has to be chosen). In order to simplify this, we 759 * have chosen that the **leftmost** resolution strategy and the 760 * **leftmost** default action are chosen. This enables the developer 761 * to view the leftmost matched rule as the "base" to which other 762 * elements are added. 763 * 764 * As an example, assume that a packet filter Capability, Cpf, is 765 * defined. Further, assume that a second Capability, called Ctime, 766 * exists, and that it defines time-based conditions. Suppose we need 767 * to construct a new generic packet filter, Cpfgen, that adds 768 * time-based conditions to Cpf. 769 * 770 * 771 * Conceptually, this is simply the addition of the Cpf and Ctime 772 * Capabilities, as follows: 773 * Apf = {Allow, Deny} 774 * Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} 775 * Epf = {} 776 * RSpf = {FMR} 777 * Dpf = {A1} 778 * 779 * Atime = {Allow, Deny, Log} 780 * Ctime = {timestart, timeend, datestart, datestop} 781 * Etime = {} 782 * RStime = {LMR} 783 * Dtime = {A2} 784 * 785 * Then, Cpfgen is defined as: 786 * Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf, Dpf} 787 * = {Allow, Deny, Log}, 788 * {{IPsrc, IPdst, Psrc, Pdst, protType} U 789 * {timestart, timeend, datestart, datestop}}, 790 * {}, 791 * {FMR}, 792 * {A1} 793 * 794 * In other words, Cpfgen provides three actions (Allow, Deny, Log), 795 * filters traffic based on a 5-tuple that is logically ANDed with a 796 * time period, and uses FMR; it provides A1 as a default action, and 797 * it does not react to events. 798 * 799 * Note: We are investigating, for a next revision of this draft, the 800 * possibility to add further operations that do not follow the 801 * symmetric vs. asymmetric properties presented in the previous note. 802 * We are looking for use cases that may justify the complexity added 803 * by the availability of more Capability manipulation operations. 804 * 805 *** End Note to WG 807 3.4. Initial NSFs Capability Categories 809 The following subsections define three common categories of 810 Capabilities: network security, content security, and attack 811 mitigation. Future versions of this document may expand both the 812 number of categories as well as the types of Capabilities within a 813 given category. 815 3.4.1. Network Security Capabilities 817 Network security is a category that describes the inspecting and 818 processing of network traffic based on the use of pre-defined 819 security policies. 821 The inspecting portion may be thought of as a packet-processing 822 engine that inspects packets traversing networks, either directly or 823 in the context of flows with which the packet is associated. From 824 the perspective of packet-processing, implementations differ in the 825 depths of packet headers and/or payloads they can inspect, the 826 various flow and context states they can maintain, and the actions 827 that can be applied to the packets or flows. 829 3.4.2. Content Security Capabilities 831 Content security is another category of security Capabilities 832 applied to the application layer. Through analyzing traffic contents 833 carried in, for example, the application layer, Capabilities can be 834 used to identify various security functions that are required, such 835 as defending against intrusion, inspecting for viruses, filtering 836 malicious URL or junk email, blocking illegal web access, or 837 preventing malicious data retrieval. 839 Generally, each type of threat in the content security category has 840 a set of unique characteristics, and requires handling using a set 841 of methods that are specific to that type of content. Thus, these 842 NSFs will be characterized by their own content- specific security 843 Capabilities. 845 3.4.3. Attack Mitigation Capabilities 847 This category of security Capabilities is used to detect and mitigate 848 various types of network attacks. Today's common network attacks can 849 be classified into the following sets: 851 o DDoS attacks: 852 - Network layer DDoS attacks: Examples include SYN flood, UDP 853 flood, ICMP flood, IP fragment flood, IPv6 Routing header 854 attack, and IPv6 duplicate address detection attack; 855 - Application layer DDoS attacks: Examples include HTTP flood, 856 https flood, cache-bypass HTTP floods, WordPress XML RPC 857 floods, and ssl DDoS. 858 o Single-packet attacks: 859 - Scanning and sniffing attacks: IP sweep, port scanning, etc. 860 - malformed packet attacks: Ping of Death, Teardrop, etc. 861 - special packet attacks: Oversized ICMP, Tracert, IP timestamp 862 option packets, etc. 864 Each type of network attack has its own network behaviors and 865 packet/flow characteristics. Therefore, each type of attack needs a 866 special security function, which is advertised as a set of 867 Capabilities, for detection and mitigation. The implementation and 868 management of this category of security Capabilities of attack 869 mitigation control is very similar to content security control. A 870 standard interface, through which the security controller can 871 choose and customize the given security Capabilities according to 872 specific requirements, is essential. 874 4. Information Sub-Model for Network Security Capabilities 876 The purpose of the Capability Information Sub-Model is to define the 877 concept of a Capability, and enable Capabilities to be aggregated to 878 appropriate objects. The following sections present the Network 879 Security, Content Security, and Attack Mitigation Capability 880 sub-models. 882 4.1. Information Sub-Model for Network Security 884 The purpose of the Network Security Information Sub-Model is to 885 define how network traffic is defined, and determine if one or more 886 network security features need to be applied to the traffic or not. 887 Its basic structure is shown in the following figure: 889 +---------------------+ 890 +---------------+ 1..n 1..n | | 891 | |/ \ \| A Common Superclass | 892 | ECAPolicyRule + A -------------+ for ECA Objects | 893 | |\ / /| | 894 +-------+-------+ +---------+-----------+ 895 / \ / \ 896 | | 897 | | 898 (subclasses to define Network (subclasses of Event, 899 Security ECA Policy Rules Condition, and Action Objects 900 with some extension, for Network Security) 901 such as InspectTraffic) 903 Figure 2. Network Security Information Sub-Model Overview 905 In the above figure, the ECAPolicyRule, along with the Event, 906 Condition, and Action Objects, are defined in the external ECA 907 Information Model. The Network Security Sub-Model extends all of 908 these objects in order to define security-specific ECA policy rules, 909 as well as extensions to the (generic) Events, Conditions, and 910 Action objects. 912 An I2NSF Policy Rule is a special type of Policy Rule that is in 913 event-condition-action (ECA) form. It consists of the Policy Rule, 914 components of a Policy Rule (e.g., events, conditions, actions, and 915 some extensions like resolution policy, default action and external 916 data), and optionally, metadata. It can be applied to both uni- and 917 bi-directional traffic across the NSF. 919 Each rule is triggered by one or more events. If the set of events 920 evaluates to true, then a set of conditions are evaluated and, if 921 true, enable a set of actions to be executed. This takes the 922 following conceptual form: 924 IF is TRUE 925 IF is TRUE 926 THEN execute 927 END-IF 928 END-IF 930 In the above example, the Event, Condition, and Action portions of a 931 Policy Rule are all **Boolean Clauses**. 933 Note that Metadata, such as Capabilities, can be aggregated by I2NSF 934 ECA Policy Rules. 936 4.1.1. Network Security Policy Rule Extensions 938 Figure 3 shows an example of more detailed design of the ECA Policy 939 Rule subclasses that are contained in the Network Security 940 Information Sub-Model, which just illustrates how more specific 941 Network Security Policies are inherited and extended from the 942 SecurityECAPolicyRule class. Any new kinds of specific Network 943 Security Policy can be created by following the same pattern of 944 class design as below. 946 +---------------+ 947 | External | 948 | ECAPolicyRule | 949 +-------+-------+ 950 / \ 951 | 952 | 953 +------------+----------+ 954 | SecurityECAPolicyRule | 955 +------------+----------+ 956 | 957 | 958 +----+-----+--------+-----+----+---------+---------+--- ... 959 | | | | | | 960 | | | | | | 961 +------+-------+ | +-----+-------+ | +------+------+ | 962 |Authentication| | | Accounting | | |ApplyProfile | | 963 |ECAPolicyRule | | |ECAPolicyRule| | |ECAPolicyRule| | 964 +--------------+ | +-------------+ | +-------------+ | 965 | | | 966 +------+------+ +------+------+ +--------------+ 967 |Authorization| | Traffic | |ApplySignature| 968 |ECAPolicyRule| | Inspection | |ECAPolicyRule | 969 +-------------+ |ECAPolicyRule| +--------------+ 970 +-------------+ 972 Figure 3. Network Security Info Sub-Model ECAPolicyRule Extensions 973 The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule 974 hierarchy. It inherits from the (external) generic ECA Policy Rule, 975 and represents the specialization of this generic ECA Policy Rule to 976 add security-specific ECA Policy Rules. The SecurityECAPolicyRule 977 contains all of the attributes, methods, and relationships defined in 978 its superclass, and adds additional concepts that are required for 979 Network Security (these will be defined in the next version of this 980 draft). The six SecurityECAPolicyRule subclasses extend the 981 SecurityECAPolicyRule class to represent six different types of 982 Network Security ECA Policy Rules. It is assumed that the (external) 983 generic ECAPolicyRule class defines basic information in the form of 984 attributes, such as an unique object ID, as well as a description 985 and other necessary information. 987 *** Note to WG 988 * 989 * The design in Figure 3 represents the simplest conceptual design 990 * for network security. An alternative model would be to use a 991 * software pattern (e.g., the Decorator pattern); this would result 992 * in the SecurityECAPolicyRule class being "wrapped" by one or more 993 * of the six subclasses shown in Figure 3. The advantage of such a 994 * pattern is to reduce the number of active objects at runtime, as 995 * well as offer the ability to combine multiple actions of different 996 * policy rules (e.g., inspect traffic and then apply a filter) into 997 * one. The disadvantage is that it is a more complex software design. 998 * The design team is requesting feedback from the WG regarding this. 999 * 1000 *** End of Note to WG 1002 It is assumed that the (external) generic ECA Policy Rule is 1003 abstract; the SecurityECAPolicyRule is also abstract. This enables 1004 data model optimizations to be made while making this information 1005 model detailed but flexible and extensible. For example, abstract 1006 classes may be collapsed into concrete classes. 1008 The SecurityECAPolicyRule defines network security policy as a 1009 container that aggregates Event, Condition, and Action objects, 1010 which are described in Section 4.1.3, 4.1.4, and 4.1.5, 1011 respectively. Events, Conditions, and Actions can be generic or 1012 security-specific. 1014 Brief class descriptions of these six ECA Policy Rules are provided 1015 in Appendix A. 1017 4.1.2. Network Security Policy Rule Operation 1019 A Network Security Policy consists of one or more ECA Policy Rules 1020 formed from the information model described above. In simpler cases, 1021 where the Event and Condition clauses remain unchanged, then network 1022 security may be performed by calling additional network security 1023 actions. Network security policy examines and performs basic 1024 processing of the traffic as follows: 1026 1. The NSF evaluates the Event clause of a given 1027 SecurityECAPolicyRule (which can be generic or specific to 1028 security, such as those in Figure 3). It may use security 1029 Event objects to do all or part of this evaluation, which are 1030 defined in section 4.1.3. If the Event clause evaluates to 1031 TRUE, then the Condition clause of this SecurityECAPolicyRule 1032 is evaluated; otherwise, the execution of this 1033 SecurityECAPolicyRule is stopped, and the next 1034 SecurityECAPolicyRule (if one exists) is evaluated. 1035 2. The Condition clause is then evaluated. It may use security 1036 Condition objects to do all or part of this evaluation, which 1037 are defined in section 4.1.4. If the Condition clause 1038 evaluates to TRUE, it is defined as "matching" the 1039 SecurityECAPolicyRule; otherwise, execution of this 1040 SecurityECAPolicyRule is stopped, and the next 1041 SecurityECAPolicyRule (if one exists) is evaluated. 1042 3. The set of actions to be executed are retrieved, and then the 1043 resolution strategy is used to define their execution order. 1044 This process includes using any optional external data 1045 associated with the SecurityECAPolicyRule. 1046 4. Execution then takes one of the following three forms: 1047 a. If one or more actions is selected, then the NSF may 1048 perform those actions as defined by the resolution 1049 strategy. For example, the resolution strategy may only 1050 allow a single action to be executed (e.g., FMR or LMR), 1051 or it may allow all actions to be executed (optionally, 1052 in a particular order). In these and other cases, the NSF 1053 Capability MUST clearly define how execution will be done. 1054 It may use security Action objects to do all or part of 1055 this execution, which are defined in section 4.1.5. If the 1056 basic Action is permit or mirror, the NSF firstly performs 1057 that function, and then checks whether certain other 1058 security Capabilities are referenced in the rule. If yes, 1059 go to step 5. If no, the traffic is permitted. 1060 b. If no actions are selected, and if a default action exists, 1061 then the default action is performed. Otherwise, no actions 1062 are performed. 1063 c. Otherwise, the traffic is denied. 1064 5. If other security Capabilities (e.g., the conditions and/or 1065 actions implied by Anti-virus or IPS profile NSFs) are 1066 referenced in the action set of the SecurityECAPolicyRule, the 1067 NSF can be configured to use the referenced security 1068 Capabilities (e.g., check conditions or enforce actions). 1069 Execution then terminates. 1071 One policy or rule can be applied multiple times to different 1072 managed objects (e.g., links, devices, networks, VPNS). This not 1073 only guarantees consistent policy enforcement, but also decreases 1074 the configuration workload. 1076 4.1.3. Network Security Event Sub-Model 1078 Figure 4 shows a more detailed design of the Event subclasses that 1079 are contained in the Network Security Information Sub-Model. 1081 +---------------------+ 1082 +---------------+ 1..n 1..n| | 1083 | |/ \ \| A Common Superclass | 1084 | ECAPolicyRule + A ---------+ for ECA Objects | 1085 | |\ / /| | 1086 +---------------+ +---------+-----------+ 1087 / \ 1088 | 1089 | 1090 +---------------+-----------+------+ 1091 | | | 1092 | | | 1093 +-----+----+ +------+------+ +-----+-----+ 1094 | An Event | | A Condition | | An Action | 1095 | Class | | Class | | Class | 1096 +-----+----+ +-------------+ +-----------+ 1097 / \ 1098 | 1099 | 1100 | 1101 +-----+---------+----------------+--------------+-- ... 1102 | | | | 1103 | | | | 1104 +-------+----+ +--------+-----+ +--------+-----+ +------+-----+ 1105 |UserSecurity| | Device | | System | |TimeSecurity| 1106 | Event | | SecurityEvent| | SecurityEvent| | Event | 1107 +------------+ +--------------+ +--------------+ +------------+ 1109 Figure 4. Network Security Info Sub-Model Event Class Extensions 1111 The four Event classes shown in Figure 4 extend the (external) 1112 generic Event class to represent Events that are of interest to 1113 Network Security. It is assumed that the (external) generic Event 1114 class defines basic Event information in the form of attributes, 1115 such as a unique event ID, a description, as well as the date and 1116 time that the event occurred. 1118 The following are assumptions that define the functionality of the 1119 generic Event class. If desired, these could be defined as 1120 attributes in a SecurityEvent class (which would be a subclass of 1121 the generic Event class, and a superclass of the four Event classes 1122 shown in Figure 4). However, this makes it harder to use any 1123 generic Event model with the I2NSF events. Assumptions are: 1125 - All four SecurityEvent subclasses are concrete 1126 - The generic Event class uses the composite pattern, so 1127 individual Events as well as hierarchies of Events are 1128 available (the four subclasses in Figure 4 would be 1129 subclasses of the Atomic Event class); otherwise, a mechanism 1130 is needed to be able to group Events into a collection 1131 - The generic Event class has a mechanism to uniquely identify 1132 the source of the Event 1133 - The generic Event class has a mechanism to separate header 1134 information from its payload 1135 - The generic Event class has a mechanism to attach zero or more 1136 metadata objects to it 1138 *** Note to WG: 1139 * 1140 * The design in Figure 4 represents the simplest conceptual design 1141 * design for describing Security Events. An alternative model would 1142 * be to use a software pattern (e.g., the Decorator pattern); this 1143 * would result in the SecurityEvent class being "wrapped" by one or 1144 * more of the four subclasses shown in Figure 4. The advantage of 1145 * such a pattern is to reduce the number of active objects at runtime, 1146 * as well as offer the ability to combine multiple events of different 1147 * types into one. The disadvantage is that it is a more complex 1148 * software design. 1149 * 1150 *** End of Note to WG 1152 Brief class descriptions are provided in Appendix B. 1154 4.1.4. Network Security Condition Sub-Model 1156 Figure 5 shows a more detailed design of the Condition subclasses 1157 that are contained in the Network Security Information Sub-Model. 1158 The six Condition classes shown in Figure 5 extend the (external) 1159 generic Condition class to represent Conditions that are of interest 1160 to Network Security. It is assumed that the (external) generic 1161 Condition class is abstract, so that data model optimizations may be 1162 defined. It is also assumed that the generic Condition class defines 1163 basic Condition information in the form of attributes, such as a 1164 unique object ID, a description, as well as a mechanism to attach 1165 zero or more metadata objects to it. While this could be defined as 1166 attributes in a SecurityCondition class (which would be a subclass 1167 of the generic Condition class, and a superclass of the six 1168 Condition classes shown in Figure 5), this makes it harder to use 1169 any generic Condition model with the I2NSF conditions. 1171 +---------------------+ 1172 +---------------+ 1..n 1..n | | 1173 | |/ \ \| A Common Superclass | 1174 | ECAPolicyRule+ A -------------+ for ECA Objects | 1175 | |\ / /| | 1176 +-------+-------+ +-----------+---------+ 1177 / \ 1178 | 1179 | 1180 +--------------+----------+----+ 1181 | | | 1182 | | | 1183 +-----+----+ +------+------+ +-----+-----+ 1184 | An Event | | A Condition | | An Action | 1185 | Class | | Class | | Class | 1186 +----------+ +------+------+ +-----------+ 1187 / \ 1188 | 1189 | 1190 +--------+----------+------+---+---------+--------+--- ... 1191 | | | | | | 1192 | | | | | | 1193 +-----+-----+ | +-------+-------+ | +------+-----+ | 1194 | Packet | | | PacketPayload | | | Target | | 1195 | Security | | | Security | | | Security | | 1196 | Condition | | | Condition | | | Condition | | 1197 +-----------+ | +---------------+ | +------------+ | 1198 | | | 1199 +------+-------+ +----------+------+ +--------+-------+ 1200 | UserSecurity | | SecurityContext | | GenericContext | 1201 | Condition | | Condition | | Condition | 1202 +--------------+ +-----------------+ +----------------+ 1204 Figure 5. Network Security Info Sub-Model Condition Class Extensions 1206 *** Note to WG: 1207 * 1208 * The design in Figure 5 represents the simplest conceptual design 1209 * for describing Security Conditions. An alternative model would be 1210 * to use a software pattern (e.g., the Decorator pattern); this would 1211 * result in the SecurityCondition class being "wrapped" by one or 1212 * more of the six subclasses shown in Figure 5. The advantage of such 1213 * a pattern is to reduce the number of active objects at runtime, as 1214 * well as offer the ability to combine multiple conditions of 1215 * different types into one. The disadvantage is that it is a more 1216 * complex software design. 1217 * The design team is requesting feedback from he WG regarding this. 1218 * 1219 *** End of Note to WG 1221 Brief class descriptions are provided in Appendix C. 1223 4.1.5. Network Security Action Sub-Model 1225 Figure 6 shows a more detailed design of the Action subclasses that 1226 are contained in the Network Security Information Sub-Model. 1228 +---------------------+ 1229 +---------------+ 1..n 1..n | | 1230 | |/ \ \| A Common Superclass | 1231 | ECAPolicyRule+ A -------------+ for ECA Objects | 1232 | |\ / /| | 1233 +---------------+ +-----------+---------+ 1234 / \ 1235 | 1236 | 1237 +--------------+--------+------+ 1238 | | | 1239 | | | 1240 +-----+----+ +------+------+ +-----+-----+ 1241 | An Event | | A Condition | | An Action | 1242 | Class | | Class | | Class | 1243 +----------+ +-------------+ +-----+-----+ 1244 / \ 1245 | 1246 | 1247 +-----------------+---------------+------- ... 1248 | | | 1249 | | | 1250 +---+-----+ +----+---+ +------+-------+ 1251 | Ingress | | Egress | | ApplyProfile | 1252 | Action | | Action | | Action | 1253 +---------+ +--------+ +--------------+ 1255 Figure 6. Network Security Info Sub-Model Action Extensions 1257 The four Action classes shown in Figure 6 extend the (external) 1258 generic Action class to represent Actions that perform a Network 1259 Security Control function. 1261 The three Action classes shown in Figure 6 extend the (external) 1262 generic Action class to represent Actions that are of interest to 1263 Network Security. It is assumed that the (external) generic Action 1264 class is abstract, so that data model optimizations may be defined. 1265 It is also assumed that the generic Action class defines basic 1266 Action information in the form of attributes, such as a unique 1267 object ID, a description, as well as a mechanism to attach zero or 1268 more metadata objects to it. While this could be defined as 1269 attributes in a SecurityAction class (which would be a subclass of 1270 the generic Action class, and a superclass of the six Action classes 1271 shown in Figure 6), this makes it harder to use any generic Action 1272 model with the I2NSF actions. 1274 *** Note to WG 1275 * The design in Figure 6 represents the simplest conceptual design 1276 * for describing Security Actions. An alternative model would be to 1277 * use a software pattern (e.g., the Decorator pattern); this would 1278 * result in the SecurityAction class being "wrapped" by one or more 1279 * of the three subclasses shown in Figure 6. The advantage of such a 1280 * pattern is to reduce the number of active objects at runtime, as 1281 * well as offer the ability to combine multiple actions of different 1282 * types into one. The disadvantage is that it is a more complex 1283 * software design. 1284 * The design team is requesting feedback from the WG regarding this. 1285 * 1286 *** End of Note to WG 1288 Brief class descriptions are provided in Appendix D. 1290 4.2. Information Model for I2NSF Capabilities 1292 The I2NSF Capability Model is made up of a number of Capabilities 1293 that represent various content security and attack mitigation 1294 functions. Each Capability protects against a specific type of 1295 threat in the application layer. This is shown in Figure 7. 1297 +-------------------------+ 0..n 0..n +---------------+ 1298 | |/ \ \| External | 1299 | External ECA Info Model + A ----------------+ Metadata | 1300 | |\ / Aggregates /| Info Model | 1301 +-------+-----------------+ Metadata +-----+---------+ 1302 | / \ 1303 | | 1304 / \ | 1305 Subclasses +---------------------------------+--------------+ 1306 derived | Capability | | 1307 for I2NSF | Sub-Model +----------+---------+ | 1308 | | SecurityCapability | | 1309 | +----------+---------+ | 1310 | | | 1311 | | | 1312 | +----------------------+---+ | 1313 | | | | 1314 | +--------+---------+ +----------+--------+ | 1315 | | Content Security | | Attack Mitigation | | 1316 | + Capabilities | | Capabilities | | 1317 | +------------------+ +-------------------+ | 1318 +------------------------------------------------+ 1320 Figure 7. I2NSF Security Capability High-Level Model 1322 Figure 7 shows a common I2NSF Security Capability class, called 1323 SecurityCapability. This enables us to add common attributes, 1324 relationships, and behavior to this class without affecting the 1325 design of the external metadata information model. 1327 All I2NSF Security Capabilities are then subclassed from the 1328 SecuritCapability class. 1330 Note: the SecurityCapability class will be defined in the next 1331 version of this draft, after feedback from the WG is obtained. 1333 4.3. Information Model for Content Security Capabilities 1335 Content security is composed of a number of distinct security 1336 functions; each such function protects against a specific type of 1337 threat in the application layer. Content security is a type of 1338 Generic Network Security Function, which summarizes a well-defined 1339 set of security Capabilities, and was shown in Figure 7. Figure 8 1340 shows exemplary types of content security Generic Network 1341 Security Function. 1343 +--------------------------------------------------------------+ 1344 | +--------------------+ | 1345 | Capability | SecurityCapability | | 1346 | Sub-Model: +---------+----------+ | 1347 | Content Security / \ | 1348 | | | 1349 | | | 1350 | +-------+----------+----------+---------------+ | 1351 | | | | | | 1352 | +-----+----+ | +-------+----+ +-------+------+ | 1353 | |Anti-Virus| | | Intrusion | | Attack | | 1354 | |Capability| | | Prevention | | Mitigation | | 1355 | +----------+ | | Capability | | Capabilities | | 1356 | | +------------+ +--------------+ | 1357 | | | 1358 | +--------+----+------------+-----------+--------+ | 1359 | | | | | | | 1360 | +----+-----+ +-----+----+ +-----+----+ +----+-----+ | | 1361 | | URL | | Mail | | File | | Data | | | 1362 | |Filtering | |Filtering | |Filtering | |Filtering | | | 1363 | |Capability| |Capability| |Capability| |Capability| | | 1364 | +----------+ +----------+ +----------+ +----------+ | | 1365 | | | 1366 | +----------------+------------------+----+ | 1367 | | | | | 1368 | +------+------+ +------+------+ +---------+---------+ | 1369 | |PacketCapture| |FileIsolation| |ApplicationBehavior| | 1370 | | Capability | | Capability | | Capability | | 1371 | +-------------+ +-------------+ +-------------------+ | 1372 +--------------------------------------------------------------+ 1374 Figure 8. Network Security Capability Information Model 1376 The detailed description about a standard interface, and the 1377 parameters for all the security Capabilities of this category, will 1378 be defined in a future version of this document. 1380 4.4. Information Model for Attack Mitigation Capabilities 1382 Attack mitigation is composed of a number of Generic Network Security 1383 Functions; each one protects against a specific type of network 1384 attack. Attack Mitigation security is a type of Generic Network 1385 Security Function, which summarizes a well-defined set of security 1386 Capabilities, and was shown in Figure 7. Figure 9 shows exemplary 1387 types of Attack Mitigation Generic Network Security Functions. 1389 +---------------------------------------------------------------+ 1390 | +--------------------+ | 1391 | Capability | SecurityCapability | | 1392 | Sub-Model: +---------+----------+ | 1393 | Attack Mitigation / \ | 1394 | | | 1395 | | | 1396 | +-------+--------+------------+-------------+ | 1397 | | | | | | 1398 | +-----+----+ | +-----+----+ +-------+------+ | 1399 | | SSLDDoS | | | PortScan | | Content | | 1400 | |Capability| | |Capability| | Security | | 1401 | +----------+ | +----------+ | Capabilities | | 1402 | | +--------------+ | 1403 | | | 1404 | +--------+----+------------+-----------+--------+ | 1405 | | | | | | | 1406 | +----+-----+ +-----+----+ +-----+----+ +----+-----+ | | 1407 | | SYNFlood | | UDPFlood | |ICMPFlood | | WebFlood | | | 1408 | |Capability| |Capability| |Capability| |Capability| | | 1409 | +----------+ +----------+ +----------+ +----------+ | | 1410 | | | 1411 | +-----------------+--------------+-----------+ | 1412 | | | | | 1413 | +-------+-------+ +-------+------+ +-----+-----+ +-----+----+ | 1414 | |IPFragmentFlood| |DNSAmplication| |PingOfDeath| | IPSweep | | 1415 | | Capability | | Capability | |Capability | |Capability| | 1416 | +---------------+ +--------------+ +-----------+ +----------+ | 1417 +---------------------------------------------------------------+ 1419 Figure 9. Attack Mitigation Capability Information Model 1421 The detailed description about a standard interface, and the 1422 parameters for all the security Capabilities of this category, will 1423 be defined in a future version of this document. 1425 5. Security Considerations 1427 The security Capability policy information sent to NSFs should be 1428 protected by the secure communication channel, to ensure its 1429 confidentiality and integrity. Note that the NSFs and security 1430 controller can all be spoofed, which leads to undesirable results 1431 (e.g., security policy leakage from security controller, or a spoofed 1432 security controller sending false information to mislead the NSFs). 1433 Hence, mutual authentication MUST be supported to protected against 1434 this kind of attack. The current mainstream security technologies 1435 (i.e., TLS, DTLS, and IPSEC) can be employed to protect against the 1436 above threats. 1438 In addition, to defend against DDoS attacks caused by a hostile 1439 security controller sending too many configuration messages to the 1440 NSFs, rate limiting or similar mechanisms should be considered. 1442 6. IANA Considerations 1444 TBD 1446 7. Contributors 1448 The following people contributed to creating this document, and are 1449 listed below in alphabetical order: 1451 Antonio Lioy (Politecnico di Torino) 1452 Dacheng Zhang (Huawei) 1453 Edward Lopez (Fortinet) 1454 Fulvio Valenza (Politecnico di Torino) 1455 Kepeng Li (Alibaba) 1456 Luyuan Fang (Microsoft) 1457 Nicolas Bouthors (QoSmos) 1459 8. References 1461 8.1. Normative References 1463 [RFC2119] 1464 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1465 Levels", BCP 14, RFC 2119, March 1997. 1466 [RFC3539] 1467 Aboba, B., and Wood, J., "Authentication, Authorization, and 1468 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1470 8.2. Informative References 1472 [RFC2975] 1473 Aboba, B., et al., "Introduction to Accounting Management", 1474 RFC 2975, October 2000. 1475 [I-D.draft-ietf-i2nsf-problem-and-use-cases] 1476 Hares, S., et.al., "I2NSF Problem Statement and Use cases", 1477 draft-ietf-i2nsf-problem-and-use-cases-11, March 2017. 1478 [I-D.draft-ietf-i2nsf-framework] 1479 Lopez, E., et.al., "Framework for Interface to Network Security 1480 Functions", draft-ietf-i2nsf-framework-04, October, 2016. 1481 [I-D.draft-ietf-i2nsf-terminology] 1482 Hares, S., et.al., "Interface to Network Security Functions 1483 (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03, 1484 March, 2017 1485 [I-D.draft-ietf-supa-generic-policy-info-model] 1486 Strassner, J., Halpern, J., van der Meer, S., "Generic Policy 1487 Information Model for Simplified Use of Policy Abstractions 1488 (SUPA)", Woaft-ietf-supa-generic-policy-info-model-02, 1489 October, 2016. 1490 [I-D.draft-zhang-i2nsf-info-model-monitoring] 1491 Zhang, D., et al., "An Information Model for the Monitoring of 1492 Network Security Functions (NSF)", 1493 draft-zhang-i2nsf-info-model-monitoring-02, September, 2016. 1494 [Alshaer] 1495 Al Shaer, E. and H. Hamed, "Modeling and management of firewall 1496 policies", 2004. 1497 [Bas12] 1498 Basile, C., Cappadonia, A., and A. Lioy, "Network-Level Access 1499 Control Policy Analysis and Transformation", 2012. 1500 [Bas15] 1501 Basile, C. and Lioy, A., "Analysis of application-layer filtering 1502 policies with application to HTTP", IEEE/ACM Transactions on 1503 Networking, Vol 23, Issue 1, February 2015. 1504 [Cormen] 1505 Cormen, T., "Introduction to Algorithms", 2009. 1506 [Hohpe] 1507 Hohpe, G. and Woolf, B., "Enterprise Integration Patterns", 1508 Addison-Wesley, 2003, ISBN 0-32-120068-3 1509 [Lunt] 1510 van Lunteren, J. and T. Engbersen, "Fast and scalable packet 1511 classification", IEEE Journal on Selected Areas in Communication, 1512 vol 21, Issue 4, September 2003. 1513 [Martin] 1514 Martin, R.C., "Agile Software Development, Principles, Patterns, 1515 and Practices", Prentice-Hall, 2002, ISBN: 0-13-597444-5 1517 [OODMP] 1518 http://www.oodesign.com/mediator-pattern.html 1519 [OODOP] 1520 http://www.oodesign.com/observer-pattern.html 1521 [OODSRP] 1522 http://www.oodesign.com/single-responsibility-principle.html 1524 Appendix A. Network Security Capability Policy Rule Definitions 1526 Six exemplary Network Security Capability Policy Rules are 1527 introduced in this Appendix to clarify how to create different kinds 1528 of specific ECA policy rules to manage Network Security Capabilities. 1530 Note that there is a common pattern that defines how these 1531 ECAPolicyRules operate; this simplifies their implementation. All of 1532 these six ECA Policy Rules are concrete classes. 1534 In addition, none of these six subclasses define attributes. This 1535 enables them to be viewed as simple object containers, and hence, 1536 applicable to a wide variety of content. It also means that the 1537 content of the function (e.g., how an entity is authenticated, what 1538 specific traffic is inspected, or which particular signature is 1539 applied) is defined solely by the set of events, conditions, and 1540 actions that are contained by the particular subclass. This enables 1541 the policy rule, with its aggregated set of events, conditions, and 1542 actions, to be treated as a reusable object. 1544 A.1. AuthenticationECAPolicyRule Class Definition 1546 The purpose of an AuthenticationECAPolicyRule is to define an I2NSF 1547 ECA Policy Rule that can verify whether an entity has an attribute 1548 of a specific value. A high-level conceputal figure is shown below. 1550 +----------------+ 1551 +----------------+ 1..n 1...n | | 1552 | |/ \ HasAuthenticationMethod \| Authentication | 1553 | Authentication + A ----------+-----------------+ Method | 1554 | ECAPolicyRule |\ / ^ /| | 1555 | | | +----------------+ 1556 +----------------+ | 1557 | 1558 +------------+-------------+ 1559 | AuthenticationRuleDetail | 1560 +------------+-------------+ 1561 / \ 0..n 1562 | 1563 | PolicyControlsAuthentication 1564 | 1565 / \ 1566 A 1567 \ / 0..n 1568 +----------+--------------+ 1569 | ManagementECAPolicyRule | 1570 +-------------------------+ 1572 Figure 10. Modeling Authentication Mechanisms 1574 This class does NOT define the authentication method used. This is 1575 because this would effectively "enclose" this information within the 1576 AuthenticationECAPolicyRule. This has two drawbacks. First, other 1577 entities that need to use information from the Authentication 1578 class(es) could not; they would have to associate with the 1579 AuthenticationECAPolicyRule class, and those other classes would not 1580 likely be interested in the AuthenticationECAPolicyRule. Second, the 1581 evolution of new authentication methods should be independent of the 1582 AuthenticationECAPolicyRule; this cannot happen if the 1583 Authentication class(es) are embedded in the 1584 AuthenticationECAPolicyRule. 1586 This document only defines the AuthenticationECAPolicyRule; all other 1587 classes, and the aggregations, are defined in an external model. For 1588 completeness, descriptions of how the two aggregations are used are 1589 described below. 1591 Figure 10 defines an aggregation between an external class, which 1592 defines one or more authentication methods, and an 1593 AuthenticationECAPolicyRule. This decouples the implementation of 1594 authentication mechanisms from how authentication mechanisms are 1595 managed and used. 1597 Since different AuthenticationECAPolicyRules can use different 1598 authentication mechanisms in different ways, the aggregation is 1599 realized as an association class. This enables the attributes and 1600 methods of the association class (i.e., AuthenticationRuleDetail) to 1601 be used to define how a given AuthenticationMethod is used by a 1602 particular AuthenticationECAPolicyRule. 1604 Similarly, the PolicyControlsAuthentication aggregation defines 1605 Policy Rules to control the configuration of the 1606 AuthenticationRuleDetail association class. This enables the entire 1607 authentication process to be managed by ECA PolicyRules. 1609 Note: a data model MAY choose to collapse this design into a more 1610 efficient implementation. For example, a data model could define two 1611 attributes for the AuthenticationECAPolicyRule class (e.g., called 1612 authenticationMethodCurrent and authenticationMethodSupported), to 1613 represent the HasAuthenticationMethod aggregation and its 1614 association class. The former would be a string attribute that 1615 defines the current authentication method used by this 1616 AuthenticationECAPolicyRule, while the latter would define a set of 1617 authentication methods, in the form of an authentication Capability, 1618 which this AuthenticationECAPolicyRule can advertise. 1620 A.2. AuthorizationECAPolicyRuleClass Definition 1622 The purpose of an AuthorizationECAPolicyRule is to define an I2NSF 1623 ECA Policy Rule that can determine whether access to a resource 1624 should be given and, if so, what permissions should be granted to 1625 the entity that is accessing the resource. 1627 This class does NOT define the authorization method(s) used. This 1628 is because this would effectively "enclose" this information within 1629 the AuthorizationECAPolicyRule. This has two drawbacks. First, other 1630 entities that need to use information from the Authorization 1631 class(es) could not; they would have to associate with the 1632 AuthorizationECAPolicyRule class, and those other classes would not 1633 likely be interested in the AuthorizationECAPolicyRule. Second, the 1634 evolution of new authorization methods should be independent of the 1635 AuthorizationECAPolicyRule; this cannot happen if the Authorization 1636 class(es) are embedded in the AuthorizationECAPolicyRule. Hence, 1637 this document recommends the following design: 1639 +---------------+ 1640 +----------------+ 1..n 1...n | | 1641 | |/ \ HasAuthorizationMethod \| Authorization | 1642 | Authorization + A ----------+----------------+ Method | 1643 | ECAPolicyRule |\ / ^ /| | 1644 | | | +---------------+ 1645 +----------------+ | 1646 | 1647 +------------+------------+ 1648 | AuthorizationRuleDetail | 1649 +------------+------------+ 1650 / \ 0..n 1651 | 1652 | PolicyControlsAuthorization 1653 | 1654 / \ 1655 A 1656 \ / 0..n 1657 +----------+--------------+ 1658 | ManagementECAPolicyRule | 1659 +-------------------------+ 1661 Figure 11. Modeling Authorization Mechanisms 1663 This document only defines the AuthorizationECAPolicyRule; all other 1664 classes, and the aggregations, are defined in an external model. For 1665 completeness, descriptions of how the two aggregations are used are 1666 described below. 1668 Figure 11 defines an aggregation between the 1669 AuthorizationECAPolicyRule and an external class that defines one or 1670 more authorization methods. This decouples the implementation of 1671 authorization mechanisms from how authorization mechanisms are 1672 managed and used. 1674 Since different AuthorizationECAPolicyRules can use different 1675 authorization mechanisms in different ways, the aggregation is 1676 realized as an association class. This enables the attributes and 1677 methods of the association class (i.e., AuthorizationRuleDetail) 1678 to be used to define how a given AuthorizationMethod is used by a 1679 particular AuthorizationECAPolicyRule. 1681 Similarly, the PolicyControlsAuthorization aggregation defines 1682 Policy Rules to control the configuration of the 1683 AuthorizationRuleDetail association class. This enables the entire 1684 authorization process to be managed by ECA PolicyRules. 1686 Note: a data model MAY choose to collapse this design into a more 1687 efficient implementation. For example, a data model could define 1688 two attributes for the AuthorizationECAPolicyRule class, called 1689 (for example) authorizationMethodCurrent and 1690 authorizationMethodSupported, to represent the 1691 HasAuthorizationMethod aggregation and its association class. The 1692 former is a string attribute that defines the current authorization 1693 method used by this AuthorizationECAPolicyRule, while the latter 1694 defines a set of authorization methods, in the form of an 1695 authorization Capability, which this AuthorizationECAPolicyRule 1696 can advertise. 1698 A.3. AccountingECAPolicyRuleClass Definition 1700 The purpose of an AccountingECAPolicyRule is to define an I2NSF 1701 ECA Policy Rule that can determine which information to collect, 1702 and how to collect that information, from which set of resources 1703 for the purpose of trend analysis, auditing, billing, or cost 1704 allocation [RFC2975] [RFC3539]. 1706 This class does NOT define the accounting method(s) used. This is 1707 because this would effectively "enclose" this information within 1708 the AccountingECAPolicyRule. This has two drawbacks. First, other 1709 entities that need to use information from the Accounting class(es) 1710 could not; they would have to associate with the 1711 AccountingECAPolicyRule class, and those other classes would not 1712 likely be interested in the AccountingECAPolicyRule. Second, the 1713 evolution of new accounting methods should be independent of the 1714 AccountingECAPolicyRule; this cannot happen if the Accounting 1715 class(es) are embedded in the AccountingECAPolicyRule. Hence, this 1716 document recommends the following design: 1718 +-------------+ 1719 +----------------+ 1..n 1...n | | 1720 | |/ \ HasAccountingMethod \| Accounting | 1721 | Accounting + A ----------+--------------+ Method | 1722 | ECAPolicyRule |\ / ^ /| | 1723 | | | +-------------+ 1724 +----------------+ | 1725 | 1726 +----------+-----------+ 1727 | AccountingRuleDetail | 1728 +----------+-----------+ 1729 / \ 0..n 1730 | 1731 | PolicyControlsAccounting 1732 | 1733 / \ 1734 A 1735 \ / 0..n 1736 +----------+--------------+ 1737 | ManagementECAPolicyRule | 1738 +-------------------------+ 1740 Figure 12. Modeling Accounting Mechanisms 1742 This document only defines the AccountingECAPolicyRule; all other 1743 classes, and the aggregations, are defined in an external model. 1744 For completeness, descriptions of how the two aggregations are used 1745 are described below. 1747 Figure 12 defines an aggregation between the AccountingECAPolicyRule 1748 and an external class that defines one or more accounting methods. 1749 This decouples the implementation of accounting mechanisms from how 1750 accounting mechanisms are managed and used. 1752 Since different AccountingECAPolicyRules can use different 1753 accounting mechanisms in different ways, the aggregation is realized 1754 as an association class. This enables the attributes and methods of 1755 the association class (i.e., AccountingRuleDetail) to be used to 1756 define how a given AccountingMethod is used by a particular 1757 AccountingECAPolicyRule. 1759 Similarly, the PolicyControlsAccounting aggregation defines Policy 1760 Rules to control the configuration of the AccountingRuleDetail 1761 association class. This enables the entire accounting process to be 1762 managed by ECA PolicyRules. 1764 Note: a data model MAY choose to collapse this design into a more 1765 efficient implementation. For example, a data model could define 1766 two attributes for the AccountingECAPolicyRule class, called 1767 (for example) accountingMethodCurrent and accountingMethodSupported, 1768 to represent the HasAccountingMethod aggregation and its association 1769 class. 1771 The former is a string attribute that defines the current accounting 1772 method used by this AccountingECAPolicyRule, while the latter 1773 defines a set of accounting methods, in the form of an accounting 1774 Capability, which this AccountingECAPolicyRule can advertise. 1776 A.4. TrafficInspectionECAPolicyRuleClass Definition 1778 The purpose of a TrafficInspectionECAPolicyRule is to define an I2NSF 1779 ECA Policy Rule that, based on a given context, can determine which 1780 traffic to examine on which devices, which information to collect 1781 from those devices, and how to collect that information. 1783 This class does NOT define the traffic inspection method(s) used. 1784 This is because this would effectively "enclose" this information 1785 within the TrafficInspectionECAPolicyRule. This has two drawbacks. 1786 First, other entities that need to use information from the 1787 TrafficInspection class(es) could not; they would have to associate 1788 with the TrafficInspectionECAPolicyRule class, and those other 1789 classes would not likely be interested in the 1790 TrafficInspectionECAPolicyRule. Second, the evolution of new traffic 1791 inspection methods should be independent of the 1792 TrafficInspectionECAPolicyRule; this cannot happen if the 1793 TrafficInspection class(es) are embedded in the 1794 TrafficInspectionECAPolicyRule. Hence, this document recommends the 1795 following design: 1797 +------------------+ 1798 +-------------------+1..n 1..n| | 1799 | |/ \ HasTrafficInspection \| Traffic | 1800 | TrafficInspection + A ----------+-------------+ InspectionMethod | 1801 | ECAPolicyRule |\ / ^ / | | 1802 | | | +------------------+ 1803 +-------------------+ | 1804 | 1805 +------------+------------+ 1806 | TrafficInspectionDetail | 1807 +------------+------------+ 1808 / \ 0..n 1809 | 1810 | PolicyControlsTrafficInspection 1811 | 1812 / \ 1813 A 1814 \ / 0..n 1815 +----------+--------------+ 1816 | ManagementECAPolicyRule | 1817 +-------------------------+ 1819 Figure 13. Modeling Traffic Inspection Mechanisms 1821 This document only defines the TrafficInspectionECAPolicyRule; all 1822 other classes, and the aggregations, are defined in an external 1823 model. For completeness, descriptions of how the two aggregations 1824 are used are described below. 1826 Figure 13 defines an aggregation between the 1827 TrafficInspectionECAPolicyRule and an external class that defines 1828 one or more traffic inspection mechanisms. This decouples the 1829 implementation of traffic inspection mechanisms from how traffic 1830 inspection mechanisms are managed and used. 1832 Since different TrafficInspectionECAPolicyRules can use different 1833 traffic inspection mechanisms in different ways, the aggregation is 1834 realized as an association class. This enables the attributes and 1835 methods of the association class (i.e., TrafficInspectionDetail) to 1836 be used to define how a given TrafficInspectionMethod is used by a 1837 particular TrafficInspectionECAPolicyRule. 1839 Similarly, the PolicyControlsTrafficInspection aggregation defines 1840 Policy Rules to control the configuration of the 1841 TrafficInspectionDetail association class. This enables the entire 1842 traffic inspection process to be managed by ECA PolicyRules. 1844 Note: a data model MAY choose to collapse this design into a more 1845 efficient implementation. For example, a data model could define 1846 two attributes for the TrafficInspectionECAPolicyRule class, called 1847 (for example) trafficInspectionMethodCurrent and 1848 trafficInspectionMethodSupported, to represent the 1849 HasTrafficInspectionMethod aggregation and its association class. 1850 The former is a string attribute that defines the current traffic 1851 inspection method used by this TrafficInspectionECAPolicyRule, 1852 while the latter defines a set of traffic inspection methods, in 1853 the form of a traffic inspection Capability, which this 1854 TrafficInspectionECAPolicyRule can advertise. 1856 A.5. ApplyProfileECAPolicyRuleClass Definition 1858 The purpose of an ApplyProfileECAPolicyRule is to define an I2NSF 1859 ECA Policy Rule that, based on a given context, can apply a 1860 particular profile to specific traffic. The profile defines the 1861 security Capabilities for content security control and/or attack 1862 mitigation control; these will be described in sections 4.4 and 1863 4.5, respectively. 1865 This class does NOT define the set of Profiles used. This is 1866 because this would effectively "enclose" this information within 1867 the ApplyProfileECAPolicyRule. This has two drawbacks. First, other 1868 entities that need to use information from the Profile class(es) 1869 could not; they would have to associate with the 1870 ApplyProfileECAPolicyRule class, and those other classes would not 1871 likely be interested in the ApplyProfileECAPolicyRule. Second, the 1872 evolution of new Profile classes should be independent of the 1873 ApplyProfileECAPolicyRule; this cannot happen if the Profile 1874 class(es) are embedded in the ApplyProfileECAPolicyRule. Hence, 1875 this document recommends the following design: 1877 +-------------+ 1878 +-------------------+ 1..n 1..n | | 1879 | |/ \ ProfileApplied \| | 1880 | ApplyProfile + A -----------+-------------+ Profile | 1881 | ECAPolicyRule |\ / ^ /| | 1882 | | | +-------------+ 1883 +-------------------+ | 1884 | 1885 +------------+---------+ 1886 | ProfileAppliedDetail | 1887 +------------+---------+ 1888 / \ 0..n 1889 | 1890 | 1891 PolicyControlsProfileApplication | 1892 | 1893 / \ 1894 A 1895 \ / 0..n 1896 +----------+--------------+ 1897 | ManagementECAPolicyRule | 1898 +-------------------------+ 1900 Figure 14. Modeling Profile ApplicationMechanisms 1902 This document only defines the ApplyProfileECAPolicyRule; all other 1903 classes, and the aggregations, are defined in an external model. 1904 For completeness, descriptions of how the two aggregations are used 1905 are described below. 1907 Figure 14 defines an aggregation between the 1908 ApplyProfileECAPolicyRule and an external Profile class. This 1909 decouples the implementation of Profiles from how Profiles are used. 1911 Since different ApplyProfileECAPolicyRules can use different 1912 Profiles in different ways, the aggregation is realized as an 1913 association class. This enables the attributes and methods of the 1914 association class (i.e., ProfileAppliedDetail) to be used to define 1915 how a given Profile is used by a particular 1916 ApplyProfileECAPolicyRule. 1918 Similarly, the PolicyControlsProfileApplication aggregation defines 1919 policies to control the configuration of the ProfileAppliedDetail 1920 association class. This enables the application of Profiles to be 1921 managed and used by ECA PolicyRules. 1923 Note: a data model MAY choose to collapse this design into a more 1924 efficient implementation. For example, a data model could define two 1925 attributes for the ApplyProfileECAPolicyRuleclass, called (for 1926 example) profileAppliedCurrent and profileAppliedSupported, to 1927 represent the ProfileApplied aggregation and its association class. 1928 The former is a string attribute that defines the current Profile 1929 used by this ApplyProfileECAPolicyRule, while the latter defines a 1930 set of Profiles, in the form of a Profile Capability, which this 1931 ApplyProfileECAPolicyRule can advertise. 1933 A.6. ApplySignatureECAPolicyRuleClass Definition 1935 The purpose of an ApplySignatureECAPolicyRule is to define an I2NSF 1936 ECA Policy Rule that, based on a given context, can determine which 1937 Signature object (e.g., an anti-virus file, or aURL filtering file, 1938 or a script) to apply to which traffic. The Signature object defines 1939 the security Capabilities for content security control and/or attack 1940 mitigation control; these will be described in sections 4.4 and 4.5, 1941 respectively. 1943 This class does NOT define the set of Signature objects used. This 1944 is because this would effectively "enclose" this information within 1945 the ApplySignatureECAPolicyRule. This has two drawbacks. First, 1946 other entities that need to use information from the Signature 1947 object class(es) could not; they would have to associate with the 1948 ApplySignatureECAPolicyRule class, and those other classes would not 1949 likely be interested in the ApplySignatureECAPolicyRule. Second, the 1950 evolution of new Signature object classes should be independent of 1951 the ApplySignatureECAPolicyRule; this cannot happen if the Signature 1952 object class(es) are embedded in the ApplySignatureECAPolicyRule. 1953 Hence, this document recommends the following design: 1955 This document only defines the ApplySignatureECAPolicyRule; all 1956 other classes, and the aggregations, are defined in an external 1957 model. For completeness, descriptions of how the two aggregations 1958 are used are described below. 1960 Figure 15 defines an aggregation between the 1961 ApplySignatureECAPolicyRule and an external Signature object class. 1962 This decouples the implementation of signature objects from how 1963 Signature objects are used. 1965 Since different ApplySignatureECAPolicyRules can use different 1966 Signature objects in different ways, the aggregation is realized as 1967 an association class. This enables the attributes and methods of the 1968 association class (i.e., SignatureAppliedDetail) to be used to 1969 define how a given Signature object is used by a particular 1970 ApplySignatureECAPolicyRule. 1972 +-------------+ 1973 +---------------+ 1..n 1..n | | 1974 | |/ \ SignatureApplied \| | 1975 | ApplySignature+ A ----------+--------------+ Signature | 1976 | ECAPolicyRule |\ / ^ /| | 1977 | | | +-------------+ 1978 +---------------+ | 1979 | 1980 +------------+-----------+ 1981 | SignatureAppliedDetail | 1982 +------------+-----------+ 1983 / \ 0..n 1984 | 1985 | PolicyControlsSignatureApplication 1986 | 1987 / \ 1988 A 1989 \ / 0..n 1990 +----------+--------------+ 1991 | ManagementECAPolicyRule | 1992 +-------------------------+ 1994 Figure 15. Modeling Sginature Application Mechanisms 1996 Similarly, the PolicyControlsSignatureApplication aggregation 1997 defines policies to control the configuration of the 1998 SignatureAppliedDetail association class. This enables the 1999 application of the Signature object to be managed by policy. 2001 Note: a data model MAY choose to collapse this design into a more 2002 efficient implementation. For example, a data model could define 2003 two attributes for the ApplySignatureECAPolicyRule class, called 2004 (for example) signature signatureAppliedCurrent and 2005 signatureAppliedSupported, to represent the SignatureApplied 2006 aggregation and its association class. The former is a string 2007 attribute that defines the current Signature object used by this 2008 ApplySignatureECAPolicyRule, while the latter defines a set of 2009 Signature objects, in the form of a Signature Capability, which 2010 this ApplySignatureECAPolicyRule can advertise. 2012 Appendix B. Network Security Event Class Definitions 2014 This Appendix defines a preliminary set of Network Security Event 2015 classes, along with their attributes. 2017 B.1. UserSecurityEvent Class Description 2019 The purpose of this class is to represent Events that are initiated 2020 by a user, such as logon and logoff Events. Information in this 2021 Event may be used as part of a test to determine if the Condition 2022 clause in this ECA Policy Rule should be evaluated or not. Examples 2023 include user identification data and the type of connection used by 2024 the user. 2026 The UserSecurityEvent class defines the following attributes. 2028 B.1.1. The usrSecEventContent Attribute 2030 This is a mandatory string that contains the content of the 2031 UserSecurityEvent. The format of the content is specified in the 2032 usrSecEventFormat class attribute, and the type of Event is defined 2033 in the usrSecEventType class attribute. An example of the 2034 usrSecEventContent attribute is the string "hrAdmin", with the 2035 usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute 2036 set to 5 (new logon). 2038 B.1.2. The usrSecEventFormat Attribute 2040 This is a mandatory non-negative enumerated integer, which is used 2041 to specify the data type of the usrSecEventContent attribute. The 2042 content is specified in the usrSecEventContent class attribute, and 2043 the type of Event is defined in the usrSecEventType class attribute. 2044 An example of the usrSecEventContent attribute is the string 2045 "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and 2046 the usrSecEventType attribute set to 5 (new logon). Values include: 2048 0: unknown 2049 1: GUID (Generic Unique IDentifier) 2050 2: UUID (Universal Unique IDentifier) 2051 3: URI (Uniform Resource Identifier) 2052 4: FQDN (Fully Qualified Domain Name) 2053 5: FQPN (Fully Qualified Path Name) 2055 B.1.3. The usrSecEventType Attribute 2057 This is a mandatory non-negative enumerated integer, which is used 2058 to specify the type of Event that involves this user. The content 2059 and format are specified in the usrSecEventContent and 2060 usrSecEventFormat class attributes, respectively. 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: new user created 2068 2: new user group created 2069 3: user deleted 2070 4: user group deleted 2071 5: user logon 2072 6: user logoff 2073 7: user access request 2074 8: user access granted 2075 9: user access violation 2077 B.2. DeviceSecurityEvent Class Description 2079 The purpose of a DeviceSecurityEvent is to represent Events that 2080 provide information from the Device that are important to I2NSF 2081 Security. Information in this Event may be used as part of a test 2082 to determine if the Condition clause in this ECA Policy Rule should 2083 be evaluated or not. Examples include alarms and various device 2084 statistics (e.g., a type of threshold that was exceeded), which may 2085 signal the need for further action. 2087 The DeviceSecurityEvent class defines the following attributes. 2089 B.2.1. The devSecEventContent Attribute 2091 This is a mandatory string that contains the content of the 2092 DeviceSecurityEvent. The format of the content is specified in the 2093 devSecEventFormat class attribute, and the type of Event is defined 2094 in the devSecEventType class attribute. An example of the 2095 devSecEventContent attribute is "alarm", with the devSecEventFormat 2096 attribute set to 1 (GUID), the devSecEventType attribute set to 2097 5 (new logon). 2099 B.2.2. The devSecEventFormat Attribute 2101 This is a mandatory non-negative enumerated integer, which is used 2102 to specify the data type of the devSecEventContent attribute. 2103 Values include: 2105 0: unknown 2106 1: GUID (Generic Unique IDentifier) 2107 2: UUID (Universal Unique IDentifier) 2108 3: URI (Uniform Resource Identifier) 2109 4: FQDN (Fully Qualified Domain Name) 2110 5: FQPN (Fully Qualified Path Name) 2112 B.2.3. The devSecEventType Attribute 2114 This is a mandatory non-negative enumerated integer, which is used 2115 to specify the type of Event that was generated by this device. 2116 Values include: 2118 0: unknown 2119 1: communications alarm 2120 2: quality of service alarm 2121 3: processing error alarm 2122 4: equipment error alarm 2123 5: environmental error alarm 2125 Values 1-5 are defined in X.733. Additional types of errors may also 2126 be defined. 2128 B.2.4. The devSecEventTypeInfo[0..n] Attribute 2130 This is an optional array of strings, which is used to provide 2131 additional information describing the specifics of the Event 2132 generated by this Device. For example, this attribute could contain 2133 probable cause information in the first array, trend information in 2134 the second array, proposed repair actions in the third array, and 2135 additional information in the fourth array. 2137 B.2.5. The devSecEventTypeSeverity Attribute 2139 This is a mandatory non-negative enumerated integer, which is used 2140 to specify the perceived severity of the Event generated by this 2141 Device. Values (which are defined in X.733) include: 2143 0: unknown 2144 1: cleared 2145 2: indeterminate 2146 3: critical 2147 4: major 2148 5: minor 2149 6: warning 2151 B.3. SystemSecurityEvent Class Description 2153 The purpose of a SystemSecurityEvent is to represent Events that 2154 are detected by the management system, instead of Events that are 2155 generated by a user or a device. Information in this Event may be 2156 used as part of a test to determine if the Condition clause in 2157 this ECA Policy Rule should be evaluated or not. Examples include 2158 an event issued by an analytics system that warns against a 2159 particular pattern of unknown user accesses, or an Event issued by 2160 a management system that represents a set of correlated and/or 2161 filtered Events. 2163 The SystemSecurityEvent class defines the following attributes. 2165 B.3.1. The sysSecEventContent Attribute 2167 This is a mandatory string that contains the content of the 2168 SystemSecurityEvent. The format of the content is specified in the 2169 sysSecEventFormat class attribute, and the type of Event is defined 2170 in the sysSecEventType class attribute. An example of the 2171 sysSecEventContent attribute is the string "sysadmin3", with the 2172 sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType 2173 attribute set to 2 (audit log cleared). 2175 B.3.2. The sysSecEventFormat Attribute 2177 This is a mandatory non-negative enumerated integer, which is used 2178 to specify the data type of the sysSecEventContent attribute. 2179 Values include: 2181 0: unknown 2182 1: GUID (Generic Unique IDentifier) 2183 2: UUID (Universal Unique IDentifier) 2184 3: URI (Uniform Resource Identifier) 2185 4: FQDN (Fully Qualified Domain Name) 2186 5: FQPN (Fully Qualified Path Name) 2188 B.3.3. The sysSecEventType Attribute 2190 This is a mandatory non-negative enumerated integer, which is used 2191 to specify the type of Event that involves this device. 2192 Values include: 2194 0: unknown 2195 1: audit log written to 2196 2: audit log cleared 2197 3: policy created 2198 4: policy edited 2199 5: policy deleted 2200 6: policy executed 2202 B.4. TimeSecurityEvent Class Description 2204 The purpose of a TimeSecurityEvent is to represent Events that are 2205 temporal in nature (e.g., the start or end of a period of time). 2206 Time events signify an individual occurrence, or a time period, in 2207 which a significant event happened. Information in this Event may be 2208 used as part of a test to determine if the Condition clause in this 2209 ECA Policy Rule should be evaluated or not. Examples include issuing 2210 an Event at a specific time to indicate that a particular resource 2211 should not be accessed, or that different authentication and 2212 authorization mechanisms should now be used (e.g., because it is now 2213 past regular business hours). 2215 The TimeSecurityEvent class defines the following attributes. 2217 B.4.1. The timeSecEventPeriodBegin Attribute 2219 This is a mandatory DateTime attribute, and represents the beginning 2220 of a time period. It has a value that has a date and/or a time 2221 component (as in the Java or Python libraries). 2223 B.4.2. The timeSecEventPeriodEnd Attribute 2225 This is a mandatory DateTime attribute, and represents the end of a 2226 time period. It has a value that has a date and/or a time component 2227 (as in the Java or Python libraries). If this is a single Event 2228 occurence, and not a time period when the Event can occur, then the 2229 timeSecEventPeriodEnd attribute may be ignored. 2231 B.4.3. The timeSecEventTimeZone Attribute 2233 This is a mandatory string attribute, and defines the time zone that 2234 this Event occurred in using the format specified in ISO8601. 2236 Appendix C. Network Security Condition Class Definitions 2238 This Appendix defines a preliminary set of Network Security Condition 2239 classes, along with their attributes. 2241 C.1. PacketSecurityCondition 2243 The purpose of this Class is to represent packet header information 2244 that can be used as part of a test to determine if the set of Policy 2245 Actions in this ECA Policy Rule should be executed or not. This class 2246 is abstract, and serves as the superclass of more detailed conditions 2247 that act on different types of packet formats. Its subclasses are 2248 shown in Figure 16, and are defined in the following sections. 2250 +-------------------------+ 2251 | PacketSecurityCondition | 2252 +------------+------------+ 2253 / \ 2254 | 2255 | 2256 +---------+----------+---+-----+----------+ 2257 | | | | | 2258 | | | | | 2259 +--------+-------+ | +--------+-------+ | +--------+-------+ 2260 | PacketSecurity | | | PacketSecurity | | | PacketSecurity | 2261 | MACCondition | | | IPv4Condition | | | IPv6Condition | 2262 +----------------+ | +----------------+ | +----------------+ 2263 | | 2264 +--------+-------+ +--------+-------+ 2265 | TCPCondition | | UDPCondition | 2266 +----------------+ +----------------+ 2268 Figure 16. Network Security Info Sub-Model PacketSecurityCondition 2269 Class Extensions 2271 C.1.1. PacketSecurityMACCondition 2273 The purpose of this Class is to represent packet MAC packet header 2274 information that can be used as part of a test to determine if the 2275 set of Policy Actions in this ECA Policy Rule should be executed or 2276 not. This class is concrete, and defines the following attributes. 2278 C.1.1.1. The pktSecCondMACDest Attribute 2280 This is a mandatory string attribute, and defines the MAC 2281 destination address (6 octets long). 2283 C.1.1.2. The pktSecCondMACSrc Attribute 2285 This is a mandatory string attribute, and defines the MAC source 2286 address (6 octets long). 2288 C.1.1.3. The pktSecCondMAC8021Q Attribute 2290 This is an optional string attribute, and defines the 802.1Q tag 2291 value (2 octets long). This defines VLAN membership and 802.1p 2292 priority values. 2294 C.1.1.4. The pktSecCondMACEtherType Attribute 2296 This is a mandatory string attribute, and defines the EtherType 2297 field (2 octets long). Values up to and including 1500 indicate the 2298 size of the payload in octets; values of 1536 and above define 2299 which protocol is encapsulated in the payload of the frame. 2301 C.1.1.5. The pktSecCondMACTCI Attribute 2303 This is an optional string attribute, and defines the Tag Control 2304 Information. This consists of a 3 bit user priority field, a drop 2305 eligible indicator (1 bit), and a VLAN identifier (12 bits). 2307 C.1.2. PacketSecurityIPv4Condition 2309 The purpose of this Class is to represent packet IPv4 packet header 2310 information that can be used as part of a test to determine if the 2311 set of Policy Actions in this ECA Policy Rule should be executed or 2312 not. This class is concrete, and defines the following attributes. 2314 C.1.2.1. The pktSecCondIPv4SrcAddr Attribute 2316 This is a mandatory string attribute, and defines the IPv4 Source 2317 Address (32 bits). 2319 C.1.2.2. The pktSecCondIPv4DestAddr Attribute 2321 This is a mandatory string attribute, and defines the IPv4 2322 Destination Address (32 bits). 2324 C.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute 2326 This is a mandatory string attribute, and defines the protocol used 2327 in the data portion of the IP datagram (8 bits). 2329 C.1.2.4. The pktSecCondIPv4DSCP Attribute 2331 This is a mandatory string attribute, and defines the Differentiated 2332 Services Code Point field (6 bits). 2334 C.1.2.5. The pktSecCondIPv4ECN Attribute 2336 This is an optional string attribute, and defines the Explicit 2337 Congestion Notification field (2 bits). 2339 C.1.2.6. The pktSecCondIPv4TotalLength Attribute 2341 This is a mandatory string attribute, and defines the total length 2342 of the packet (including header and data) in bytes (16 bits). 2344 C.1.2.7. The pktSecCondIPv4TTL Attribute 2346 This is a mandatory string attribute, and defines the Time To Live 2347 in seconds (8 bits). 2349 C.1.3. PacketSecurityIPv6Condition 2351 The purpose of this Class is to represent packet IPv6 packet header 2352 information that can be used as part of a test to determine if the 2353 set of Policy Actions in this ECA Policy Rule should be executed or 2354 not. This class is concrete, and defines the following attributes. 2356 C.1.3.1. The pktSecCondIPv6SrcAddr Attribute 2358 This is a mandatory string attribute, and defines the IPv6 Source 2359 Address (128 bits). 2361 C.1.3.2. The pktSecCondIPv6DestAddr Attribute 2363 This is a mandatory string attribute, and defines the IPv6 2364 Destination Address (128 bits). 2366 C.1.3.3. The pktSecCondIPv6DSCP Attribute 2368 This is a mandatory string attribute, and defines the Differentiated 2369 Services Code Point field (6 bits). It consists of the six most 2370 significant bits of the Traffic Class field in the IPv6 header. 2372 C.1.3.4. The pktSecCondIPv6ECN Attribute 2374 This is a mandatory string attribute, and defines the Explicit 2375 Congestion Notification field (2 bits). It consists of the two least 2376 significant bits of the Traffic Class field in the IPv6 header. 2378 C.1.3.5. The pktSecCondIPv6FlowLabel Attribute 2380 This is a mandatory string attribute, and defines an IPv6 flow 2381 label. This, in combination with the Source and Destination Address 2382 fields, enables efficient IPv6 flow classification by using only the 2383 IPv6 main header fields (20 bits). 2385 C.1.3.6. The pktSecCondIPv6PayloadLength Attribute 2387 This is a mandatory string attribute, and defines the total length 2388 of the packet (including the fixed and any extension headers, and 2389 data) in bytes (16 bits). 2391 C.1.3.7. The pktSecCondIPv6NextHeader Attribute 2393 This is a mandatory string attribute, and defines the type of the 2394 next header (e.g., which extension header to use) (8 bits). 2396 C.1.3.8. The pktSecCondIPv6HopLimit Attribute 2398 This is a mandatory string attribute, and defines the maximum 2399 number of hops that this packet can traverse (8 bits). 2401 C.1.4. PacketSecurityTCPCondition 2403 The purpose of this Class is to represent packet TCP packet header 2404 information that can be used as part of a test to determine if the 2405 set of Policy Actions in this ECA Policy Rule should be executed or 2406 not. This class is concrete, and defines the following attributes. 2408 C.1.4.1. The pktSecCondTPCSrcPort Attribute 2410 This is a mandatory string attribute, and defines the Source Port 2411 number (16 bits). 2413 C.1.4.2. The pktSecCondTPCDestPort Attribute 2415 This is a mandatory string attribute, and defines the Destination 2416 Port number (16 bits). 2418 C.1.4.3. The pktSecCondTCPSeqNum Attribute 2420 This is a mandatory string attribute, and defines the sequence 2421 number (32 bits). 2423 C.1.4.4. The pktSecCondTCPFlags Attribute 2425 This is a mandatory string attribute, and defines the nine Control 2426 bit flags (9 bits). 2428 C.1.5. PacketSecurityUDPCondition 2430 The purpose of this Class is to represent packet UDP packet header 2431 information that can be used as part of a test to determine if the 2432 set of Policy Actions in this ECA Policy Rule should be executed or 2433 not. This class is concrete, and defines the following attributes. 2435 C.1.5.1.1. The pktSecCondUDPSrcPort Attribute 2437 This is a mandatory string attribute, and defines the UDP Source 2438 Port number (16 bits). 2440 C.1.5.1.2. The pktSecCondUDPDestPort Attribute 2442 This is a mandatory string attribute, and defines the UDP 2443 Destination Port number (16 bits). 2445 C.1.5.1.3. The pktSecCondUDPLength Attribute 2447 This is a mandatory string attribute, and defines the length in 2448 bytes of the UDP header and data (16 bits). 2450 C.2. PacketPayloadSecurityCondition 2452 The purpose of this Class is to represent packet payload data that 2453 can be used as part of a test to determine if the set of Policy 2454 Actions in this ECA Policy Rule should be executed or not. Examples 2455 include a specific set of bytes in the packet payload. 2457 C.3. TargetSecurityCondition 2459 The purpose of this Class is to represent information about 2460 different targets of this policy (i.e., entities to which this 2461 Policy Rule should be applied), which can be used as part of a 2462 test to determine if the set of Policy Actions in this ECA Policy 2463 Rule should be executed or not. Examples include whether the 2464 targeted entities are playing the same role, or whether each 2465 device is administered by the same set of users, groups, or roles. 2466 This Class has several important subclasses, including: 2468 a. ServiceSecurityContextCondition is the superclass for all 2469 information that can be used in an ECA Policy Rule that 2470 specifies data about the type of service to be analyzed 2471 (e.g., the protocol type and port number) 2472 b. ApplicationSecurityContextCondition is the superclass for all 2473 information that can be used in a ECA Policy Rule that 2474 specifies data that identifies a particular application 2475 (including metadata, such as risk level) 2476 c. DeviceSecurityContextCondition is the superclass for all 2477 information that can be used in a ECA Policy Rule that 2478 specifies data about a device type and/or device OS that is 2479 being used 2481 C.4. UserSecurityCondition 2483 The purpose of this Class is to represent data about the user or 2484 group referenced in this ECA Policy Rule that can be used as part of 2485 a test to determine if the set of Policy Actions in this ECA Policy 2486 Rule should be evaluated or not. Examples include the user or group 2487 id used, the type of connection used, whether a given user or group 2488 is playing a particular role, or whether a given user or group has 2489 failed to login a particular number of times. 2491 C.5. SecurityContextCondition 2493 The purpose of this Class is to represent security conditions that 2494 are part of a specific context, which can be used as part of a test 2495 to determine if the set of Policy Actions in this ECA Policy Rule 2496 should be evaluated or not. Examples include testing to determine 2497 if a particular pattern of security-related data have occurred, or 2498 if the current session state matches the expected session state. 2500 C.6. GenericContextSecurityCondition 2502 The purpose of this Class is to represent generic contextual 2503 information in which this ECA Policy Rule is being executed, which 2504 can be used as part of a test to determine if the set of Policy 2505 Actions in this ECA Policy Rule should be evaluated or not. 2506 Examples include geographic location and temporal information. 2508 Appendix D. Network Security Action Class Definitions 2510 This Appendix defines a preliminary set of Network Security Action 2511 classes, along with their attributes. 2513 D.1. IngressAction 2515 The purpose of this Class is to represent actions performed on 2516 packets that enter an NSF. Examples include pass, dropp, or 2517 mirror traffic. 2519 D.2. EgressAction 2521 The purpose of this Class is to represent actions performed on 2522 packets that exit an NSF. Examples include pass, drop, or mirror 2523 traffic, signal, and encapsulate. 2525 D.3. ApplyProfileAction 2527 The purpose of this Class is to define the application of a profile 2528 to packets to perform content security and/or attack mitigation 2529 control. 2531 Appendix E. Geometric Model 2533 The geometric model defined in [Bas12] is summarized here. Note that 2534 our work has extended the work of [Bas12] to model ECA Policy Rules, 2535 instead of just condition-action Policy Rules. However, the 2536 geometric model in this Appendix is simplified in this version of 2537 this I-D, and is used to define just the CA part of the ECA model. 2539 All the actions available to the security function are well known 2540 and organized in an action set A. 2542 For filtering controls, the enforceable actions are either Allow or 2543 Deny, thus A={Allow,Deny}. For channel protection controls, they may 2544 be informally written as "enforce confidentiality", "enforce data 2545 authentication and integrity", and "enforce confidentiality and data 2546 authentication and integrity". However, these actions need to be 2547 instantiated to the technology used. For example, AH-transport mode 2548 and ESP-transport mode (and combinations thereof) are a more precise 2549 definition of channel protection actions. 2551 Conditions are typed predicates concerning a given selector. A 2552 selector describes the values that a protocol field may take. For 2553 example, the IP source selector is the set of all possible IP 2554 addresses, and it may also refer to the part of the packet where the 2555 values come from (e.g., the IP source selector refers to the IP 2556 source field in the IP header). Geometrically, a condition is the 2557 subset of its selector for which it evaluates to true. A condition 2558 on a given selector matches a packet if the value of the field 2559 referred to by the selector belongs to the condition. For instance, 2560 in Figure 17 the conditions are s1 <= S1 (read as s1 subset of or 2561 equal to S1) and s2 <= S2 (s1 of or equal to S2), both s1 and s2 2562 match the packet x1, while only s2 matches x2. 2564 To consider conditions in different selectors, the decision space is 2565 extended using the Cartesian product because distinct selectors 2566 refer to different fields, possibly from different protocol headers. 2567 Hence, given a policy-enabled element that allows the definition of 2568 conditions on the selectors S1, S2,..., Sm (where m is the number 2569 of Selectors available at the security control we want to model), 2570 its selection space is: 2572 S=S1 X S2 X ... X Sm 2574 To consider conditions in different selectors, the decision space is 2575 extended using the Cartesian product because distinct selectors 2576 refer to different fields, possibly from different protocol headers. 2578 S2 ^ Destination port 2579 | 2580 | x2 2581 +......o 2582 | . 2583 | . 2584 --+.............+------------------------------------+ 2585 | | . | | 2586 s | . | | 2587 e | . | (rectangle) | 2588 g | . | condition clause (c) | 2589 m | . | here the action a is applied | 2590 e | . | | 2591 n | . | x1=point=packet | 2592 t +.............|.............o | 2593 | | . | . | 2594 --+.............+------------------------------------+ 2595 | . . . . 2596 | . . . . 2597 +------------+------+-------------+----------------------+------> 2598 | |---- segment = condition in S1 -----| S1 2599 + IP source 2601 Figure 17: Geometric representation of a rule r=(c,a) that 2602 matches x1, but does not match x2. 2604 Accordingly, the condition clause c is a subset of S: 2606 c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S 2608 S represents the totality of the packets that are individually 2609 selectable by the security control to model when we use it to 2610 enforce a policy. Unfortunately, not all its subsets are valid 2611 condition clauses: only hyper-rectangles, or the union of 2612 hyper-rectangles (as they are Cartesian product of conditions), 2613 are valid. This is an intrinsic constraint of the policy 2614 language, as it specifies rules by defining a condition for each 2615 selector. Languages that allow specification of conditions as 2616 relations over more fields are modeled by the geometric model as 2617 more complex geometric shapes determined by the equations. However, 2618 the algorithms to compute intersections are much more sophisticated 2619 than intersection hyper-rectangles. Figure 17 graphically represents 2620 a condition clause c in a two-dimensional selection space. 2622 In the geometric model, a rule is expressed as r=(c,a), where c <= S 2623 (the condition clause is a subset of the selection space), and the 2624 action a belongs to A. Rule condition clauses match a packet (rules 2625 match a packet), if all the conditions forming the clauses match the 2626 packet. In Figure 17, the rule with condition clause c matches the 2627 packet x1 but not x2. 2629 The rule set R is composed of n rules ri=(ci,ai). 2631 The decision criteria for the action to apply when a packet matches 2632 two or more rules is abstracted by means of the resolution strategy 2634 RS: Pow(R) -> A 2636 where Pow(R) is the power set of rules in R. 2638 Formally, given a set of rules, the resolution strategy maps all the 2639 possible subsets of rules to an action a in A. When no rule matches a 2640 packet, the security controls may select the default action d in A, 2641 if they support one. 2643 Resolution strategies may use, besides intrinsic rule data (i.e., 2644 condition clause and action clause), also external data associated to 2645 each rule, such as priority, identity of the creator, and creation 2646 time. Formally, every rule ri is associated by means of the 2647 function e(.): 2649 e(ri) = (ri,f1(ri),f2(ri),...) 2651 where E={fj:R -> Xj} (j=1,2,...) is the set that includes all 2652 functions that map rules to external attributes in Xj. However, 2653 E, e, and all the Xj are determined by the resolution strategy used. 2655 A policy is thus a function p: S -> A that connects each point of 2656 the selection space to an action taken from the action set A 2657 according to the rules in R. By also assuming RS(0)=d (where 0 is 2658 the empty-set) and RS(ri)=ai, the policy p can be described as: 2660 p(x)=RS(match{R(x)}). 2662 Therefore, in the geometric model, a policy is completely defined by 2663 the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS, 2664 the set E of mappings to the external attributes, and the default 2665 action d. 2667 Note that, the geometric model also supports ECA paradigms by simply 2668 modeling events like an additional selector. 2670 Authors' Addresses 2671 Liang Xia (Frank) 2672 Huawei 2673 101 Software Avenue, Yuhuatai District 2674 Nanjing, Jiangsu 210012 2675 China 2676 Email: Frank.xialiang@huawei.com 2678 John Strassner 2679 Huawei 2680 Email: John.sc.Strassner@huawei.com 2682 Cataldo Basile 2683 Politecnico di Torino 2684 Corso Duca degli Abruzzi, 34 2685 Torino, 10129 2686 Italy 2687 Email: cataldo.basile@polito.it 2689 Diego R. Lopez 2690 Telefonica I+D 2691 Zurbaran, 12 2692 Madrid, 28010 2693 Spain 2694 Phone: +34 913 129 041 2695 Email: diego.r.lopez@telefonica.com