--- 1/draft-ietf-i2nsf-terminology-01.txt 2016-10-23 19:15:55.201639041 -0700 +++ 2/draft-ietf-i2nsf-terminology-02.txt 2016-10-23 19:15:55.229639727 -0700 @@ -1,22 +1,24 @@ I2NSF S. Hares Internet-Draft J. Strassner Intended status: Informational Huawei -Expires: January 29, 2017 D. Lopez +Expires: April 25, 2017 D. Lopez Telefonica I+D L. Xia Huawei - July 8, 2016 + H. Birkholz + Fraunhofer SIT + October 23, 2016 Interface to Network Security Functions (I2NSF) Terminology - draft-ietf-i2nsf-terminology-01.txt + draft-ietf-i2nsf-terminology-02.txt Abstract This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -25,21 +27,21 @@ Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 29, 2017. + This Internet-Draft will expire on April 25, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -118,21 +120,21 @@ Access Control: Protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy, and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy [RFC4949]. Accounting: The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation ([RFC2975] [RFC3539]). - ACL (Acess Control List): This is a mechanism that implements + ACL (Access Control List): This is a mechanism that implements access control for a system resource by enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity [RFC4949]. A YANG description is defined in [I-D.ietf-netmod-acl-model]. Action: Defines what is to be done when a set of Conditions are met (See I2NSF Action). (from [I-D.ietf-supa-generic-policy-info-model]). @@ -164,42 +166,42 @@ or FALSE. Also called Boolean Expression. Capability: Defines a set of features that are available from a managed entity (see also I2NSF Capability). Examples of "managed entities" are NSFs and Controllers, where NSF Capabilities and Controller Capabilities define functionality of an NSF and about Controller, respectively. These functions may, but do not have to, be used. All Capabilities are announced through the Registration Interface. - Capability Interface: An interface dedicated to requesting, - receiving, editing, and deleting capability information. - Client: See Consumer. [Editor's note: placeholder for gradually replacing Client with Consumer, since Client is too vague and has other connotations (e.g., client-server)]. Client-Facing Interface: See Consumer-Facing Interface. See also: Interface, NSF-Facing Interface. Component: An encapsulation of software that communicates using Interfaces. A Component may be implemented by hardware and/or software, and be represented using a set of classes. In general, a Component encapsulates a set of data structures and a set of algorithms that implement the function(s) that it provides. Consumer: A Consumer is a Role that is assigned to an I2NSF - Component that can receive information from another I2NSF - Component. See also: Provider, Role. + Component that represents the needs of a user of I2NSF services. + A consumer can send/receive information to/from another I2NSF + Component (e.g., for defining and monitoring security policies + for the Consumer's specific flows through an I2NSF + administrative domain). See also: Producer, Role. Consumer-Facing Interface: An Interface dedicated to communication - with Consumers of NSF data and Services. This is typically + with Consumers of NSF Data and Services. This is typically defined per I2NSF administrative domain. See also: Interface, NSF-Facing Interface. Condition: A set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to make a decision. A Condition, when used in the context of a Policy Rule, is used to determine whether or not the set of Actions in that Policy Rule can be executed or not. Examples of an I2NSF Condition include matching attributes of a packet or flow, and comparing the internal state of a NSF to a @@ -269,43 +271,50 @@ ECA: Event - Condition - Action (a type of Policy Rule). Firewall (FW): A function that restricts data communication traffic to and from one of the connected networks (the one said to be 'inside' the firewall), and thus protects that network's system resources against threats from the other network (the one that is said to be 'outside' the firewall) [RFC4949]. [I-D.ietf-opsawg-firewalls] + Flow: A set of information (e.g., packets) that are related in a + fundamental manner (e.g., sent from the same source and sent to + the same destination). A common example is a sequence of packets. + It is the opposite of packet-based, which treats each packet + discretely (e.g., each packet is assessed individually to + determine the action(s) to be taken). + Flow-based NSF: A NSF that inspects network flows according to a set of policies intended for enforcing security properties. Flow- based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process. + I2NSF Agent: A software Component in a device that implements an + NSF. It receives provisioning information and requests for + operational data (e.g., monitoring data) from an I2NSF Consumer. + It is also responsible for enforcing the policies that it + receives from an I2NSF Consumer. + I2NSF Action: An I2NSF Action is a special type of Action that is used to control and monitor aspects of flow-based Network Security Functions. Examples of I2NSF Actions include providing intrusion detection and/or protection, web and flow filtering, and deep packet inspection for packets and flows. An I2NSF Action, when used in the context of a I2NSF Policy Rule, may be executed when both the Event and the Condition clauses of its owning I2NSF Policy Rule evaluate to true. The execution of this Action may be influenced by applicable metadata. (from [I-D.ietf-supa-generic-policy-info-model]). - I2NSF Agent: A software Component in a device that implements an - NSF. It receives provisioning information and requests for - operational data (e.g., monitoring data) from an I2NSF Consumer. - It is also responsible for enforcing the policies that it - receives from an I2NSF Consumer. - I2NSF Capability: A set of features that are available from an NSF Server or an NSF Controller. While both are Capabilities, the former defines functions that are available from an NSF, whereas the latter defines functions that are available from a security Controller or other Management Entity. This definition is based on that in [I-D.ietf-sacm-terminology]. I2NSF Client: See I2NSF Consumer. I2NSF Component: A Component that provides one or more I2NSF @@ -379,20 +388,23 @@ types of interfaces to serve different purposes. An example of multiple interfaces can be seen by considering the interfaces include a firewall uses; these include: * multiple interfaces for data packets to traverse through, * an interface for a controller to impose policy,or retrieve the results of execution of a policy rule. See also: Consumer Interface, I2NSF Interface, Provider Interface + Interface Group: A set of Interfaces that are related in purpose and + which share the same communication mechanisms. + Intrusion Detection System (IDS): A system that detects network intrusions via a variety of filters, monitors, and/or probes. An IDS may be stateful or stateless. Intrusion Protection System (IPS): A system that protects against network intrusions. An IPS may be stateful or stateless. Management Plane: In the context of I2NSF, the Management Plane is an architectural Component that provides common functions to define the behavior of I2NSF Components. The primary use of the @@ -495,51 +507,52 @@ The following people contributed to creating this document, and are listed in alphabetical order: Henk Birkholz 6. References 6.1. Informative References [I-D.ietf-i2nsf-gap-analysis] - Hares, S., Moskowitz, R., and D. Zhang, "Analysis of - Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-01 - (work in progress), April 2016. + Hares, S., Moskowitz, R., and Zhang, D., "Analysis of + Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-02 + (work in progress), July 2016. [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Jacquenet, "I2NSF Problem Statement and Use cases", draft- - ietf-i2nsf-problem-and-use-cases-01 (work in progress), - July 2016. + ietf-i2nsf-problem-and-use-cases-02 (work in progress), + October 2016. [I-D.ietf-netmod-acl-model] Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., "Network Access Control List (ACL) YANG Data Model", - draft-ietf-netmod-acl-model-08 (work in progress), - July 2016. + draft-ietf-netmod-acl-model-09 (work in progress), + October 2016. [I-D.ietf-opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", draft-ietf-opsawg-firewalls-01 (work in progress), October 2012. [I-D.ietf-sacm-terminology] - Birkholz, H., Lu, J., Cam-Wignet, N., "Secure Automation - and Continuous Monitoring (SACM) Terminology", - draft-ietf-sacm-terminology-09, March 2016 + Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., + "Secure Automation and Continuous Monitoring (SACM) + Terminology", draft-ietf-sacm-terminology-11, + September 2016 [I-D.ietf-supa-generic-policy-info-model] Strassner, J., Halpern, J., and J. Coleman, "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", draft-ietf-supa-generic-policy- - info-model-00 (work in progress), June 2016. + info-model-01 (work in progress), July 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, . [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, @@ -548,41 +561,45 @@ [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, DOI 10.17487/RFC3539, June 2003, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [X.1252] ITU-T, "Baseline identity management terms and - definitions", Recommendation ITU-T X.1252, April 2010 + definitions", Recommendation ITU-T X.1252, April 2510 Authors' Addresses Susan Hares Huawei 7453 Hickory Hill - Saline, MI 48176 - USA + Saline, MI USA 48176 Phone: +1-734-604-0332 Email: shares@ndzh.com John Strassner Huawei Technologies - Santa Clara, CA - USA + Santa Clara, CA USA 95050 Email: john.sc.strassner@huawei.com Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain Email: diego.r.lopez@telefonica.com - Liang Xia (Frank) Huawei 101 Software Avenue, Yuhuatai District Nanjing , Jiangsu 210012 China Email: Frank.Xialiang@huawei.com + + Henk Birkholz + Fraunhofer SIT + Rheinstrasse 75 + Darmstadt 64295 + Germany + Email: henk.birkholz@sit.fraunhofer.de