idnits 2.17.1 draft-ietf-i2nsf-terminology-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2016) is 2919 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-i2nsf-gap-analysis-01 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-00 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft J. Strassner 4 Intended status: Informational Huawei 5 Expires: October 29, 2016 D. Lopez 6 Telefonica I+D 7 L. Xia 8 Huawei 9 April 29, 2016 11 Interface to Network Security Functions (I2NSF) Terminology 12 draft-ietf-i2nsf-terminology-00.txt 14 Abstract 16 This document defines a set of terms that are used for the Interface 17 to Network Security Functions (I2NSF) effort. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current 27 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on October 29, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided 50 without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Informative References . . . . . . . . . . . . . . . . . 9 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 62 1. Introduction 64 This document defines the terminology for the Interface to Network 65 Security Functions(I2NSF) effort. This section provides some 66 background on I2NSF; a detailed problem statement can be found in 67 [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to 68 previous work can be found in [I-D.ietf-i2nsf-gap-analysis]. 70 Enterprises are now considering using network security functions 71 (NSFs) hosted by service providers due to the growing challenges and 72 complexity in maintaining an up to date secure infrastructure that 73 complies with regulatory requirements, while controlling costs. The 74 hosted security service is especially attractive to small and medium 75 size enterprises who suffer from a lack of security experts to 76 continuously monitor, acquire new skills and propose immediate 77 mitigations to ever increasing sets of security attacks. Small and 78 medium-sized businesses (SMBs) are increasingly adopting cloud-based 79 security services to replace on-premises security tools, while larger 80 enterprises are deploying a mix of traditional (hosted) and cloud- 81 based security services. 83 To meet the demand, more and more service providers are providing 84 hosted security solutions to deliver cost-effective managed security 85 services to enterprise customers. The hosted security services are 86 primarily targeted at enterprises, but could also be provided to any 87 kind of mass-market customers as well. NSFs are provided and 88 consumed in increasingly diverse environments. Users of NSFs may 89 consume network security services hosted by one or more providers, 90 which may be their own enterprise, service providers, or a 91 combination of both. 93 It is out of scope in this document to define an exhaustive list of 94 terms that are used in the security field; the reader is referred to 95 other applicable documents, such as [RFC4949]. 97 2. Terminology 99 AAA: Authentication, Authorization, and Accounting. See individual 100 definitions. 102 Abstraction: The definition of the salient characteristics and 103 behavior of an object that distinguish it from all other types of 104 objects. It manages complexity by exposing common properties 105 between objects and processes while hiding detail that is not 106 relevant. 108 Access Control: Protection of system resources against unauthorized 109 access; a process by which use of system resources is regulated 110 according to a security policy, and is permitted by only 111 authorized entities (users, programs, processes, or other systems) 112 according to that policy [RFC4949]. 114 Accounting: The act of collecting information on resource usage for 115 the purpose of trend analysis, auditing, billing, or cost 116 allocation ([RFC2975] [RFC3539] 118 ACL (Acess Control List): This is a mechanism that implements 119 access control for a system resource by enumerating the system 120 entities that are permitted to access the resource and stating, 121 either implicitly or explicitly, the access modes granted to each 122 entity [RFC4949]. A YANG description is defined in 123 [I-D.ietf-netmod-acl-model]. 125 Action: Defines what is to be done when a set of conditions are 126 met (See I2NSF Action). (from 127 [I-D.strassner-supa-generic-policy-info-model]) 129 Authentication: The act of verifying a claimed identity, in the 130 form of a pre-existing label from a mutually known name space, as 131 the originator of a message (message authentication) or as the 132 end-point of a channel (entity authentication) [RFC3539]. 134 Authorization: The act of determining if a particular right, such 135 as access to some resource, can be granted to the presenter of a 136 particular credential [RFC3539]. 138 B2B: Business-to-Business. 140 Bespoke: Something made to fit a particular person, customer, or 141 company. 143 Bespoke security management: Security management systems that are 144 make to fit a particular customer. 146 Boolean Clause: A logical statement that evaluates to either TRUE 147 or FALSE. Also called Boolean Expression. 149 Capability: Defines a set of features that are available from a 150 managed entity (see also I2NSF Capability). 152 Capability Layer: Defines an abstraction layer that exposes a set 153 of capabilities of the I2NSF system. 155 Condition: A set of attributes, features, and/or values that are to 156 be compared with a set of known attributes, features, and/or 157 values in order to make a decision. A Condition, when used in the 158 context of a Policy Rule, is used to determine whether or not the 159 set of Actions in that Policy Rule can be executed or not. 160 Examples of an I2NSF Condition include matching attributes of a 161 packet or flow, and comparing the internal state of a NSF to a 162 desired state. [I-D.strassner-supa-generic-policy-info-model] 164 Constraint: A constraint is a limitation or restriction. 165 Constraints may be associated with any type of object (e.g., 166 events, conditions, and actions in Policy Rules). 168 Constraint Programming: A type of programming that uses constraints 169 to define relations between variables in order to find a 170 feasible (and not necessarily optimal) solution. 172 Context: The Context of an Entity is a collection of measured and/ 173 or inferred knowledge that describe the state and the environment 174 in which an Entity exists or has existed. (from 175 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 177 Controller: TBD [Editorial: The definition is lacking content 178 ("used interchangeably with Service Provider Security Controller 179 or management system throughout this document") and overloaded - 180 the two terms should be split into two separate definitions in 181 documents.] 183 Customer: A business role of an entity that is involved in the 184 definition and/or consumption of services, and the possible 185 negotiation of a contract to use services from a Provider. 187 DC: Data Center 189 Data Model: A representation of concepts of interest to an 190 environment in a form that is dependent on data repository, data 191 definition language, query language, implementation language, and 192 protocol (typically one or more of these ) 193 [I-D.strassner-supa-generic-policy-info-model]. 195 Event: An important occurrence in time of a change in the system 196 being managed, and/or in the environment of the system being 197 managed. Examples of an I2NSF Event include time and user actions 198 (e.g. logon, logoff, and actions that violate an ACL). An Event, 199 when used in the context of a Policy Rule, is used to determine 200 whether the condition clause of an imperative Policy Rule can be 201 evaluated or not [I-D.strassner-supa-generic-policy-info-model]. 203 ECA: Event - Condition - Action policy (a type of Policy Rule). 205 Firewall (FW): A function that restricts data communication traffic 206 to and from one of the connected networks (the one said to be 207 'inside' the firewall), and thus protects that network's system 208 resources against threats from the other network (the one that 209 is said to be 'outside' the firewall) [RFC4949]. 210 [I-D.ietf-opsawg-firewalls] 212 Flow-based NSF: A NSF that inspects network flows according to a 213 set of policies intended for enforcing security properties. Flow- 214 based security also means that packets are inspected in the order 215 they are received, and without modification to the packet due to 216 the inspection process. 218 I2NSF Action: An I2NSF Action is a special type of Action that is 219 used to control and monitor aspects of flow-based Network Security 220 Functions. Examples of I2NSF Actions include providing intrusion 221 detection and/or protection, web and flow filtering, and deep 222 packet inspection for packets and flows. An I2NSF Action, when 223 used in the context of a I2NSF Policy Rule, may be executed when 224 both the event and the condition clauses of its owning I2NSF 225 Policy Rule evaluate to true. The execution of this action may be 226 influenced by applicable metadata 227 [I-D.strassner-supa-generic-policy-info-model]. 229 I2NSF Agent: A software component in a device that implements an 230 NSF. It receives provisioning information and requests for 231 operational data (e.g., monitoring data) from an I2NSF client. It 232 is also responsible for enforcing the policies that it receives 233 from an I2NSF client. 235 I2NSF Capability: A set of features that are available from an NSF 236 server. 238 I2NSF client: A software component that uses the I2NSF framework 239 to read, write, and/or change provisioning and operational aspects 240 of the NSFs that it attaches to. 242 I2NSF Management System: I2NSF clients operate within a network 243 management system, which serves as a collection and distribution 244 point for I2NSF security provisioning and filters data. 246 I2NSF Policy: A set of rules that are used to manage and control 247 the changing or maintaining of the state of an NSF instance. 249 I2NSF Policy Rule: A policy rule that is adapted for I2NSF usage. 250 The I2NSF Policy Rule is assumed to be in ECA form (i.e., an 251 imperative structure). Other types of programming paradigms 252 (e.g., declarative and functional) are currently out of scope. 253 An example of an I2NSF Policy Rule is, in pseudo-code: 255 IF is TRUE 257 IF is TRUE 259 THEN execute 261 END-IF 263 END-IF 265 In the above example, the Event, Condition, and Action portions of 266 a Policy Rule are all **Boolean Clauses**. 268 I2NSF Registry: A registry that contains I2NSF capability 269 information, which can be controlled by the I2NSF Management 270 System. 272 IDS: Intrusion Detection System (see below). 274 IPS: Intrusion Protection System (see below). 276 Information Model: A representation of concepts of interest to an 277 environment in a form that is independent of data repository, 278 data definition language, query language, implementation language, 279 and protocol [I-D.strassner-supa-generic-policy-info-model]. 281 Interface: A set of operations one object knows it can invoke on, 282 and expose to, another object. It is a subset of all operations 283 that a given object implements. The same object may have multiple 284 types of interfaces to serve different purposes. An example of 285 multiple interfaces can be seen by considering the interfaces 286 include a firewall uses; these include: 288 * multiple interfaces for data packets to traverse through, 289 * an interface for a controller to impose policy,or retrieve the 290 results of execution of a policy rule. 292 Intrusion Detection System (IDS): A system that detects network 293 intrusions via a variety of filters, monitors, and/or probes. An 294 IDS may be stateful or stateless. 296 Intrusion Protection System (IPS): A system that protects against 297 network intrusions. An IPS may be stateful or stateless. 299 Metadata: Data that provides information about other data. 300 Examples include IETF network management protocols (e.g. NETCONF, 301 RESTCONF, IPFix) or IETF routing interfaces (I2RS). The I2NSF 302 security interface may utilize Metadata to describe and/or 303 prescribe characteristics and behavior of the YANG data models. 305 Middlebox: Any intermediary device performing functions other 306 than the normal, standard functions of an IP router on the 307 datagram path between a source host and destination host 308 [RFC3234]. 310 Network Security Function (NSF): Software that provides a set of 311 security-related services. Examples include detecting unwanted 312 activity and blocking or mitigating the effect of such unwanted 313 activity in order to fulfil service requirements. The NSF can 314 also help in supporting communication stream integrity and 315 confidentiality. 317 OCL (Object Constraint Language): A constraint programming language 318 that is used to specify constraints (e.g., in UML) (from 319 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 321 Policy Rule: A set of rules that are used to manage and control 322 the changing or maintaining of the state of one or more managed 323 objects. Often this is shorterned to Rule or Policy (see I2NSF 324 policy rule) [I-D.strassner-supa-generic-policy-info-model]. 326 Profile: A structured representation of information that 327 characterizes the capabilities of an object, typically in a 328 specific context. This may be used to simplify how this object 329 interacts with other objects in its environment. [Editors note: 330 John Strassner suggests this is a simplified definition from a 331 variety of sources (UAProf and CC/PP). It does not mention the 332 concept of preference, therefore John wonders if we need a 333 different definition here.] 335 Registry: is a logically centralized location containing data of a 336 particular type; it may optionally contain metadata, 337 relationships, and other aspects of the registered data in order 338 to use those data effectively. An I2NSF registry is used to 339 contain capability information that can be controlled by the 340 controller. 342 Registration Interface: An interface dedicated to requesting, 343 receiving, editing, and deleting information in a Registry. 345 Service Layer: Software that enables clients to manage security 346 policies for their specific flows. This is also called the 347 Client-Facing Interface. 349 Service Provider Security Controller: TBD (Editorial: Place holder 350 for a split between controller and security controller 351 definitions.) 353 Tenant: A group of users that share common access privileges to 354 the same software. An I2NSF tenant may be physical or virtual, 355 and may run on a variety of systems or servers. 357 Vendor Facing Interface: This enables vendors to register their 358 NSFs, along with the capabilities of their NSFs, with a logically 359 centralized authority. 361 Virtual NSF: An NSF that is deployed as a distributed virtual 362 device. 364 Virtual Network Function (VNF): A virtualized network component, 365 such as a router, switch, security box, or AAA Servier. 367 VNFM (VNF Manager): Manager of virtual network functions that 368 creates, deletes, manages, and moves VNFs. 370 VNFPool: A collection of interchangeable VNFs (i.e., each VNF has 371 the same set of capabilities). 373 Virtualization: Virtualization is a type of software that creates 374 a non-physical version of an object. Examples include virtualized 375 operating systems, storagte devices, and networking elements. 376 [Editor's notes: Questions from John: Do we want or need to 377 differentiate between different tyeps of virtualization? For 378 example: full vs. partial vs. para-virtualization (all types of 379 "hardware virtualization")? Do we need to introduce OS 380 virtualization? What about application virtualization?] 382 3. IANA Considerations 384 No IANA considerations exist for this document. 386 4. Security Considerations 388 This is a terminology document with no security considerations. 390 5. References 392 5.1. Informative References 394 [I-D.ietf-i2nsf-gap-analysis] 395 Hares, S., Moskowitz, R., and D. Zhang, "Analysis of 396 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-01 397 (work in progress), April 2016. 399 [I-D.ietf-i2nsf-problem-and-use-cases] 400 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 401 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 402 ietf-i2nsf-problem-and-use-cases-00 (work in progress), 403 February 2016. 405 [I-D.ietf-netmod-acl-model] 406 Bogdanovic, D., Koushik, K., Huang, L., and Blair, D., 407 "Network Access Control List (ACL) YANG Data Model", 408 draft-ietf-netmod-acl-model-07 (work in progress), 409 March 2016. 411 [I-D.ietf-opsawg-firewalls] 412 Baker, F. and P. Hoffman, "On Firewalls in Internet 413 Security", draft-ietf-opsawg-firewalls-01 (work in 414 progress), October 2012. 416 [I-D.strassner-supa-generic-policy-info-model] 417 Strassner, J., Halpern, J., and J. Coleman, "Generic 418 Policy Information Model for Simplified Use of Policy 419 Abstractions (SUPA)", draft-strassner-supa-generic-policy- 420 info-model-05 (work in progress), April 2016. 422 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 423 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 424 October 2000, . 426 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 427 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 428 . 430 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 431 Accounting (AAA) Transport Profile", RFC 3539, 432 DOI 10.17487/RFC3539, June 2003, 433 . 435 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 436 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 437 . 439 Authors' Addresses 441 Susan Hares 442 Huawei 443 7453 Hickory Hill 444 Saline, MI 48176 445 USA 447 Phone: +1-734-604-0332 448 Email: shares@ndzh.com 450 John Strassner 451 Huawei 452 Santa Clara, CA 453 USA 455 Email: john.sc.strassner@huawei.com 456 Diego R. Lopez 457 Telefonica I+D 458 Don Ramon de la Cruz, 82 459 Madrid 28006 460 Spain 462 Email: diego.r.lopez@telefonica.com 464 Liang Xia (Frank) 465 Huawei 466 101 Software Avenue, Yuhuatai District 467 Nanjing , Jiangsu 210012 468 China 470 Email: Frank.Xialiang@huawei.com