idnits 2.17.1 draft-xibassnez-i2nsf-capability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** There are 2 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([I-D.draft-xia-i2nsf-capability-interface-im-06], [I-D.draft-baspez-i2nsf-capabilities-00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2016) is 2734 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) -- Missing reference section? 'I-D.draft-baspez-i2nsf-capabilities-00' on line 2033 looks like a reference -- Missing reference section? 'I-D.draft-ietf-i2nsf-problem-and-use-cases' on line 2016 looks like a reference -- Missing reference section? 'I-D.draft-ietf-i2nsf-framework' on line 2020 looks like a reference -- Missing reference section? 'I-D.draft-zhang-i2nsf-info-model-monitoring' on line 225 looks like a reference -- Missing reference section? 'RFC2119' on line 1989 looks like a reference -- Missing reference section? 'I-D.draft-ietf-i2nsf-terminology' on line 2024 looks like a reference -- Missing reference section? 'I-D.draft-ietf-supa-generic-policy-info-model' on line 2028 looks like a reference -- Missing reference section? 'Alshaer' on line 2041 looks like a reference -- Missing reference section? 'Bas12' on line 2044 looks like a reference -- Missing reference section? 'RFC3198' on line 2004 looks like a reference -- Missing reference section? 'Bas15' on line 2047 looks like a reference -- Missing reference section? 'Lunt' on line 2052 looks like a reference -- Missing reference section? 'Cormen' on line 2050 looks like a reference -- Missing reference section? 'Taylor' on line 2055 looks like a reference -- Missing reference section? 'RFC2234' on line 1992 looks like a reference -- Missing reference section? 'RFC6020' on line 1996 looks like a reference -- Missing reference section? 'RFC5511' on line 2000 looks like a reference -- Missing reference section? 'INCITS359 RBAC' on line 2012 looks like a reference -- Missing reference section? 'I-D.draft-xia-i2nsf-capability-interface-im-06' on line 2037 looks like a reference -- Missing reference section? 'RFC2975' on line 2243 looks like a reference -- Missing reference section? 'RFC3539' on line 2243 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 23 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 D.Zhang 4 Huawei 5 K. Li 6 Alibaba 7 C. Basile 8 A. Lioy 9 PoliTO 10 D. Lopez 11 TID 12 E. Lopez 13 Fortinet 14 N. BOUTHORS 15 Qosmos 16 Luyuan Fang 17 Microsoft 19 Expires: December 2017 November 1, 2016 21 Information Model of NSFs Capabilities 22 draft-xibassnez-i2nsf-capability-00.txt 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 1,2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Abstract 64 This draft aims at defining the concept of capability. Capabilities 65 are data that unambiguously characterize NSFs (Network Security 66 Functions). Their correct definition will ease all the management 67 and automation that can be. Moreover, it allows the definition of 68 Interfaces to manage NSFs. 70 This draft is the first trial to merge two previous existing drafts 71 on NSFs capabilities [I-D.draft-baspez-i2nsf-capabilities-00] and on 72 the capability interface [I-D.draft-xia-i2nsf-capability-interface- 73 im-06]. Further work will be needed to homogenize all the concepts 74 and incorporate the feedback that will result after its publication. 76 Table of Contents 78 1. Introduction ................................................ 4 79 2. Conventions used in this document ........................... 6 80 2.1. Terminology ............................................ 6 81 3. Management of NSFs: Design Principles towards a model of 82 Capabilities ................................................... 7 83 4. Information Model .......................................... 10 84 5. Capabilities for security policy enforcement ............... 12 85 5.1. The CA Policy Model ................................... 13 86 5.2. Geometric Model of CA Policies ........................ 14 87 5.3. Condition Types ....................................... 17 88 5.4. Model of Capabilities for Policy Specification and Enforcement 89 Purposes ................................................... 19 90 5.5. Algebra of capabilities ............................... 20 91 5.6. Examples of NSFs Categories ........................... 21 92 5.6.1. Network Security ................................. 22 93 5.6.2. Content Security .................................. 22 94 5.6.3. Attack Mitigation ................................. 22 95 6. Information Sub-Model for Network Security Capabilities ..... 23 96 6.1. Information Sub-Model for Network Security ............. 23 97 6.1.1. Network Security Policy Rule Extensions ........... 24 98 6.1.2. Network Security Policy Rule Operation ............ 26 99 6.1.3. Network Security Event Sub-Model .................. 27 100 6.1.3.1. UserSecurityEvent Class Description .......... 29 101 6.1.3.1.1. The usrSecEventContent Attribute ........ 29 102 6.1.3.1.2. The usrSecEventFormat Attribute.......... 29 103 6.1.3.1.3. The usrSecEventType Attribute ........... 30 104 6.1.3.2. DeviceSecurityEvent Class Description ........ 30 105 6.1.3.2.1. The devSecEventContent Attribute ........ 30 106 6.1.3.2.2. The devSecEventFormat Attribute.......... 31 107 6.1.3.2.3. The devSecEventType Attribute ........... 31 108 6.1.3.2.4. The devSecEventTypeInfo[0..n] Attribute . 31 109 6.1.3.2.5. The devSecEventTypeSeverity Attribute ... 32 110 6.1.3.3. SystemSecurityEvent Class Description ........ 32 111 6.1.3.3.1. The sysSecEventContent Attribute ........ 32 112 6.1.3.3.2. The sysSecEventFormat Attribute.......... 33 113 6.1.3.3.3. The sysSecEventType Attribute ........... 33 114 6.1.3.4. TimeSecurityEvent Class Description .......... 33 115 6.1.3.4.1. The timeSecEventPeriodBegin Attribute ... 34 116 6.1.3.4.2. The timeSecEventPeriodEnd Attribute ..... 34 117 6.1.3.4.3. The timeSecEventTimeZone Attribute ...... 34 118 6.1.4. Network Security Condition Sub-Model .............. 34 119 6.1.4.1. PacketSecurityCondition ...................... 36 120 6.1.4.1.1. PacketSecurityMACCondition .............. 36 121 6.1.4.1.1.1. The pktSecCondMACDest Attribute .... 37 122 6.1.4.1.1.2. The pktSecCondMACSrc Attribute ..... 37 123 6.1.4.1.1.3. The pktSecCondMAC8021Q Attribute ... 37 124 6.1.4.1.1.4. The pktSecCondMACEtherType Attribute 37 125 6.1.4.1.1.5. The pktSecCondMACTCI Attribute ..... 37 126 6.1.4.1.2. PacketSecurityIPv4Condition ............. 37 127 6.1.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute 37 128 6.1.4.1.2.2. The pktSecCondIPv4DestAddr Attribute 37 129 6.1.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute 130 ................................................ 38 131 6.1.4.1.2.4. The pktSecCondIPv4DSCP Attribute ... 38 132 6.1.4.1.2.5. The pktSecCondIPv4ECN Attribute .... 38 133 6.1.4.1.2.6. The pktSecCondIPv4TotalLength Attribute 134 ................................................ 38 135 6.1.4.1.2.7. The pktSecCondIPv4TTL Attribute .... 38 136 6.1.4.1.3. PacketSecurityIPv6Condition ............. 38 137 6.1.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute 38 138 6.1.4.1.3.2. The pktSecCondIPv6DestAddr Attribute 38 139 6.1.4.1.3.3. The pktSecCondIPv6DSCP Attribute ... 38 140 6.1.4.1.3.4. The pktSecCondIPv6ECN Attribute .... 39 141 6.1.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute39 142 6.1.4.1.3.6. The pktSecCondIPv6PayloadLength 143 Attribute ....................................... 39 144 6.1.4.1.3.7. The pktSecCondIPv6NextHeader Attribute39 145 6.1.4.1.3.8. The pktSecCondIPv6HopLimit Attribute 39 146 6.1.4.1.4. PacketSecurityTCPCondition .............. 39 147 6.1.4.1.4.1. The pktSecCondTPCSrcPort Attribute . 39 148 6.1.4.1.4.2. The pktSecCondTPCDestPort Attribute 39 149 6.1.4.1.4.3. The pktSecCondTPCSeqNum Attribute .. 40 150 6.1.4.1.4.4. The pktSecCondTPCFlags Attribute ... 40 151 6.1.4.1.5. PacketSecurityUDPCondition .............. 40 152 6.1.4.1.5.1. The pktSecCondUDPSrcPort Attribute . 40 153 6.1.4.1.5.2. The pktSecCondUDPDestPort Attribute 40 154 6.1.4.1.5.3. The pktSecCondUDPLength Attribute .. 40 155 6.1.4.2. PacketPayloadSecurityCondition ............... 40 156 6.1.4.3. TargetSecurityCondition ...................... 40 157 6.1.4.4. UserSecurityCondition ........................ 41 158 6.1.4.5. SecurityContextCondition ..................... 41 159 6.1.4.6. GenericContextSecurityCondition .............. 41 160 6.1.5. Network Security Action Sub-Model ................. 42 161 6.1.5.1. IngressAction ................................ 43 162 6.1.5.2. EgressAction ................................. 43 163 6.1.5.3. ApplyProfileAction ........................... 43 164 6.1.5.4. ApplySignatureAction ......................... 43 165 6.2. Information Model for Content Security Control ......... 43 166 6.3. Information Model for Attack Mitigation Control ........ 44 167 7. Security Considerations ..................................... 45 168 8. IANA Considerations ......................................... 46 169 9. References .................................................. 46 170 9.1. Normative References ................................... 46 171 9.2. Informative References ................................. 46 172 10. Acknowledgments ............................................ 47 173 Appendix A. .................................................... 48 174 A.1. AuthenticationECAPolicyRule Class Definition ........... 48 175 A.2. AuthorizationECAPolicyRuleClass Definition ............. 50 176 A.3. AccountingECAPolicyRuleClass Definition ................ 52 177 A.4. TrafficInspectionECAPolicyRuleClass Definition.......... 54 178 A.5. ApplyProfileECAPolicyRuleClass Definition .............. 56 179 A.6. ApplySignatureECAPolicyRuleClass Definition ............ 58 181 1. Introduction 183 The rapid development of virtualized systems, along with the demand 184 of security services in virtualized systems, requires advanced 185 security protection in various scenarios. Examples include network 186 devices in an enterprise network, User Equipment (UE) in a mobile 187 network, devices in the Internet of Things (IoT), or residential 188 access users [I-D.draft-ietf-i2nsf-problem-and-use-cases]. 190 Capabilities are precise information that characterize in an 191 unambiguous way (in a given virtualized system) what a NSF can do in 192 terms of security policy enforcement and how a Controller can 193 interact with it in order to enforce a security policy. Even if the 194 aim is a general of capabilities, the unambiguity of capabilities is 195 only assured in a given virtualized system. 197 According to [I-D.draft-ietf-i2nsf-framework], there are two types 198 of I2NSF interfaces available for security rules provisioning: 200 o Interface between I2NSF clients and a security controller (Client 201 Facing Interface): This is a service-oriented interface, whose 202 main objective is to define a communication channel over which 203 information defining security services controlling client's 204 specific flow can be requested. This enables security information 205 to be exchanged between various applications (e.g., OpenStack, or 206 various BSS/OSS components) and other components (e.g., security 207 controllers). The design goal of the service interface is to 208 decouple the security service in the application layer from 209 various kinds of security devices and their device-specific 210 security functions. 212 Interface between NSFs (e.g., firewall, intrusion prevention, or 213 anti-virus) and a security controller (NSFs Facing Interface): 214 This interface is independent of how the NSFs are implemented 215 (e.g., run in Virtual Machines (VMs) or physical appliances). The 216 NSFs Facing Interface is used to decouple the security management 217 scheme from the set of NSFs and their various implementations for 218 this scheme, so as to specify and monitor a number of flow based 219 security policies to individual NSFs. According to the definition 220 in [I-D.draft-ietf-i2nsf-framework], NSFs Facing Interface 221 includes sub-interfaces of Capability Interface, Registration 222 Interface and Monitoring Interface. This document proposes the 223 information model design for the first two interfaces (Capability 224 and Registration), the Monitoring Interface information model is 225 discussed in [I-D.draft-zhang-i2nsf-info-model-monitoring]. 227 This document is organized as follows: Section 3 discusses the 228 design principles for NSF capabilities and related ECA model. 229 Section 4 further describes design principles for I2NSF capability 230 information model. Section 5 provides more details about the design 231 of network security capability. Section 6 presents further 232 information on specific aspects of the information model. 234 2. Conventions used in this document 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in RFC-2119 [RFC2119]. 240 This document references to [I-D.draft-ietf-i2nsf-terminology] for 241 more specific security related and I2NSF scoped terminology 242 definitions. 244 2.1. Terminology 246 AAA -Access control, Authorization, Authentication 248 ACL - Access Control List 250 AD - Active Directory 252 ANSI - American National Standards Institute 254 DDoS - Distributed Deny of Services 256 FW - Firewall 258 I2NSF - Interface to Network Security Functions 260 INCITS - International Committee for Information Technology 261 Standards 263 IoT - Internet of Things 265 IPS - Intrusion Prevention System 267 LDAP - Lightweight Directory Access Protocol 269 NAT - Network Address Translation 271 NBI - North-bound Interface 273 NIST - National Institute of Standard Technology 275 NSF - Network Security Function 277 RBAC - Role Based Access Control 279 UE - User Equipment 280 URL - Uniform/Universal Resource Locator 282 VM - Virtual Machine 284 WAF - Web Application Firewall 286 3. Management of NSFs: Design Principles towards a model of 287 Capabilities 289 Some basic principles for security capabilities and the systems that 290 have to manage them need to be considered: 292 o Flexibility: each security capability should be an independent 293 function, with minimum overlap or dependency to other 294 capabilities. This enables each security capability to be 295 utilized and assembled together freely. More importantly, changes 296 to one capability will not affect other capabilities; 298 o High level of abstraction: each capability should be associated 299 to a unified interface to make it programmable; this in turn 300 provides a standardized ability to describe and report its 301 processing results and corresponding statistics information. 302 Furthermore, it facilitates the multi-vendor interoperability; 304 o Automation: The system must have the ability to auto-discover, 305 auto-negotiate, and auto-update security capabilities. These 306 features are especially useful for the management of a large 307 number of NSFs. They are essential to add smart services 308 (refinement, analysis, capability reasoning, optimization) on top 309 of the virtual layer; 311 o Scalability: the management system must have the capability to 312 scale up/down or scale in/out. Thus, it can meet various 313 performance requirements derived from changeable network traffic 314 or service requests. In addition, the security capability must 315 support reporting statistics to the security controller to assist 316 its decision on whether it needs to invoke scaling or not. 318 Based on the above principles, a set of abstract and vendor-neutral 319 capabilities with standard interfaces is needed together with a 320 model of capabilities that allows to unambiguously determine what 321 NSFs can do in terms of security policy enforcement. The security 322 controller can compare the requirements of clients to the set of 323 capabilities that are currently available in order to choose which 324 NSFs are needed to meet those requirements. Note that this choice is 325 independent of vendor, and instead relies specifically on the 326 capabilities (i.e., the description) of the functions provided. This 327 also facilitates the customization of the functionality of the 328 selected NSFs by setting the parameters of their interfaces. 330 Furthermore, when an unknown threat (e.g., zero-day exploits, 331 unknown malware, and APTs) is reported by a network security device, 332 new capabilities may be created, and/or existing capabilities may be 333 updated (e.g., signature and algorithm), to correspond to the new 334 functionality provided by the NSF to handle the threat. The new 335 capabilities are provided from different vendors after their 336 analysis of the new threats and subsequent installation of the 337 functions required to report on (and possibly mitigate) the threat. 338 New capabilities may be sent to and stored in a centralized 339 repository, or stored separately in a local repository. In either 340 cases, a standard interface is needed during this automated update 341 process. 343 In defining the capabilities of a NSF, the "Event-Condition-Action" 344 (ECA) policy rule set model in [I-D.draft-ietf-i2nsf-framework] 345 should be here as the basis for the design: 347 o Event: An Event is defined as any important occurrence in time of 348 a change in the system being managed, and/or in the environment 349 of the system being managed. When used in the context of policy 350 rules for I2NSF, it is used to determine whether the Condition 351 clause of the Policy Rule can be evaluated or not. Examples of an 352 I2NSF Event include time and user actions (e.g., logon, logoff, 353 and actions that violate an ACL); 355 o Condition: A set of attributes, features, and/or values that are 356 to be compared with a set of known attributes, features, and/or 357 values in order to make a decision. When used in the context of 358 policy rules for I2NSF, it is used to determine whether or not 359 the set of Actions in that Policy Rule can be executed or not. 360 The following are exemplary types of conditions: 362 ? Packet content values: Refer to the kind of information or 363 attributes acquired directly from the packet headers or 364 payloads that can be used in the security policy. It can be 365 any fields or attributes in the packet L2/L3/L4 header, or 366 special segment of bytes in the packet payload; 368 ? Context values: Refer to the context information for the 369 received packets. It can be (and not limited to): 371 * User: The user (or user group) information to which a 372 network flow is associated. A user has many attributes, 373 such as name, id, password, authentication mode, and so 374 on. The combination of name and id (where id could be a 375 password, a certificate, or other means of identifying 376 the user) is often used in the security policy to 377 identify the user. For example, if an NSF is aware of 378 the IP (or MAC) address associated with the user, the 379 NSF can use a pre-defined or dynamically learned name- 380 address association to enforce the security functions 381 for this given user (or user group); 383 * Schedule: Time or time range when packet or flow is 384 received; 386 * Region: The geographic location where network traffic is 387 received; 389 * Target: The target indicates the entity to which the 390 security services are applied. This can be a service, 391 application, or device. A service is identified by the 392 protocol type and/or port number. An application is a 393 computer program for a specific task or purpose. It 394 provides additional semantics (e.g., dependencies 395 between services) for matching traffic. A device is a 396 managed entity that is connected to the network. The 397 attributes that can identify a device include type (e.g., 398 router, switch, pc) and operating system (e.g., Windows, 399 Linux, or Android), as well as the device's owner; 401 * State: It refers to various states to which the network 402 flow is associated. It can be either the TCP session 403 state (e.g., new, established, related, invalid, or 404 untracked), the session AAA state (e.g., authenticated 405 but not authorized), or the access mode of the device 406 (e.g., wireline, wireless, or cellular; these could be 407 augmented with additional attributes, such as the type 408 of VPN that is being used); 410 * Direction: the direction of the network flow. 412 o Action: NSFs provide security functions by executing various 413 Actions, which at least includes: 415 ? Ingress actions, such as pass, drop, mirroring, etc; 416 ? Egress actions, such as invoke signaling, tunnel 417 encapsulation, packet forwarding and/or transformation; 419 ? Applying a specific Functional Profile or signature - e.g., 420 an IPS Profile, a signature file, an anti-virus file, or a 421 URL filtering file. It is one of the key properties that 422 determine the effectiveness of the NSF, and is mostly vendor- 423 specific today. One goal of I2NSF is to standardize the form 424 and functional interface of those security capabilities while 425 supporting vendor-specific implementations of each. However, 426 it is important to properly model the parts that are related 427 to the action (what is enforced) and the conditions (on what 428 it is enforced). 430 The above ECA ruleset is very general and easily extensible, thus 431 can avoid any potential constraints which could limit the 432 implementation of the network security control capability. 434 4. Information Model 436 An information model will be developed in order to describe in an 437 abstract and vendor independent manner all the aspects related to 438 the capabilities of NSFs. A detailed information model will be 439 designed in the next versions of this draft as a consequence of the 440 discussions, feedback, and extensions that will originate after the 441 publication of this draft. In this version of the draft, we present 442 a simplified view that only highlights the most important concepts. 444 The I2NSF capability interface is in charge of controlling and 445 managing the NSFs by means of the information about the capabilities 446 each NSF owns. This is done using the following approach: 448 1) User of the capability interface selects the set of capabilities 449 required to meet the needs of the application; 451 2) A management entity uses the information model to match chosen 452 capabilities to NSFs, independent of vendor; 454 3) A management entity takes the above information and creates or 455 uses vendor-specific data models to install the NSFs identified by 456 the chosen capabilities; 458 4) Control and monitoring can then begin. 460 This assumes that an external model, or set of models, is used to 461 define the concept of an ECA Policy Rule and its components (e.g., 462 Event, Condition, and Action objects). 464 Since Capabilities are unambiguous only within the same management 465 system, and are not inherent characteristics that differentiate 466 objects, it is also assumed that an external model (or set of models) 467 will define a generic metadata concept. 469 The Capability is a general abstract concept. Currently, the most 470 promising approach for defining the information model of the 471 Capabilities uses the sub-classing to define non-overlapping and 472 independent concepts. For instance, the Capability model that will 473 be presented in the next sections that abstractly determines the 474 security policies that a NSF can enforce does not overlap with an 475 independent model that specifies how a NSF can be contacted by the 476 controller (i.e., the protocols and secure channels) and when (i.e., 477 the events to which it reacts). Capabilities are sub-classed from an 478 appropriate class in the external metadata model. 480 The capability interface is used for advertising, creating, 481 selecting and managing a set of specific security capabilities 482 independent of the type and vendor of device that contains the NSF. 483 That is, the user of the capability interface does not care whether 484 the NSF is virtualized or hosted in a physical device, the vendor of 485 the NSF, and which set of entities the NSF is communicating with 486 (e.g., a firewall or an IPS). Instead, the user only cares about the 487 set of capabilities that the NSF has, such as packet filtering or 488 deep packet inspection. The overall structure is illustrated in the 489 figure below: 491 +-------------------------+ 0..n 0..n +---------------+ 492 | |/ \ \| External | 493 | External ECA Info Model + A ----------------+ Metadata | 494 | |\ / Aggregates /| Info Model | 495 +-------------------------+ Metadata +------+--------+ 496 / \ 497 | 498 | 499 | 500 +----+-------+ 501 | Capability | 502 | Sub-Model | 503 +------------+ 505 Figure 1. The Overall I2NSF Information Model Design 507 This draft defines the Capability sub-Model shown in Figure 1. This 508 model assumes that another, generic, information model for defining 509 ECA policy rules (which includes a specific one for the CA part of 510 ECA policy rules) exists outside of I2NSF. 512 It also assumes that Capabilities are modeled as metadata, since a 513 Capability is something that describes and/or prescribes 514 functionality about an object, but is not an inherent part of that 515 object. Hence, the Security Capability Sub-Model extends the generic 516 external metadata model. 518 Both of these external models could, but do not have to, draw from 519 the SUPA model [I-D.draft-ietf-supa-generic-policy-info-model]. 521 The external ECA Information Model supplies at least a set of 522 objects that represent a generic ECA Policy Rule, and a set of 523 objects that represent Events, Conditions, and Actions that can be 524 aggregated by the generic ECA Policy Rule. This enables I2NSF to 525 reuse this generic model for different purposes. 527 It is assumed that the external ECA Information Model has the 528 ability to aggregate metadata. Capabilities are then sub-classed 529 from an appropriate class in the external Metadata Information Model; 530 this enables the ECA objects to use the existing aggregation between 531 them and Metadata to add Metadata to appropriate ECA objects. 533 Detailed descriptions of each portion of the information model are 534 given in the following sections. 536 5. Capabilities for security policy enforcement 538 At present, a variety of NSFs produced by multiple security vendors 539 provide various security capabilities to customers. Multiple NSFs 540 can be combined together to provide security services over the given 541 network traffic, regardless of whether the NSFs are implemented as 542 physical or virtual functions. 544 Security Capabilities are intended to describe the potentiality that 545 Network Security Functions (NSFs) have for security policy 546 enforcement purposes. Security Capabilities are abstract concepts 547 that are independent of the actual security control that will 548 implement them. However, every NSF will be associated to the 549 capabilities it owns. Security Capabilities are required to allow 550 differentiating among network functions. It would be a market 551 enabler having a way to substitute a NSF with an equivalent one 552 (i.e., having the same functionality). Moreover, Security 553 Capabilities are very useful to reason about generic functions, 554 which may be needed at design time. That is, it is not needed to 555 refer to a specific product when designing the network; rather the 556 functions characterized by their capabilities are considered. 558 Therefore, we have developed another model where Security 559 Capabilities determine what a security control can do in terms of 560 conditions, actions, resolution strategies, external data, if it 561 supports default action, etc. That is, Security Capabilities define 562 without any ambiguity the actions a function can do in term of 563 security policy enforcement. The Security Capability model is built 564 on a predefined general policy model. The type of policies that a 565 NSF can enforce is obtained by customizing the general policy model 566 with the Security Capability information. 568 The Capability Model has been preliminarily validated by verifying 569 that is allows the correct description of several existing security 570 controls. 572 5.1. The CA Policy Model 574 The starting point of the design of our capability model is a simple 575 observation. As human beings, we all understand immediately each 576 other when we refer to security controls by just naming their 577 category. For instance, experts agree on what is a NAT, a filtering 578 control, or a VPN concentrator. Network security experts 579 unequivocally refer to "packet filters" as stateless devices able to 580 allow or deny packets forwarding based on conditions on source and 581 destination IP addresses, source and destination ports, and IP 582 protocol type fields [Alshaer]. Moreover, it is known that packet 583 filter rules are prioritized and it is possible to specify a default 584 action. More precisely, packet filters implement the First Matching 585 Rule (FMR) or Last Matching Rule (LMR) resolution strategies. 587 However, we feel the need for more information in case of other 588 devices, like stateful firewalls or application layer filters. 589 These devices filter packets or communications, but there are 590 differences among products in the packets and communications that 591 they can categorize and the states they maintain. Analogous 592 considerations can be applied for channel protection protocols, 593 where we all understand that they will protect packets by means of 594 symmetric algorithms whose keys could have been negotiated with 595 asymmetric cryptography, but they may work at different layers and 596 support different algorithms and protocols. To ensure protection, 597 these protocols apply integrity, optionally confidentiality, apply 598 anti-reply protections, and authenticate peers. 600 The purpose is to build a model of security capabilities that allow 601 automatic management of virtualized systems, where intelligent 602 components are able to properly identify and manage NSFs, and allow 603 NSFs to properly declare their functionality so that they can be 604 used in the correct way. 606 5.2. Geometric Model of CA Policies 608 We refer in this draft to the policy model defined in [Bas12] as 609 geometric model, which is summarized here. Policies are specified by 610 means of a set of rules in the "if condition then action" format 611 [RFC3198]. Rules are formed by a condition clause and an action 612 clause. This model can be further extended to support events, that 613 is, in the Event-Condition-Action paradigms. However, for our 614 purpose, the geometric model will only be used to define the CA part 615 of the ECA model that we have selected as reference. 617 All the actions available to the security function are well known 618 and organized in an action set A. 620 For filtering controls, the enforceable actions are either Allow and 621 Deny, thus A={Allow,Deny}. For channel protection controls, they may 622 be informally written as "enforce confidentiality", "enforce data 623 authentication and integrity", and "enforce confidentiality and data 624 authentication and integrity". However, these actions need to be 625 instantiated to the technology used, for instance AH-transport mode 626 and ESP-transport mode (and combinations thereof) are a more precise 627 and univocal definition of channel protection actions. 629 Conditions are typed predicates concerning a given selector. A 630 selector describes the values that a protocol field may take, e.g., 631 the IP source selector is the set of all possible IP addresses, and 632 it may also refer to the part of the packet where the values come 633 from, e.g., the IP source selector refers to the IP source field in 634 the IP header. Geometrically, a condition is the subset of its 635 selector for which it evaluates to true. A condition on a given 636 selector matches a packet if the value of the field referred to by 637 the selector belongs to the condition. For instance, in Figure 2 638 the conditions are s1 <= S1 (read as s1 subset of or equal to S1) 639 and s2 <= S2 (s1 of or equal to S2), both s1 and s2 match the packet 640 x1, while only s2 matches x2. 642 S2 ^ Destination port 643 | 644 | 645 | x2 646 +......o 647 | . 648 | . 649 --+.............+------------------------------------+ 650 | | . | | 651 s | . | | 652 e | . | (rectangle) | 653 g | . | condition clause (c) | 654 m | . | here the action a is applied | 655 e | . | | 656 n | . | x1=point=packet | 657 t +.............|.............o | 658 | | . | . | 659 --+.............+------------------------------------+ 660 | . . . . 661 | . . . . 662 | . . . . 663 | . . . . 664 | . . . . 665 | . . . . 666 +------------+------+-------------+----------------------+------> 667 | |---- segment = condition in S1 -----| S1 668 + IP source 670 Figure 2: Geometric representation of a rule r=(c,a) that matches x1 671 but does not match x2. 673 To consider conditions in different selectors, the decision space is 674 extended using the Cartesian product because distinct selectors 675 refer to different fields, possibly from different protocol headers. 676 Hence, given a policy-enabled element that allows the definition of 677 conditions on the selectors S1, S2,..., Sm (where m is the number of 678 Selectors available at the security control we want to model), its 679 selection space is: 681 S=S1 X S2 X ... X Sm 683 To consider conditions in different selectors, the decision space is 684 extended using the Cartesian product because distinct selectors 685 refer to different fields, possibly from different protocol headers. 687 Accordingly, the condition clause c is a subset of S: 689 c = s1 X s2 X ... X sm <= S1 X S2 X ... X Sm = S 691 S represents the totality of the packets that are individually 692 selectable by the security control to model when we use it to 693 enforce a policy. Unfortunately, not all its subsets are valid 694 condition clauses: only hyper-rectangles or union of hyper- 695 rectangles (as they are Cartesian product of conditions) are valid. 696 This is an intrinsic constraint of the policy languages as they 697 specify rules by defining a condition for each selector. Languages 698 that allow specification of conditions as relations over more fields 699 are modeled by the geometric model as more complex geometric shapes 700 determined by the equations. However, the algorithms to compute 701 intersections are much more sophisticated than intersection hyper- 702 rectangles. Figure 1 graphically represents a condition clause c in 703 a two-dimensional selection space. 705 In the geometric model, a rule is expressed as r=(c,a), where c <= S 706 (the condition clause is a subset of the selection space), and the 707 action a belongs to A. Rule condition clauses matche a packet (rules 708 matche a packet), if all the conditions forming the clauses match 709 the packet: in Figure 1, the rule with condition clause c matches 710 the packet x1 but not x2. 712 The rule set R is composed of n rules ri=(ci,ai). 714 The decision criteria for the action to apply when a packet matches 715 two or more rules is abstracted by means of the resolution strategy 716 RS: Pow(R) -> A, where Pow(R) is the power set of rules in R. 718 Formally, given a set of rules, the resolution strategy maps all the 719 possible subsets of rules to an action a in A. When no rule matches 720 a packet, the security controls may select the default action d in A, 721 if they support one. 723 Resolution strategies may use, besides intrinsic rule data (i.e., 724 condition clause and action clause), also ``external data'' 725 associated to each rule, such as priority, identity of the creator, 726 and creation time. Formally, every rule ri is associated by means 727 of the function e(.) to: 729 e(ri) = (ri,f1(ri),f2(ri),...) 731 where E={fj:R -> Xj} (j=1,2,...) is the set that includes all the 732 functions that map rules to external attributes in Xj. However, E, e, 733 and all the Xj are determined by the resolution strategy used. 735 A policy is thus a function p: S -> A that connects each point of 736 the selection space to an action taken from the action set A 737 according to the rules in R. By also assuming RS(0)=d (where 0 is 738 the empty-set) and RS(ri)=ai, the policy p can be described with 739 this formula 741 p(x)=RS(match{R(x)}). 743 Therefore, in the geometric model, a policy is completely defined by 744 the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS, 745 the set E of mappings to the external attributes, and the default 746 action d. 748 Note that, the geometric model also supports ECA paradigms by simply 749 modeling events like an additional selector. 751 5.3. Condition Types 753 After having analyzed the literature and the existing security 754 controls, we have categorized the types of selectors in exact-match, 755 range-based, regex-based, and custom-match [Bas15][Lunt]. 757 Exact-match selectors are (unstructured) sets: elements can only be 758 checked for equality, as no order is defined on them. As an example, 759 the protocol type field of the IP header is a unordered set of 760 integer values associated to protocols. The assigned protocol 761 numbers are maintained by the IANA 762 (http://www.iana.org/assignments/protocol-numbers/protocol- 763 numbers.xhtml). 765 In this selector, it is only meaningful to specify conditions 767 proto = tcp, udp (protocol type field equals to TCP or UDP) 769 proto != tcp (protocol type field different from TCP) 771 No other operators are allowed on exact-match selectors, for 772 instance 774 proto < 62 (invalid condition) 776 is not a valid condition, even if protocol types map to integers. 778 Range-based selectors are ordered sets where it is possible to 779 naturally specify ranges as they can be easily mapped to integers. 781 As an example, the ports in the TCP protocol are well represented 782 using a range-based selector (e.g., 1024-65535). As an example 784 source_port = 80 786 source_port < 1024 788 source_port < 30000 && source_port >= 1024 790 are valid conditions. 792 We include in the range-based selectors all the category of 793 selectors that have been defined by Al-Shaer et al. as prefix match 794 [Alshaer]. These selectors allow the specification of ranges of 795 values by means of simple regular expressions. The typical case is 796 the IP address selector (e.g., 10.10.1.*). There is no need to 797 distinguish between prefix match and range-based selectors as 798 10.10.1.* easily maps to [10.10.1.0, 10.10.1.255]. 800 Another category of selector types includes the regex-based 801 selectors, where the matching is performed by using regular 802 expressions. This selector type is frequent at the application layer, 803 where data are often represented as strings of text. The regex-based 804 selector type also includes as sub-case the string-based selectors, 805 where matching is evaluated using string matching algorithms (SMA) 806 [Cormen] Indeed, for our purposes, string matching can be mapped to 807 regular expressions, even if in practice SMA are much faster. For 808 instance, Squid (http://www.squid-cache.org/), a popular Web caching 809 proxy that offers various access control capabilities, allows the 810 definition of conditions on URLs that can be evaluated with SMA 811 (e.g., dstdomain) or regex matching (e.g., dstdom_regex). 813 As an example, 815 URL = *.website.* 817 matches all the URLs that contain a domain, subdomain named website 818 and the ones whose path contain the string .website. 820 MIME_type = video/* 822 matches all the MIME objects whose type is video. 824 Finally, we introduce the idea of custom check selectors. For 825 instance the malware analysis looks for specific patterns and 826 returns a Boolean value is an example of custom check selector, if 827 the logic of checking is not seen (nor really interesting) from the 828 outside. 830 In order to be properly used by high-level policy based processed 831 (like reasoning systems, refinement systems) these custom check 832 selector need at least to be described as black-boxes, that is, the 833 list of fields that they process (inputs) in order to return the 834 Boolean verdict (output). 836 More examples of custom check selectors will be presented in the 837 next versions of the draft. Some example is already present in 838 Section 6. 840 5.4. Model of Capabilities for Policy Specification and Enforcement 841 Purposes 843 Our model of capabilities is based on actions and traffic 844 classification features. Indeed, the need for enforcing one of the 845 actions that a security control can apply to packets/flows is the 846 main reason to use a security control. Moreover, security controls 847 have classification features that permit the identification of the 848 target packets/flows of the actions enforced, i.e., the selectors 849 presented in Section 5.2. A security manager decides for a specific 850 security control depending on the actions and classification 851 features. If the security control can enforce the needed actions and 852 has the classification features needed to identify the packets flows 853 required by a policy, then the security control is capable of 854 enforcing the policy. Our refinement model needs to know NSFs 855 capabilities to perform its operations. 857 However, security controls may have specific characteristics that 858 automatic processes or administrators need to know when they have to 859 generate configurations, like the available resolution strategies 860 and the possibility to set default actions. We have ignored, to 861 simplify this presentation, options to generate configurations that 862 may have better performance, like the use of chains or ad hoc 863 structures [Taylor]. Adding support to these forms of optimization 864 is certainly feasible with a limited effort but it was outside the 865 scope of this paper, that is, to show that adding security awareness 866 to NFV management and orchestration features is possible. It is one 867 of the task for future work. 869 Capabilities can be used for two purposes: describing generic 870 security functions, and describing specific products. With the term 871 generic security function (GNSF) we denote known classes of security 872 functions. The idea is to have generic components whose behavior is 873 as well understood as for the network components (i.e., a switch is 874 a switch and we know to use it even if it may have some vendor- 875 specific functions). These generic functions can be substituted by 876 any product that owns the required capability at instantiation time. 878 We have analyzed several classes of NSFs to prove the validity of 879 our approach. We found the common features and defined a set of 880 generic NSFs, including packet filter, URL filter, HTTP filter, VPN 881 gateway, anti-virus, anti-malware, content filter, monitoring, 882 anonymity proxy that will be described in a data model TBD. 884 Moreover, we have also categorized common extensions of the generic 885 NSFs, packet filters that may decide based on time information. 886 Moreover, some other packet filters add stateful features at ISO/OSI 887 layer 4. 889 The next section will introduce our algebra to compose capabilities, 890 defined to associate NSFs to capabilities and to check whether a NSF 891 has the capabilities needed to enforce policies. 893 5.5. Algebra of capabilities 895 Our capabilities are defined by a 4-tuple, that is every NSF N will 896 be associated to a 4-tuple (Ac; Cc; RSc; Dc) such that: 898 (Ac; Cc; RSc; Dc) <= (XAC; XCC; XRSC; XDC)= K 900 where 902 o XAC is the set of all the supported actions, that is, the set of 903 all the actions supported by at least one of the existing NSFs; 905 o Ac <= XAC is a set of actions that determine the actions actually 906 available at the NSF N; 908 o XCC is set of all the supported conditions types, that is, the 909 set of all the conditions that can be to specify rules in at 910 least one of the existing NSFs; 912 o Cc <= XCC is the sef of conditions actually available at the NSF 913 N; 915 o XRSC is the set of all the existing resolutions strategies, 917 o RSc <= XCC is the set of resolution strategies that can be used 918 to specify solve conflicts of multiple matching rules at the NSF 919 N; 921 o XDC={F} U XAC, is the set of all the existing actions plus a 922 dummy symbol F, a placeholder value that can be used to indicate 923 that the default action can be freely selected by the policy 924 editor; and 926 o Dc <= XDC, Dc may be {F}, to indicate that the default action can 927 be freely selected by the policy editor, thus it can vary in 928 every policy, or an explicit action {a<=XAC} to indicate that the 929 default action is fixed and the policy editor will not have the 930 possibility to choice it. 932 Given cap1=(Ac1,Cc1,RSc1,def1) and cap2=(Ac2,Cc2,RSc2,def2), we 933 define two operations that are useful to manipulate capabilities: 935 o capability addition: cap1+cap2 = (Ac1 U Ac2, Cc1 U Cc2, RSc1,def1) 937 o capability subtraction: cap_1-cap_2 = (Ac1\Ac2,Cc1\Cc2,RSc1,def1) 939 Note that addition and subtraction do not alter the resolution 940 strategy and the default action method, as our main intent was to 941 model addition of modules. 943 As an example, a generic packet filter that supports the first 944 matching rule resolution strategies, allows the explicit 945 specification of default actions and also supports time-based 946 conditions. The description of its capabilities is the following: 948 Apf = {Allow, Deny} 950 Cpf= {IPsrc,IPdst,Psrc,Pdst,protType} 952 Ctime = {timestart,days,datestart,datestop} 954 cap_pf=(Apf; Cpf; {FMR}; F) 956 cap_pf+time=cap_pf + Ctime 958 By abuse of notation, we have written cap_pf+time=cap_pf + Ctime to 959 shorten the more correct expression cap_pf+time=cap_pf +(;Ctime;;). 961 5.6. Examples of NSFs Categories 963 As an example of the application of the general capability model, we 964 present in the next sections three examples of common categories: 965 network security, content security, and attack mitigation. 967 5.6.1. Network Security 969 Network security is a category that describes the inspecting and 970 processing of network traffic based on pre-defined security policies. 972 The inspecting portion may be thought of as a packet-processing 973 engine that inspects packets traversing networks, either directly or 974 in context to flows with which the packet is associated. From the 975 perspective of packet-processing, implementations differ in the 976 depths of packet headers and/or payloads they can inspect, the 977 various flow and context states they can maintain, and the actions 978 that can be applied to the packets or flows. 980 5.6.2. Content Security 982 Content security is another category of security capabilities 983 applied to application layer. Through detecting the contents carried 984 over the traffic in application layer, these capabilities can 985 realize various security functions, such as defending against 986 intrusion, inspecting virus, filtering malicious URL or junk email, 987 blocking illegal web access or malicious data retrieval. 989 Generally, each type of threat in the application layer has a set of 990 unique characteristics, and requires handling with a set of specific 991 methods. Thus, these NSFs will be characterized by their own 992 security capabilities. 994 5.6.3. Attack Mitigation 996 This category of security capabilities is used to detect and 997 mitigate various types of network attacks. Today's common network 998 attacks can be classified into the following sets, and each set 999 further consists of a number of specific attacks: 1001 o DDoS attacks: 1003 ?Network layer DDoS attacks: Examples include SYN flood, UDP 1004 flood, ICMP flood, IP fragment flood, IPv6 Routing header 1005 attack, and IPv6 duplicate address detection attack; 1007 ?Application layer DDoS attacks: Examples include http flood, 1008 https flood, cache-bypass http floods, WordPress XML RPC 1009 floods, ssl DDoS. 1011 o Single-packet attack: 1013 ?Scanning and sniffing attacks: IP sweep, port scanning, etc 1014 ?malformed packet attacks: Ping of Death, Teardrop, etc 1016 ?special packet attacks: Oversized ICMP, Tracert, IP timestamp 1017 option packets, etc 1019 Each type of network attack has its own network behaviors and 1020 packet/flow characteristics. Therefore, each type of attack needs a 1021 special security function, which is advertised as a capability, for 1022 detection and mitigation. 1024 Overall, the implementation and management of this category of 1025 security capabilities of attack mitigation control is very similar 1026 to content security control. A standard interface, through which the 1027 security controller can choose and customize the given security 1028 capabilities according to specific requirements, is essential. 1030 6. Information Sub-Model for Network Security Capabilities 1032 The purpose of the Capability Framework Information Sub-Model is to 1033 define the concept of a Capability from an external metadata model, 1034 and enable Capabilities to be aggregated to appropriate objects. In 1035 the following sections we will present the cases of Network Security, 1036 Content Security, and Attack Mitigation sub-models. 1038 6.1. Information Sub-Model for Network Security 1040 The purpose of the Network Security Information Sub-Model is to 1041 define how network traffic is defined and determine if one or more 1042 network security features need to be applied to the traffic or not. 1043 Its basic structure is shown in the following figure: 1045 +---------------------+ 1046 +---------------+ | | 1047 | |/ \ \| A Common Superclass | 1048 | ECAPolicyRule + A -------------+ for ECA Objects | 1049 | |\ / /| | 1050 +-------+-------+ +---------+-----------+ 1051 / \ / \ 1052 | | 1053 | | 1054 (subclasses to define Network (subclasses of Event, 1055 Security ECA Policy Rules, Condition, and Action Objects 1056 such as InspectTraffic) for Network Security Control) 1058 Figure 3. Network Security Information Sub-Model Overview 1060 In the above figure, the ECAPolicyRule, along with the Event, 1061 Condition, and Action Objects, are defined in the external ECA Info 1062 Model. The Network Security Sub-Model extends both to define 1063 security-specific ECA policy rules, as well as Events, Conditions, 1064 and Actions. 1065 An I2NSF Policy Rule is a special type of Policy Rule that is in 1066 event-condition-action (ECA) form. It consists of the Policy Rule, 1067 components of a Policy Rule (e.g., events, conditions, and actions), 1068 and optionally, metadata. It can be applied to both uni-directional 1069 and bi-directional traffic across the NSF. 1071 Each rule is triggered by one or more events. If the set of events 1072 evaluates to true, then a set of conditions are evaluated and, if 1073 true, enable a set of actions to be executed. 1075 An example of an I2NSF Policy Rule is, in pseudo-code: 1077 IF is TRUE 1078 IF is TRUE 1079 THEN execute 1080 END-IF 1081 END-IF 1083 In the above example, the Event, Condition, and Action portions of a 1084 Policy Rule are all **Boolean Clauses**. 1086 6.1.1. Network Security Policy Rule Extensions 1088 Figure 3 shows an example of more detailed design of the ECA Policy 1089 Rule subclasses that are contained in the Network Security 1090 Information Sub-Model, which just illustrates how more specific 1091 Network Security Policies are inherited and extended from the 1092 SecurityECAPolicyRule class. Any new kinds of specific Network 1093 Security Policy can be created by following the same pattern of 1094 class design as below. 1096 +---------------+ 1097 | External | 1098 | ECAPolicyRule | 1099 +-------+-------+ 1100 / \ 1101 | 1102 | 1103 +------------+----------+ 1104 | SecurityECAPolicyRule | 1105 +------------+----------+ 1106 | 1107 | 1108 +----+-----+--------+-----+----+---------+---------+--- ... 1109 | | | | | | 1110 | | | | | | 1111 +------+-------+ | +-----+-------+ | +------+------+ | 1112 |Authentication| | | Accounting | | |ApplyProfile | | 1113 |ECAPolicyRule | | |ECAPolicyRule| | |ECAPolicyRule| | 1114 +--------------+ | +-------------+ | +-------------+ | 1115 | | | 1116 +------+------+ +------+------+ +--------------+ 1117 |Authorization| | Traffic | |ApplySignature| 1118 |ECAPolicyRule| | Inspection | |ECAPolicyRule | 1119 +-------------+ |ECAPolicyRule| +--------------+ 1120 +-------------+ 1122 Figure 4. Network Security Info Sub-Model ECAPolicyRule Extensions 1124 The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule 1125 hierarchy. It inherits from the (external) generic ECA Policy Rule 1126 to define Security ECA Policy Rules. The SecurityECAPolicyRule 1127 contains all of the attributes, methods, and relationships defined 1128 in its superclass, and adds additional concepts that are required 1129 for Network Security (these will be defined in the next version of 1130 this draft). The six SecurityECAPolicyRule subclasses extend the 1131 SecurityECAPolicyRule class to represent six different types of 1132 Network Security ECA Policy Rules. It is assumed that the (external) 1133 generic ECAPolicyRule class defines basic information in the form of 1134 attributes, such as an unique object ID, as well as a description 1135 and other basic, but necessary, information. 1137 It is assumed that the (external) generic ECA Policy Rule is 1138 abstract; the SecurityECAPolicyRule is also abstract. This enables 1139 data model optimizations to be made while making this information 1140 model detailed but flexible and extensible. 1142 The SecurityECAPolicyRule defines network security policy as a 1143 container that aggregates Event, Condition, and Action objects, 1144 which are described in Section 6.1.3, 6.1.4, and 6.1.5, respectively. 1145 Events, Conditions, and Actions can be generic or security-specific. 1146 Section 4.6 defines the concept of default security Actions. 1148 Brief class descriptions of these six ECA Policy Rules are provided 1149 in the Appendix A. 1151 6.1.2. Network Security Policy Rule Operation 1153 Network security policy consists of a number of more granular ECA 1154 Policy Rules formed from the information model described above. In 1155 simpler cases, where the Event and Condition clauses remain 1156 unchanged, then network security control may be performed by calling 1157 additional network security actions. Network security policy 1158 examines and performs basic processing of the traffic as follows: 1160 1. For a given SecurityECAPolicyRule (which can be generic or 1161 specific to security, such as those in Figure 3), the NSF 1162 evaluates the Event clause. It may use security Event objects to 1163 do all or part of this evaluation, which are defined in section 1164 4.3.3. If the Event clause evaluates to TRUE, then the Condition 1165 clause of this SecurityECAPolicyRule is evaluated; otherwise, 1166 execution of this SecurityECAPolicyRule is stopped, and the next 1167 SecurityECAPolicyRule (if one exists) is evaluated; 1169 2. The Condition clause is then evaluated. It may use security 1170 Condition objects to do all or part of this evaluation, which are 1171 defined in section 4.3.4. If the Condition clause evaluates to 1172 TRUE, then the set of Actions in this SecurityECAPolicyRule MUST 1173 be executed. This is defined as "matching" the 1174 SecurityECAPolicyRule; otherwise, execution of this 1175 SecurityECAPolicyRule is stopped, and the next 1176 SecurityECAPolicyRule (if one exists) is evaluated; 1178 3. If none of the SecurityECAPolicyRules are matched, then the NSF 1179 denies the traffic by default; 1181 4. If the traffic matches a rule, the NSF performs the defined 1182 Actions on the traffic. It may use security Action objects to do 1183 all or part of this execution, which are defined in section 4.3.5. 1184 If the action is "deny", the NSF blocks the traffic. If the basic 1185 action is permit or mirror, the NSF firstly performs that 1186 function, and then checks whether certain other security 1187 capabilities are referenced in the rule. If yes, go to step 5. If 1188 no, the traffic is permitted; 1190 5. If other security capabilities (e.g., Anti-virus or IPS) are 1191 referenced in the SecurityECAPolicyRule, and the Action defined 1192 in the rule is permit or mirror, the NSF performs the referenced 1193 security capabilities. 1195 Metadata attached to the SecurityECAPolicyRule MAY be used to 1196 control how the SecurityECAPolicyRule is evaluated. This is called a 1197 Policy Rule Evaluation Strategy. For example, one strategy is to 1198 match and execute the first SecurityECAPolicyRule, and then exit 1199 without executing any other SecurityECAPolicyRules (even if they 1200 matched). In contrast, a second strategy is to first collect all 1201 SecurityECAPolicyRules that matched, and then execute them according 1202 to a pre-defined order (e.g., the priority of each 1203 SecurityECAPolicyRule). 1205 One policy or rule can be applied multiple times to different 1206 managed objects (e.g., links, devices, networks, VPNS). This not 1207 only guarantees consistent policy enforcement, but also decreases 1208 the configuration workload. 1210 6.1.3. Network Security Event Sub-Model 1212 Figure 10 shows a more detailed design of the Event subclasses that 1213 are contained in the Network Security Information Sub-Model. 1215 +---------------------+ 1216 +---------------+ 1..n 1..n| | 1217 | |/ \ \| A Common Superclass | 1218 | ECAPolicyRule + A ---------+ for ECA Objects | 1219 | |\ / /| | 1220 +---------------+ +-----------+---------+ 1221 / \ 1222 | 1223 | 1224 +--------------+--------+------+ 1225 | | | 1226 | | | 1227 +-----+----+ +------+------+ +-----+-----+ 1228 | An Event | | A Condition | | An Action | 1229 | Class | | Class | | Class | 1230 +-----+----+ +-------------+ +-----------+ 1231 / \ 1232 | 1233 | 1234 | 1235 +-----------+---+----------------+--------------+-- ... 1236 | | | | 1237 | | | | 1238 +-------+----+ +--------+-----+ +--------+-----+ +------+-----+ 1239 |UserSecurity| | Device | | System | |TimeSecurity| 1240 | Event | | SecurityEvent| | SecurityEvent| | Event | 1241 +------------+ +--------------+ +--------------+ +------------+ 1243 Figure 5. Network Security Info Sub-Model Event Class Extensions 1245 The four Event classes shown in Figure 5 extend the (external) 1246 generic Event class to represent Events that are of interest to 1247 Network Security. It is assumed that the (external) generic Event 1248 class defines basic Event information in the form of attributes, 1249 such as a unique event ID, a description, as well as the date and 1250 time that the event occurred. 1252 The following are assumptions that define the functionality of the 1253 generic Event class. If desired, these could be defined as 1254 attributes in a SecurityEvent class (which would be a subclass of 1255 the generic Event class, and a superclass of the four Event classes 1256 shown in Figure 10). However, this makes it harder to use any 1257 generic Event model with the I2NSF events. Assumptions are: 1259 - The generic Event class is abstract 1260 - All four SecurityEvent subclasses are concrete 1261 - The generic Event class uses the composite pattern, so 1262 individual Events as well as hierarchies of Events are 1263 available (the four subclasses in Figure 10 would be 1264 subclasses of the Atomic Event) 1265 - The generic Event class has a mechanism to uniquely identify 1266 the source of the Event 1267 - The generic Event class has a mechanism to separate header 1268 information from its payload 1269 - The generic Event class has a mechanism to attach zero or more 1270 metadata objects to it 1272 Brief class descriptions are provided in the following sub-sections. 1274 6.1.3.1. UserSecurityEvent Class Description 1276 The purpose of this class is to represent Events that are initiated 1277 by a user, such as logon and logoff Events. Information in this 1278 Event may be used as part of a test to determine if the Condition 1279 clause in this ECA Policy Rule should be evaluated or not. Examples 1280 include user identification data and the type of connection used by 1281 the user. 1283 The UserSecurityEvent class defines the following attributes: 1285 6.1.3.1.1. The usrSecEventContent Attribute 1287 This is a mandatory string that contains the content of the 1288 UserSecurityEvent. The format of the content is specified in the 1289 usrSecEventFormat class attribute, and the type of Event is defined 1290 in the usrSecEventType class attribute. An example of the 1291 usrSecEventContent attribute is the string "hrAdmin", with the 1292 usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute 1293 set to 5 (new logon). 1295 6.1.3.1.2. The usrSecEventFormat Attribute 1297 This is a mandatory non-negative enumerated integer, which is used 1298 to specify the data type of the usrSecEventContent attribute. The 1299 content is specified in the usrSecEventContent class attribute, and 1300 the type of Event is defined in the usrSecEventType class attribute. 1301 An example of the usrSecEventContent attribute is the string 1302 "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and 1303 the usrSecEventType attribute set to 5 (new logon). Values include: 1305 0: unknown 1306 1: GUID (Generic Unique IDentifier) 1307 2: UUID (Universal Unique IDentifier) 1308 3: URI (Uniform Resource Identifier) 1309 4: FQDN (Fully Qualified Domain Name) 1310 5: FQPN (Fully Qualified Path Name) 1312 6.1.3.1.3. The usrSecEventType Attribute 1314 This is a mandatory non-negative enumerated integer, which is used 1315 to specify the type of Event that involves this user. The content 1316 and format are specified in the usrSecEventContent and 1317 usrSecEventFormat class attributes, respectively. An example of the 1318 usrSecEventContent attribute is the string "hrAdmin", with the 1319 usrSecEventFormat attribute set to 1 (GUID) and the usrSecEventType 1320 attribute set to 5 (new logon). Values include: 1322 0: unknown 1323 1: new user created 1324 2: new user group created 1325 3: user deleted 1326 4: user group deleted 1327 5: user logon 1328 6: user logoff 1329 7: user access request 1330 8: user access granted 1331 9: user access violation 1333 6.1.3.2. DeviceSecurityEvent Class Description 1335 The purpose of a DeviceSecurityEvent is to represent Events that 1336 provide information from the Device that are important to I2NSF 1337 Security. Information in this Event may be used as part of a test to 1338 determine if the Condition clause in this ECA Policy Rule should be 1339 evaluated or not. Examples include alarms and various device 1340 statistics (e.g., a type of threshold that was exceeded), which may 1341 signal the need for further action. 1343 The DeviceSecurityEvent class defines the following attributes: 1345 6.1.3.2.1. The devSecEventContent Attribute 1347 This is a mandatory string that contains the content of the 1348 DeviceSecurityEvent. The format of the content is specified in the 1349 devSecEventFormat class attribute, and the type of Event is defined 1350 in the devSecEventType class attribute. An example of the 1351 devSecEventContent attribute is "alarm", with the devSecEventFormat 1352 attribute set to 1 (GUID), the devSecEventType attribute set to 5 1353 (new logon). 1355 6.1.3.2.2. The devSecEventFormat Attribute 1357 This is a mandatory non-negative enumerated integer, which is used 1358 to specify the data type of the devSecEventContent attribute. Values 1359 include: 1361 0: unknown 1362 1: GUID (Generic Unique IDentifier) 1363 2: UUID (Universal Unique IDentifier) 1364 3: URI (Uniform Resource Identifier) 1365 4: FQDN (Fully Qualified Domain Name) 1366 5: FQPN (Fully Qualified Path Name) 1368 6.1.3.2.3. The devSecEventType Attribute 1370 This is a mandatory non-negative enumerated integer, which is used 1371 to specify the type of Event that was generated by this device. 1372 Values include: 1374 0: unknown 1375 1: communications alarm 1376 2: quality of service alarm 1377 3: processing error alarm 1378 4: equipment error alarm 1379 5: environmental error alarm 1381 Values 1-5 are defined in X.733. Additional types of errors may also 1382 be defined. 1384 6.1.3.2.4. The devSecEventTypeInfo[0..n] Attribute 1386 This is an optional array of strings, which is used to provide 1387 additional information describing the specifics of the Event 1388 generated by this Device. For example, this attribute could contain 1389 probable cause information in the first array, trend information in 1390 the second array, proposed repair actions in the third array, and 1391 additional information in the fourth array. 1393 6.1.3.2.5. The devSecEventTypeSeverity Attribute 1395 This is a mandatory non-negative enumerated integer, which is used 1396 to specify the perceived severity of the Event generated by this 1397 Device. Values include: 1399 0: unknown 1400 1: cleared 1401 2: indeterminate 1402 3: critical 1403 4: major 1404 5: minor 1405 6: warning 1407 Values 1-6 are from X.733. 1409 6.1.3.3. SystemSecurityEvent Class Description 1411 The purpose of a SystemSecurityEvent is to represent Events that are 1412 detected by the management system, instead of Events that are 1413 generated by a user or a device. Information in this Event may be 1414 used as part of a test to determine if the Condition clause in this 1415 ECA Policy Rule should be evaluated or not. Examples include an 1416 event issued by an analytics system that warns against a particular 1417 pattern of unknown user accesses, or an Event issued by a management 1418 system that represents a set of correlated and/or filtered Events. 1420 The SystemSecurityEvent class defines the following attributes: 1422 6.1.3.3.1. The sysSecEventContent Attribute 1424 This is a mandatory string that contains the content of the 1425 SystemSecurityEvent. The format of the content is specified in the 1426 sysSecEventFormat class attribute, and the type of Event is defined 1427 in the sysSecEventType class attribute. An example of the 1428 sysSecEventContent attribute is the string "sysadmin3", with the 1429 sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType 1430 attribute set to 2 (audit log cleared). 1432 6.1.3.3.2. The sysSecEventFormat Attribute 1434 This is a mandatory non-negative enumerated integer, which is used 1435 to specify the data type of the sysSecEventContent attribute. Values 1436 include: 1438 0: unknown 1439 1: GUID (Generic Unique IDentifier) 1440 2: UUID (Universal Unique IDentifier) 1441 3: URI (Uniform Resource Identifier) 1442 4: FQDN (Fully Qualified Domain Name) 1443 5: FQPN (Fully Qualified Path Name) 1445 6.1.3.3.3. The sysSecEventType Attribute 1447 This is a mandatory non-negative enumerated integer, which is used 1448 to specify the type of Event that involves this device. Values 1449 include: 1451 0: unknown 1452 1: audit log written to 1453 2: audit log cleared 1454 3: policy created 1455 4: policy edited 1456 5: policy deleted 1457 6: policy executed 1459 6.1.3.4. TimeSecurityEvent Class Description 1461 The purpose of a TimeSecurityEvent is to represent Events that are 1462 temporal in nature (e.g., the start or end of a period of time). 1463 Time events signify an individual occurrence, or a time period, in 1464 which a significant event happened. Information in this Event may be 1465 used as part of a test to determine if the Condition clause in this 1466 ECA Policy Rule should be evaluated or not. Examples include issuing 1467 an Event at a specific time to indicate that a particular resource 1468 should not be accessed, or that different authentication and 1469 authorization mechanisms should now be used (e.g., because it is now 1470 past regular business hours). 1472 The TimeSecurityEvent class defines the following attributes: 1474 6.1.3.4.1. The timeSecEventPeriodBegin Attribute 1476 This is a mandatory DateTime attribute, and represents the beginning 1477 of a time period. It has a value that has a date and/or a time 1478 component (as in the Java or Python libraries). 1480 6.1.3.4.2. The timeSecEventPeriodEnd Attribute 1482 This is a mandatory DateTime attribute, and represents the end of a 1483 time period. It has a value that has a date and/or a time component 1484 (as in the Java or Python libraries). If this is a single Event 1485 occurence, and not a time period when the Event can occur, then the 1486 timeSecEventPeriodEnd attribute may be ignored. 1488 6.1.3.4.3. The timeSecEventTimeZone Attribute 1490 This is a mandatory string attribute, and defines the time zone that 1491 this Event occurred in using the format specified in ISO8601. 1493 6.1.4. Network Security Condition Sub-Model 1495 Figure 6 shows a more detailed design of the Condition subclasses 1496 that are contained in the Network Security Information Sub-Model. 1498 +---------------------+ 1499 +---------------+ 1..n 1..n | | 1500 | |/ \ \| A Common Superclass | 1501 | ECAPolicyRule+ A ----------+ for ECA Objects | 1502 | |\ / /| | 1503 +-------+-------+ +-----------+---------+ 1504 / \ 1505 | 1506 | 1507 +--------------+----------+----+ 1508 | | | 1509 | | | 1510 +-----+----+ +------+------+ +-----+-----+ 1511 | An Event | | A Condition | | An Action | 1512 | Class | | Class | | Class | 1513 +----------+ +------+------+ +-----------+ 1514 / \ 1515 | 1516 | 1517 +--------+----------+------+---+---------+--------+--- ... 1518 | | | | | | 1519 | | | | | | 1520 +-----+-----+ | +-------+-------+ | +------+-----+ | 1521 | Packet | | | PacketPayload | | | Target | | 1522 | Security | | | Security | | | Security | | 1523 | Condition | | | Condition | | | Condition | | 1524 +-----------+ | +---------------+ | +------------+ | 1525 | | | 1526 +------+-------+ +----------+------+ +--------+-------+ 1527 | UserSecurity | | SecurityContext | | GenericContext | 1528 | Condition | | Condition | | Condition | 1529 +--------------+ +-----------------+ +----------------+ 1531 Figure 6. Network Security Info Sub-Model Condition Class 1532 Extensions 1534 The six Condition classes shown in Figure 6 extend the (external) 1535 generic Condition class to represent Conditions that are of interest 1536 to Network Security. It is assumed that the (external) generic 1537 Condition class is abstract, so that data model optimizations may be 1538 defined. It is also assumed that the generic Condition class defines 1539 basic Condition information in the form of attributes, such as a 1540 unique object ID, a description, as well as a mechanism to attach 1541 zero or more metadata objects to it. While this could be defined as 1542 attributes in a SecurityCondition class (which would be a subclass 1543 of the generic Condition class, and a superclass of the six 1544 Condition classes shown in Figure 11), this makes it harder to use 1545 any generic Condition model with the I2NSF conditions. 1547 Brief class descriptions are provided in the following sub-sections. 1549 6.1.4.1. PacketSecurityCondition 1551 The purpose of this Class is to represent packet header information 1552 that can be used as part of a test to determine if the set of Policy 1553 Actions in this ECA Policy Rule should be executed or not. This 1554 class is abstract, and serves as the superclass of more detailed 1555 conditions that involve different types of packet formats. Its 1556 subclasses are shown in Figure 7, and are defined in the following 1557 sections. 1559 +-------------------------+ 1560 | PacketSecurityCondition | 1561 +------------+------------+ 1562 / \ 1563 | 1564 | 1565 +---------+----------+---+-----+----------+ 1566 | | | | | 1567 | | | | | 1568 +--------+-------+ | +--------+-------+ | +--------+-------+ 1569 | PacketSecurity | | | PacketSecurity | | | PacketSecurity | 1570 | MACCondition | | | IPv4Condition | | | IPv6Condition | 1571 +----------------+ | +----------------+ | +----------------+ 1572 | | 1573 +--------+-------+ +--------+-------+ 1574 | TCPCondition | | UDPCondition | 1575 +----------------+ +----------------+ 1577 Figure 7. Network Security Info Sub-Model PacketSecurityCondition 1578 Class Extensions 1580 6.1.4.1.1. PacketSecurityMACCondition 1582 The purpose of this Class is to represent packet MAC packet header 1583 information that can be used as part of a test to determine if the 1584 set of Policy Actions in this ECA Policy Rule should be executed or 1585 not. This class is concrete, and defines the following attributes: 1587 6.1.4.1.1.1. The pktSecCondMACDest Attribute 1589 This is a mandatory string attribute, and defines the MAC 1590 destination address (6 octets long). 1592 6.1.4.1.1.2. The pktSecCondMACSrc Attribute 1594 This is a mandatory string attribute, and defines the MAC source 1595 address (6 octets long). 1597 6.1.4.1.1.3. The pktSecCondMAC8021Q Attribute 1599 This is an optional string attribute, and defines the 802.1Q tag 1600 value (2 octets long). This defines VLAN membership and 802.1p 1601 priority values. 1603 6.1.4.1.1.4. The pktSecCondMACEtherType Attribute 1605 This is a mandatory string attribute, and defines the EtherType 1606 field (2 octets long). Values up to and including 1500 indicate the 1607 size of the payload in octets; values of 1536 and above define which 1608 protocol is encapsulated in the payload of the frame. 1610 6.1.4.1.1.5. The pktSecCondMACTCI Attribute 1612 This is an optional string attribute, and defines the Tag Control 1613 Information. This consists of a 3 bit user priority field, a drop 1614 eligible indicator (1 bit), and a VLAN identifier (12 bits). 1616 6.1.4.1.2. PacketSecurityIPv4Condition 1618 The purpose of this Class is to represent packet IPv4 packet header 1619 information that can be used as part of a test to determine if the 1620 set of Policy Actions in this ECA Policy Rule should be executed or 1621 not. This class is concrete, and defines the following attributes: 1623 6.1.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute 1625 This is a mandatory string attribute, and defines the IPv4 Source 1626 Address (32 bits). 1628 6.1.4.1.2.2. The pktSecCondIPv4DestAddr Attribute 1630 This is a mandatory string attribute, and defines the IPv4 1631 Destination Address (32 bits). 1633 6.1.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute 1635 This is a mandatory string attribute, and defines the protocol used 1636 in the data portion of the IP datagram (8 bits). 1638 6.1.4.1.2.4. The pktSecCondIPv4DSCP Attribute 1640 This is a mandatory string attribute, and defines the Differentiated 1641 Services Code Point field (6 bits). 1643 6.1.4.1.2.5. The pktSecCondIPv4ECN Attribute 1645 This is an optional string attribute, and defines the Explicit 1646 Congestion Notification field (2 bits). 1648 6.1.4.1.2.6. The pktSecCondIPv4TotalLength Attribute 1650 This is a mandatory string attribute, and defines the total length 1651 of the packet (including header and data) in bytes (16 bits). 1653 6.1.4.1.2.7. The pktSecCondIPv4TTL Attribute 1655 This is a mandatory string attribute, and defines the Time To Live 1656 in seconds (8 bits). 1658 6.1.4.1.3. PacketSecurityIPv6Condition 1660 The purpose of this Class is to represent packet IPv6 packet header 1661 information that can be used as part of a test to determine if the 1662 set of Policy Actions in this ECA Policy Rule should be executed or 1663 not. This class is concrete, and defines the following attributes: 1665 6.1.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute 1667 This is a mandatory string attribute, and defines the IPv6 Source 1668 Address (128 bits). 1670 6.1.4.1.3.2. The pktSecCondIPv6DestAddr Attribute 1672 This is a mandatory string attribute, and defines the IPv6 1673 Destination Address (128 bits). 1675 6.1.4.1.3.3. The pktSecCondIPv6DSCP Attribute 1677 This is a mandatory string attribute, and defines the Differentiated 1678 Services Code Point field (6 bits). It consists of the six most 1679 significant bits of the Traffic Class field in the IPv6 header. 1681 6.1.4.1.3.4. The pktSecCondIPv6ECN Attribute 1683 This is a mandatory string attribute, and defines the Explicit 1684 Congestion Notification field (2 bits). It consists of the two least 1685 significant bits of the Traffic Class field in the IPv6 header. 1687 6.1.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute 1689 This is a mandatory string attribute, and defines an IPv6 flow label. 1690 This, in combination with the Source and Destination Address fields, 1691 enables efficient IPv6 flow classification by using only the IPv6 1692 main header fields (20 bits). 1694 6.1.4.1.3.6. The pktSecCondIPv6PayloadLength Attribute 1696 This is a mandatory string attribute, and defines the total length 1697 of the packet (including the fixed and any extension headers, and 1698 data) in bytes (16 bits). 1700 6.1.4.1.3.7. The pktSecCondIPv6NextHeader Attribute 1702 This is a mandatory string attribute, and defines the type of the 1703 next header (e.g., which extension header to use) (8 bits). 1705 6.1.4.1.3.8. The pktSecCondIPv6HopLimit Attribute 1707 This is a mandatory string attribute, and defines the maximum number 1708 of hops that this packet can traverse (8 bits). 1710 6.1.4.1.4. PacketSecurityTCPCondition 1712 The purpose of this Class is to represent packet TCP packet header 1713 information that can be used as part of a test to determine if the 1714 set of Policy Actions in this ECA Policy Rule should be executed or 1715 not. This class is concrete, and defines the following attributes: 1717 6.1.4.1.4.1. The pktSecCondTPCSrcPort Attribute 1719 This is a mandatory string attribute, and defines the Source Port 1720 (16 bits). 1722 6.1.4.1.4.2. The pktSecCondTPCDestPort Attribute 1724 This is a mandatory string attribute, and defines the Destination 1725 Port (16 bits). 1727 6.1.4.1.4.3. The pktSecCondTPCSeqNum Attribute 1729 This is a mandatory string attribute, and defines the sequence 1730 number (32 bits). 1732 6.1.4.1.4.4. The pktSecCondTPCFlags Attribute 1734 This is a mandatory string attribute, and defines the nine Control 1735 bit flags (9 bits). 1737 6.1.4.1.5. PacketSecurityUDPCondition 1739 The purpose of this Class is to represent packet UDP packet header 1740 information that can be used as part of a test to determine if the 1741 set of Policy Actions in this ECA Policy Rule should be executed or 1742 not. This class is concrete, and defines the following attributes: 1744 6.1.4.1.5.1. The pktSecCondUDPSrcPort Attribute 1746 This is a mandatory string attribute, and defines the UDP Source 1747 Port (16 bits). 1749 6.1.4.1.5.2. The pktSecCondUDPDestPort Attribute 1751 This is a mandatory string attribute, and defines the UDP 1752 Destination Port (16 bits). 1754 6.1.4.1.5.3. The pktSecCondUDPLength Attribute 1756 This is a mandatory string attribute, and defines the length in 1757 bytes of the UDP header and data (16 bits). 1759 6.1.4.2. PacketPayloadSecurityCondition 1761 The purpose of this Class is to represent packet payload data that 1762 can be used as part of a test to determine if the set of Policy 1763 Actions in this ECA Policy Rule should be executed or not. Examples 1764 include a specific set of bytes in the packet payload. 1766 6.1.4.3. TargetSecurityCondition 1768 The purpose of this Class is to represent information about 1769 different targets of this policy (i.e., entities to which this 1770 policy rule should be applied), which can be used as part of a test 1771 to determine if the set of Policy Actions in this ECA Policy Rule 1772 should be executed or not. Examples include whether the targeted 1773 entities are playing the same role, or whether each device is 1774 administered by the same set of users, groups, or roles. 1776 This Class has several important subclasses, including: 1778 a. ServiceSecurityContextCondition is the superclass for all 1779 information that can be used in an ECA Policy Rule that specifies 1780 data about the type of service to be analyzed (e.g., the protocol 1781 type and port number) 1783 b. ApplicationSecurityContextCondition is the superclass for all 1784 information that can be used in a ECA Policy Rule that specifies 1785 data that identifies a particular application (including metadata, 1786 such as risk level) 1788 c. DeviceSecurityContextCondition is the superclass for all 1789 information that can be used in a ECA Policy Rule that specifies 1790 data about a device type and/or device OS that is being used 1792 6.1.4.4. UserSecurityCondition 1794 The purpose of this Class is to represent data about the user or 1795 group referenced in this ECA Policy Rule that can be used as part of 1796 a test to determine if the set of Policy Actions in this ECA Policy 1797 Rule should be evaluated or not. Examples include the user or group 1798 id used, the type of connection used, whether a given user or group 1799 is playing a particular role, or whether a given user or group has 1800 failed to login a particular number of times. 1802 6.1.4.5. SecurityContextCondition 1804 The purpose of this Class is to represent security conditions that 1805 are part of a specific context, which can be used as part of a test 1806 to determine if the set of Policy Actions in this ECA Policy Rule 1807 should be evaluated or not. Examples include testing to determine if 1808 a particular pattern of security-related data have occurred, or if 1809 the current session state matches the expected session state. 1811 6.1.4.6. GenericContextSecurityCondition 1813 The purpose of this Class is to represent generic contextual 1814 information in which this ECA Policy Rule is being executed, which 1815 can be used as part of a test to determine if the set of Policy 1816 Actions in this ECA Policy Rule should be evaluated or not. Examples 1817 include geographic location and temporal information. 1819 6.1.5. Network Security Action Sub-Model 1821 Figure 7 shows a more detailed design of the Action subclasses that 1822 are contained in the Network Security Information Sub-Model. 1824 +---------------------+ 1825 +---------------+ 1..n 1..n | | 1826 | |/ \ \| A Common Superclass | 1827 | ECAPolicyRule+ A ----------+ for ECA Objects | 1828 | |\ / /| | 1829 +---------------+ +-----------+---------+ 1830 / \ 1831 | 1832 | 1833 +--------------+--------+------+ 1834 | | | 1835 | | | 1836 +-----+----+ +------+------+ +-----+-----+ 1837 | An Event | | A Condition | | An Action | 1838 | Class | | Class | | Class | 1839 +----------+ +-------------+ +-----+-----+ 1840 / \ 1841 | 1842 | 1843 +------------+-------------+------------------+-------- ... 1844 | | | | 1845 | | | | 1846 +----+----+ +----+---+ +------+-------+ +-------+--------+ 1847 | Ingress | | Egress | | ApplyProfile | | ApplySignature | 1848 | Action | | Action | | Action | | Action | 1849 +---------+ +--------+ +--------------+ +----------------+ 1851 Figure 7. Network Security Info Sub-Model Action Extensions 1853 The four Action classes shown in Figure 7 extend the (external) 1854 generic Action class to represent Actions that perform a Network 1855 Security Control function. Brief class descriptions are provided in 1856 the following sub-sections. 1858 6.1.5.1. IngressAction 1860 The purpose of this Class is to represent actions performed on 1861 packets that enter an NSF. Examples include pass, drop, mirror 1862 traffic. 1864 6.1.5.2. EgressAction 1866 The purpose of this Class is to represent actions performed on 1867 packets that exit an NSF. Examples include pass, drop, mirror 1868 traffic, signal, encapsulate. 1870 6.1.5.3. ApplyProfileAction 1872 The purpose of this Class is to represent applying a profile to 1873 packets to perform content security and/or attack mitigation control. 1875 6.1.5.4. ApplySignatureAction 1877 The purpose of this Class is to represent applying a signature file 1878 to packets to perform content security and/or attack mitigation 1879 control. 1881 6.2. Information Model for Content Security Control 1883 The block for content security control is composed of a number of 1884 security capabilities, while each one aims for protecting against a 1885 specific type of threat in the application layer. 1887 Following figure shows a basic structure of the information model: 1889 +----------------------------------+ 1890 | | 1891 | | 1892 | Anti-Virus | 1893 | Intrusion Prevention | 1894 | URL Filtering | 1895 | File Blocking | 1896 | Data Filtering | 1897 | Application Behavior Control | 1898 | Mail Filtering | 1899 | Packet Capturing | 1900 | File Isolation | 1901 | ... | 1902 | | 1903 | | 1904 | | 1905 | | 1906 | Information model | 1907 | for content security| 1908 | control | 1909 +----------------------------------+ 1910 Figure 8. The basic structure of information model for content 1911 security control 1913 The detailed description about the standard interface and the 1914 parameters for all the security capabilities of this category are 1915 TBD. 1917 6.3. Information Model for Attack Mitigation Control 1919 The block for attack mitigation control is composed of a number of 1920 security capabilities, while each one aims for mitigating a specific 1921 type of network attack. 1923 Following figure shows a basic structure of the information model: 1925 Please view in a fixed-width font such as Courier. 1927 +-------------------------------------------------+ 1928 | | 1929 | +---------------------+ +---------------+ | 1930 | |Attack mitigation | | General Shared| | 1931 | |capabilites: | | Parameters: | | 1932 | | SYN flood, | | | | 1933 | | UDP flood, | | | | 1934 | | ICMP flood, | | | | 1935 | | IP fragment flood, | | | | 1936 | | IPv6 related attacks| | | | 1937 | | HTTP flood, | | | | 1938 | | HTTPS flood, | | | | 1939 | | DNS flood, | | | | 1940 | | DNS amplification, | | | | 1941 | | SSL DDoS, | | | | 1942 | | IP sweep, | | | | 1943 | | Port scanning, | | | | 1944 | | Ping of Death, | | | | 1945 | | Oversized ICMP | | | | 1946 | | | | | | 1947 | | ... | | | | 1948 | | | | | | 1949 | +---------------------+ +---------------+ | 1950 | | 1951 | Information model | 1952 | for attack mitigation| 1953 | control | 1954 +-------------------------------------------------+ 1955 Figure 9. The basic structure of information model for attack 1956 mitigation control 1958 The detailed description about the standard interface and the 1959 general shared parameters for all the security capabilities of this 1960 category are TBD. 1962 7. Security Considerations 1964 The security capability policy information sent to NSFs should be 1965 protected by the secure communication channel, to ensure the 1966 confidentiality and integrity. In another side, the NSFs and 1967 security controller can all be faked, which lead to undesirable 1968 results, i.e., security policy leakage from security controller, 1969 faked security controller sending false information to mislead the 1970 NSFs. The mutual authentication is essential to protected against 1971 this kind of attack. The current mainstream security technologies 1972 (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be employed appropriately to 1973 provide the above security functionalities. 1975 In addition, to defend against the DDoS attack caused by the 1976 security controller sending too much configuration messages to the 1977 NSFs, the rate limiting or similar mechanisms should be considered 1978 in NSF, whether in advance or just in the process of DDoS attack. 1980 8. IANA Considerations 1982 This document requires no IANA actions. RFC Editor: Please remove 1983 this section before publication. 1985 9. References 1987 9.1. Normative References 1989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1990 Requirement Levels", BCP 14, RFC 2119, March 1997. 1992 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1993 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1994 Consortium and Demon Internet Ltd., November 1997. 1996 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1997 Network Configuration Protocol (NETCONF)", RFC 6020, 1998 October 2010. 2000 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2001 Used to Form Encoding Rules in Various Routing Protocol 2002 Specifications", RFC 5511, April 2009. 2004 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 2005 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 2006 J., and S. Waldbusser, "Terminology for Policy-Based 2007 Management", RFC 3198, DOI 10.17487/RFC3198, 2008 November 2001, . 2010 9.2. Informative References 2012 [INCITS359 RBAC] NIST/INCITS, "American National Standard for 2013 Information Technology - Role Based Access Control", 2014 INCITS 359, April, 2003 2016 [I-D.draft-ietf-i2nsf-problem-and-use-cases] Hares, S., et.al., 2017 "I2NSF Problem Statement and Use cases", Work in Progress, 2018 February, 2016. 2020 [I-D.draft-ietf-i2nsf-framework] Lopez, E., et.al., "Framework for 2021 Interface to Network Security Functions", Work in Progress, 2022 October, 2016. 2024 [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to 2025 Network Security Functions (I2NSF) Terminology", Work in 2026 Progress, April, 2016 2028 [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., 2029 Halpern, J., Coleman, J., "Generic Policy Information 2030 Model for Simplified Use of Policy Abstractions (SUPA)", 2031 Work in Progress, June, 2016. 2033 [I-D.draft-baspez-i2nsf-capabilities-00] Basile C., Lopez D. R., "A 2034 Model of Security Capabilities for Network Security 2035 Functions", July 2016 2037 [I-D.draft-xia-i2nsf-capability-interface-im-06] Xia L., et al., 2038 "Information Model of Interface to Network Security 2039 Functions Capability Interface", June 2016 2041 [Alshaer] Al Shaer, E. and H. Hamed, "Modeling and management of 2042 firewall policies", 2004. 2044 [Bas12] Basile, C., Cappadonia, A., and A. Lioy, "Network-Level 2045 Access Control Policy Analysis and Transformation", 2012. 2047 [Bas15] Basile, C. and A. Lioy, "Analysis of application-layer 2048 filtering policies with application to HTTP", 2015. 2050 [Cormen] Cormen, T., "Introduction to Algorithms", 2009. 2052 [Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable 2053 packet classification", 2003. 2055 [Taylor] Taylor, D. and J. Turner, "Scalable packet classification 2056 using distributed crossproducting of field labels", 2004. 2058 10. Acknowledgments 2060 This document was prepared using 2-Word-v2.0.template.dot. 2062 Appendix A. 2064 Six exemplary policy rules of Network Security Capability are 2065 introduced in this Appendix to clarify how to create different kinds 2066 of specific ECA policy rules. 2068 Note that there is a common pattern that defines how these 2069 ECAPolicyRules operate; this simplifies their implementation. All of 2070 these six ECA Policy Rules are concrete classes. 2072 In addition, none of these six subclasses define attributes. This 2073 enables them to be viewed as simple object containers, and hence, 2074 applicable to a wide variety of content. It also means that the 2075 content of the function (e.g., how an entity is authenticated, what 2076 specific traffic is inspected, or which particular signature is 2077 applied) is defined solely by the set of events, conditions, and 2078 actions that are contained by the particular subclass. This enables 2079 the policy rule, with its aggregated set of events, conditions, and 2080 actions, to be treated as a reusable object. 2082 A.1. AuthenticationECAPolicyRule Class Definition 2084 The purpose of an AuthenticationECAPolicyRule is to define an ECA 2085 Policy Rule that can verify whether an entity has an attribute of a 2086 specific value. 2088 This class does NOT define the authentication method used. This is 2089 because this would effectively "enclose" this information within the 2090 AuthenticationECAPolicyRule. This has two drawbacks. First, other 2091 entities that need to use information from the Authentication 2092 class(es) could not; they would have to associate with the 2093 AuthenticationECAPolicyRule class, and those other classes would not 2094 likely be interested in the AuthenticationECAPolicyRule. Second, the 2095 evolution of new authentication methods should be independent of the 2096 AuthenticationECAPolicyRule; this cannot happen if the 2097 Authentication class(es) are embedded in the 2098 AuthenticationECAPolicyRule. Hence, this document recommends the 2099 following design: 2100 +----------------+ 2101 +----------------+ 1..n 1...n | | 2102 | |/ \ HasAuthenticationMethod \| Authentication | 2103 | Authentication + A ----------+-----------------+ Method | 2104 | ECAPolicyRule |\ / ^ /| | 2105 | | | +----------------+ 2106 +----------------+ | 2107 | 2108 +------------+-------------+ 2109 | AuthenticationRuleDetail | 2110 +------------+-------------+ 2111 / \ 0..n 2112 | 2113 | PolicyControlsAuthentication 2114 | 2115 / \ 2116 A 2117 \ / 0..n 2118 +----------+--------------+ 2119 | ManagementECAPolicyRule | 2120 +-------------------------+ 2122 Figure 10. Modeling Authentication Mechanisms 2124 This document only defines the AuthenticationECAPolicyRule; all 2125 other classes, and the aggregations, are defined in an external 2126 model. For completeness, descriptions of how the two aggregations 2127 are used are below. 2129 Figure 10 defines an aggregation between the 2130 AuthenticationECAPolicyRule and an externalAuthenticationMethod 2131 class (which is likely a superclass for different types of 2132 authentication mechanisms). This decouples the implementation of 2133 authentication mechanisms from how authentication mechanisms are 2134 used. 2136 Since different AuthenticationECAPolicyRules can use different 2137 authentication mechanisms in different ways, the aggregation is 2138 realized as an association class. This enables the attributes and 2139 methods of the association class (i.e., AuthenticationRuleDetail) to 2140 be used to define how a given AuthenticationMethod is used by a 2141 particular AuthenticationECAPolicyRule. 2143 Similarly, the PolicyControlsAuthentication aggregation defines 2144 policies to control the configuration of the 2145 AuthenticationRuleDetail association class. This enables the entire 2146 authentication process to be managed by ECAPolicyRules. 2148 Note: a data model MAY choose to collapse this design into a more 2149 efficient implementation. For example, a data model could define two 2150 attributes for the AuthenticationECAPolicyRule class, called (for 2151 example) authenticationMethodCurrent and 2152 authenticationMethodSupported, to represent the 2153 HasAuthenticationMethod aggregation and its association class. The 2154 former is a string attribute that defines the current authentication 2155 method used by this AuthenticationECAPolicyRule, while the latter 2156 defines a set of authentication methods, in the form of an 2157 authentication capability, which this AuthenticationECAPolicyRule 2158 can advertise. 2160 A.2. AuthorizationECAPolicyRuleClass Definition 2162 The purpose of an AuthorizationECAPolicyRule is to define an ECA 2163 Policy Rule that can determine whether access to a resource should 2164 be given and, if so, what permissions should be granted to the 2165 entity that is accessing the resource. 2167 This class does NOT define the authorization method(s) used. This is 2168 because this would effectively "enclose" this information within the 2169 AuthorizationECAPolicyRule. This has two drawbacks. First, other 2170 entities that need to use information from the Authorization 2171 class(es) could not; they would have to associate with the 2172 AuthorizationECAPolicyRule class, and those other classes would not 2173 likely be interested in the AuthorizationECAPolicyRule. Second, the 2174 evolution of new authorization methods should be independent of the 2175 AuthorizationECAPolicyRule; this cannot happen if the Authorization 2176 class(es) are embedded in the AuthorizationECAPolicyRule. Hence, 2177 this document recommends the following design: 2179 +---------------+ 2180 +----------------+ 1..n 1...n | | 2181 | |/ \ HasAuthorizationMethod \| Authorization | 2182 | Authorization + A ----------+----------------+ Method | 2183 | ECAPolicyRule |\ / ^ /| | 2184 | | | +---------------+ 2185 +----------------+ | 2186 | 2187 +------------+------------+ 2188 | AuthorizationRuleDetail | 2189 +------------+------------+ 2190 / \ 0..n 2191 | 2192 | PolicyControlsAuthorization 2193 | 2194 / \ 2195 A 2196 \ / 0..n 2197 +----------+--------------+ 2198 | ManagementECAPolicyRule | 2199 +-------------------------+ 2201 Figure 11. Modeling Authorization Mechanisms 2203 This document only defines the AuthorizationECAPolicyRule; all other 2204 classes, and the aggregations, are defined in an external model. For 2205 completeness, descriptions of how the two aggregations are used are 2206 below. 2208 Figure 11 defines an aggregation between the 2209 AuthorizationECAPolicyRule and an external AuthorizationMethod class 2210 (which is likely a superclass for different types of authorization 2211 mechanisms). This decouples the implementation of authorization 2212 mechanisms from how authorization mechanisms are used. 2214 Since different AuthorizationECAPolicyRules can use different 2215 authorization mechanisms in different ways, the aggregation is 2216 realized as an association class. This enables the attributes and 2217 methods of the association class (i.e., AuthorizationRuleDetail) to 2218 be used to define how a given AuthorizationMethod is used by a 2219 particular AuthorizationECAPolicyRule. 2221 Similarly, the PolicyControlsAuthorization aggregation defines 2222 policies to control the configuration of the AuthorizationRuleDetail 2223 association class. This enables the entire authorization process to 2224 be managed by ECAPolicyRules. 2226 Note: a data model MAY choose to collapse this design into a more 2227 efficient implementation. For example, a data model could define two 2228 attributes for the AuthorizationECAPolicyRule class, called (for 2229 example) authorizationMethodCurrent and authorizationMethodSupported, 2230 to represent the HasAuthorizationMethod aggregation and its 2231 association class. The former is a string attribute that defines the 2232 current authorization method used by this AuthorizationECAPolicyRule, 2233 while the latter defines a set of authorization methods, in the form 2234 of an authorization capability, which this 2235 AuthorizationECAPolicyRule can advertise. 2237 A.3. AccountingECAPolicyRuleClass Definition 2239 The purpose of an AccountingECAPolicyRule is to define an ECA Policy 2240 Rule that can determine which information to collect, and how to 2241 collect that information, from which set of resources for the 2242 purpose of trend analysis, auditing, billing, or cost allocation 2243 [RFC2975] [RFC3539]. 2245 This class does NOT define the accounting method(s) used. This is 2246 because this would effectively "enclose" this information within the 2247 AccountingECAPolicyRule. This has two drawbacks. First, other 2248 entities that need to use information from the Accounting class(es) 2249 could not; they would have to associate with the 2250 AccountingECAPolicyRule class, and those other classes would not 2251 likely be interested in the AccountingECAPolicyRule. Second, the 2252 evolution of new accounting methods should be independent of the 2253 AccountingECAPolicyRule; this cannot happen if the Accounting 2254 class(es) are embedded in the AccountingECAPolicyRule. Hence, this 2255 document recommends the following design: 2257 +-------------+ 2258 +----------------+ 1..n 1...n | | 2259 | |/ \ HasAccountingMethod \| Accounting | 2260 | Accounting + A ----------+--------------+ Method | 2261 | ECAPolicyRule |\ / ^ /| | 2262 | | | +-------------+ 2263 +----------------+ | 2264 | 2265 +----------+-----------+ 2266 | AccountingRuleDetail | 2267 +----------+-----------+ 2268 / \ 0..n 2269 | 2270 | PolicyControlsAccounting 2271 | 2272 / \ 2273 A 2274 \ / 0..n 2275 +----------+--------------+ 2276 | ManagementECAPolicyRule | 2277 +-------------------------+ 2279 Figure 12. Modeling Accounting Mechanisms 2281 This document only defines the AccountingECAPolicyRule; all other 2282 classes, and the aggregations, are defined in an external model. For 2283 completeness, descriptions of how the two aggregations are used are 2284 below. 2286 Figure 12 defines an aggregation between the AccountingECAPolicyRule 2287 and an external AccountingMethod class (which is likely a superclass 2288 for different types of accounting mechanisms). This decouples the 2289 implementation of accounting mechanisms from how accounting 2290 mechanisms are used. 2292 Since different AccountingECAPolicyRules can use different 2293 accounting mechanisms in different ways, the aggregation is realized 2294 as an association class. This enables the attributes and methods of 2295 the association class (i.e., AccountingRuleDetail) to be used to 2296 define how a given AccountingMethod is used by a particular 2297 AccountingECAPolicyRule. 2299 Similarly, the PolicyControlsAccounting aggregation defines policies 2300 to control the configuration of the AccountingRuleDetail association 2301 class. This enables the entire accounting process to be managed by 2302 ECAPolicyRules. 2304 Note: a data model MAY choose to collapse this design into a more 2305 efficient implementation. For example, a data model could define two 2306 attributes for the AccountingECAPolicyRule class, called (for 2307 example) accountingMethodCurrent and accountingMethodSupported, to 2308 represent the HasAccountingMethod aggregation and its association 2309 class. The former is a string attribute that defines the current 2310 accounting method used by this AccountingECAPolicyRule, while the 2311 latter defines a set of accounting methods, in the form of an 2312 authorization capability, which this AccountingECAPolicyRule can 2313 advertise. 2315 A.4. TrafficInspectionECAPolicyRuleClass Definition 2317 The purpose of a TrafficInspectionECAPolicyRule is to define an ECA 2318 Policy Rule that, based on a given context, can determine which 2319 traffic to examine on which devices, which information to collect 2320 from those devices, and how to collect that information. 2322 This class does NOT define the traffic inspection method(s) used. 2323 This is because this would effectively "enclose" this information 2324 within the TrafficInspectionECAPolicyRule. This has two drawbacks. 2325 First, other entities that need to use information from the 2326 TrafficInspection class(es) could not; they would have to associate 2327 with the TrafficInspectionECAPolicyRule class, and those other 2328 classes would not likely be interested in the 2329 TrafficInspectionECAPolicyRule. Second, the evolution of new traffic 2330 inspection methods should be independent of the 2331 TrafficInspectionECAPolicyRule; this cannot happen if the 2332 TrafficInspection class(es) are embedded in the 2333 TrafficInspectionECAPolicyRule. Hence, this document recommends the 2334 following design: 2336 +------------------+ 2337 +-------------------+1..n 1..n| | 2338 | |/ \ HasTrafficInspection \| Traffic | 2339 | TrafficInspection + A ----------+-------------+ InspectionMethod | 2340 | ECAPolicyRule |\ / ^ / | | 2341 | | | +------------------+ 2342 +-------------------+ | 2343 | 2344 +------------+------------+ 2345 | TrafficInspectionDetail | 2346 +------------+------------+ 2347 / \ 0..n 2348 | 2349 | PolicyControlsTrafficInspection 2350 | 2351 / \ 2352 A 2353 \ / 0..n 2354 +----------+--------------+ 2355 | ManagementECAPolicyRule | 2356 +-------------------------+ 2357 Figure 13. Modeling Traffic Inspection Mechanisms 2359 This document only defines the TrafficInspectionECAPolicyRule; all 2360 other classes, and the aggregations, are defined in an external 2361 model. For completeness, descriptions of how the two aggregations 2362 are used are below. 2364 Figure 13 defines an aggregation between the 2365 TrafficInspectionECAPolicyRule and an external TrafficInspection 2366 class (which is likely a superclass for different types of traffic 2367 inspection mechanisms). This decouples the implementation of traffic 2368 inspection mechanisms from how traffic inspection mechanisms are 2369 used. 2371 Since different TrafficInspectionECAPolicyRules can use different 2372 traffic inspection mechanisms in different ways, the aggregation is 2373 realized as an association class. This enables the attributes and 2374 methods of the association class (i.e., TrafficInspectionDetail) to 2375 be used to define how a given TrafficInspectionMethod is used by a 2376 particular TrafficInspectionECAPolicyRule. 2378 Similarly, the PolicyControlsTrafficInspection aggregation defines 2379 policies to control the configuration of the TrafficInspectionDetail 2380 association class. This enables the entire traffic inspection 2381 process to be managed by ECAPolicyRules. 2383 Note: a data model MAY choose to collapse this design into a more 2384 efficient implementation. For example, a data model could define two 2385 attributes for the TrafficInspectionECAPolicyRule class, called (for 2386 example) trafficInspectionMethodCurrent and 2387 trafficInspectionMethodSupported, to represent the 2388 HasTrafficInspectionMethod aggregation and its association class. 2389 The former is a string attribute that defines the current traffic 2390 inspection method used by this TrafficInspectionECAPolicyRule, while 2391 the latter defines a set of traffic inspection methods, in the form 2392 of a traffic inspection capability, which this 2393 TrafficInspectionECAPolicyRule can advertise. 2395 A.5. ApplyProfileECAPolicyRuleClass Definition 2397 The purpose of an ApplyProfileECAPolicyRule is to define an ECA 2398 Policy Rule that, based on a given context, can apply a particular 2399 profile to specific traffic. The profile defines the security 2400 capabilities for content security control and/or attack mitigation 2401 control; these will be described in sections 4.4 and 4.5, 2402 respectively. 2404 This class does NOT define the set of Profiles used. This is because 2405 this would effectively "enclose" this information within the 2406 ApplyProfileECAPolicyRule. This has two drawbacks. First, other 2407 entities that need to use information from the Profile class(es) 2408 could not; they would have to associate with the 2409 ApplyProfileECAPolicyRule class, and those other classes would not 2410 likely be interested in the ApplyProfileECAPolicyRule. Second, the 2411 evolution of new Profile classes should be independent of the 2412 ApplyProfileECAPolicyRule; this cannot happen if the Profile 2413 class(es) are embedded in the ApplyProfileECAPolicyRule. Hence, this 2414 document recommends the following design: 2416 +-------------+ 2417 +-------------------+ 1..n 1..n | | 2418 | |/ \ ProfileApplied \| | 2419 | ApplyProfile + A -----------+-------------+ Profile | 2420 | ECAPolicyRule |\ / ^ /| | 2421 | | | +-------------+ 2422 +-------------------+ | 2423 | 2424 +------------+---------+ 2425 | ProfileAppliedDetail | 2426 +------------+---------+ 2427 / \ 0..n 2428 | 2429 | 2430 PolicyControlsProfileApplication | 2431 | 2432 / \ 2433 A 2434 \ / 0..n 2435 +----------+--------------+ 2436 | ManagementECAPolicyRule | 2437 +-------------------------+ 2439 Figure 14. Modeling Profile ApplicationMechanisms 2441 This document only defines the ApplyProfileECAPolicyRule; all other 2442 classes, and the aggregations, are defined in an external model. For 2443 completeness, descriptions of how the two aggregations are used are 2444 below. 2446 Figure 14 defines an aggregation between the 2447 ApplyProfileECAPolicyRule and an external Profile class (which is 2448 likely a superclass for different types of Profiles). This decouples 2449 the implementation of Profiles from how Profiles are used. 2451 Since different ApplyProfileECAPolicyRules can use different 2452 Profiles in different ways, the aggregation is realized as an 2453 association class. This enables the attributes and methods of the 2454 association class (i.e., ProfileAppliedDetail) to be used to define 2455 how a given Profileis used by a particular ApplyProfileECAPolicyRule. 2457 Similarly, the PolicyControlsProfileApplication aggregation defines 2458 policies to control the configuration of the ProfileAppliedDetail 2459 association class. This enables the application of Profiles to be 2460 managed by ECAPolicyRules. 2462 Note: a data model MAY choose to collapse this design into a more 2463 efficient implementation. For example, a data model could define two 2464 attributes for the ApplyProfileECAPolicyRuleclass, called (for 2465 example) profileAppliedCurrent and profileAppliedSupported, to 2466 represent the ProfileApplied aggregation and its association class. 2467 The former is a string attribute that defines the current Profile 2468 used by this ApplyProfileECAPolicyRule, while the latter defines a 2469 set of Profiles, in the form of a Profile capability, which this 2470 ApplyProfileECAPolicyRule can advertise. 2472 A.6. ApplySignatureECAPolicyRuleClass Definition 2474 The purpose of an ApplySignatureECAPolicyRule is to define an ECA 2475 Policy Rule that, based on a given context, can determine which 2476 Signature object (e.g., an anti-virus file, or aURL filtering file, 2477 or a script) to apply to which traffic. The Signature object defines 2478 the security capabilities for content security control and/or attack 2479 mitigation control; these will be described in sections 4.4 and 4.5, 2480 respectively. 2482 This class does NOT define the set of Signature objects used. This 2483 is because this would effectively "enclose" this information within 2484 the ApplySignatureECAPolicyRule. This has two drawbacks. First, 2485 other entities that need to use information from the Signature 2486 object class(es) could not; they would have to associate with the 2487 ApplySignatureECAPolicyRule class, and those other classes would not 2488 likely be interested in the ApplySignatureECAPolicyRule. Second, the 2489 evolution of new Signature object classes should be independent of 2490 the ApplySignatureECAPolicyRule; this cannot happen if the Signature 2491 object class(es) are embedded in the ApplySignatureECAPolicyRule. 2492 Hence, this document recommends the following design: 2494 +-------------+ 2495 +---------------+ 1..n 1..n | | 2496 | |/ \ SignatureApplied \| | 2497 | ApplySignature+ A ----------+--------------+ Signature | 2498 | ECAPolicyRule |\ / ^ /| | 2499 | | | +-------------+ 2500 +---------------+ | 2501 | 2502 +------------+-----------+ 2503 | SignatureAppliedDetail | 2504 +------------+-----------+ 2505 / \ 0..n 2506 | 2507 | PolicyControlsSignatureApplication 2508 | 2509 / \ 2510 A 2511 \ / 0..n 2512 +----------+--------------+ 2513 | ManagementECAPolicyRule | 2514 +-------------------------+ 2516 Figure 15. Modeling Sginature Application Mechanisms 2518 This document only defines the ApplySignatureECAPolicyRule; all 2519 other classes, and the aggregations, are defined in an external 2520 model. For completeness, descriptions of how the two aggregations 2521 are used are below. 2523 Figure 15 defines an aggregation between the 2524 ApplySignatureECAPolicyRule and an external Signature object class 2525 (which is likely a superclass for different types of Signature 2526 objects). This decouples the implementation of signature objects 2527 from how Signature objects are used. 2529 Since different ApplySignatureECAPolicyRules can use different 2530 Signature objects in different ways, the aggregation is realized as 2531 an association class. This enables the attributes and methods of the 2532 association class (i.e., SignatureAppliedDetail) to be used to 2533 define how a given Signature object is used by a particular 2534 ApplySignatureECAPolicyRule. 2536 Similarly, the PolicyControlsSignatureApplication aggregation 2537 defines policies to control the configuration of the 2538 SignatureAppliedDetail association class. This enables the 2539 application of the Signature object to be managed by policy. 2541 Note: a data model MAY choose to collapse this design into a more 2542 efficient implementation. For example, a data model could define two 2543 attributes for the ApplySignatureECAPolicyRule class, called (for 2544 example) signature signatureAppliedCurrent and 2545 signatureAppliedSupported, to represent the SignatureApplied 2546 aggregation and its association class. The former is a string 2547 attribute that defines the current Signature object used by this 2548 ApplySignatureECAPolicyRule, while the latter defines a set of 2549 Signature objects, in the form of a Signature capability, which this 2550 ApplySignatureECAPolicyRule can advertise. 2552 Authors' Addresses 2554 Liang Xia (Frank) 2555 Huawei 2557 101 Software Avenue, Yuhuatai District 2558 Nanjing, Jiangsu 210012 2559 China 2561 Email: Frank.xialiang@huawei.com 2563 John Strassner 2564 Huawei 2565 Email: John.sc.Strassner@huawei.com 2567 DaCheng Zhang 2568 Huawei 2570 Email: dacheng.zhang@huawei.com 2572 Kepeng Li 2573 Alibaba 2575 Email: kepeng.lkp@alibaba-inc.com 2577 Cataldo Basile, Antonio Lioy 2578 Politecnico di Torino 2579 Corso Duca degli Abruzzi, 34 2580 Torino, 10129 2581 Italy 2582 Email: cataldo.basile@polito.it 2584 Antonio Lioy 2585 Politecnico di Torino 2586 Corso Duca degli Abruzzi, 34 2587 Torino, 10129 2588 Italy 2589 Email: lioy@polito.it 2590 Diego R. Lopez 2591 Telefonica I+D 2592 Zurbaran, 12 2593 Madrid, 28010 2594 Spain 2596 Phone: +34 913 129 041 2597 Email: diego.r.lopez@telefonica.com 2599 Edward Lopez 2600 Fortinet 2601 899 Kifer Road 2602 Sunnyvale, CA 94086 2603 Phone: +1 703 220 0988 2605 EMail: elopez@fortinet.com 2607 Nicolas BOUTHORS 2608 Qosmos 2610 Email: Nicolas.BOUTHORS@qosmos.com 2612 Luyuan Fang 2613 Microsoft 2614 15590 NE 31st St 2615 Redmond, WA 98052 2616 Email: lufang@microsoft.com