idnits 2.17.1 draft-xia-i2nsf-capability-interface-im-06.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: ' 5. 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: ' 6. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2016) is 2857 days in the past. Is this intentional? 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: 'RFC2975' is mentioned on line 892, but not defined == Missing Reference: 'RFC3539' is mentioned on line 892, but not defined == Unused Reference: 'RFC2234' is defined on line 2024, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 2028, but no explicit reference was found in the text == Unused Reference: 'INCITS359 RBAC' is defined on line 2038, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-i2nsf-problem-and-use-cases' is defined on line 2042, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF L. Xia 2 Internet Draft J. Strassner 3 Intended status: Standard Track Huawei 4 K. Li 5 D.Zhang 6 Alibaba 7 E. Lopez 8 Fortinet 9 N. BOUTHORS 10 Qosmos 11 Luyuan Fang 12 Microsoft 14 Expires: December 2016 June 29, 2016 16 Information Model of Interface to Network Security Functions 17 Capability Interface 18 draft-xia-i2nsf-capability-interface-im-06.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on December 29,2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Abstract 60 This draft is focused on the capability interface of NSFs (Network 61 Security Functions) and proposes its information model for managing 62 the various network security functions. 64 Table of Contents 66 1. Introduction ................................................ 4 67 2. Conventions used in this document ........................... 5 68 2.1. Terminology ............................................ 5 69 3. Overall Analysis of Security Capability ..................... 6 70 3.1. Network Security ....................................... 7 71 3.2. Content Security ....................................... 9 72 3.3. Attack Mitigation ..................................... 11 73 4. Information Model Design ................................... 11 74 4.1. Overall Structure ..................................... 11 75 4.2. Information Sub-Model for Network Security Capabilities 14 76 4.3. Information Sub-Model for Network Security ............ 14 77 4.3.1. Network Security Policy Rule Extensions .......... 15 78 4.3.1.1. AuthenticationECAPolicyRule Class Definition 17 79 4.3.1.2. AuthorizationECAPolicyRuleClass Definition .. 19 80 4.3.1.3. AccountingECAPolicyRuleClass Definition ..... 21 81 4.3.1.4. TrafficInspectionECAPolicyRuleClass Definition23 82 4.3.1.5. ApplyProfileECAPolicyRuleClass Definition ... 25 83 4.3.1.6. ApplySignatureECAPolicyRuleClass Definition . 27 84 4.3.2. Network Security Policy Rule Operation ........... 29 85 4.3.3. Network Security Event Sub-Model ................. 30 86 4.3.3.1. UserSecurityEvent Class Description ......... 32 87 4.3.3.1.1. The usrSecEventContent Attribute ....... 32 88 4.3.3.1.2. The usrSecEventFormat Attribute ........ 32 89 4.3.3.1.3. The usrSecEventType Attribute .......... 33 90 4.3.3.2. DeviceSecurityEvent Class Description ....... 33 91 4.3.3.2.1. The devSecEventContent Attribute ....... 33 92 4.3.3.2.2. The devSecEventFormat Attribute ........ 34 93 4.3.3.2.3. The devSecEventType Attribute .......... 34 94 4.3.3.2.4. The devSecEventTypeInfo[0..n] Attribute 34 95 4.3.3.2.5. The devSecEventTypeSeverity Attribute .. 35 96 4.3.3.3. SystemSecurityEvent Class Description ....... 35 97 4.3.3.3.1. The sysSecEventContent Attribute ....... 35 98 4.3.3.3.2. The sysSecEventFormat Attribute ........ 36 99 4.3.3.3.3. The sysSecEventType Attribute .......... 36 100 4.3.3.4. TimeSecurityEvent Class Description ......... 36 101 4.3.3.4.1. The timeSecEventPeriodBegin Attribute .. 37 102 4.3.3.4.2. The timeSecEventPeriodEnd Attribute .... 37 103 4.3.3.4.3. The timeSecEventTimeZone Attribute ..... 37 104 4.3.4. Network Security Condition Sub-Model ............. 37 105 4.3.4.1. PacketSecurityCondition ..................... 39 106 4.3.4.1.1. PacketSecurityMACCondition ............. 39 107 4.3.4.1.1.1. The pktSecCondMACDest Attribute ... 40 108 4.3.4.1.1.2. The pktSecCondMACSrc Attribute .... 40 109 4.3.4.1.1.3. The pktSecCondMAC8021Q Attribute .. 40 110 4.3.4.1.1.4. The pktSecCondMACEtherType Attribute40 111 4.3.4.1.1.5. The pktSecCondMACTCI Attribute .... 40 112 4.3.4.1.2. PacketSecurityIPv4Condition ............ 40 113 4.3.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute 40 114 4.3.4.1.2.2. The pktSecCondIPv4DestAddr Attribute40 115 4.3.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute 116 ............................................... 41 117 4.3.4.1.2.4. The pktSecCondIPv4DSCP Attribute .. 41 118 4.3.4.1.2.5. The pktSecCondIPv4ECN Attribute ... 41 119 4.3.4.1.2.6. The pktSecCondIPv4TotalLength Attribute 120 ............................................... 41 121 4.3.4.1.2.7. The pktSecCondIPv4TTL Attribute ... 41 122 4.3.4.1.3. PacketSecurityIPv6Condition ............ 41 123 4.3.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute 41 124 4.3.4.1.3.2. The pktSecCondIPv6DestAddr Attribute41 125 4.3.4.1.3.3. The pktSecCondIPv6DSCP Attribute .. 41 126 4.3.4.1.3.4. The pktSecCondIPv6ECN Attribute ... 42 127 4.3.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute42 128 4.3.4.1.3.6. The pktSecCondIPv6PayloadLength 129 Attribute ...................................... 42 130 4.3.4.1.3.7. The pktSecCondIPv6NextHeader Attribute42 131 4.3.4.1.3.8. The pktSecCondIPv6HopLimit Attribute42 132 4.3.4.1.4. PacketSecurityTCPCondition ............. 42 133 4.3.4.1.4.1. The pktSecCondTPCSrcPort Attribute 42 134 4.3.4.1.4.2. The pktSecCondTPCDestPort Attribute 42 135 4.3.4.1.4.3. The pktSecCondTPCSeqNum Attribute . 43 136 4.3.4.1.4.4. The pktSecCondTPCFlags Attribute .. 43 137 4.3.4.1.5. PacketSecurityUDPCondition ............. 43 138 4.3.4.1.5.1. The pktSecCondUDPSrcPort Attribute 43 139 4.3.4.1.5.2. The pktSecCondUDPDestPort Attribute 43 140 4.3.4.1.5.3. The pktSecCondUDPLength Attribute . 43 142 4.3.4.2. PacketPayloadSecurityCondition .............. 43 143 4.3.4.3. TargetSecurityCondition ..................... 43 144 4.3.4.4. UserSecurityCondition ....................... 44 145 4.3.4.5. SecurityContextCondition .................... 44 146 4.3.4.6. GenericContextSecurityCondition ............. 44 147 4.3.5. Network Security Action Sub-Model ................ 45 148 4.3.5.1. IngressAction ............................... 46 149 4.3.5.2. EgressAction ................................ 46 150 4.3.5.3. ApplyProfileAction .......................... 46 151 4.3.5.4. ApplySignatureAction ........................ 46 152 4.4. Information Model for Content Security Control ........ 46 153 4.5. Information Model for Attack Mitigation Control ....... 47 154 5. Security Considerations .................................... 48 155 6. IANA Considerations ........................................ 48 156 7. References ................................................. 49 157 7.1. Normative References .................................. 49 158 7.2. Informative References ................................ 49 159 8. Acknowledgments ............................................ 49 160 Appendix A. ................................................... 50 162 1. Introduction 164 The rapid development of cloud computing, along with the demand of 165 cloud-based security services, requires advanced security protection 166 in various scenarios. Examples include network devices in an 167 enterprise network, User Equipment (UE) in a mobile network, devices 168 in the Internet of Things (IoT), or residential access users [I- 169 D.draft-ietf-i2nsf-problem-and-use-cases]. 171 According to [I-D.draft-ietf-i2nsf-framework], there are two types 172 of I2NSF interfaces available for security rules provisioning: 174 o Interface between I2NSF clients and a security controller: This 175 is a service-oriented interface, whose main objective is to 176 define a communication channel over which information defining 177 security services can be requested. This enables security 178 information to be exchanged between various applications (e.g., 179 OpenStack, or various BSS/OSS components) and other components 180 (e.g., security controllers). The design goal of the service 181 interface is to decouple the security service in the application 182 layer from various kinds of security devices and their device- 183 specific security functions. 185 o Interface between NSFs (e.g., firewall, intrusion prevention, or 186 anti-virus) and a security controller. This interface is 187 independent of how the NSFs are implemented (e.g., run in Virtual 188 Machines (VMs) or physical appliances). In this document, this 189 type of interface is also referred to as the "capability 190 interface". Capabilities are functions that NSFs can perform. 191 This interface is used to advertise, select, and activate 192 capabilities of selected NSFs in a vendor-independent manner. 194 The capability interface is used to decouple the security management 195 scheme from the set of NSFs that implement this scheme, and through 196 this interface, an NSF can advertise its security functions to its 197 controller. 199 The information model proposed in this draft is about the functions 200 of an NSF, but is limited to managing part of the capability 201 interface. Note that the monitoring of security functions is out of 202 scope. 204 This document is organized as follows: Section 3 is an analysis of 205 security capability for the I2NSF capability interface. Section 4 206 presents the detailed structure and content of the information model. 207 Section 4 specifies the information model of security policy in 208 Routing Backus-Naur Form [RFC5511]. 210 2. Conventions used in this document 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC-2119 [RFC2119]. 216 This document references to [I-D.draft-ietf-i2nsf-terminology] for 217 more specific security related and I2NSF scoped terminology 218 definitions. 220 2.1. Terminology 222 AAA -Access control, Authorization, Authentication 224 ACL - Access Control List 226 AD - Active Directory 228 ANSI - American National Standards Institute 230 DDoS - Distributed Deny of Services 231 FW - Firewall 233 I2NSF - Interface to Network Security Functions 235 INCITS - International Committee for Information Technology 236 Standards 238 IoT - Internet of Things 240 IPS - Intrusion Prevention System 242 LDAP - Lightweight Directory Access Protocol 244 NAT - Network Address Translation 246 NBI - North-bound Interface 248 NIST - National Institute of Standard Technology 250 NSF - Network Security Function 252 RBAC - Role Based Access Control 254 UE - User Equipment 256 URL - Uniform/Universal Resource Locator 258 VM - Virtual Machine 260 WAF - Web Application Firewall 262 3. Overall Analysis of Security Capability 264 At present, a variety of NSFs produced by multiple security vendors 265 provide various security capabilities to customers. Multiple NSFs 266 can be combined together to provide security services over the given 267 network traffic, regardless of whether the NSFs are implemented as 268 physical or virtual functions. 270 Most of today's security capabilities fall into several common 271 categories, including network security control, content security 272 control, and attack mitigation control. Each category further covers 273 more specific security capabilities, which are described below. 275 3.1. Network Security 277 Network security is a category that describes the inspecting and 278 processing of network traffic based on pre-defined security policies. 280 The inspecting portion may be thought of as a packet-processing 281 engine that inspects packets traversing networks, either directly or 282 in context to flows with which the packet is associated. From the 283 perspective of packet-processing, implementations differ in the 284 depths of packet headers and/or payloads they can inspect, the 285 various flow and context states they can maintain, and the actions 286 that can be applied to the packets or flows. 288 The "Event-Condition-Action" (ECA) policy rule set in [I-D.draft- 289 ietf-i2nsf-framework] is used here as the basis for the security 290 rule design: 292 o Event: An Event is defined as any important occurrence in time of 293 a change in the system being managed, and/or in the environment 294 of the system being managed. When used in the context of policy 295 rules for I2NSF, it is used to determine whether the Condition 296 clause of the Policy Rule can be evaluated or not. Examples of an 297 I2NSF Event include time and user actions (e.g., logon, logoff, 298 and actions that violate an ACL); 300 o Condition: A set of attributes, features, and/or values that are 301 to be compared with a set of known attributes, features, and/or 302 values in order to make a decision. When used in the context of 303 policy rules for I2NSF, it is used to determine whether or not 304 the set of Actions in that Policy Rule can be executed or not. 305 The following are exemplary types of conditions: 307 - Packet content values: Refer to the kind of information or 308 attributes acquired directly from the packet headers or 309 payloads that can be used in the security policy. It can be 310 any fields or attributes in the packet L2/L3/L4 header, or 311 special segment of bytes in the packet payload; 313 - Context values: Refer to the context information for the 314 received packets. It can be (and not limited to): 316 * User: The user (or user group) information to which a 317 network flow is associated. A user has many attributes, 318 such as name, id, password, authentication mode, and so 319 on. The combination of name and id (where id could be a 320 password, a certificate, or other means of identifying 321 the user) is often used in the security policy to 322 identify the user. For example, if an NSF is aware of 323 the IP (or MAC) address associated with the user, the 324 NSF can use a pre-defined or dynamically learned name- 325 address association to enforce the security functions 326 for this given user (or user group); 328 * Schedule: Time or time range when packet or flow is 329 received; 331 * Region: The geographic location where network traffic is 332 received; 334 * Target: The target indicates the entity to which the 335 security services are applied. This can be a service, 336 application, or device. A service is identified by the 337 protocol type and/or port number. An application is a 338 computer program for a specific task or purpose. It 339 provides additional semantics (e.g., dependencies 340 between services) for matching traffic. A device is a 341 managed entity that is connected to the network. The 342 attributes that can identify a device include type (e.g., 343 router, switch, pc) and operating system (e.g., Windows, 344 Linux, or Android), as well as the device's owner; 346 * State: It refers to various states to which the network 347 flow is associated. It can be either the TCP session 348 state (e.g., new, established, related, invalid, or 349 untracked), the session AAA state (e.g., authenticated 350 but not authorized), or the access mode of the device 351 (e.g., wireline, wireless, or cellular; these could be 352 augmented with additional attributes, such as the type 353 of VPN that is being used); 355 * Direction: the direction of the network flow. 357 o Action: NSFs provide security functions by executing various 358 Actions, which at least includes: 360 - Ingress actions, such as pass, drop, mirroring, etc; 361 - Egress actions, such as invoke signaling, tunnel 362 encapsulation, packet forwarding and/or transformation; 364 - Applying a specific Functional Profile or signature - e.g., 365 an IPS Profile, a signature file, an anti-virus file, or a 366 URL filtering file. The functional profile or signature file 367 defines the security capabilities for content security 368 control and/or attack mitigation control; these will be 369 described in sections 3.2 and 3.3, respectively. It is one of 370 the key properties that determine the effectiveness of the 371 NSF, and is mostly vendor-specific today. One goal of I2NSF 372 is to standardize the form and functional interface of those 373 security capabilities while supporting vendor-specific 374 implementations of each. 376 The above ECA ruleset is very general and easily extensible, thus 377 can avoid any potential constraints which could limit the 378 implementation of the network security control capability. 380 3.2. Content Security 382 Content security is another category of security capabilities 383 applied to application layer. Through detecting the contents carried 384 over the traffic in application layer, these capabilities can 385 realize various security functions, such as defending against 386 intrusion, inspecting virus, filtering malicious URL or junk email, 387 blocking illegal web access or malicious data retrieval. 389 Generally, each type of threat in the application layer has a set of 390 unique characteristics, and requires handling with a set of specific 391 methods. Thus, it can be thought of as a logically independent 392 security capability. Since there are a large number of types of 393 threats in the application layer, as well as new types of threats 394 that occur quickly, there will be a large number of security 395 capabilities. Therefore, some basic principles for security 396 capability management and utilization need to be considered: 398 o Flexibility: each security capability should be an independent 399 function, with minimum overlap or dependency to other 400 capabilities. This enables each security capability to be 401 utilized and assembled together freely. More importantly, changes 402 to one capability will not affect other capabilities; 404 o High level of abstraction: this enables each capability to have a 405 unified interface to make it programmable; this in turn provides 406 a standardized ability to describe and report its processing 407 results and corresponding statistics information. Furthermore, it 408 facilitates the multi-vendor interoperability; 410 o Scalability: The system must have the capability to scale up/down 411 or scale in/out. Thus, it can meet various performance 412 requirements derived from changeable network traffic or service 413 requests. In addition, the security capability must support 414 reporting statistics to the security controller to assist its 415 decision on whether it needs to invoke scaling or not; 417 o Automation: The system must have the ability to auto-discover, 418 auto-negotiate, and auto-update security capabilities. These 419 features are especially useful for the management of a large 420 number of NSFs. 422 Based on the above principles, a set of abstract and vendor-neutral 423 capabilities with standard interfaces is needed. The security 424 controller can compare the requirements of clients to the set of 425 capabilities that are currently available in order to choose which 426 NSFs are needed to meet those requirements. Note that this choice is 427 independent of vendor, and instead relies specifically on the 428 capabilities (i.e., the description) of the functions provided. This 429 also facilitates the customization of the functionality of the 430 selected NSFs by setting the parameters of their interfaces. This 431 category of security capability abstracts security as a black box 432 that has selectable features compared with current network security 433 control mechanisms. 435 Furthermore, when an unknown threat (e.g., zero-day exploits, 436 unknown malware, and APTs) is reported by a network security device, 437 new capabilities may be created, and/or existing capabilities may be 438 updated (e.g., signature and algorithm), to correspond to the new 439 functionality provided by the NSF to handle the threat. The new 440 capabilities are provided from different vendors after their 441 analysis of the new threats and subsequent installation of the 442 functions required to report on (and possibly mitigate) the threat. 443 New capabilities may be sent to and stored in a centralized 444 repository, or stored separately in a local repository. In either 445 case, a standard interface is needed during this automated update 446 process. 448 3.3. Attack Mitigation 450 This category of security capabilities is used to detect and 451 mitigate various types of network attacks. Today's common network 452 attacks can be classified into the following sets, and each set 453 further consists of a number of specific attacks: 455 o DDoS attacks: 457 -Network layer DDoS attacks: Examples include SYN flood, UDP 458 flood, ICMP flood, IP fragment flood, IPv6 Routing header 459 attack, and IPv6 duplicate address detection attack; 461 -Application layer DDoS attacks: Examples include http flood, 462 https flood, cache-bypass http floods, WordPress XML RPC 463 floods, ssl DDoS. 465 o Single-packet attack: 467 -Scanning and sniffing attacks: IP sweep, port scanning, etc 469 -malformed packet attacks: Ping of Death, Teardrop, etc 471 -special packet attacks: Oversized ICMP, Tracert, IP timestamp 472 option packets, etc 474 Each type of network attack has its own network behaviors and 475 packet/flow characteristics. Therefore, each type of attack needs a 476 special security function, which is advertised as a capability, for 477 detection and mitigation. 479 Overall, the implementation and management of this category of 480 security capabilities of attack mitigation control is very similar 481 to content security control. A standard interface, through which the 482 security controller can choose and customize the given security 483 capabilities according to specific requirements, is essential. 485 4. Information Model Design 487 4.1. Overall Structure 489 The I2NSF capability interface is in charge of controlling and 490 monitoring the NSFs. This is done using the following approach: 492 1) User of the capability interface selects the set of capabilities 493 required to meet the needs of the application; 495 2) A management entity uses the information model to match chosen 496 capabilities to NSFs, independent of vendor; 498 3) A management entity takes the above information and creates or 499 uses vendor-specific data models to install the NSFs identified by 500 the chosen capabilities; 502 4) Control and monitoring can then begin. 504 Based on the analysis above, the information model should consist of 505 at least four sections: capability, network security, content 506 security and attack mitigation. This assumes that an external model, 507 or set of models, is used to define the concept of an ECA Policy 508 Rule and its components (e.g., Event, Condition, and Action objects). 510 Since Capabilities are determined by the management system, and are 511 not inherent characteristics that differentiate objects, it is also 512 assumed that an external model (or set of models) will define a 513 generic metadata concept. Capabilities are then sub-classed from an 514 appropriate class in the external metadata model. 516 The capability interface is used for advertising, creating, 517 selecting and managing a set of specific security capabilities 518 independent of the type and vendor of device that contains the NSF. 519 That is, the user of the capability interface does not care whether 520 the NSF is virtualized or hosted in a physical device, the vendor of 521 the NSF, and which set of entities the NSF is communicating with 522 (e.g., a firewall or an IPS). Instead, the user only cares about the 523 set of capabilities that the NSF has, such as packet filtering or 524 deep packet inspection. The overall structure is illustrated in the 525 figure below: 527 +-------------------------+ 0..n 0..n +---------------+ 528 | |/ \ \| External | 529 | External ECA Info Model + A ----------------+ Metadata | 530 | |\ / Aggregates /| Info Model | 531 +---------------+---------+ Metadata +------+--------+ 532 / \ / \ 533 | | 534 | | 535 +-------------+------------------------------------+----------+ 536 | | | | 537 | | +----+-------+ | 538 | | | Capability | | 539 | | | Sub-Model | | 540 | | +------------+ | 541 | | | 542 | +----+-----------+----------------+ | 543 | | | | | 544 | | | | | 545 | +-----+-----+ +-----+-----+ +-----+------+ | 546 | | Network |call| Content |call| Attack | | 547 | | Security <----+ Security +----> Mitigation | | 548 | | Sub-Model | | Sub-Model | | Sub-Model | | 549 | +-----+-----+ +-----+-----+ +-----+------+ | 550 | | 551 | | 552 | I2NSF Information Model Design | 553 +-------------------------------------------------------------+ 554 Figure 1. The Overall I2NSF Information Model Design 556 As illustrated in Figure 1, the network security function is the key. 557 It usually runs as the first step to handle traffic (e.g., 558 packet/flow detection and filtering, etc.) over the network layer. 559 The framework portion of the information model ensures that each of 560 the three domain sub-models (content security, network security, and 561 attack mitigation) can function in collaboration or independently. 563 The content security and attack mitigation sub-models can be 564 enforced on demand (i.e., once or recursively based on the results 565 of network security function). 567 This draft defines the four sub-models inside the I2NSF information 568 model shown in Figure 1.This model assumes that another, generic, 569 information model for defining ECA policy rules exists outside of 570 I2NSF. Hence, the Network Security, Content Security, and Attack 571 Mitigation Sub-Models each extend the generic external ECA model to 572 form security policy rules. 574 It also assumes that Capabilities are modeled as metadata, since a 575 Capability is something that describes and/or prescribes 576 functionality about an object, but is not an inherent part of that 577 object. Hence, the Security Capability Sub-Model extends the generic 578 external metadata model. 580 Both of these external models could, but do not have to, draw from 581 the SUPA model [I-D.draft-ietf-supa-generic-policy-info-model]. 583 The external ECA Information Model supplies at least a set of 584 objects that represent a generic ECA Policy Rule, and a set of 585 objects that represent Events, Conditions, and Actions that can be 586 aggregated by the generic ECA Policy Rule. This enables I2NSF to 587 reuse this generic model for different purposes. 589 It is assumed that the external ECA Information Model has the 590 ability to aggregate metadata. Capabilities are then subclassed from 591 an appropriate class in the external Metadata Information Model; 592 this enables the ECA objects to use the existing aggregation between 593 them and Metadata to add Metadata to appropriate ECA objects. 594 Referring to Figure 1, this means that each of Network Security, 595 Content Security, and Attack Mitigation Sub-Models can aggregate 596 zero or more metadata objects to describe and/or prescribe their 597 behavior. 599 Detailed descriptions of each portion of the information model are 600 given in the following sections. 602 4.2. Information Sub-Model for Network Security Capabilities 604 The purpose of the Capability Framework Information Sub-Model is to 605 define the concept of a Capability from an external metadata model, 606 and enable Capabilities to be aggregated to appropriate objects in 607 the Network Security, Content Security, and Attack Mitigation models. 609 4.3. Information Sub-Model for Network Security 611 The purpose of the Network Security Information Sub-Model is to 612 define how network traffic is defined and determine if one or more 613 network security features need to be applied to the traffic or not. 614 Its basic structure is shown in the following figure: 616 +---------------------+ 617 +---------------+ | | 618 | |/ \ \| A Common Superclass | 619 | ECAPolicyRule + A -------------+ for ECA Objects | 620 | |\ / /| | 621 +-------+-------+ +---------+-----------+ 622 / \ / \ 623 | | 624 | | 625 (subclasses to define Network (subclasses of Event, 626 Security ECA Policy Rules, Condition, and Action Objects 627 such as InspectTraffic) for Network Security Control) 629 Figure 2. Network Security Information Sub-Model Overview 631 In the above figure, the ECAPolicyRule, along with the Event, 632 Condition, and Action Objects, are defined in the external ECA Info 633 Model. The Network Security Sub-Model extends both to define 634 security-specific ECA policy rules, as well as Events, Conditions, 635 and Actions. 636 An I2NSF Policy Rule is a special type of Policy Rule that is in 637 event-condition-action (ECA) form. It consists of the Policy Rule, 638 components of a Policy Rule (e.g., events, conditions, and actions), 639 and optionally, metadata. It can be applied to both uni-directional 640 and bi-directional traffic across the NSF. 642 Each rule is triggered by one or more events. If the set of events 643 evaluates to true, then a set of conditions are evaluated and, if 644 true, enable a set of actions to be executed. 646 An example of an I2NSF Policy Rule is, in pseudo-code: 648 IF is TRUE 649 IF is TRUE 650 THEN execute 651 END-IF 652 END-IF 654 In the above example, the Event, Condition, and Action portions 655 of a Policy Rule are all **Boolean Clauses**. 657 4.3.1. Network Security Policy Rule Extensions 659 Figure 3 shows a more detailed design of the ECA Policy Rule 660 subclasses that are contained in the Network Security Information 661 Sub-Model. 663 +---------------+ 664 | External | 665 | ECAPolicyRule | 666 +-------+-------+ 667 / \ 668 | 669 | 670 +------------+----------+ 671 | SecurityECAPolicyRule | 672 +------------+----------+ 673 | 674 | 675 +----+-----+--------+-----+----+---------+---------+--- ... 676 | | | | | | 677 | | | | | | 678 +------+-------+ | +-----+-------+ | +------+------+ | 679 |Authentication| | | Accounting | | |ApplyProfile | | 680 |ECAPolicyRule | | |ECAPolicyRule| | |ECAPolicyRule| | 681 +--------------+ | +-------------+ | +-------------+ | 682 | | | 683 +------+------+ +------+------+ +--------+-----+ 684 |Authorization| | Traffic | |ApplySignature| 685 |ECAPolicyRule| | Inspection | |ECAPolicyRule | 686 +-------------+ |ECAPolicyRule| +--------------+ 687 +-------------+ 689 Figure 3. Network Security Info Sub-Model ECAPolicyRule Extensions 691 The SecurityECAPolicyRule is the top of the I2NSF ECA Policy Rule 692 hierarchy. It inherits from the (external) generic ECA Policy Rule 693 to define Security ECA Policy Rules. The SecurityECAPolicyRule 694 contains all of the attributes, methods, and relationships defined 695 in its superclass, and adds additional concepts that are required 696 for Network Security (these will be defined in the next version of 697 this draft). The six SecurityECAPolicyRule subclasses extend the 698 SecurityECAPolicyRule class to represent six different types of 699 Network Security ECA Policy Rules. It is assumed that the (external) 700 generic ECAPolicyRule class defines basic information in the form of 701 attributes, such as an unique object ID, as well as a description 702 and other basic, but necessary, information. 704 It is assumed that the (external) generic ECA Policy Rule is 705 abstract; the SecurityECAPolicyRule is also abstract. This enables 706 data model optimizations to be made while making this information 707 model detailed but flexible and extensible. 709 The SecurityECAPolicyRule defines network security policy as a 710 container that aggregates Event, Condition, and Action objects, 711 which are described in Section 4.4, 4.5, and 4.6, respectively. 712 Events, Conditions, and Actions can be generic or security-specific. 713 Section 4.6 defines the concept of default security Actions. 715 Brief class descriptions of these six ECA Policy Rules are provided 716 in the following sub-sections. Note that there is a common pattern 717 that defines how these ECAPolicyRules operate; this simplifies their 718 implementation. All of these six ECA Policy Rules are concrete 719 classes. 721 In addition, none of these six subclasses define attributes. This 722 enables them to be viewed as simple object containers, and hence, 723 applicable to a wide variety of content. It also means that the 724 content of the function (e.g., how an entity is authenticated, what 725 specific traffic is inspected, or which particular signature is 726 applied) is defined solely by the set of events, conditions, and 727 actions that are contained by the particular subclass. This enables 728 the policy rule, with its aggregated set of events, conditions, and 729 actions, to be treated as a reusable object. 731 4.3.1.1. AuthenticationECAPolicyRule Class Definition 733 The purpose of an AuthenticationECAPolicyRule is to define an ECA 734 Policy Rule that can verify whether an entity has an attribute of a 735 specific value. 737 This class does NOT define the authentication method used. This is 738 because this would effectively "enclose" this information within the 739 AuthenticationECAPolicyRule. This has two drawbacks. First, other 740 entities that need to use information from the Authentication 741 class(es) could not; they would have to associate with the 742 AuthenticationECAPolicyRule class, and those other classes would not 743 likely be interested in the AuthenticationECAPolicyRule. Second, the 744 evolution of new authentication methods should be independent of the 745 AuthenticationECAPolicyRule; this cannot happen if the 746 Authentication class(es) are embedded in the 747 AuthenticationECAPolicyRule. Hence, this document recommends the 748 following design: 749 +----------------+ 750 +----------------+ 1..n 1...n | | 751 | |/ \ HasAuthenticationMethod \| Authentication | 752 | Authentication + A ----------+---------------+ Method | 753 | ECAPolicyRule |\ / ^ /| | 754 | | | +----------------+ 755 +----------------+ | 756 | 757 +------------+-------------+ 758 | AuthenticationRuleDetail | 759 +------------+-------------+ 760 / \ 0..n 761 | 762 | PolicyControlsAuthentication 763 | 764 / \ 765 A 766 \ / 0..n 767 +----------+--------------+ 768 | ManagementECAPolicyRule | 769 +-------------------------+ 771 Figure 4. Modeling Authentication Mechanisms 773 This document only defines the AuthenticationECAPolicyRule; all 774 other classes, and the aggregations, are defined in an external 775 model. For completeness, descriptions of how the two aggregations 776 are used are below. 778 Figure 4 defines an aggregation between the 779 AuthenticationECAPolicyRule and an externalAuthenticationMethod 780 class (which is likely a superclass for different types of 781 authentication mechanisms). This decouples the implementation of 782 authentication mechanisms from how authentication mechanisms are 783 used. 785 Since different AuthenticationECAPolicyRules can use different 786 authentication mechanisms in different ways, the aggregation is 787 realized as an association class. This enables the attributes and 788 methods of the association class (i.e., AuthenticationRuleDetail) to 789 be used to define how a given AuthenticationMethod is used by a 790 particular AuthenticationECAPolicyRule. 792 Similarly, the PolicyControlsAuthentication aggregation defines 793 policies to control the configuration of the 794 AuthenticationRuleDetail association class. This enables the entire 795 authentication process to be managed by ECAPolicyRules. 797 Note: a data model MAY choose to collapse this design into a more 798 efficient implementation. For example, a data model could define two 799 attributes for the AuthenticationECAPolicyRule class, called (for 800 example) authenticationMethodCurrent and 801 authenticationMethodSupported, to represent the 802 HasAuthenticationMethod aggregation and its association class. The 803 former is a string attribute that defines the current authentication 804 method used by this AuthenticationECAPolicyRule, while the latter 805 defines a set of authentication methods, in the form of an 806 authentication capability, which this AuthenticationECAPolicyRule 807 can advertise. 809 4.3.1.2. AuthorizationECAPolicyRuleClass Definition 811 The purpose of an AuthorizationECAPolicyRule is to define an ECA 812 Policy Rule that can determine whether access to a resource should 813 be given and, if so, what permissions should be granted to the 814 entity that is accessing the resource. 816 This class does NOT define the authorization method(s) used. This is 817 because this would effectively "enclose" this information within the 818 AuthorizationECAPolicyRule. This has two drawbacks. First, other 819 entities that need to use information from the Authorization 820 class(es) could not; they would have to associate with the 821 AuthorizationECAPolicyRule class, and those other classes would not 822 likely be interested in the AuthorizationECAPolicyRule. Second, the 823 evolution of new authorization methods should be independent of the 824 AuthorizationECAPolicyRule; this cannot happen if the Authorization 825 class(es) are embedded in the AuthorizationECAPolicyRule. Hence, 826 this document recommends the following design: 828 +---------------+ 829 +----------------+ 1..n 1...n | | 830 | |/ \ HasAuthorizationMethod \| Authorization | 831 | Authorization + A ----------+----------------+ Method | 832 | ECAPolicyRule |\ / ^ /| | 833 | | | +---------------+ 834 +----------------+ | 835 | 836 +------------+------------+ 837 | AuthorizationRuleDetail | 838 +------------+------------+ 839 / \ 0..n 840 | 841 | PolicyControlsAuthorization 842 | 843 / \ 844 A 845 \ / 0..n 846 +----------+--------------+ 847 | ManagementECAPolicyRule | 848 +-------------------------+ 850 Figure 5. Modeling Authorization Mechanisms 852 This document only defines the AuthorizationECAPolicyRule; all other 853 classes, and the aggregations, are defined in an external model. For 854 completeness, descriptions of how the two aggregations are used are 855 below. 857 Figure 5 defines an aggregation between the 858 AuthorizationECAPolicyRule and an external AuthorizationMethod class 859 (which is likely a superclass for different types of authorization 860 mechanisms). This decouples the implementation of authorization 861 mechanisms from how authorization mechanisms are used. 863 Since different AuthorizationECAPolicyRules can use different 864 authorization mechanisms in different ways, the aggregation is 865 realized as an association class. This enables the attributes and 866 methods of the association class (i.e., AuthorizationRuleDetail) to 867 be used to define how a given AuthorizationMethod is used by a 868 particular AuthorizationECAPolicyRule. 870 Similarly, the PolicyControlsAuthorization aggregation defines 871 policies to control the configuration of the AuthorizationRuleDetail 872 association class. This enables the entire authorization process to 873 be managed by ECAPolicyRules. 875 Note: a data model MAY choose to collapse this design into a more 876 efficient implementation. For example, a data model could define two 877 attributes for the AuthorizationECAPolicyRule class, called (for 878 example) authorizationMethodCurrent and authorizationMethodSupported, 879 to represent the HasAuthorizationMethod aggregation and its 880 association class. The former is a string attribute that defines the 881 current authorization method used by this AuthorizationECAPolicyRule, 882 while the latter defines a set of authorization methods, in the form 883 of an authorization capability, which this 884 AuthorizationECAPolicyRule can advertise. 886 4.3.1.3. AccountingECAPolicyRuleClass Definition 888 The purpose of an AccountingECAPolicyRule is to define an ECA Policy 889 Rule that can determine which information to collect, and how to 890 collect that information, from which set of resources for the 891 purpose of trend analysis, auditing, billing, or cost allocation 892 [RFC2975] [RFC3539]. 894 This class does NOT define the accounting method(s) used. This is 895 because this would effectively "enclose" this information within the 896 AccountingECAPolicyRule. This has two drawbacks. First, other 897 entities that need to use information from the Accounting class(es) 898 could not; they would have to associate with the 899 AccountingECAPolicyRule class, and those other classes would not 900 likely be interested in the AccountingECAPolicyRule. Second, the 901 evolution of new accounting methods should be independent of the 902 AccountingECAPolicyRule; this cannot happen if the Accounting 903 class(es) are embedded in the AccountingECAPolicyRule. Hence, this 904 document recommends the following design: 906 +-------------+ 907 +----------------+ 1..n 1...n | | 908 | |/ \ HasAccountingMethod \| Accounting | 909 | Accounting + A ----------+--------------+ Method | 910 | ECAPolicyRule |\ / ^ /| | 911 | | | +-------------+ 912 +----------------+ | 913 | 914 +----------+-----------+ 915 | AccountingRuleDetail | 916 +----------+-----------+ 917 / \ 0..n 918 | 919 | PolicyControlsAccounting 920 | 921 / \ 922 A 923 \ / 0..n 924 +----------+--------------+ 925 | ManagementECAPolicyRule | 926 +-------------------------+ 928 Figure 6. Modeling Accounting Mechanisms 930 This document only defines the AccountingECAPolicyRule; all other 931 classes, and the aggregations, are defined in an external model. For 932 completeness, descriptions of how the two aggregations are used are 933 below. 935 Figure 6 defines an aggregation between the AccountingECAPolicyRule 936 and an external AccountingMethod class (which is likely a superclass 937 for different types of accounting mechanisms). This decouples the 938 implementation of accounting mechanisms from how accounting 939 mechanisms are used. 941 Since different AccountingECAPolicyRules can use different 942 accounting mechanisms in different ways, the aggregation is realized 943 as an association class. This enables the attributes and methods of 944 the association class (i.e., AccountingRuleDetail) to be used to 945 define how a given AccountingMethod is used by a particular 946 AccountingECAPolicyRule. 948 Similarly, the PolicyControlsAccounting aggregation defines policies 949 to control the configuration of the AccountingRuleDetail association 950 class. This enables the entire accounting process to be managed by 951 ECAPolicyRules. 953 Note: a data model MAY choose to collapse this design into a more 954 efficient implementation. For example, a data model could define two 955 attributes for the AccountingECAPolicyRule class, called (for 956 example) accountingMethodCurrent and accountingMethodSupported, to 957 represent the HasAccountingMethod aggregation and its association 958 class. The former is a string attribute that defines the current 959 accounting method used by this AccountingECAPolicyRule, while the 960 latter defines a set of accounting methods, in the form of an 961 authorization capability, which this AccountingECAPolicyRule can 962 advertise. 964 4.3.1.4. TrafficInspectionECAPolicyRuleClass Definition 966 The purpose of a TrafficInspectionECAPolicyRule is to define an ECA 967 Policy Rule that, based on a given context, can determine which 968 traffic to examine on which devices, which information to collect 969 from those devices, and how to collect that information. 971 This class does NOT define the traffic inspection method(s) used. 972 This is because this would effectively "enclose" this information 973 within the TrafficInspectionECAPolicyRule. This has two drawbacks. 974 First, other entities that need to use information from the 975 TrafficInspection class(es) could not; they would have to associate 976 with the TrafficInspectionECAPolicyRule class, and those other 977 classes would not likely be interested in the 978 TrafficInspectionECAPolicyRule. Second, the evolution of new traffic 979 inspection methods should be independent of the 980 TrafficInspectionECAPolicyRule; this cannot happen if the 981 TrafficInspection class(es) are embedded in the 982 TrafficInspectionECAPolicyRule. Hence, this document recommends the 983 following design: 985 +------------------+ 986 +-------------------+1..n 1..n| | 987 | |/ \ HasTrafficInspection\| Traffic | 988 | TrafficInspection + A ----------+-----------+ InspectionMethod | 989 | ECAPolicyRule |\ / ^ / | | 990 | | | +------------------+ 991 +-------------------+ | 992 | 993 +------------+------------+ 994 | TrafficInspectionDetail | 995 +------------+------------+ 996 / \ 0..n 997 | 998 | PolicyControlsTrafficInspection 999 | 1000 / \ 1001 A 1002 \ / 0..n 1003 +----------+--------------+ 1004 | ManagementECAPolicyRule | 1005 +-------------------------+ 1006 Figure 7. Modeling Traffic Inspection Mechanisms 1008 This document only defines the TrafficInspectionECAPolicyRule; all 1009 other classes, and the aggregations, are defined in an external 1010 model. For completeness, descriptions of how the two aggregations 1011 are used are below. 1013 Figure 7 defines an aggregation between the 1014 TrafficInspectionECAPolicyRule and an external TrafficInspection 1015 class (which is likely a superclass for different types of traffic 1016 inspection mechanisms). This decouples the implementation of traffic 1017 inspection mechanisms from how traffic inspection mechanisms are 1018 used. 1020 Since different TrafficInspectionECAPolicyRules can use different 1021 traffic inspection mechanisms in different ways, the aggregation is 1022 realized as an association class. This enables the attributes and 1023 methods of the association class (i.e., TrafficInspectionDetail) to 1024 be used to define how a given TrafficInspectionMethod is used by a 1025 particular TrafficInspectionECAPolicyRule. 1027 Similarly, the PolicyControlsTrafficInspection aggregation defines 1028 policies to control the configuration of the TrafficInspectionDetail 1029 association class. This enables the entire traffic inspection 1030 process to be managed by ECAPolicyRules. 1032 Note: a data model MAY choose to collapse this design into a more 1033 efficient implementation. For example, a data model could define two 1034 attributes for the TrafficInspectionECAPolicyRule class, called (for 1035 example) trafficInspectionMethodCurrent and 1036 trafficInspectionMethodSupported, to represent the 1037 HasTrafficInspectionMethod aggregation and its association class. 1038 The former is a string attribute that defines the current traffic 1039 inspection method used by this TrafficInspectionECAPolicyRule, while 1040 the latter defines a set of traffic inspection methods, in the form 1041 of a traffic inspection capability, which this 1042 TrafficInspectionECAPolicyRule can advertise. 1044 4.3.1.5. ApplyProfileECAPolicyRuleClass Definition 1046 The purpose of an ApplyProfileECAPolicyRule is to define an ECA 1047 Policy Rule that, based on a given context, can apply a particular 1048 profile to specific traffic. The profile defines the security 1049 capabilities for content security control and/or attack mitigation 1050 control; these will be described in sections 4.4 and 4.5, 1051 respectively. 1053 This class does NOT define the set of Profiles used. This is because 1054 this would effectively "enclose" this information within the 1055 ApplyProfileECAPolicyRule. This has two drawbacks. First, other 1056 entities that need to use information from the Profile class(es) 1057 could not; they would have to associate with the 1058 ApplyProfileECAPolicyRule class, and those other classes would not 1059 likely be interested in the ApplyProfileECAPolicyRule. Second, the 1060 evolution of new Profile classes should be independent of the 1061 ApplyProfileECAPolicyRule; this cannot happen if the Profile 1062 class(es) are embedded in the ApplyProfileECAPolicyRule. Hence, this 1063 document recommends the following design: 1065 +-----------+ 1066 +-------------------+ 1..n 1..n | | 1067 | |/ \ ProfileApplied \| | 1068 | ApplyProfile + A -------------+-----------+ Profile | 1069 | ECAPolicyRule |\ / ^ /| | 1070 | | | +-----------+ 1071 +-------------------+ | 1072 | 1073 +------------+---------+ 1074 | ProfileAppliedDetail | 1075 +------------+---------+ 1076 / \ 0..n 1077 | 1078 | 1079 PolicyControlsProfileApplication | 1080 | 1081 / \ 1082 A 1083 \ / 0..n 1084 +----------+--------------+ 1085 | ManagementECAPolicyRule | 1086 +-------------------------+ 1088 Figure 8. Modeling Profile ApplicationMechanisms 1090 This document only defines the ApplyProfileECAPolicyRule; all other 1091 classes, and the aggregations, are defined in an external model. For 1092 completeness, descriptions of how the two aggregations are used are 1093 below. 1095 Figure 8 defines an aggregation between the 1096 ApplyProfileECAPolicyRule and an external Profile class (which is 1097 likely a superclass for different types of Profiles). This decouples 1098 the implementation of Profiles from how Profiles are used. 1100 Since different ApplyProfileECAPolicyRules can use different 1101 Profiles in different ways, the aggregation is realized as an 1102 association class. This enables the attributes and methods of the 1103 association class (i.e., ProfileAppliedDetail) to be used to define 1104 how a given Profileis used by a particular ApplyProfileECAPolicyRule. 1106 Similarly, the PolicyControlsProfileApplication aggregation defines 1107 policies to control the configuration of the ProfileAppliedDetail 1108 association class. This enables the application of Profiles to be 1109 managed by ECAPolicyRules. 1111 Note: a data model MAY choose to collapse this design into a more 1112 efficient implementation. For example, a data model could define two 1113 attributes for the ApplyProfileECAPolicyRuleclass, called (for 1114 example) profileAppliedCurrent and profileAppliedSupported, to 1115 represent the ProfileApplied aggregation and its association class. 1116 The former is a string attribute that defines the current Profile 1117 used by this ApplyProfileECAPolicyRule, while the latter defines a 1118 set of Profiles, in the form of a Profile capability, which this 1119 ApplyProfileECAPolicyRule can advertise. 1121 4.3.1.6. ApplySignatureECAPolicyRuleClass Definition 1123 The purpose of an ApplySignatureECAPolicyRule is to define an ECA 1124 Policy Rule that, based on a given context, can determine which 1125 Signature object (e.g., an anti-virus file, or aURL filtering file, 1126 or a script) to apply to which traffic. The Signature object defines 1127 the security capabilities for content security control and/or attack 1128 mitigation control; these will be described in sections 4.4 and 4.5, 1129 respectively. 1131 This class does NOT define the set of Signature objects used. This 1132 is because this would effectively "enclose" this information within 1133 the ApplySignatureECAPolicyRule. This has two drawbacks. First, 1134 other entities that need to use information from the Signature 1135 object class(es) could not; they would have to associate with the 1136 ApplySignatureECAPolicyRule class, and those other classes would not 1137 likely be interested in the ApplySignatureECAPolicyRule. Second, the 1138 evolution of new Signature object classes should be independent of 1139 the ApplySignatureECAPolicyRule; this cannot happen if the Signature 1140 object class(es) are embedded in the ApplySignatureECAPolicyRule. 1141 Hence, this document recommends the following design: 1143 +-------------+ 1144 +---------------+ 1..n 1..n | | 1145 | |/ \ SignatureApplied \| | 1146 | ApplySignature+ A ----------+--------------+ Signature | 1147 | ECAPolicyRule |\ / ^ /| | 1148 | | | +-------------+ 1149 +---------------+ | 1150 | 1151 +------------+-----------+ 1152 | SignatureAppliedDetail | 1153 +------------+-----------+ 1154 / \ 0..n 1155 | 1156 | PolicyControlsSignatureApplication 1157 | 1158 / \ 1159 A 1160 \ / 0..n 1161 +----------+--------------+ 1162 | ManagementECAPolicyRule | 1163 +-------------------------+ 1165 Figure 9. Modeling Sginature Application Mechanisms 1167 This document only defines the ApplySignatureECAPolicyRule; all 1168 other classes, and the aggregations, are defined in an external 1169 model. For completeness, descriptions of how the two aggregations 1170 are used are below. 1172 Figure 9 defines an aggregation between the 1173 ApplySignatureECAPolicyRule and an external Signature object class 1174 (which is likely a superclass for different types of Signature 1175 objects). This decouples the implementation of signature objects 1176 from how Signature objects are used. 1178 Since different ApplySignatureECAPolicyRules can use different 1179 Signature objects in different ways, the aggregation is realized as 1180 an association class. This enables the attributes and methods of the 1181 association class (i.e., SignatureAppliedDetail) to be used to 1182 define how a given Signature object is used by a particular 1183 ApplySignatureECAPolicyRule. 1185 Similarly, the PolicyControlsSignatureApplication aggregation 1186 defines policies to control the configuration of the 1187 SignatureAppliedDetail association class. This enables the 1188 application of the Signature object to be managed by policy. 1190 Note: a data model MAY choose to collapse this design into a more 1191 efficient implementation. For example, a data model could define two 1192 attributes for the ApplySignatureECAPolicyRule class, called (for 1193 example) signature signatureAppliedCurrent and 1194 signatureAppliedSupported, to represent the SignatureApplied 1195 aggregation and its association class. The former is a string 1196 attribute that defines the current Signature object used by this 1197 ApplySignatureECAPolicyRule, while the latter defines a set of 1198 Signature objects, in the form of a Signature capability, which this 1199 ApplySignatureECAPolicyRule can advertise. 1201 4.3.2. Network Security Policy Rule Operation 1203 Network security policy consists of a number of more granular ECA 1204 Policy Rules formed from the information model described above. In 1205 simpler cases, where the Event and Condition clauses remain 1206 unchanged, then network security control may be performed by calling 1207 additional network security actions. Network security policy 1208 examines and performs basic processing of the traffic as follows: 1210 1. For a given SecurityECAPolicyRule (which can be generic or 1211 specific to security, such as those in Figure 3), the NSF 1212 evaluates the Event clause. It may use security Event objects to 1213 do all or part of this evaluation, which are defined in section 1214 4.3.3. If the Event clause evaluates to TRUE, then the Condition 1215 clause of this SecurityECAPolicyRule is evaluated; otherwise, 1216 execution of this SecurityECAPolicyRule is stopped, and the next 1217 SecurityECAPolicyRule (if one exists) is evaluated; 1219 2. The Condition clause is then evaluated. It may use security 1220 Condition objects to do all or part of this evaluation, which are 1221 defined in section 4.3.4. If the Condition clause evaluates to 1222 TRUE, then the set of Actions in this SecurityECAPolicyRule MUST 1223 be executed. This is defined as "matching" the 1224 SecurityECAPolicyRule; otherwise, execution of this 1225 SecurityECAPolicyRule is stopped, and the next 1226 SecurityECAPolicyRule (if one exists) is evaluated; 1228 3. If none of the SecurityECAPolicyRules are matched, then the NSF 1229 denies the traffic by default; 1231 4. If the traffic matches a rule, the NSF performs the defined 1232 Actions on the traffic. It may use security Action objects to do 1233 all or part of this execution, which are defined in section 4.3.5. 1234 If the action is "deny", the NSF blocks the traffic. If the basic 1235 action is permit or mirror, the NSF firstly performs that 1236 function, and then checks whether certain other security 1237 capabilities are referenced in the rule. If yes, go to step 5. If 1238 no, the traffic is permitted; 1240 5. If other security capabilities (e.g., Anti-virus or IPS) are 1241 referenced in the SecurityECAPolicyRule, and the Action defined 1242 in the rule is permit or mirror, the NSF performs the referenced 1243 security capabilities. 1245 Metadata attached to the SecurityECAPolicyRule MAY be used to 1246 control how the SecurityECAPolicyRule is evaluated. This is called a 1247 Policy Rule Evaluation Strategy. For example, one strategy is to 1248 match and execute the first SecurityECAPolicyRule, and then exit 1249 without executing any other SecurityECAPolicyRules (even if they 1250 matched). In contrast, a second strategy is to first collect all 1251 SecurityECAPolicyRules that matched, and then execute them according 1252 to a pre-defined order (e.g., the priority of each 1253 SecurityECAPolicyRule). 1255 One policy or rule can be applied multiple times to different 1256 managed objects (e.g., links, devices, networks, VPNS). This not 1257 only guarantees consistent policy enforcement, but also decreases 1258 the configuration workload. 1260 4.3.3. Network Security Event Sub-Model 1262 Figure 10 shows a more detailed design of the Event subclasses that 1263 are contained in the Network Security Information Sub-Model. 1265 +---------------------+ 1266 +---------------+ 1..n 1..n| | 1267 | |/ \ \| A Common Superclass | 1268 | ECAPolicyRule + A ---------+ for ECA Objects | 1269 | |\ / /| | 1270 +---------------+ +-----------+---------+ 1271 / \ 1272 | 1273 | 1274 +--------------+--------+------+ 1275 | | | 1276 | | | 1277 +-----+----+ +------+------+ +-----+-----+ 1278 | An Event | | A Condition | | An Action | 1279 | Class | | Class | | Class | 1280 +-----+----+ +-------------+ +-----------+ 1281 / \ 1282 | 1283 | 1284 | 1285 +-----------+---+----------------+--------------+-- ... 1286 | | | | 1287 | | | | 1288 +-------+----+ +--------+-----+ +--------+-----+ +------+-----+ 1289 |UserSecurity| | Device | | System | |TimeSecurity| 1290 | Event | | SecurityEvent| | SecurityEvent| | Event | 1291 +------------+ +--------------+ +--------------+ +------------+ 1293 Figure 10. Network Security Info Sub-Model Event Class Extensions 1295 The four Event classes shown in Figure 10 extend the (external) 1296 generic Event class to represent Events that are of interest to 1297 Network Security. It is assumed that the (external) generic Event 1298 class defines basic Event information in the form of attributes, 1299 such as a unique event ID, a description, as well as the date and 1300 time that the event occurred. 1302 The following are assumptions that define the functionality of the 1303 generic Event class. If desired, these could be defined as 1304 attributes in a SecurityEvent class (which would be a subclass of 1305 the generic Event class, and a superclass of the four Event classes 1306 shown in Figure 10). However, this makes it harder to use any 1307 generic Event model with the I2NSF events. Assumptions are: 1309 - The generic Event class is abstract 1310 - All four SecurityEvent subclasses are concrete 1311 - The generic Event class uses the composite pattern, so 1312 individual Events as well as hierarchies of Events are 1313 available (the four subclasses in Figure 10 would be 1314 subclasses of the Atomic Event) 1315 - The generic Event class has a mechanism to uniquely identify 1316 the source of the Event 1317 - The generic Event class has a mechanism to separate header 1318 information from its payload 1319 - The generic Event class has a mechanism to attach zero or more 1320 metadata objects to it 1322 Brief class descriptions are provided in the following sub-sections. 1324 4.3.3.1. UserSecurityEvent Class Description 1326 The purpose of this class is to represent Events that are initiated 1327 by a user, such as logon and logoff Events. Information in this 1328 Event may be used as part of a test to determine if the Condition 1329 clause in this ECA Policy Rule should be evaluated or not. Examples 1330 include user identification data and the type of connection used by 1331 the user. 1333 The UserSecurityEvent class defines the following attributes: 1335 4.3.3.1.1. The usrSecEventContent Attribute 1337 This is a mandatory string that contains the content of the 1338 UserSecurityEvent. The format of the content is specified in the 1339 usrSecEventFormat class attribute, and the type of Event is defined 1340 in the usrSecEventType class attribute. An example of the 1341 usrSecEventContent attribute is the string "hrAdmin", with the 1342 usrSecEventFormat set to 1 (GUID) and the usrSecEventType attribute 1343 set to 5 (new logon). 1345 4.3.3.1.2. The usrSecEventFormat Attribute 1347 This is a mandatory non-negative enumerated integer, which is used 1348 to specify the data type of the usrSecEventContent attribute. The 1349 content is specified in the usrSecEventContent class attribute, and 1350 the type of Event is defined in the usrSecEventType class attribute. 1351 An example of the usrSecEventContent attribute is the string 1352 "hrAdmin", with the usrSecEventFormat attribute set to 1 (GUID) and 1353 the usrSecEventType attribute set to 5 (new logon). Values include: 1355 0: unknown 1356 1: GUID (Generic Unique IDentifier) 1357 2: UUID (Universal Unique IDentifier) 1358 3: URI (Uniform Resource Identifier) 1359 4: FQDN (Fully Qualified Domain Name) 1360 5: FQPN (Fully Qualified Path Name) 1362 4.3.3.1.3. The usrSecEventType Attribute 1364 This is a mandatory non-negative enumerated integer, which is used 1365 to specify the type of Event that involves this user. The content 1366 and format are specified in the usrSecEventContent and 1367 usrSecEventFormat class attributes, respectively. An example of the 1368 usrSecEventContent attribute is the string "hrAdmin", with the 1369 usrSecEventFormat attribute set to 1 (GUID) and the usrSecEventType 1370 attribute set to 5 (new logon). Values include: 1372 0: unknown 1373 1: new user created 1374 2: new user group created 1375 3: user deleted 1376 4: user group deleted 1377 5: user logon 1378 6: user logoff 1379 7: user access request 1380 8: user access granted 1381 9: user access violation 1383 4.3.3.2. DeviceSecurityEvent Class Description 1385 The purpose of a DeviceSecurityEvent is to represent Events that 1386 provide information from the Device that are important to I2NSF 1387 Security. Information in this Event may be used as part of a test to 1388 determine if the Condition clause in this ECA Policy Rule should be 1389 evaluated or not. Examples include alarms and various device 1390 statistics (e.g., a type of threshold that was exceeded), which may 1391 signal the need for further action. 1393 The DeviceSecurityEvent class defines the following attributes: 1395 4.3.3.2.1. The devSecEventContent Attribute 1397 This is a mandatory string that contains the content of the 1398 DeviceSecurityEvent. The format of the content is specified in the 1399 devSecEventFormat class attribute, and the type of Event is defined 1400 in the devSecEventType class attribute. An example of the 1401 devSecEventContent attribute is "alarm", with the devSecEventFormat 1402 attribute set to 1 (GUID), the devSecEventType attribute set to 5 1403 (new logon). 1405 4.3.3.2.2. The devSecEventFormat Attribute 1407 This is a mandatory non-negative enumerated integer, which is used 1408 to specify the data type of the devSecEventContent attribute. Values 1409 include: 1411 0: unknown 1412 1: GUID (Generic Unique IDentifier) 1413 2: UUID (Universal Unique IDentifier) 1414 3: URI (Uniform Resource Identifier) 1415 4: FQDN (Fully Qualified Domain Name) 1416 5: FQPN (Fully Qualified Path Name) 1418 4.3.3.2.3. The devSecEventType Attribute 1420 This is a mandatory non-negative enumerated integer, which is used 1421 to specify the type of Event that was generated by this device. 1422 Values include: 1424 0: unknown 1425 1: communications alarm 1426 2: quality of service alarm 1427 3: processing error alarm 1428 4: equipment error alarm 1429 5: environmental error alarm 1431 Values 1-5 are defined in X.733. Additional types of errors may also 1432 be defined. 1434 4.3.3.2.4. The devSecEventTypeInfo[0..n] Attribute 1436 This is an optional array of strings, which is used to provide 1437 additional information describing the specifics of the Event 1438 generated by this Device. For example, this attribute could contain 1439 probable cause information in the first array, trend information in 1440 the second array, proposed repair actions in the third array, and 1441 additional information in the fourth array. 1443 4.3.3.2.5. The devSecEventTypeSeverity Attribute 1445 This is a mandatory non-negative enumerated integer, which is used 1446 to specify the perceived severity of the Event generated by this 1447 Device. Values include: 1449 0: unknown 1450 1: cleared 1451 2: indeterminate 1452 3: critical 1453 4: major 1454 5: minor 1455 6: warning 1457 Values 1-6 are from X.733. 1459 4.3.3.3. SystemSecurityEvent Class Description 1461 The purpose of a SystemSecurityEvent is to represent Events that are 1462 detected by the management system, instead of Events that are 1463 generated by a user or a device. Information in this Event may be 1464 used as part of a test to determine if the Condition clause in this 1465 ECA Policy Rule should be evaluated or not. Examples include an 1466 event issued by an analytics system that warns against a particular 1467 pattern of unknown user accesses, or an Event issued by a management 1468 system that represents a set of correlated and/or filtered Events. 1470 The SystemSecurityEvent class defines the following attributes: 1472 4.3.3.3.1. The sysSecEventContent Attribute 1474 This is a mandatory string that contains the content of the 1475 SystemSecurityEvent. The format of the content is specified in the 1476 sysSecEventFormat class attribute, and the type of Event is defined 1477 in the sysSecEventType class attribute. An example of the 1478 sysSecEventContent attribute is the string "sysadmin3", with the 1479 sysSecEventFormat attribute set to 1 (GUID), and the sysSecEventType 1480 attribute set to 2 (audit log cleared). 1482 4.3.3.3.2. The sysSecEventFormat Attribute 1484 This is a mandatory non-negative enumerated integer, which is used 1485 to specify the data type of the sysSecEventContent attribute. Values 1486 include: 1488 0: unknown 1489 1: GUID (Generic Unique IDentifier) 1490 2: UUID (Universal Unique IDentifier) 1491 3: URI (Uniform Resource Identifier) 1492 4: FQDN (Fully Qualified Domain Name) 1493 5: FQPN (Fully Qualified Path Name) 1495 4.3.3.3.3. The sysSecEventType Attribute 1497 This is a mandatory non-negative enumerated integer, which is used 1498 to specify the type of Event that involves this device. Values 1499 include: 1501 0: unknown 1502 1: audit log written to 1503 2: audit log cleared 1504 3: policy created 1505 4: policy edited 1506 5: policy deleted 1507 6: policy executed 1509 4.3.3.4. TimeSecurityEvent Class Description 1511 The purpose of a TimeSecurityEvent is to represent Events that are 1512 temporal in nature (e.g., the start or end of a period of time). 1513 Time events signify an individual occurrence, or a time period, in 1514 which a significant event happened. Information in this Event may be 1515 used as part of a test to determine if the Condition clause in this 1516 ECA Policy Rule should be evaluated or not. Examples include issuing 1517 an Event at a specific time to indicate that a particular resource 1518 should not be accessed, or that different authentication and 1519 authorization mechanisms should now be used (e.g., because it is now 1520 past regular business hours). 1522 The TimeSecurityEvent class defines the following attributes: 1524 4.3.3.4.1. The timeSecEventPeriodBegin Attribute 1526 This is a mandatory DateTime attribute, and represents the beginning 1527 of a time period. It has a value that has a date and/or a time 1528 component (as in the Java or Python libraries). 1530 4.3.3.4.2. The timeSecEventPeriodEnd Attribute 1532 This is a mandatory DateTime attribute, and represents the end of a 1533 time period. It has a value that has a date and/or a time component 1534 (as in the Java or Python libraries). If this is a single Event 1535 occurrence, and not a time period when the Event can occur, then the 1536 timeSecEventPeriodEnd attribute may be ignored. 1538 4.3.3.4.3. The timeSecEventTimeZone Attribute 1540 This is a mandatory string attribute, and defines the time zone that 1541 this Event occurred in using the format specified in ISO8601. 1543 4.3.4. Network Security Condition Sub-Model 1545 Figure 11 shows a more detailed design of the Condition subclasses 1546 that are contained in the Network Security Information Sub-Model. 1548 +---------------------+ 1549 +---------------+ 1..n 1..n | | 1550 | |/ \ \| A Common Superclass | 1551 | ECAPolicyRule+ A ----------+ for ECA Objects | 1552 | |\ / /| | 1553 +-------+-------+ +-----------+---------+ 1554 / \ 1555 | 1556 | 1557 +--------------+----------+----+ 1558 | | | 1559 | | | 1560 +-----+----+ +------+------+ +-----+-----+ 1561 | An Event | | A Condition | | An Action | 1562 | Class | | Class | | Class | 1563 +----------+ +------+------+ +-----------+ 1564 / \ 1565 | 1566 | 1567 +--------+----------+------+---+---------+--------+--- ... 1568 | | | | | | 1569 | | | | | | 1570 +-----+-----+ | +-------+-------+ | +------+-----+ | 1571 | Packet | | | PacketPayload | | | Target | | 1572 | Security | | | Security | | | Security | | 1573 | Condition | | | Condition | | | Condition | | 1574 +-----------+ | +---------------+ | +------------+ | 1575 | | | 1576 +------+-------+ +----------+------+ +--------+-------+ 1577 | UserSecurity | | SecurityContext | | GenericContext | 1578 | Condition | | Condition | | Condition | 1579 +--------------+ +-----------------+ +----------------+ 1581 Figure 11. Network Security Info Sub-Model Condition Class 1582 Extensions 1584 The six Condition classes shown in Figure 11 extend the (external) 1585 generic Condition class to represent Conditions that are of interest 1586 to Network Security. It is assumed that the (external) generic 1587 Condition class is abstract, so that data model optimizations may be 1588 defined. It is also assumed that the generic Condition class defines 1589 basic Condition information in the form of attributes, such as a 1590 unique object ID, a description, as well as a mechanism to attach 1591 zero or more metadata objects to it. While this could be defined as 1592 attributes in a SecurityCondition class (which would be a subclass 1593 of the generic Condition class, and a superclass of the six 1594 Condition classes shown in Figure 11), this makes it harder to use 1595 any generic Condition model with the I2NSF conditions. 1597 Brief class descriptions are provided in the following sub-sections. 1599 4.3.4.1. PacketSecurityCondition 1601 The purpose of this Class is to represent packet header information 1602 that can be used as part of a test to determine if the set of Policy 1603 Actions in this ECA Policy Rule should be executed or not. This 1604 class is abstract, and serves as the superclass of more detailed 1605 conditions that involve different types of packet formats. Its 1606 subclasses are shown in Figure 12, and are defined in the following 1607 sections. 1609 +-------------------------+ 1610 | PacketSecurityCondition | 1611 +------------+------------+ 1612 / \ 1613 | 1614 | 1615 +---------+----------+---+-----+----------+ 1616 | | | | | 1617 | | | | | 1618 +--------+-------+ | +--------+-------+ | +--------+-------+ 1619 | PacketSecurity | | | PacketSecurity | | | PacketSecurity | 1620 | MACCondition | | | IPv4Condition | | | IPv6Condition | 1621 +----------------+ | +----------------+ | +----------------+ 1622 | | 1623 +--------+-------+ +--------+-------+ 1624 | TCPCondition | | UDPCondition | 1625 +----------------+ +----------------+ 1627 Figure 12. Network Security Info Sub-Model PacketSecurityCondition 1628 Class Extensions 1630 4.3.4.1.1. PacketSecurityMACCondition 1632 The purpose of this Class is to represent packet MAC packet header 1633 information that can be used as part of a test to determine if the 1634 set of Policy Actions in this ECA Policy Rule should be executed or 1635 not. This class is concrete, and defines the following attributes: 1637 4.3.4.1.1.1. The pktSecCondMACDest Attribute 1639 This is a mandatory string attribute, and defines the MAC 1640 destination address (6 octets long). 1642 4.3.4.1.1.2. The pktSecCondMACSrc Attribute 1644 This is a mandatory string attribute, and defines the MAC source 1645 address (6 octets long). 1647 4.3.4.1.1.3. The pktSecCondMAC8021Q Attribute 1649 This is an optional string attribute, and defines the 802.1Q tag 1650 value (2 octets long). This defines VLAN membership and 802.1p 1651 priority values. 1653 4.3.4.1.1.4. The pktSecCondMACEtherType Attribute 1655 This is a mandatory string attribute, and defines the EtherType 1656 field (2 octets long). Values up to and including 1500 indicate the 1657 size of the payload in octets; values of 1536 and above define which 1658 protocol is encapsulated in the payload of the frame. 1660 4.3.4.1.1.5. The pktSecCondMACTCI Attribute 1662 This is an optional string attribute, and defines the Tag Control 1663 Information. This consists of a 3 bit user priority field, a drop 1664 eligible indicator (1 bit), and a VLAN identifier (12 bits). 1666 4.3.4.1.2. PacketSecurityIPv4Condition 1668 The purpose of this Class is to represent packet IPv4 packet header 1669 information that can be used as part of a test to determine if the 1670 set of Policy Actions in this ECA Policy Rule should be executed or 1671 not. This class is concrete, and defines the following attributes: 1673 4.3.4.1.2.1. The pktSecCondIPv4SrcAddr Attribute 1675 This is a mandatory string attribute, and defines the IPv4 Source 1676 Address (32 bits). 1678 4.3.4.1.2.2. The pktSecCondIPv4DestAddr Attribute 1680 This is a mandatory string attribute, and defines the IPv4 1681 Destination Address (32 bits). 1683 4.3.4.1.2.3. The pktSecCondIPv4ProtocolUsed Attribute 1685 This is a mandatory string attribute, and defines the protocol used 1686 in the data portion of the IP datagram (8 bits). 1688 4.3.4.1.2.4. The pktSecCondIPv4DSCP Attribute 1690 This is a mandatory string attribute, and defines the Differentiated 1691 Services Code Point field (6 bits). 1693 4.3.4.1.2.5. The pktSecCondIPv4ECN Attribute 1695 This is an optional string attribute, and defines the Explicit 1696 Congestion Notification field (2 bits). 1698 4.3.4.1.2.6. The pktSecCondIPv4TotalLength Attribute 1700 This is a mandatory string attribute, and defines the total length 1701 of the packet (including header and data) in bytes (16 bits). 1703 4.3.4.1.2.7. The pktSecCondIPv4TTL Attribute 1705 This is a mandatory string attribute, and defines the Time To Live 1706 in seconds (8 bits). 1708 4.3.4.1.3. PacketSecurityIPv6Condition 1710 The purpose of this Class is to represent packet IPv6 packet header 1711 information that can be used as part of a test to determine if the 1712 set of Policy Actions in this ECA Policy Rule should be executed or 1713 not. This class is concrete, and defines the following attributes: 1715 4.3.4.1.3.1. The pktSecCondIPv6SrcAddr Attribute 1717 This is a mandatory string attribute, and defines the IPv6 Source 1718 Address (128 bits). 1720 4.3.4.1.3.2. The pktSecCondIPv6DestAddr Attribute 1722 This is a mandatory string attribute, and defines the IPv6 1723 Destination Address (128 bits). 1725 4.3.4.1.3.3. The pktSecCondIPv6DSCP Attribute 1727 This is a mandatory string attribute, and defines the Differentiated 1728 Services Code Point field (6 bits). It consists of the six most 1729 significant bits of the Traffic Class field in the IPv6 header. 1731 4.3.4.1.3.4. The pktSecCondIPv6ECN Attribute 1733 This is a mandatory string attribute, and defines the Explicit 1734 Congestion Notification field (2 bits). It consists of the two least 1735 significant bits of the Traffic Class field in the IPv6 header. 1737 4.3.4.1.3.5. The pktSecCondIPv6FlowLabel Attribute 1739 This is a mandatory string attribute, and defines an IPv6 flow label. 1740 This, in combination with the Source and Destination Address fields, 1741 enables efficient IPv6 flow classification by using only the IPv6 1742 main header fields (20 bits). 1744 4.3.4.1.3.6. The pktSecCondIPv6PayloadLength Attribute 1746 This is a mandatory string attribute, and defines the total length 1747 of the packet (including the fixed and any extension headers, and 1748 data) in bytes (16 bits). 1750 4.3.4.1.3.7. The pktSecCondIPv6NextHeader Attribute 1752 This is a mandatory string attribute, and defines the type of the 1753 next header (e.g., which extension header to use) (8 bits). 1755 4.3.4.1.3.8. The pktSecCondIPv6HopLimit Attribute 1757 This is a mandatory string attribute, and defines the maximum number 1758 of hops that this packet can traverse (8 bits). 1760 4.3.4.1.4. PacketSecurityTCPCondition 1762 The purpose of this Class is to represent packet TCP packet header 1763 information that can be used as part of a test to determine if the 1764 set of Policy Actions in this ECA Policy Rule should be executed or 1765 not. This class is concrete, and defines the following attributes: 1767 4.3.4.1.4.1. The pktSecCondTPCSrcPort Attribute 1769 This is a mandatory string attribute, and defines the Source Port 1770 (16 bits). 1772 4.3.4.1.4.2. The pktSecCondTPCDestPort Attribute 1774 This is a mandatory string attribute, and defines the Destination 1775 Port (16 bits). 1777 4.3.4.1.4.3. The pktSecCondTPCSeqNum Attribute 1779 This is a mandatory string attribute, and defines the sequence 1780 number (32 bits). 1782 4.3.4.1.4.4. The pktSecCondTPCFlags Attribute 1784 This is a mandatory string attribute, and defines the nine Control 1785 bit flags (9 bits). 1787 4.3.4.1.5. PacketSecurityUDPCondition 1789 The purpose of this Class is to represent packet UDP packet header 1790 information that can be used as part of a test to determine if the 1791 set of Policy Actions in this ECA Policy Rule should be executed or 1792 not. This class is concrete, and defines the following attributes: 1794 4.3.4.1.5.1. The pktSecCondUDPSrcPort Attribute 1796 This is a mandatory string attribute, and defines the UDP Source 1797 Port (16 bits). 1799 4.3.4.1.5.2. The pktSecCondUDPDestPort Attribute 1801 This is a mandatory string attribute, and defines the UDP 1802 Destination Port (16 bits). 1804 4.3.4.1.5.3. The pktSecCondUDPLength Attribute 1806 This is a mandatory string attribute, and defines the length in 1807 bytes of the UDP header and data (16 bits). 1809 4.3.4.2. PacketPayloadSecurityCondition 1811 The purpose of this Class is to represent packet payload data that 1812 can be used as part of a test to determine if the set of Policy 1813 Actions in this ECA Policy Rule should be executed or not. Examples 1814 include a specific set of bytes in the packet payload. 1816 4.3.4.3. TargetSecurityCondition 1818 The purpose of this Class is to represent information about 1819 different targets of this policy (i.e., entities to which this 1820 policy rule should be applied), which can be used as part of a test 1821 to determine if the set of Policy Actions in this ECA Policy Rule 1822 should be executed or not. Examples include whether the targeted 1823 entities are playing the same role, or whether each device is 1824 administered by the same set of users, groups, or roles. 1826 This Class has several important subclasses, including: 1828 a. ServiceSecurityContextCondition is the superclass for all 1829 information that can be used in an ECA Policy Rule that specifies 1830 data about the type of service to be analyzed (e.g., the protocol 1831 type and port number) 1833 b. ApplicationSecurityContextCondition is the superclass for all 1834 information that can be used in a ECA Policy Rule that specifies 1835 data that identifies a particular application (including metadata, 1836 such as risk level) 1838 c. DeviceSecurityContextCondition is the superclass for all 1839 information that can be used in a ECA Policy Rule that specifies 1840 data about a device type and/or device OS that is being used 1842 4.3.4.4. UserSecurityCondition 1844 The purpose of this Class is to represent data about the user or 1845 group referenced in this ECA Policy Rule that can be used as part of 1846 a test to determine if the set of Policy Actions in this ECA Policy 1847 Rule should be evaluated or not. Examples include the user or group 1848 id used, the type of connection used, whether a given user or group 1849 is playing a particular role, or whether a given user or group has 1850 failed to login a particular number of times. 1852 4.3.4.5. SecurityContextCondition 1854 The purpose of this Class is to represent security conditions that 1855 are part of a specific context, which can be used as part of a test 1856 to determine if the set of Policy Actions in this ECA Policy Rule 1857 should be evaluated or not. Examples include testing to determine if 1858 a particular pattern of security-related data have occurred, or if 1859 the current session state matches the expected session state. 1861 4.3.4.6. GenericContextSecurityCondition 1863 The purpose of this Class is to represent generic contextual 1864 information in which this ECA Policy Rule is being executed, which 1865 can be used as part of a test to determine if the set of Policy 1866 Actions in this ECA Policy Rule should be evaluated or not. Examples 1867 include geographic location and temporal information. 1869 4.3.5. Network Security Action Sub-Model 1871 Figure 13 shows a more detailed design of the Action subclasses that 1872 are contained in the Network Security Information Sub-Model. 1874 +---------------------+ 1875 +---------------+ 1..n 1..n | | 1876 | |/ \ \| A Common Superclass | 1877 | ECAPolicyRule+ A ----------+ for ECA Objects | 1878 | |\ / /| | 1879 +---------------+ +-----------+---------+ 1880 / \ 1881 | 1882 | 1883 +--------------+--------+------+ 1884 | | | 1885 | | | 1886 +-----+----+ +------+------+ +-----+-----+ 1887 | An Event | | A Condition | | An Action | 1888 | Class | | Class | | Class | 1889 +----------+ +-------------+ +-----+-----+ 1890 / \ 1891 | 1892 | 1893 +------------+-------------+------------------+-------- ... 1894 | | | | 1895 | | | | 1896 +----+----+ +----+---+ +------+-------+ +-------+--------+ 1897 | Ingress | | Egress | | ApplyProfile | | ApplySignature | 1898 | Action | | Action | | Action | | Action | 1899 +---------+ +--------+ +--------------+ +----------------+ 1901 Figure 13. Network Security Info Sub-Model Action Extensions 1903 The four Action classes shown in Figure 13 extend the (external) 1904 generic Action class to represent Actions that perform a Network 1905 Security Control function. Brief class descriptions are provided in 1906 the following sub-sections. 1908 4.3.5.1. IngressAction 1910 The purpose of this Class is to represent actions performed on 1911 packets that enter an NSF. Examples include pass, drop, mirror 1912 traffic. 1914 4.3.5.2. EgressAction 1916 The purpose of this Class is to represent actions performed on 1917 packets that exit an NSF. Examples include pass, drop, mirror 1918 traffic, signal, encapsulate. 1920 4.3.5.3. ApplyProfileAction 1922 The purpose of this Class is to represent applying a profile to 1923 packets to perform content security and/or attack mitigation control. 1925 4.3.5.4. ApplySignatureAction 1927 The purpose of this Class is to represent applying a signature file 1928 to packets to perform content security and/or attack mitigation 1929 control. 1931 4.4. Information Model for Content Security Control 1933 The block for content security control is composed of a number of 1934 security capabilities, while each one aims for protecting against a 1935 specific type of threat in the application layer. 1937 Following figure shows a basic structure of the information model: 1939 +----------------------------------+ 1940 | | 1941 | | 1942 | Anti-Virus | 1943 | Intrusion Prevention | 1944 | URL Filtering | 1945 | File Blocking | 1946 | Data Filtering | 1947 | Application Behavior Control | 1948 | Mail Filtering | 1949 | Packet Capturing | 1950 | File Isolation | 1951 | ... | 1952 | | 1953 | | 1954 | | 1955 | | 1956 | Information model | 1957 | for content security| 1958 | control | 1959 +----------------------------------+ 1960 Figure 14. The basic structure of information model for content 1961 security control 1963 The detailed description about the standard interface and the 1964 parameters for all the security capabilities of this category are 1965 TBD. 1967 4.5. Information Model for Attack Mitigation Control 1969 The block for attack mitigation control is composed of a number of 1970 security capabilities, while each one aims for mitigating a specific 1971 type of network attack. 1973 Following figure shows a basic structure of the information model: 1975 Please view in a fixed-width font such as Courier. 1977 +-------------------------------------------------+ 1978 | | 1979 | +---------------------+ +---------------+ | 1980 | |Attack mitigation | | General Shared| | 1981 | |capabilites: | | Parameters: | | 1982 | | SYN flood, | | | | 1983 | | UDP flood, | | | | 1984 | | ICMP flood, | | | | 1985 | | IP fragment flood, | | | | 1986 | | IPv6 related attacks| | | | 1987 | | HTTP flood, | | | | 1988 | | HTTPS flood, | | | | 1989 | | DNS flood, | | | | 1990 | | DNS amplification, | | | | 1991 | | SSL DDoS, | | | | 1992 | | IP sweep, | | | | 1993 | | Port scanning, | | | | 1994 | | Ping of Death, | | | | 1995 | | Oversized ICMP | | | | 1996 | | | | | | 1997 | | ... | | | | 1998 | | | | | | 1999 | +---------------------+ +---------------+ | 2000 | | 2001 | Information model | 2002 | for attack mitigation| 2003 | control | 2004 +-------------------------------------------------+ 2005 Figure 15. The basic structure of information model for attack 2006 mitigation control 2008 The detailed description about the standard interface and the 2009 general shared parameters for all the security capabilities of this 2010 category are TBD. 2012 5. Security Considerations 2014 TBD 2016 6. IANA Considerations 2017 7. References 2019 7.1. Normative References 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2022 Requirement Levels", BCP 14, RFC 2119, March 1997. 2024 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 2025 Syntax Specifications: ABNF", RFC 2234, Internet Mail 2026 Consortium and Demon Internet Ltd., November 1997. 2028 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2029 Network Configuration Protocol (NETCONF)", RFC 6020, 2030 October 2010. 2032 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2033 Used to Form Encoding Rules in Various Routing Protocol 2034 Specifications", RFC 5511, April 2009. 2036 7.2. Informative References 2038 [INCITS359 RBAC] NIST/INCITS, "American National Standard for 2039 Information Technology - Role Based Access Control", 2040 INCITS 359, April, 2003 2042 [I-D.draft-ietf-i2nsf-problem-and-use-cases] Hares, S., et.al., 2043 "I2NSF Problem Statement and Use cases", Work in Progress, 2044 February, 2016. 2046 [I-D.draft-ietf-i2nsf-framework] Lopez, E., et.al., "Framework for 2047 Interface to Network Security Functions", Work in Progress, 2048 May, 2016. 2050 [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to 2051 Network Security Functions (I2NSF) Terminology", Work in 2052 Progress, April, 2016 2054 [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., 2055 Halpern, J., Coleman, J., "Generic Policy Information 2056 Model for Simplified Use of Policy Abstractions (SUPA)", 2057 Work in Progress, June, 2016. 2059 8. Acknowledgments 2061 This document was prepared using 2-Word-v2.0.template.dot. 2063 Appendix A. 2065 This Appendix specifies the information model of security policy in 2066 Routing Backus-Naur Form [RFC5511]. This grammar is intended to 2067 help the reader better understand the english text description in 2068 order to derive a data model. 2070 Firstly, several types of route are specified as follows: 2072 o IPv4: Match on destination IP address in the IPv4 header 2074 o IPv6: Match on destination IP address in the IPv6 header 2076 o MPLS: Match on a MPLS label at the top of the MPLS label stack 2078 o MAC: Match on MAC destination addresses in the ethernet header 2080 o Interface: Match on incoming/outcoming interface of the packet 2082 Then, the I2NSF information model grammar of security policy is 2083 specified as follows: 2085 ::= ( ...) 2087 ::= 2089 ::= [] [] 2091 ::= [ ...] 2093 [ ...] 2095 ::= [] [] 2097 [] [] 2099 ::= ( | | 2101 | | ) 2103 ::= | | | | 2105 ::= ( | 2106 | ( 2108 )) 2110 ::= 2112 ::= 2114 ::= 2116 ::= ( | 2118 | ( 2120 )) 2122 ::= 2124 ::= 2126 ::= 2128 ::= | | 2130 ::= | 2132 ::= 2134 [] [] 2136 ::= 2138 [] 2140 [] [] 2142 ::= [ ...] [] [] 2144 [] [] 2146 ::= ( 2147 2149 ) | | 2151 ::= 2153 2155 ::= | 2157 ::= [] [] [] 2159 ::= [] [] 2161 [] 2163 ::= | | | | 2165 ::= 2167 2169 2171 ::= | | 2173 | 2175 ::= | | | | 2177 | | | ... 2179 ::= | | 2181 | | 2183 2185 ::= | | | 2187 | | 2189 | 2191 ::= 2193 2195 ::= | | 2197 ::= | 2199 ::= | | 2201 ::= | | | | 2203 2205 ::= [] 2207 ::= | | | | 2209 2211 ::= [] [] 2213 [] 2215 [] 2217 [] 2219 [] 2221 Authors' Addresses 2223 Liang Xia (Frank) 2224 Huawei 2226 101 Software Avenue, Yuhuatai District 2227 Nanjing, Jiangsu 210012 2228 China 2230 Email: Frank.xialiang@huawei.com 2232 John Strassner 2233 Huawei 2234 Email: John.sc.Strassner@huawei.com 2236 Kepeng Li 2237 Alibaba 2239 Email: kepeng.lkp@alibaba-inc.com 2241 DaCheng Zhang 2242 Alibaba 2244 Email: Dacheng.zdc@alibaba-inc.com 2246 Edward Lopez 2247 Fortinet 2248 899 Kifer Road 2249 Sunnyvale, CA 94086 2250 Phone: +1 703 220 0988 2252 EMail: elopez@fortinet.com 2253 Nicolas BOUTHORS 2254 Qosmos 2256 Email: Nicolas.BOUTHORS@qosmos.com 2258 Luyuan Fang 2259 Microsoft 2260 15590 NE 31st St 2261 Redmond, WA 98052 2262 Email: lufang@microsoft.com