idnits 2.17.1 draft-ietf-i2nsf-capability-03.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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) ** There are 4 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '... Every NSF SHOULD be described with ...' RFC 2119 keyword, line 147: '... NSFs. Capabilities MUST be defined in...' RFC 2119 keyword, line 181: '... are advertised MAY be restricted acc...' RFC 2119 keyword, line 198: '...urity capability SHOULD be an independ...' RFC 2119 keyword, line 202: '...o one capability SHOULD NOT affect oth...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2006 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC8192' on line 982 looks like a reference -- Missing reference section? 'RFC2119' on line 961 looks like a reference -- Missing reference section? 'RFC8174' on line 992 looks like a reference -- Missing reference section? 'Alshaer' on line 1010 looks like a reference -- Missing reference section? 'Hirschman' on line 1030 looks like a reference -- Missing reference section? 'Galitsky' on line 1021 looks like a reference -- Missing reference section? 'Martin' on line 1041 looks like a reference -- Missing reference section? 'OODSRP' on line 1052 looks like a reference -- Missing reference section? 'OODOP' on line 226 looks like a reference -- Missing reference section? 'OODMP' on line 1048 looks like a reference -- Missing reference section? 'Hohpe' on line 1035 looks like a reference -- Missing reference section? 'RFC8329' on line 988 looks like a reference -- Missing reference section? 'I-D.draft-ietf-supa-generic-policy-info-model' on line 1005 looks like a reference -- Missing reference section? 'Gamma' on line 1025 looks like a reference -- Missing reference section? 'Bas12' on line 1013 looks like a reference -- Missing reference section? 'PDO' on line 1055 looks like a reference -- Missing reference section? 'MCM' on line 1045 looks like a reference -- Missing reference section? 'Bas15' on line 1016 looks like a reference -- Missing reference section? 'Lunt' on line 1038 looks like a reference -- Missing reference section? 'Cormen' on line 1019 looks like a reference -- Missing reference section? 'RFC2234' on line 964 looks like a reference -- Missing reference section? 'RFC6020' on line 968 looks like a reference -- Missing reference section? 'RFC5511' on line 972 looks like a reference -- Missing reference section? 'RFC3198' on line 976 looks like a reference -- Missing reference section? 'INCITS359 RBAC' on line 997 looks like a reference -- Missing reference section? 'I-D.draft-ietf-i2nsf-terminology' on line 1001 looks like a reference -- Missing reference section? 'OODSOP' on line 1050 looks like a reference -- Missing reference section? 'Taylor' on line 1058 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF L. Xia 2 Internet Draft J. Strassner 3 Intended status: Standard Track Huawei 4 Expires: April 22, 2019 C. Basile 5 PoliTO 6 D. Lopez 7 TID 8 October 22, 2018 10 Information Model of NSFs Capabilities 11 draft-ietf-i2nsf-capability-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 22, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This draft defines the concept of an NSF (Network Security Function) 54 capability, as well as its information model. Capabilities are a set 55 of features that are available from a managed entity, and are 56 represented as data that unambiguously characterizes an NSF. 57 Capabilities enable management entities to determine the set of 58 features from available NSFs that will be used, and simplify the 59 management of NSFs. 61 Table of Contents 63 1. Introduction ................................................ 3 64 2. Conventions used in this document ........................... 3 65 2.1. Acronyms ............................................... 4 66 3. Capability Information Model Design ......................... 4 67 3.1. Design Principles and ECA Policy Model Overview ........ 5 68 3.2. Relation with the External Information Model ........... 8 69 3.3. I2NSF Capability Information Model Theory of Operation . 9 70 3.3.1. I2NSF Capability Information Model ............... 11 71 3.3.2. The SecurityCapability class ..................... 14 72 3.4. Modelling NSF Features as Security Capabilities ....... 15 73 3.4.1. Matched Policy Rule .............................. 15 74 3.4.2. Conflict, Resolution Strategy and Default Action . 16 75 3.4.3. I2NSF Condition Clause Operator Types ............ 17 76 3.4.4. Uses of the capability information model ......... 19 77 3.4.5. A Syntax to Describe the Capability of an NSF .... 19 78 3.4.6. Capability Algebra ............................... 20 79 4. Considerations on the Practical Use of the CapIM ........... 21 80 5. Security Considerations .................................... 22 81 6. Contributors ............................................... 22 82 7. Acknowledgements ........................................... 23 83 8. References ................................................. 23 84 8.1. Normative References .................................. 23 85 8.2. Informative References ................................ 24 87 1. Introduction 89 The rapid development of virtualized systems requires advanced 90 security protection in various scenarios. Examples include network 91 devices in an enterprise network, User Equipment in a mobile 92 network, devices in the Internet of Things, or residential access 93 users [RFC8192]. 95 NSFs produced by multiple security vendors provide various security 96 capabilities to customers. Multiple NSFs can be combined together to 97 provide security services over the given network traffic, regardless 98 of whether the NSFs are implemented as physical or virtual 99 functions. 101 Security Capabilities describe the functions that Network Security 102 Functions (NSFs) are available to provide for security policy 103 enforcement purposes. Security Capabilities are independent of the 104 actual security control mechanisms that will implement them. 106 Every NSF SHOULD be described with the set of capabilities it 107 offers. Security Capabilities enable security functionality to be 108 described in a vendor-neutral manner. That is, it is not needed to 109 refer to a specific product or technology when designing the 110 network; rather, the functions characterized by their capabilities 111 are considered. Security Capabilities are a market enabler, 112 providing a way to define customized security protection by 113 unambiguously describing the security features offered by a given 114 NSF. 116 This document is organized as follows. Section 2 defines conventions 117 and acronyms used. Section 3 discusses the design principles for 118 I2NSF capability information model, the related ECA model, and 119 provides detailed information model design of I2NSF network security 120 capability. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 This document uses terminology defined in [I-D.draft-ietf-i2nsf- 131 terminology] for security related and I2NSF scoped terminology. 133 2.1. Acronyms 135 I2NSF - Interface to Network Security Functions 137 NSF - Network Security Function 139 DNF - Disjunctive Normal Form 141 3. Capability Information Model Design 143 A Capability Information Model (CapIM) is a formalization of the 144 functionality that an NSF advertises. This enables the precise 145 specification of what an NSF can do in terms of security policy 146 enforcement, so that computer-based tasks can unambiguously refer 147 to, use, configure, and manage NSFs. Capabilities MUST be defined in 148 a vendor- and technology-independent manner (e.g., regardless of the 149 differences among vendors and individual products). 151 Humans are able to refer to categories of security controls and 152 understand each other. For instance, security experts agree on what 153 is meant by the terms "NAT", "filtering", and "VPN concentrator". 154 As a further example, network security experts unequivocally refer 155 to "packet filters" as stateless devices able to allow or deny 156 packet forwarding based on various conditions (e.g., source and 157 destination IP addresses, source and destination ports, and IP 158 protocol type fields) [Alshaer]. 160 However, more information is required in case of other devices, like 161 stateful firewalls or application layer filters. These devices 162 filter packets or communications, but there are differences in the 163 packets and communications that they can categorize and the states 164 they maintain. Humans deal with these differences by asking more 165 questions to determine the specific category and functionality of 166 the device. Machines can follow a similar approach, which is 167 commonly referred to as question-answering [Hirschman] [Galitsky]. 168 In this context, the CapIM and the derived Data Models provide 169 important and rich information sources. 171 Analogous considerations can be applied for channel protection 172 protocols, where we all understand that they will protect packets by 173 means of symmetric algorithms whose keys could have been negotiated 174 with asymmetric cryptography, but they may work at different layers 175 and support different algorithms and protocols. To ensure 176 protection, these protocols apply integrity, optionally 177 confidentiality, anti-reply protections, and authenticate peers. 179 The CapIM is intended to clarify these ambiguities by providing a 180 formal description of NSF functionality. The set of functions that 181 are advertised MAY be restricted according to the privileges of the 182 user or application that is viewing those functions. I2NSF 183 Capabilities enable unambiguous specification of the security 184 capabilities available in a (virtualized) networking environment, 185 and their automatic processing by means of computer-based 186 techniques. 188 This includes enabling the security controller to properly identify 189 and manage NSFs, and allow NSFs to properly declare their 190 functionality, so that they can be used in the correct way. 192 3.1. Design Principles and ECA Policy Model Overview 194 This document defines an information model for representing NSF 195 capabilities. Some basic design principles for security capabilities 196 and the systems that manage them are: 198 o Independence: each security capability SHOULD be an independent 199 function, with minimum overlap or dependency on other 200 capabilities. This enables each security capability to be 201 utilized and assembled together freely. More importantly, changes 202 to one capability SHOULD NOT affect other capabilities. This 203 follows the Single Responsibility Principle [Martin] [OODSRP]. 205 o Abstraction: each capability MUST be defined in a vendor- 206 independent manner. 208 o Advertisement: A dedicated, well-known interface MUST be used to 209 advertise and register the capabilities of each NSF. This same 210 interface MUST be used by other I2NSF Components to determine 211 what Capabilities are currently available to them. 213 o Execution: a dedicated, well-known interface MUST be used to 214 configure and monitor the use of a capability. This provides a 215 standardized ability to describe its functionality, and report 216 its processing results. This facilitates multi-vendor 217 interoperability. 219 o Automation: the system MUST have the ability to auto-discover, 220 auto-negotiate, and auto-update its security capabilities (i.e., 221 without human intervention). These features are especially useful 222 for the management of a large number of NSFs. They are essential 223 for adding smart services (e.g., refinement, analysis, capability 224 reasoning, and optimization) to the security scheme employed. 225 These features are supported by many design patterns, including 226 the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a 227 set of Message Exchange Patterns [Hohpe]. 229 o Scalability: the management system SHOULD have the capability to 230 scale up/down or scale in/out. Thus, it can meet various 231 performance requirements derived from changeable network traffic 232 or service requests. In addition, security capabilities that are 233 affected by scalability changes SHOULD support reporting 234 statistics to the security controller to assist its decision on 235 whether it needs to invoke scaling or not. 237 Based on the above principles, this document defines a capability 238 model that enables an NSF to register (and hence advertise) its set 239 of capabilities that other I2NSF Components can use. These 240 capabilities MAY have their access control restricted by policy; 241 this is out of scope for this document. The set of capabilities 242 provided by a given set of NSFs unambiguously define the security 243 offered by the set of NSFs used. The security controller can compare 244 the requirements of users and applications to the set of 245 capabilities that are currently available in order to choose which 246 capabilities of which NSFs are needed to meet those requirements. 247 Note that this choice is independent of vendor, and instead relies 248 specifically on the capabilities (i.e., the description) of the 249 functions provided. 251 Furthermore, when an unknown threat (e.g., zero-day exploits and 252 unknown malware) is reported by an NSF, new capabilities may be 253 created, and/or existing capabilities may be updated (e.g., by 254 updating its signature and algorithm). This results in enhancing the 255 existing NSFs (and/or creating new NSFs) to address the new threats. 256 New capabilities may be sent to and stored in a centralized 257 repository, or stored separately in a vendor's local repository. In 258 either case, a standard interface facilitates the update process. 259 This document specifies a metadata model that MAY be used to further 260 describe and/or prescribe the characteristics and behavior of the 261 I2NSF capability model. For example, in this case, metadata could be 262 used to describe the updating of the capability, and prescribe the 263 particular version that an implementation should use. This initial 264 version of the model covers and has been validated to describe NSFs 265 that are designed with a set of capabilities (which covers most of 266 the existing NSFs). Checking the behavior of the model with systems 267 that change capabilities dynamically at runtime has been extensively 268 explored (e.g., impact on automatic registration). 270 The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used 271 as the basis for the design of the capability model; definitions of 272 all I2NSF policy-related terms are also defined in [I-D.draft-ietf- 273 i2nsf-terminology]. The following three terms define the structure 274 and behavior of an I2NSF imperative policy rule: 276 o Event: An Event is defined as any important occurrence in time of 277 a change in the system being managed, and/or in the environment 278 of the system being managed. When used in the context of I2NSF 279 Policy Rules, it is used to determine whether the Condition 280 clause of the I2NSF Policy Rule can be evaluated or not. Examples 281 of an I2NSF Event include time and user actions (e.g., logon, 282 logoff, and actions that violate an ACL). 284 o Condition: A condition is defined as a set of attributes, 285 features, and/or values that are to be compared with a set of 286 known attributes, features, and/or values in order to determine 287 whether or not the set of Actions in that (imperative) I2NSF 288 Policy Rule can be executed or not. Examples of I2NSF Conditions 289 include matching attributes of a packet or flow, and comparing 290 the internal state of an NSF to a desired state. 292 o Action: An action is used to control and monitor aspects of flow- 293 based NSFs when the event and condition clauses are satisfied. 294 NSFs provide security functions by executing various Actions. 295 Examples of I2NSF Actions include providing intrusion detection 296 and/or protection, web and flow filtering, and deep packet 297 inspection for packets and flows. 299 An I2NSF Policy Rule is made up of three Boolean clauses: an Event 300 clause, a Condition clause, and an Action clause. This structure is 301 also called an ECA (Event-Condition-Action) Policy Rule. A Boolean 302 clause is a logical statement that evaluates to either TRUE or 303 FALSE. It may be made up of one or more terms; if more than one term 304 is present, then each term in the Boolean clause is combined using 305 logical connectives (i.e., AND, OR, and NOT). 307 An I2NSF ECA Policy Rule has the following semantics: 309 IF is TRUE 311 IF is TRUE 312 THEN execute [constrained by metadata] 314 END-IF 316 END-IF 318 Technically, the "Policy Rule" is really a container that aggregates 319 the above three clauses, as well as metadata. Aggregating metadata 320 enables business logic to be used to prescribe behavior. For 321 example, suppose a particular ECA Policy Rule contains three actions 322 (A1, A2, and A3, in that order). Action A2 has a priority of 10; 323 actions A1 and A3 have no priority specified. Then, metadata may be 324 used to restrict the set of actions that can be executed when the 325 event and condition clauses of this ECA Policy Rule are evaluated to 326 be TRUE; two examples are: (1) only the first action (A1) is 327 executed, and then the policy rule returns to its caller, or (2) all 328 actions are executed, starting with the highest priority. 330 The above ECA policy model is very general and easily extensible. 332 3.2. Relation with the External Information Model 334 Note: the symbology used from this point forward is taken from 335 section 3.3 of [I-D.draft-ietf-supa-generic-policy-info-model]. 337 The I2NSF NSF-Facing Interface is used to select and manage the NSFs 338 using their capabilities. This is done using the following approach: 340 1) Each NSF registers its capabilities with the management system 341 through a dedicated interface, and hence, makes its capabilities 342 available to the management system; 344 2) The security controller compares the needs of the security service 345 with the set of capabilities from all available NSFs that it 346 manages using the CapIM; 348 3) The security controller uses the CapIM to select the final set of 349 NSFs to be used; 351 4) The security controller takes the above information and creates or 352 uses one or more data models from the CapIM to manage the NSFs; 354 5) Control and monitoring can then begin. 356 This assumes that an external information model is used to define 357 the concept of an ECA Policy Rule and its components (e.g., Event, 358 Condition, and Action objects). This enables I2NSF Policy Rules [I- 359 D.draft-ietf-i2nsf-terminology] to be sub-classed from an external 360 information model. 362 The external ECA Information Model supplies at least a set of 363 objects that represent a generic ECA Policy Rule, and a set of 364 objects that represent Events, Conditions, and Actions that can be 365 aggregated by the generic ECA Policy Rule. This enables appropriate 366 I2NSF Components to reuse this generic model for different purposes, 367 as well as specialize it (i.e., create new model objects) to 368 represent concepts that are specific to I2NSF and/or an application 369 that is using I2NSF. 371 It is assumed that the external ECA Information Model also has the 372 ability to aggregate metadata. This enables metadata to be used to 373 prescribe and/or describe characteristics and behavior of the ECA 374 Policy Rule. Specifically, Capabilities are sub-classed from this 375 external metadata model. If the desired Capabilities are already 376 defined in the CapIM, then no further action is necessary. 377 Otherwise, new Capabilities SHOULD be defined either by defining new 378 classes that can wrap existing classes using the decorator pattern 379 [Gamma] or by another mechanism (e.g., through sub-classing); the 380 parent class of the new Capability SHOULD be either an existing 381 CapIM metadata class or a class defined in the external metadata 382 information model. In either case, the ECA objects can use the 383 existing aggregation between them and the Metadata class to add 384 metadata to appropriate ECA objects. 386 Detailed descriptions of each portion of the information model are 387 given in the following sections. 389 3.3. I2NSF Capability Information Model Theory of Operation 391 Capabilities are typically used to represent NSF functions that can 392 be invoked. Capabilities are objects, and hence, can be used in the 393 event, condition, and/or action clauses of an I2NSF ECA Policy Rule. 395 The I2NSF CapIM refines a predefined (and external) metadata model; 396 the application of I2NSF Capabilities is done by refining a 397 predefined (and external) ECA Policy Rule information model that 398 defines how to use, manage, or otherwise manipulate a set of 399 capabilities. In this approach, an I2NSF Policy Rule is a container 400 that is made up of three clauses: an event clause, a condition 401 clause, and an action clause. When the I2NSF policy engine receives 402 a set of events, it matches those events to events in active ECA 403 Policy Rules. If the event matches, then this triggers the 404 evaluation of the condition clause of the matched I2NSF Policy Rule. 405 The condition clause is then evaluated; if it matches, then the set 406 of actions in the matched I2NSF Policy Rule MAY be executed. The 407 operation of each of these clauses MAY be affected by metadata that 408 is aggregated by either the ECA Policy Rule and/or by each clause, 409 as well as the selected resolution strategy. 411 Condition clauses are logical formulas that combine one or more 412 conditions that evaluate to a Boolean (i.e., true or false) result. 413 The values in a condition clause are built on values received or 414 owned by the NSF. For instance, the condition clause 'ip source == 415 1.2.3.4' is true when the IP address is equal to 1.2.3.4. Two or 416 more conditions require a formal mechanism to represent how to 417 operate on each condition to produce a result. For the purposes of 418 this document, every condition clause MUST be expressed in either 419 conjunctive or disjunctive normal form. Informally, conjunctive 420 normal form expresses a clause as a set of sub-clauses that are 421 logically ANDed together, where each sub-clause contains only terms 422 that use OR and/or NOT operators). Similarly, disjunctive normal 423 form is a set of sub-clauses that are logically ORed together, where 424 each sub-clause contains only terms that use AND and/or NOT 425 operators. 427 This document defines additional important extensions to both the 428 external ECA Policy Rule model and the external Metadata model that 429 are used by the I2NSF CapIM; examples include resolution strategy, 430 external data, and default actions. All these extensions come from 431 the geometric model defined in [Bas12]. A summary of the important 432 points of this geometric model follows. 434 Formally, given a set of actions in an I2NSF Policy Rule, the 435 resolution strategy maps all the possible subsets of actions to an 436 outcome. In other words, the resolution strategy is included in an 437 I2NSF Policy Rule to decide how to evaluate all the actions from the 438 matching I2NSF Policy Rule. 440 Some concrete examples of resolution strategy are: 442 o First Matching Rule (FMR) 444 o Last Matching Rule (LMR) 446 o Prioritized Matching Rule (PMR) with Errors (PMRE) 448 o Prioritized Matching Rule with No Errors (PMRN) 449 In the above, a PMR strategy is defined as follows: 451 1. Order all actions by their Priority (highest is first, no 452 priority is last); actions that have the same priority may be 453 appear in any order in their relative location. 455 2. For PMRE: if any action fails to execute properly, temporarily 456 stop execution of all actions. Invoke the error handler of the 457 failed action. If the error handler is able to recover from the 458 error, then continue execution of any remaining actions; else, 459 terminate execution of the ECA Policy Rule. 461 3. For PMRN: if any action fails to execute properly, stop 462 execution of all actions. Invoke the error handler of the failed 463 action, but regardless of the result, execution of the ECA 464 Policy Rule MUST be terminated. 466 Regardless of the resolution strategy, when no rule matches a 467 packet, a default action MAY be executed. 469 Resolution strategies may use, besides intrinsic rule data (i.e., 470 event, condition, and action clauses), "external data" associated to 471 each rule, such as priority, identity of the creator, and creation 472 time. Two examples of this are attaching metadata to the policy rule 473 and/or its action, and associating the policy rule with another 474 class to convey such information. 476 3.3.1. I2NSF Capability Information Model 478 Figure 1 below shows one example of an external model. This is a 479 simplified version of the MEF Policy model [PDO]. For our purposes: 481 o MCMPolicyObject is an abstract class, and is derived from 482 MCMManagedEntity [MCM] 484 o MCMPolicyStructure is an abstract superclass for building 485 different types of Policy Rules (currently, for I2NSF, only 486 imperative (i.e., ECA) Policy Rules are considered) 488 o An I2NSFECAPolicyRule could be subclassed from MCMECAPolicyRule 490 o I2NSF Events, Conditions, and Actions could be subclasses from 491 MCMPolicyEvent, MCMPolicyCondition, and MCMPolicyAction 493 o MCMMetaData is aggregated by MCMEntity, which is the superclass 494 of MCMManagedEntity. So all Policy objects may aggregate 495 MCMMetaData 496 +------------------------+ 497 +---------------+ |HasPolicyStructure | 498 |MCMPolicyObject| |ComponentDecoratorDetail| 499 +-------A-------+ +---------------------*--+ 500 | * 501 | * 502 +---------------+----------------+ * 503 | | * 504 +-------+----------+ +----------+----------------+1..* * 505 |MCMPolicyStructure| |MCMPolicyStructureComponent|<------*+ 506 +--------A---------+ +-----------A---------------+ | 507 | | | 508 | +------------+--------+ | 509 | | | 0..1 ^ 510 +-------+--------+ +-------+-------+ +-----------+---------------V+ 511 |MCMECAPolicyRule| |MCMPolicyClause| |MCMPolicyClauseComponent | 512 +----------------+ +---------------+ |Decorator | 513 +---------------A------------+ 514 | 515 | 516 +--------+---------+ 517 |MCMPolicyComponent| 518 +--------A---------+ 519 | 520 | 521 +--------------------+---------------+----+ 522 +-------+------+ +---------+--------+ +--------+------+ 523 |MCMPolicyEvent| |MCMPolicyCondition| |MCMPolicyAction| 524 +--------------+ +------------------+ +---------------+ 526 Figure 1 Exemplary External Information Model (from the MEF) 528 The CapIM model uses the Decorator Pattern [Gamma]. The decorator 529 pattern enables a base object to be "wrapped" by zero or more 530 decorator objects. The Decorator MAY attach additional 531 characteristics and behavior, in the form of attributes at runtime 532 in a transparent manner without requiring recompilation and/or 533 redeployment. This is done by using composition instead of 534 inheritance. Objects can "wrap" (more formally, extend the interface 535 of) an object. In essence, a new object can be built out of pre- 536 existing objects. 538 The Decorator Pattern is applied to allow NSF instances to aggregate 539 I2NSFSecurityCapability instances. By means of this aggregation, an 540 NSF can be associated to the functions it provides in terms of 541 security policy enforcement, both at specification time (i.e., when 542 a vendor provides a new NSF), statically, when a NSF is added to a 543 (virtualized) networking environment, and dynamically, during 544 network operations. Figure 2 shows an NSF aggregating zero or more 545 SecurityCapabilities. This may be thought of as an NSF possessing 546 (or defining) zero or more Security Capabilities. This "possession" 547 (or "definition") is represented in UML as an aggregated, called 548 HasSecurityCapability. The hasSecurityCapabilityDetail is an 549 association class that allows NSF instances to aggregate 550 I2NSFSecurityCapability instances. An NSF MAY be described by 0 or 551 more SecurityCapabilities. 553 Since there can be many types of NSF that have many different types 554 of I2NSFSecurityCapabilities, the definition of a SecurityCapability 555 must be done using the context of an NSF. This is realized by an 556 association class in UML. HasSecurityCapabilityDetail is an 557 association class. This yields the following design: 559 +-----+0..n 0..n+--------------------+ 560 | |/ \ HasSecurityCapability | | 561 | NSF | A ----------+----------------+ SecurityCapability | 562 | |\ / ^ | | 563 +-----+ | +--------------------+ 564 | 565 +-------------+---------------+ 566 | HasSecurityCapabilityDetail | 567 + ----------------------------+ 569 Figure 2 Defining SecurityCapabilities of an NSF 571 This enables the HasSecurityCapabilityDetail association class to be 572 the target of a Policy Rule. That is, the 573 HasSecurityCapabilityDetail class has attributes and methods that 574 define which I2NSFSecurityCapabilities of this NSF are visible and 575 can be used [MCM]. 577 3.3.2. The SecurityCapability class 579 The SecurityCapability class defines the concept of metadata that 580 define security-related capabilities. It is subclassed from an 581 appropriate class of an external metadata information model. 582 Subclasses of the SecurityCapability class can be used to answer the 583 following questions: 585 o What are the events that are caught by the NSF to trigger the 586 condition clause evaluation (Event subclass)? 588 o What kind of condition clauses can be specified on the NSF to 589 define valid rules? This question splits into two questions: 590 (1) what are the conditions that can be specified (Condition 591 subclass), and (2) how to build a valid condition clause from a 592 set of individual conditions (ClauseEvaluation class). 594 o What are the actions that the NSF can enforce (Action class)? 596 o How to define a correct policy on the NSF? 598 3.4. Modelling NSF Features as Security Capabilities 600 The capability model proposed in this document is intended to 601 provide a formal framework to describe and process the features of 602 NSFs, and to evaluate their fitness to a particular purpose, 603 expressed in terms of a (possibly complex) policy statement. Using 604 the capability model, NSF providers and users can declare and 605 manipulate the features of a function or a combination of them. 607 Specifically, if the NSF has the classification features needed to 608 identify the packets/flows required by a policy, and can enforce the 609 needed actions, then that particular NSF is capable of enforcing the 610 policy. Therefore, capability selection and usage are based on the 611 set of security traffic classification and action features that an 612 NSF provides. 614 NSFs may also have specific characteristics that automatic processes 615 or administrators need to know when they have to generate 616 configurations, like the available resolution strategies and the 617 possibility to set default actions, which are described in Sections 618 3.4.3. 620 3.4.1. Matched Policy Rule 622 The concept of a "matched" policy rule is defined as one in which 623 its event and condition clauses both evaluate to true. To precisely 624 describe what an NSF can do in terms of security, the things need to 625 describe are the events it can catch, the conditions it can 626 evaluate, and the actions it can enforce. 628 Therefore, the properties that to characterize the capabilities of a 629 NSF are as below: 631 o Ac is the set of Actions currently available from the NSF; 633 o Ec is the set of Events that an NSF can catch. Note that for NSF 634 (e.g., a packet filter) that are not able to react to events, 635 this set will be empty; 637 o Cc is the set of Conditions currently available from the NSF; 639 o EVc defines the set of Condition Clause Evaluation Rules that can 640 be used at the NSF to decide when the Condition Clause is true 641 given the result of the evaluation of the individual Conditions. 643 3.4.2. Conflict, Resolution Strategy and Default Action 645 Formally, two I2NSF Policy Rules conflict with each other if: 647 o the Event Clauses of each evaluate to TRUE; 649 o the Condition Clauses of each evaluate to TRUE; 651 o the Action Clauses affect the same object in different ways. 653 For example, if we have two Policy Rules in the same Policy: 655 R1: During 8am-6pm, if traffic is external, then run through FW 656 R2: During 7am-8pm, conduct anti-malware investigation 658 There is no conflict between R1 and R2, since the actions are 659 different. However, consider these two rules: 661 R3: During 8am-6pm, John gets GoldService 662 R4: During 10am-4pm, FTP from all users gets BronzeService 664 R3 and R4 are now in conflict, between the hours of 10am and 4pm, 665 because the actions of R3 and R4 are different and apply to the same 666 user (i.e., John). 668 Conflicts theoretically compromise the correct functioning of 669 devices (as happened for routers several year ago). However, NSFs 670 have been designed to cope with these issues. Since conflicts are 671 originated by simultaneously matching rules, an additional process 672 decides the action to be applied, e.g., among the ones the matching 673 rule would have enforced. This process is described by means of a 674 resolution strategy 676 On the other hand, it may happen that, if an event is caught, none 677 of the policy rules matches. As a simple case, no rules may match a 678 packet arriving at border firewall. In this case, the packet is 679 usually dropped, that is, the firewall has a default behavior to 680 manage cases that are not covered by specific rules. 682 Therefore, we introduce another security capability that serves to 683 characterize valid policies for an NSF that solve conflicts with 684 resolution strategies and enforce default actions if no rules match: 686 o RSc is the set of Resolution Strategy that can be used to specify 687 how to resolve conflicts that occur between the actions of the 688 same or different policy rules that are matched and contained in 689 this particular NSF; 691 o Dc defines the notion of a Default action. This action can be 692 either an explicit action that has been chosen {a}, or a set of 693 actions {F}, where F is a dummy symbol (i.e., a placeholder 694 value) that can be used to indicate that the default action can 695 be freely selected by the policy editor. This is denoted as {F} U 696 {a}. 698 3.4.3. I2NSF Condition Clause Operator Types 700 After having analyzed the literature and some existing NSFs, the 701 types of Condition clause operators/selectors are categorized as 702 exact-match, range-based, regex-based, and custom-match 703 [Bas15][Lunt]. 705 Exact-match selectors are (unstructured) sets: elements can only be 706 checked for equality, as no order is defined on them. As an 707 example, the protocol type field of the IP header is an unordered 708 set of integer values associated to protocols. The assigned protocol 709 numbers are maintained by the IANA 710 (http://www.iana.org/assignments/protocol-numbers/protocol- 711 numbers.xhtml). 713 In this selector, it is only meaningful to specify condition clauses 714 that use either the "equals" or "not equals operators": 716 proto = tcp, udp (protocol type field equals to TCP or UDP) 718 proto != tcp (protocol type field different from TCP) 720 No other operators are allowed on exact-match selectors. For 721 example, the following is an invalid condition clause, even if 722 protocol types map to integers: 724 proto < 62 (invalid condition) 726 Range-based selectors are ordered sets where it is possible to 727 naturally specify ranges as they can be easily mapped to integers. 728 As an example, the ports in the TCP protocol may be represented 729 using a range-based selector (e.g., 1024-65535). For example, the 730 following are examples of valid condition clauses: 732 source_port = 80 734 source_port < 1024 736 source_port < 30000 && source_port >= 1024 738 We include, in range-based selectors, the category of selectors that 739 have been defined by Al-Shaer et al. as "prefix-match" [Alshaer]. 740 These selectors allow the specification of ranges of values by means 741 of simple regular expressions. The typical case is the IP address 742 selector (e.g., 10.10.1.*). There is no need to distinguish between 743 prefix match and range-based selectors as 10.10.1.* easily maps to 744 [10.10.1.0, 10.10.1.255]. 746 Another category of selector types includes the regex-based 747 selectors, where the matching is performed by using regular 748 expressions. This selector type is used frequently at the 749 application layer, where data are often represented as strings of 750 text. The regex-based selector type also includes string-based 751 selectors, where matching is evaluated using string matching 752 algorithms (SMA) [Cormen]. Indeed, for our purposes, string matching 753 can be mapped to regular expressions, even if in practice SMA are 754 much faster. For instance, Squid (http://www.squid-cache.org/), a 755 popular Web caching proxy that offers various access control 756 capabilities, allows the definition of conditions on URLs that can 757 be evaluated with SMA (e.g., dstdomain) or regex matching (e.g., 758 dstdom_regex). 760 As an example, the condition clause: 762 URL = *.website.* 764 matches all the URLs that contain a subdomain named website and the 765 ones whose path contain the string ".website.". As another example, 766 the condition clause: 768 MIME_type = video/* 770 matches all MIME objects whose type is video. 772 Finally, the idea of a custom check selector is introduced. For 773 instance, malware analysis can look for specific patterns, and 774 returns a Boolean value if the pattern is found or not. 776 In order to be properly used by high-level policy-based processing 777 systems (such as reasoning systems and policy translation systems), 778 these custom check selectors can be modeled as black-boxes (i.e., a 779 function that has a defined set of inputs and outputs for a 780 particular state), which provide an associated Boolean output. 782 3.4.4. Uses of the capability information model 784 The capability information model can be used for two purposes: 785 describing the features provided by generic security functions, and 786 describing the features provided by specific products. The term 787 Generic Network Security Function (GNSF) has been used to define 788 generalized categories of NSFs. The idea is to have generic 789 components whose behavior is well understood, so that the generic 790 component can be used even if it has some vendor-specific functions. 792 These generic functions represent a point of interoperability, and 793 can be provided by any product that offers the required 794 capabilities. GNSF examples include packet filter, URL filter, HTTP 795 filter, VPN gateway, anti-virus, anti-malware, content filter, 796 monitoring, and anonymity proxy; these will be described later in a 797 revision of this draft. 799 3.4.5. A Syntax to Describe the Capability of an NSF 801 To characterize the behavior of the Policy Rule as specified by the 802 CapIM, a NSF can be associated to its security capabilities by means 803 of a 6-tuple {Ac, Cc, Ec, RSc, Dc, EVc}, where Ac, Cc, Ec, RSc, Dc, 804 and EVc have been described in the previous sections. 806 As an example, assume that a packet filter capability, Cap_pf, is 807 defined, its, capabilities can be defined as 809 Cap_pf = (Apf, Cpf, Epf, RSpf, Dpf, EVpf) 811 where: 813 Apf = {Allow, Deny} 814 Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} 815 Epf = {} 816 RSpf = {FMR} 817 Dpf = {A1} 818 EVpf = {DNF} 820 3.4.6. Capability Algebra 822 Assigning capabilities to a large number of NSFs can be a complex 823 (and boring) operation, therefore, this document presents a formal 824 way (Capability Algebra) to define templates and manipulate them for 825 NSF. 827 Before introducing the capability algebra, we will introduce the 828 symbols that we will use to represent set operations: 830 o "U" is the union operation, A U B returns a new set that includes 831 all the elements in A and all the elements in B 833 o "\" is the set minus operation, A \ B returns all the elements 834 that are in A but not in B. 836 Given two sets of capabilities, denoted as cap1=(Ac1,Cc1, 837 Ec1,RSc1,Dc1,EVc1) and cap2=(Ac2,Cc2,Ec2,RSc2,Dc2,EVc2) 838 two set operations are defined for manipulating capabilities: 840 o capability addition: cap1+cap2 = {Ac1 U Ac2, Cc1 U Cc2, Ec1 U 841 Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2} 843 o capability subtraction: cap_1-cap_2 = {Ac1 \ Ac2, Cc1 \ Cc2, Ec1 844 \ Ec2, RSc1 U RSc2, Dc1 U DC2, EVc1 U EVc2} 846 In the above formulae, "U" is the set union operator and "\" is the 847 set difference operator. 849 The addition and subtraction of capabilities are defined as the 850 addition (set union) and subtraction (set difference) of both the 851 capabilities and their associated actions. Note that the Resolution 852 Strategies and Default Actions are added in both cases. 854 As an example, assume that a packet filter capability, Cap_pf, is 855 defined as in a previous section. Further, assume that a second 856 capability, called Cap_time, exists, and that it defines time-based 857 conditions. Suppose we need to construct a new generic packet 858 filter, Cap_pfgen, that adds time-based conditions to Cap_pf. 860 Conceptually, this is simply the addition of the Cap_pf and Cap_time 861 capabilities, as follows: 863 Apf = {Allow, Deny} 864 Cpf = {IPsrc,IPdst,Psrc,Pdst,protType} 865 Epf = {} 866 RSpf = {FMR} 867 Dpf = {A1} 868 EVpf = {DNF} 870 Atime = {Allow, Deny, Log} 871 Ctime = {timestart, timeend, datestart, datestop} 872 Etime = {} 873 RStime = {LMR} 874 Dtime = {A2} 875 EVtime = {} 877 Then, Cap_pfgen is defined as: 879 Cpfgen = {Apf U Atime, Cpf U Ctime, Epf U Etime, RSpf U RStime, 880 Dpf U Time, EVpf U EVtime} 881 = { {Allow, Deny, Log}, 882 {IPsrc,IPdst,Psrc,Pdst,protType} U {timestart, 883 timeend, datestart, datestop}, 884 {}, 885 {FMR, LMR}, 886 {A1, A2}, 887 {DNF} } 889 In other words, Cap_pfgen provides three actions (Allow, Deny, Log), 890 filters traffic based on a 5-tuple that is logically ANDed with a 891 time period, can use either FMR or LMR (but obviously not both), and 892 can provide either A1 or A2 (but again, not both) as a default 893 action. In any case, multiple conditions will be processed with DNF 894 when evaluating the condition clause. 896 4. Considerations on the Practical Use of the CapIM 898 CapIM is a solid basis for the data models that may serve in I2NSF. 899 Nevertheless, a partial re-organization of the data models already 900 produced by the WG is expected. 902 Currently (A survey on the existing data models in the I2NSF world 903 with a couple of lines about it and a list of things that can be 904 inherited). 906 The CapIM can benefit from the definition of lists of elements to 907 help to easily build the description of the capabilities which 908 mainly consists in listing the things it can do: 910 o the actions that NSFs can enforce; 912 o the conditions that can be specified by at least one NSF. 914 Knowing all actions and conditions would be desirable, but covering 915 all of them is actually unreasonable. For instance, one-of-the-YANG- 916 models lists a high number of protocols that can be a solid basis to 917 build this list. 919 On the other hand, resolution strategies, and condition clause 920 evaluation methods are limited and listing all of them seems 921 feasible. 923 Finally, Events are too bounded to the systems/domain/architectures, 924 therefore, compiling a list is simply impossible. 926 5. Security Considerations 928 This document defines an object-oriented information model for 929 describing policy information that is independent of any specific 930 repository, language, or protocol. This document does not define any 931 particular system implementation, including a protocol. Hence, it 932 does not have any specific security requirements. 934 6. Contributors 936 The following people contributed to creating this document, and are 937 listed below in alphabetical order: 939 Antonio Lioy (Politecnico di Torino) 941 Dacheng Zhang (Huawei) 943 Edward Lopez (Fortinet) 945 Fulvio Valenza (Politecnico di Torino) 947 Kepeng Li (Alibaba) 948 Luyuan Fang (Microsoft) 950 Nicolas Bouthors (QoSmos) 952 7. Acknowledgements 954 Thanks to Linda Dunbar, Susan Hares and Jaehoon Paul Jeong for the 955 discussion and comments. 957 8. References 959 8.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, March 1997. 964 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 965 Syntax Specifications: ABNF", RFC 2234, Internet Mail 966 Consortium and Demon Internet Ltd., November 1997. 968 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 969 Network Configuration Protocol (NETCONF)", RFC 6020, 970 October 2010. 972 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 973 Used to Form Encoding Rules in Various Routing Protocol 974 Specifications", RFC 5511, April 2009. 976 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 977 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 978 J., and S. Waldbusser, "Terminology for Policy-Based 979 Management", RFC 3198, DOI 10.17487/RFC3198, 980 November 2001, . 982 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, 983 R., and J. Jeong, "Interface to Network Security Functions 984 (I2NSF): Problem Statement and Use Cases", RFC 8192, 985 DOI 10.17487/RFC8192, July 2017, 986 . 988 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J. and R. 989 Kumar, "Framework for Interface to Network Security 990 Functions", RFC 8329, February 2018. 992 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 993 2119 Key Words", RFC8174, May 2017. 995 8.2. Informative References 997 [INCITS359 RBAC] NIST/INCITS, "American National Standard for 998 Information Technology - Role Based Access Control", 999 INCITS 359, April, 2003 1001 [I-D.draft-ietf-i2nsf-terminology] Hares, S., et.al., "Interface to 1002 Network Security Functions (I2NSF) Terminology", Work in 1003 Progress, January, 2018 1005 [I-D.draft-ietf-supa-generic-policy-info-model] Strassner, J., 1006 Halpern, J., Coleman, J., "Generic Policy Information 1007 Model for Simplified Use of Policy Abstractions (SUPA)", 1008 Work in Progress, May, 2017. 1010 [Alshaer] Al Shaer, E. and H. Hamed, "Modeling and management of 1011 firewall policies", 2004. 1013 [Bas12] Basile, C., Cappadonia, A., and A. Lioy, "Network-Level 1014 Access Control Policy Analysis and Transformation", 2012. 1016 [Bas15] Basile, C. and A. Lioy, "Analysis of application-layer 1017 filtering policies with application to HTTP", 2015. 1019 [Cormen] Cormen, T., "Introduction to Algorithms", 2009. 1021 [Galitsky] Galitsky, B. and Pampapathi, R., "Can many agents answer 1022 questions better than one", First Monday, 2005; 1023 http://dx.doi.org/10.5210/fm.v10i1.1204 1025 [Gamma] Gamma, E., Helm, R. Johnson, R., Vlissides, J., "Design 1026 Patterns: Elements of Reusable Object-Oriented 1027 Software", Addison-Wesley, Nov, 1994. 1028 ISBN 978-0201633610 1030 [Hirschman] Hirschman, L., and Gaizauskas, R., "Natural Language 1031 Question Answering: The View from Here", Natural Language 1032 Engineering 7:4, pgs 275-300, Cambridge University Press, 1033 2001 1035 [Hohpe] Hohpe, G. and Woolf, B., "Enterprise Integration 1036 Patterns", Addison-Wesley, 2003, ISBN 0-32-120068-3 1038 [Lunt] van Lunteren, J. and T. Engbersen, "Fast and scalable 1039 packet classification", 2003. 1041 [Martin] Martin, R.C., "Agile Software Development, Principles, 1042 Patterns, and Practices", Prentice-Hall, 2002, 1043 ISBN: 0-13-597444-5 1045 [MCM] MEF, "MEF Core Model", Technical Specification MEF X, 1046 April 2018 1048 [OODMP] http://www.oodesign.com/mediator-pattern.html 1050 [OODSOP] http://www.oodesign.com/observer-pattern.html 1052 [OODSRP] http://www.oodesign.com/single-responsibility- 1053 principle.html 1055 [PDO] MEF, "Policy Driven Orchestration", Technical 1056 Specification MEF Y, January 2018 1058 [Taylor] Taylor, D. and J. Turner, "Scalable packet classification 1059 using distributed crossproducting of field labels", 2004. 1061 Authors' Addresses 1063 Cataldo Basile 1064 Politecnico di Torino 1065 Corso Duca degli Abruzzi, 34 1066 Torino, 10129 1067 Italy 1068 Email: cataldo.basile@polito.it 1070 Liang Xia (Frank) 1071 Huawei 1072 101 Software Avenue, Yuhuatai District 1073 Nanjing, Jiangsu 210012 1074 China 1075 Email: Frank.xialiang@huawei.com 1077 John Strassner 1078 Huawei 1079 2330 Central Expressway 1080 Santa Clara, CA 95050 USA 1081 Email: John.sc.Strassner@huawei.com 1083 Diego R. Lopez 1084 Telefonica I+D 1085 Zurbaran, 12 1086 Madrid, 28010 1087 Spain 1088 Phone: +34 913 129 041 1089 Email: diego.r.lopez@telefonica.com