Internet DRAFT - draft-hares-i2nsf-terminology
draft-hares-i2nsf-terminology
I2NSF S. Hares
Internet-Draft J. Strassner
Intended status: Informational Huawei
Expires: October 6, 2016 D. Lopez
Telefonica I+D
L. Xia
Huawei
April 4, 2016
Interface to Network Security Functions (I2NSF) Terminology
draft-hares-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.
Internet-Drafts are working documents of the Internet Engineering
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 October 6, 2016.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hares, et al. Expires October 6, 2016 [Page 1]
Internet-Draft I2NSF Terminology April 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document defines the terminology for the Interface to Network
Security Functions(I2NSF) effort. This section provides some
background on I2NSF; a detailed problem statement can be found in
[I-D.ietf-i2nsf-problem-and-use-cases]
Enterprises are now considering using network security functions
(NSFs) hosted by service providers due to the growing challenges and
complexity in maintaining an up to date secure infrastructure that
complies with regulatory requirements, while controlling costs. The
hosted security service is especially attractive to small and medium
size enterprises who suffer from a lack of security experts to
continuously monitor, acquire new skills and propose immediate
mitigations to ever increasing sets of security attacks. Small and
medium-sized businesses (SMBs) are increasingly adopting cloud-based
security services to replace on-premises security tools, while larger
enterprises are deploying a mix of traditional (hosted) and cloud-
based security services.
To meet the demand, more and more service providers are providing
hosted security solutions to deliver cost-effective managed security
services to enterprise customers. The hosted security services are
primarily targeted at enterprises, but could also be provided to any
kind of mass-market customers as well. NSFs are provided and
consumed in increasingly diverse environments. Users of NSFs may
consume network security services hosted by one or more providers,
which may be their own enterprise, service providers, or a
combination of both.
It is out of scope in this document to define an exhaustive list of
terms that are used in the security field; the reader is referred to
other applicable documents, such as [RFC4949].
Hares, et al. Expires October 6, 2016 [Page 2]
Internet-Draft I2NSF Terminology April 2016
2. Terminology
AAA: Authentication, Authorization, and Accounting. See individual
definitions.
Abstraction: The definition of the salient characteristics and
behavior of an object that distinguish it from all other types of
objects. It manages complexity by exposing common properties
between objects and processes while hiding detail that is not
relevant.
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
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].
Action: Defines what is to be done when a set of conditions are
met (See I2NSF Action). (from
[I-D.strassner-supa-generic-policy-info-model])
Authentication: The act of verifying a claimed identity, in the
form of a pre-existing label from a mutually known name space, as
the originator of a message (message authentication) or as the
end-point of a channel (entity authentication) [RFC3539].
Authorization: The act of determining if a particular right, such
as access to some resource, can be granted to the presenter of a
particular credential [RFC3539].
B2B: Business-to-Business.
Bespoke: Something made to fit a particular person, customer, or
company.
Bespoke security management: Security management systems that are
make to fit a particular customer.
Hares, et al. Expires October 6, 2016 [Page 3]
Internet-Draft I2NSF Terminology April 2016
Boolean Clause: A logical statement that evaluates to either TRUE
or FALSE. Also called Boolean Expression.
Capability: Defines a set of features that are available from a
managed entity (see also I2NSF Capability).
Capability Layer: Defines an abstraction layer that exposes a set
of capabilities of the I2NSF system.
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
desired state. [I-D.strassner-supa-generic-policy-info-model]
Constraint: A constraint is a limitation or restriction.
Constraints may be associated with any type of object (e.g.,
events, conditions, and actions in Policy Rules).
Constraint Programming: A type of programming that uses
constraints to define relations between variables in order to find
a feasible (and not necessarily optimal) solution.
Context: The Context of an Entity is a collection of measured and/
or inferred knowledge that describe the state and the environment
in which an Entity exists or has existed. (from
http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html)
Controller: TBD [Editorial: The definition is lacking content
("used interchangeably with Service Provider Security Controller
or management system throughout this document") and overloaded -
the two terms should be split into two separate definitions in
documents.]
Customer: A business role of an entity that is involved in the
definition and/or consumption of services, and the possible
negotiation of a contract to use services from a Provider.
DC: Data Center
Data Model: A representation of concepts of interest to an
environment in a form that is dependent on data repository, data
definition language, query language, implementation language, and
protocol (typically one or more of these )
[I-D.strassner-supa-generic-policy-info-model].
Hares, et al. Expires October 6, 2016 [Page 4]
Internet-Draft I2NSF Terminology April 2016
Event: An important occurrence in time of a change in the system
being managed, and/or in the environment of the system being
managed. Examples of an I2NSF Event include time and user actions
(e.g. logon, logoff, and actions that violate an ACL). An Event,
when used in the context of a Policy Rule, is used to determine
whether the condition clause of an imperative Policy Rule can be
evaluated or not [I-D.strassner-supa-generic-policy-info-model].
ECA: Event - Condition - Action policy (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-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 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
[I-D.strassner-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 client. It
is also responsible for enforcing the policies that it receives
from an I2NSF client.
I2NSF Capability: A set of features that are available from an NSF
server.
I2NSF client: A software component that uses the I2NSF framework
to read, write, and/or change provisioning and operational aspects
of the NSFs that it attaches to.
Hares, et al. Expires October 6, 2016 [Page 5]
Internet-Draft I2NSF Terminology April 2016
I2NSF Management System: I2NSF clients operate within a network
management system, which serves as a collection and distribution
point for I2NSF security provisioning and filters data.
I2NSF Policy: A set of rules that are used to manage and control
the changing or maintaining of the state of an NSF instance.
I2NSF Policy Rule: A policy rule that is adapted for I2NSF usage.
The I2NSF Policy Rule is assumed to be in ECA form (i.e., an
imperative structure). Other types of programming paradigms
(e.g., declarative and functional) are currently out of scope. An
example of an I2NSF Policy Rule is, in pseudo-code:
IF <event-clause> is TRUE
IF <condition-clause> is TRUE
THEN execute <action-clause>
END-IF
END-IF
In the above example, the Event, Condition, and Action portions of
a Policy Rule are all **Boolean Clauses**.
I2NSF Registry: A registry that contains I2NSF capability
information, which can be controlled by the I2NSF Management
System.
IDS: Intrusion Detection System (see below).
IPS: Intrusion Protection System (see below).
Information Model: Is a representation of concepts of interest to
an environment in a form that is independent of data repository,
data definition language, query language, implementation language,
and protocol [I-D.strassner-supa-generic-policy-info-model].
Interface: A set of operations one object knows it can invoke on,
and expose to, another object. It is a subset of all operations
that a given object implements. The same object may have multiple
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,
Hares, et al. Expires October 6, 2016 [Page 6]
Internet-Draft I2NSF Terminology April 2016
* an interface for a controller to impose policy,or retrieve the
results of execution of a policy rule.
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.
Metadata: Data that provides information about other data.
Examples include IETF network management protocols (e.g. NETCONF,
RESTCONF, IPFix) or IETF routing interfaces (I2RS). The I2NSF
security interface may utilize Metadata to describe and/or
prescribe characteristics and behavior of the YANG data models.
Middlebox: Any intermediary device performing functions other
than the normal, standard functions of an IP router on the
datagram path between a source host and destination host
[RFC3234].
Network Security Function (NSF): Software that provides a set of
security-related services. Examples include detecting unwanted
activity and blocking or mitigating the effect of such unwanted
activity in order to fulfil service requirements. The NSF can
also help in supporting communication stream integrity and
confidentiality.
OCL (Object Constraint Language): A constraint programming language
that is used to specify constraints (e.g., in UML) (from
http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html)
Policy Rule: A set of rules that are used to manage and control
the changing or maintaining of the state of one or more managed
objects. Often this is shorterned to Rule or Policy (see I2NSF
policy rule) [I-D.strassner-supa-generic-policy-info-model].
Profile: A structured representation of information that
characterizes the capabilities of an object, typically in a
specific context. This may be used to simplify how this object
interacts with other objects in its environment. [Editors note:
John Strassner suggests this is a simplified definition from a
variety of sources (UAProf and CC/PP). It does not mention the
concept of preference, therefore John wonders if we need a
different definition here.]
Registry: is a logically centralized location containing data of a
particular type; it may optionally contain metadata,
Hares, et al. Expires October 6, 2016 [Page 7]
Internet-Draft I2NSF Terminology April 2016
relationships, and other aspects of the registered data in order
to use those data effectively. An I2NSF registry is used to
contain capability information that can be controlled by the
controller.
Registration Interface: An interface dedicated to requesting,
receiving, editing, and deleting information in a Registry.
Service Layer: Software that enables clients to manage security
policies for their specific flows. This is also called the
Client-Facing Interface.
Service Provider Security Controller: TBD (Editorial: Place holder
for a split between controller and security controller
definitions.)
Tenant: A group of users that share common access privileges to
the same software. An I2NSF tenant may be physical or virtual,
and may run on a variety of systems or servers.
Vendor Facing Interface: This enables vendors to register their
NSFs, along with the capabilities of their NSFs, with a logically
centralized authority.
Virtual NSF: An NSF that is deployed as a distributed virtual
device.
Virtual Network Function (VNF): A virtualized network component,
such as a router, switch, security box, or AAA Servier.
VNFM (VNF Manager): Manager of virtual network functions that
creates, deletes, manages, and moves VNFs.
VNFPool: A collection of interchangeable VNFs (i.e., each VNF has
the same set of capabilities).
Virtualization: Virtualization is a type of software that creates
a non-physical version of an object. Examples include virtualized
operating systems, storagte devices, and networking elements.
[Editor's notes: Questions from John: Do we want or need to
differentiate between different tyeps of virtualization? For
example: full vs. partial vs. para-virtualization (all types of
"hardware virtualization")? Do we need to introduce OS
virtualization? What about application virtualization?]
Hares, et al. Expires October 6, 2016 [Page 8]
Internet-Draft I2NSF Terminology April 2016
3. IANA Considerations
No IANA considerations exist for this document.
4. Security Considerations
This is a terminology document with no security considerations.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
5.2. 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-00
(work in progress), February 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-00 (work in progress),
February 2016.
[I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-06 (work in progress),
December 2015.
[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.strassner-supa-generic-policy-info-model]
Strassner, J., Halpern, J., and J. Coleman, "Generic
Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-strassner-supa-generic-policy-
info-model-04 (work in progress), February 2016.
Hares, et al. Expires October 6, 2016 [Page 9]
Internet-Draft I2NSF Terminology April 2016
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
October 2000, <http://www.rfc-editor.org/info/rfc2975>.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <http://www.rfc-editor.org/info/rfc3198>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003,
<http://www.rfc-editor.org/info/rfc3539>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
Authors' Addresses
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Phone: +1-734-604-0332
Email: shares@ndzh.com
John Strassner
Huawei
Santa Clara, CA
USA
Email: John.Strassner@huawei.com
Hares, et al. Expires October 6, 2016 [Page 10]
Internet-Draft I2NSF Terminology April 2016
Diego R. Lopex
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
Hares, et al. Expires October 6, 2016 [Page 11]
