idnits 2.17.00 (12 Aug 2021) /tmp/idnits12169/draft-strassner-i2nfs-info-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.1. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. 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: ' 7. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2015) is 2650 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 section? 'RFC2119' on line 438 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF John Strassner 2 Internet Draft Liang Xia 3 Intended status: Standard Track Huawei 5 Expires: August 2015 February 10, 2015 7 Interface to Network Security Functions Information Model 8 draft-strassner-i2nfs-info-model-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on August 10, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 This document describes an information model that defines the 51 salient managed entities and their relationships in an Interface to 52 Network Security Function (I2NSF) architecture. The information 53 model is independent of platform, language, and protocol, and serves 54 as a common consensual lexicon for the I2NFS architecture as well as 55 clients using this architecture. This enables multiple application- 56 specific data models (which are dependent on platform, language, 57 and/or protocol) to be built from this information model. The 58 advantage of doing so is to ensure that such data models will be 59 able to share and reuse consensually defined concepts, thereby 60 increasing interoperability. 62 Table of Contents 64 1. Introduction ................................................ 3 65 2. Conventions used in this document ........................... 3 66 2.1. Acronyms ............................................... 4 67 2.2. Definitions ............................................ 4 68 2.2.1. Information Model ................................. 4 69 2.2.2. Data Model......................................... 5 70 2.2.3. Inheritance ....................................... 5 71 2.2.4. Relationship ...................................... 5 72 2.2.4.1. Association .................................. 5 73 2.2.4.2. Aggregation .................................. 5 74 2.2.4.3. Composition .................................. 5 75 2.2.5. Multiplicity ...................................... 6 76 2.3. Symbology .............................................. 6 77 2.3.1. Basic Symbols ..................................... 6 78 2.3.2. Relationship Multiplicity ......................... 6 79 2.3.3. Relationship Naming ............................... 7 80 2.3.4. Relationship Navigability ......................... 7 81 2.3.5. Relationships Implemented as Classes .............. 7 82 3. Design of the I2NSF Information Model ....................... 8 83 3.1. Overview ............................................... 8 84 3.2. I2NSF Clients ......................................... 10 85 3.3. Security Policy Layer ................................. 10 86 3.4. Context-Aware Policy Engine ........................... 10 87 3.5. Security Capability Layer ............................. 11 88 4. I2NSF Information Model Hierarchy .......................... 11 89 5. Usage Examples of the I2NSF Information Model .............. 11 90 6. Security Considerations .................................... 11 91 7. IANA Considerations ........................................ 12 92 8. References ................................................. 12 93 8.1. Normative References .................................. 12 94 8.2. Informative References ................................ 12 95 9. Acknowledgments ............................................ 12 97 1. Introduction 99 Networks and networked applications are becoming increasingly 100 diverse and complex. Concurrently, operators are struggling to 101 deploy new services quickly, and require more powerful and robust 102 network management services and applications. Both of these problems 103 are exacerbated by the proliferation of vendor-specific devices and 104 data models. 106 While Yang offers an easier way to build data models, it lacks 107 several software abstractions that facilitate representing high- 108 level entities and relationships between such entities. UML 109 Information Models are the de facto method for defining entities and 110 relationships in a technologically-neutral manner. The use of an 111 information model increases interoperability by defining a common 112 lexicon of concepts, terms, entities, and relationships that all 113 clients and applications can use. Data Models created in Yang, as 114 well as in other technologies, can use the terms and concepts 115 defined in the information model to ensure that concepts defined in 116 different technologies can be identified and translated to each 117 other. 119 The I2NFS Information Model will define managed objects and 120 mechanisms to address the operational, administrative, and 121 management aspects of the managed objects. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC-2119 [RFC2119]. 129 2.1. Acronyms 131 AAA - Authentication, Authorization, Accounting 133 ABAC - Attribute Based Access Control 135 I2NSF - Interface to Network Security Functions 137 Netconf - Network Configuration protocol 139 NSF - Network Security Function 141 OAM - Operational, Administrative, and Management 143 PAP - Policy Administration Point 145 PBAC - Policy Based Access Control 147 PDP - Policy Decision Point 149 PEP - Policy Enforcement Point 151 PIP - Policy Information Point 153 PR - Policy Repository 155 PXP - Policy Execution Point 157 RBAC - Role Based Access Control 159 UML - Unified Modeling Language 161 Yang - A data definition language for use with Netconf 163 2.2. Definitions 165 This section defines important terms that are used in this document. 167 2.2.1. Information Model 169 An information model is a representation of concepts of interest to 170 an environment in a form that is independent of platform, language, 171 and protocol. 173 2.2.2. Data Model 175 A data model is a representation of concepts of interest to an 176 environment in a form that is dependent on platform, language, 177 and/or protocol (typically, but not necessarily, all three). 179 2.2.3. Inheritance 181 Inheritance makes an entity at a lower level of abstraction (e.g., 182 the subclass) a type of an entity at a higher level of abstraction 183 (e.g., the superclass). A subclass does NOT change the 184 characteristics or behavior of the superclass that it inherits from. 185 However, a subclass MAY add new attributes and relationships that 186 distinguish it from the attributes and relationships defined by its 187 superclass. 189 2.2.4. Relationship 191 A relationship is a generic term that represents how a first set of 192 entities interact with a second set of entities. A recursive 193 relationship sets the first and second entity to the same entity. 194 There are three basic types of relationships, as defined in the 195 subsections below. 197 2.2.4.1. Association 199 An association represents a generic dependency between a first and a 200 second set of entities. 202 2.2.4.2. Aggregation 204 An aggregation is a stronger type (i.e., more restricted 205 semantically) of association, and represents a whole-part dependency 206 between a first and a second set of entities. In other words, three 207 objects are implied by an aggregation: the first entity, the second 208 entity, and a new third entity that represents the combination of 209 the first and second entities. The entity owning the aggregation is 210 referred to as the "aggregate", and the entity that is aggregated is 211 referred to as the "part". 213 2.2.4.3. Composition 215 A composition is a stronger type (i.e., more restricted semantically) 216 of aggregation, and represents a whole-part dependency with two 217 important behaviors. First, an instance of the part is included in 218 at most one instance of the aggregate at a time. Second, any action 219 performed on the composite entity (i.e., the aggregate) is 220 propagated to its constituent part objects. For example, if the 221 composite entity is deleted, then all of its constituent part 222 entities are also deleted. This is not true of aggregations or 223 associations - in both, only the entity being deleted is actually 224 removed, and the other entities are unaffected. 226 2.2.5. Multiplicity 228 A specification of the range of allowable cardinalities that a set 229 of entities may assume. This is always a pair of ranges, such as 1 - 230 1 or 0..n - 2..5. 232 2.3. Symbology 234 In order to unambiguously represent information in this document, 235 ASCII art will be used. This art will use the following special 236 symbols. 238 2.3.1. Basic Symbols 240 Indentation: this will be used to indicate hierarchy levels 242 Inheritance: represented by --|> (e.g., subclass -I> superclass) 244 Association: represented by --A- (e.g., ClassA --A- ClassB) 246 Aggregation: represented by --Ag- (e.g., ClassA --Ag- ClassB) 248 Composition: represented by --C- (e.g., ClassA --C- ClassB) 250 2.3.2. Relationship Multiplicity 252 Relationships MUST have a specified multiplicity, and can be 253 represented as follows: 254 --------- --------- 255 | | 0..1 1..n | | 256 | Class A |---------------A-| Class B | 257 | | BDependsOnA | | 258 --------- --------- 260 Figure 1. Illustrating a Non-Directed Association. 262 2.3.3. Relationship Naming 264 Relationships MUST be named. This is to facilitate their 265 implementation as named managed objects. The name SHOULD be in 266 InitCaps. In Figure 1, Class B depends on Class A (e.g., an event 267 must happen to A before B can take action). 268 2.3.4. Relationship Navigability 270 Relationships MAY indicate a constraint on which set of entities can 271 communicate with the other set of entities in a relationship. If 272 there is no such constraint, then the symbology in Section 2.3.1, 273 illustrated by Figure 1 in Section 2.3.2, is sufficient. Otherwise, 274 an arrow, denoted by the right angle character (i.e., ">"), is used. 275 Relationships with constraint and a specified multiplicity can be 276 represented as follows: 277 --------- --------- 278 | | 0..1 1..n | | 279 | Class A |---------------A->| Class B | 280 | | BDependsOnA | | 281 --------- --------- 283 Figure 2. Illustrating a Directed Association. 285 In this case, Entities of Class A can communicate with Class B; the 286 reverse is not allowed. 287 2.3.5. Relationships Implemented as Classes 289 A relationship MAY be realized as a class. This is typically called 290 an "association class", regardless of whether the association is an 291 association, an aggregation, or a composition. This is illustrated as 292 follows: 294 --------- 295 | Class C | 296 --------- 297 | 298 AC 299 --------- | --------- 300 | | 0..1 | 1..n | | 301 | Class A |----------------A->| Class B | 302 | | BDependsOnA | | 303 ---------- --------- 305 Figure 3. Illustrating an Association Class. 307 In Figure 3, Class C is an association class, and represents the 308 realization of the association named BDependsOnA. Conceptually, this 309 means that the relationship between Classes A and B is complex, and 310 requires a class to represent it. For example, class attributes MAY 311 be used to define how Class B depends on Class A. 313 3. Design of the I2NSF Information Model 315 This section describes the I2NSF Information Model. It first 316 provides an architectural overview of the main entities involved. 317 Then, it defines an object-oriented information model for 318 representing the entities and their relationships. 320 3.1. Overview 322 The operation of I2NSF may be conceptualized as shown in Figure 4. 324 ----------------- ------------ 325 | I2NSF Clients | | Info Model |<--------+ 326 ----------------- ------------ | 327 / \ | 328 | | 329 | Intent-based Security Policy | 330 | | 331 \ / | 332 ------------------------- ------------- | 333 | Security Policy Layer | <-------> | Data Models |<-----+ 334 ------------------------- ------------- | 335 / \ / \ | 336 | | | 337 | Policy to Device Translation | | 338 | | | 339 \ / \ / | 340 ----------------------------- --------------- | 341 | Context-Aware Policy Engine | <-----> | Data Models |<---+ 342 ----------------------------- --------------- | 343 / \ / \ | 344 | | | 345 | Device Capabilities | | 346 | | | 347 \ / \ / | 348 ----------------------------- --------------- | 349 | Security Capability Layer | <-----> | Data Models |<---+ 350 ----------------------------- --------------- 352 Figure 4. Conceptual Operation of the I2NSF. 354 An I2NSF client is a user, application, process, or similar entity 355 that wants to invoke a physical or virtual Network Security Function 356 for OAM purposes. This results from the I2NSF Security Policy Layer 357 exposing a set of security capabilities of one or more network 358 devices. The I2NSF client does not have to be aware of which set of 359 security devices is present or is being used; all the I2NSF client 360 needs to be cognizant of is which network security functions are 361 required for a given flow. 363 The Context-Aware Policy Engine uses information about the subject 364 and target of the policy, the current context, the type of operation 365 desired, and any other required information, and translates the 366 (high-level) intent of the I2NSF client to the capabilities of the 367 network security devices. 369 The Intent-based Security Policy is a declarative specification of 370 the security functions required by an I2NSF client. Since multiple 371 devices can have non-interoperable data models that describe their 372 capabilities, I2NSF uses an information model to represent all 373 concepts that are used by I2NSF clients, applications, and the 374 system itself. This enables each of the three layers shown in Figure 375 4 to (in principle) have their own data model to represent their 376 functionality in an efficient manner. The information model serves 377 as a lexicon that enables different entities in the I2NSF 378 architecture to map the same or similar terms to different 379 expressions from different data models. 381 The following subsections define important architectural entities in 382 each layer in more detail. 384 3.2. I2NSF Clients 386 3.3. Security Policy Layer 388 3.4. Context-Aware Policy Engine 390 The purpose of I2NSF is to ensure that only properly authorized and 391 validated requests to perform operations on Resources and Services 392 are allowed. 394 ----------- 1 -------- 7 ----- 395 | Requestor |---->| PEP |---->| PXP | 396 ----------- -------- ----- 397 | / \ 398 2 | | 6 399 | | 400 \ / | 401 -------- 3 -------------- 402 | |---->| | 403 | CADE |<----| PIP | 404 | | 5 | | 405 -------- -------------- 406 / \ / \ / \ 407 4a| 4b| 4c| 408 | | | 409 | | | 410 --- --- --- 411 | S || E || R | 412 --- --- --- 414 Figure 5. High-Level Overview of the I2NSF Access Control Engine. 416 3.5. Security Capability Layer 418 4. I2NSF Information Model Hierarchy 420 TBD 422 5. Usage Examples of the I2NSF Information Model 424 TBD 426 6. Security Considerations 428 TBD 430 7. IANA Considerations 432 TBD 434 8. References 436 8.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 8.2. Informative References 443 9. Acknowledgments 445 This document was prepared using 2-Word-v2.0.template.dot. 447 Authors' Addresses 449 John Strassner 450 Huawei Technologies 451 2330 Central Expressway 452 Santa Clara, CA 95138 453 USA 454 email: john.sc.strassner@huawei.com 456 Liang Xia 457 Huawei Technologies 458 email: Frank.xialiang@huawei.com