One document matched: draft-hares-i2nsf-terminology-01.xml


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2975.xml">
<!ENTITY RFC3198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3198.xml">
<!ENTITY RFC3234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC3539 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3539.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC7297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7277.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-acl-model-06.xml">
<!ENTITY I-D.ietf-opsawg-firewalls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-opsawg-firewalls-01.xml">
<!ENTITY I-D.ietf-i2nsf-gap-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2nsf-gap-analysis-00.xml">
<!ENTITY I-D.ietf-i2nsf-problem-and-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2nsf-problem-and-use-cases-00.xml"> 
<!ENTITY I-D.strassner-supa-generic-policy-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-strassner-supa-generic-policy-info-model-04.xml"> 
]>
 
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="info" docName="draft-hares-i2nsf-terminology-01.txt" ipr="trust200902">
<front>
<title abbrev="I2NSF Terminology">Interface to Network Security Functions (I2NSF) Terminolgoy </title>
	  <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <postal> 
          <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
		<phone>+1-734-604-0332</phone>
        <email>shares@ndzh.com</email>
		</address>
	  </author>
	 <author fullname="John Strassner" initials="J." surname="Strassner">
      <organization>Huawei</organization>
      <address>
        <postal> 
          <street> </street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code></code>
          <country>USA</country>
        </postal>
	  	<phone> </phone>
        <email>John.Strassner@huawei.com </email>
	    </address>
	  </author>
	 <author fullname="Diego R. Lopex" initials="D" surname="Lopez">
      <organization>Telefonica I+D</organization>
      <address>
	    <postal> 
		<street>Don Ramon de la Cruz, 82</street>
		<city>Madrid</city>
		<code>28006</code> 
		<country>Spain</country>
		</postal>
        <email>diego.r.lopez@telefonica.com</email>
      </address>
    </author>
	<author fullname="Liang Xia (Frank)" initials="L." surname="Xia">
      <organization>Huawei</organization>
      <address>
	      <postal> 
          <street>101 Software Avenue, Yuhuatai District</street>
          <city>Nanjing </city>
          <region>Jiangsu </region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>Frank.Xialiang@huawei.com</email>
      </address>
    </author>

<date year="2016" />
   <area>Security Area</area>
   <workgroup>I2NSF</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>I2NSF</keyword>
<abstract>
	 <t> This document defines a set of terms that 
	 are used for the Interface to Network Security Functions (I2NSF) effort.    
   </t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
 This document defines a set of terms that are used for the Interface to
 Security Functions(I2NSF) effort.  This section provides some background on 
 I2NSF, but a detailed problem statement can be found in 
 <xref target="I-D.ietf-i2nsf-problem-and-use-cases"></xref>
</t> 
<t>The purposeof the document is to unify the terminology used among all
the I2NSF documents. 
</t>
<t> 
   Enterprises are now considering using network security functions
  (NSFs) hosted by service providers due to the growing challenges and complexity in maintaining a secure infrastructure, 
  complying 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. 
</t>
<t>
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. 
 The Network security functions (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.  
</t>
<t>It is out of scope of this document to define exhaustive 
lists of terms that are used in the security field in general; 
the reader is invited to refer to other documents such as 
<xref target="RFC4949"></xref>.  <xref target="RFC4949"></xref>
provides an excellent terminology glossary for the Internet Security Area
 is in <xref target="RFC4949"></xref>.
 </t>
 <t>The reader may also refer to <xref target="RFC3198"></xref>
for a terminology document on policies (e.g., policy abstraction)
 and Policy-Based Management. The wise reader will have these 
 documents at hand while using this terminology guide for I2NSF
 to provide additional answers. 
</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="AAA: Authentication, Authorization, and Accounting. See individual
   definitions. "></t>
   
<t hangText="Abstraction: ">The definition of 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. </t> 
 
<t hangText="Accounting: ">The act of collecting information on 
resource usage for the purpose of trend analysis, auditing, billing, or cost
allocation (<xref target="RFC2975"></xref> <xref target="RFC3539"></xref>
 </t> 
<t hangText="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 <xref target="RFC4949"></xref>.  
</t>
<t hangText="Acess Control List (ACL): "> 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
	  <xref target="RFC4949"></xref>.
</t>
<t hangText="Action:  ">Defines what is to be done when a set of conditions are met
 (See I2NSF Action).
   (from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>) 
 </t>  
<t hangText="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) <xref target="RFC3539"></xref>.
 </t> 
<t hangText="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 
<xref target="RFC3539"></xref>.
 </t> 
<t hangText="Bespoke: ">Something made to fit a particular person, 
client or company. </t>
<t hangText="Bespoke security management: ">Security management systems which are make to 
   fit a particular customer. </t>
<t hangText="Boolean Clause:  ">A logical statement that evaluates to either TRUE
or FALSE. Also called Boolean Expression.</t>

<t hangText="Capabilities: ">Defines a set of features that are available 
from a managed entity. (See also I2NSF Capability.)  </t>   
<t hangText="Capability Layer: "> Defines an abstraction layer that 
  exposes a set of capabilities of the I2NSF system. 
  </t>    
<t hangText="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. 
   (from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>) </t>
   
<t hangText="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). </t>
<t hangText="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.
</t>

<t hangText="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)
   </t>
 
 <t hangText="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.]  </t>  

 <t hangText="Customer: ">A business role of an entity that is involved 
 in the definition, consumption of services, and the possible 
 negotiation of a contract to use services from a Provider.
</t>   
   
 <t hangText="Data Model: ">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 ).
   (from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>).
   [Editorial: this is This definition is different from that of RFC3198. 
   See the referenced draft for specifics. ]
   </t>
 <t hangText="Event:  ">An Event is defined as any 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, traffic profile, 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.
   (from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>).
   </t>
   
<t hangText="ECA:  ">Event - Condition - Action policy. 
</t> 

<t hangText="Firewall (FW):  ">Refers to 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) <xref target="RFC4949"></xref>.
	  See also <xref target="I-D.ietf-opsawg-firewalls"></xref>.
</t>

<t hangText="Flow-based NSF:  ">A NSF that inspects network flows according to 
      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 (MAC rewrites, TTL decrement action, or NAT
      inspection or changes). </t>
	  

<t hangText="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.
       (see <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>).
	  </t>
	  
<t hangText="I2NSF Capability:  ">Defines a set of features 
that are available from an NSF server.
</t>

<t hangText="I2NSF server:  ">A software instance that implements a
      network security function that 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  </t>

<t hangText="I2NSF client:  ">A software component that follows 
      the I2NSF framework to read, write or change provisioning 
	  and operational aspects for the NSFs it attaches to.
      </t>

<t hangText="I2NSF Management System: ">I2NSF client operates within a network
      management system, which serves as a collection and distribution
      point for I2NSF security provisioning and filtering of data.  </t> 
	  
	  
<t hangText="I2NSF Policy:  ">A set of rules that are used to manage and 
   control the changing or maintaining of the state of an NSF instance. 
   </t> 

<t hangText="I2NSF Policy Rule:  ">A policy rule that is adapted for
 I2NSF.  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:
  <list>
  <t>IF <event-clause> is TRUE
  <list>
    <t>IF <condition-clause> is TRUE 
	<list>
        <t>THEN execute <action-clause></t>
	</list>
	</t>
    <t>END-IF</t>
	</list>
  </t>
  <t>  END-IF </t>
  </list>
 In the above example, the Event, Condition, and Action portions
  of a Policy Rule are all **Boolean Clauses**. 
 </t>
 
 <t hangText="I2NSF Registry:  ">A registry  
  that contains I2NSF capability
   information that can be controlled by I2NSF Management
   System. </t>
   
<t hangText="I2NSF System: ">Refers to the collection of I2NSF functional 
 elements that contribute to provide the I2NSF service.
 </t>
<t hangText="Information Model:  "> 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.    
   (from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>).
   </t> 
<t hangText="Interface:  ">Is the set of operations one object knows it can
   invoke (or expose to) on another object. It is a subset of all 
   operations that a given object implements. An example of multiple
   interfaces can be seen by considering the interfaces include a firewall 
   uses.   A firewall can have: multiple interfaces for 
   data packets to traverse through and 
   an interface for a controller to impose policy, or 
   retrieve the results of execution of a policy rule.
   The same object may have multiple types
    of interfaces to serve different (functional) purposes.   
  </t>
 
 
<t hangText="Intrusion Detection System (IDS):  ">A system which detects
    network intrusions via a variety of filters, monitors, and/or probes. 
	An IDS may be stateful or stateless.   
</t>
	 
<t hangText="Intrusion Protection System (IPS):  ">A system that 
    protect against network intrusions.  An IPS may be stateful or 
	stateless. 
</t>

<t hangText="Metadata:  ">Data that provides information about other data. 
   IETF network management protocols (e.g. NETCONF/RESTCONF/IPFix) or 
   IETF routing interfaces (I2RS), and the I2NSF security interface 
   may each utilize Metadata to describe and/or prescribe characteristics 
   and behavior of the YANG data models.
</t>
   
<t hangText=" Middlebox:  ">Is defined as 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 <xref target="RFC3234"></xref>.
  </t>

<t hangText="Network security function (NSF):  ">Is a function that is
      provided as set of security-related service function. Typically, 
	  an NSF may be responsible for detecting unwanted activity 
	  and blocking/mitigating the effect of such
      unwanted activity in order to fulfil the service requirements.
      The NSF can help in supporting communication stream
      integrity and confidentiality. 
</t>

	  
<t hangText="OCL (the Object Constraint Language) ">A constraint 
programming language that is used to specify constraints in UML.  
is used to specify constraints in UML.  (from http://www.ietf.org/mail-
      archive/web/i2nsf/current/msg00762.html)
</t>

<t hangText="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.
(from <xref target="I-D.strassner-supa-generic-policy-info-model"></xref>).
 An 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.
  For the complete definition of an I2NSF Policy Rule please see above. 
  (see above I2NSF policy rule).
</t>

<t hangText="Profile:  "> A structured representation of information 
   that characterizes the capabilities of an objectin a given context. 
   This may be used to simplify how this
   object interacts with other objects in its environment.
   [Editors note: John Strassner suggestse 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.] 
    </t>

<t hangText="Registry: ">A logically centralized location containing data of a
   particular type; it may optionally contain metadata, 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.   </t>

<t hangText="Registration Interface:  ">An interface dedicated to requesting, receiving, editing, and
   deleting information in a registry. </t>
   
   
   
<t hangText="Service Layer:  ">The Service Layer 
(also called Client-Facing Interface) enables 
   clients to manage security policies for their specific flows.
   [Editorial: Med suggest picking on eterm. ]
</t>

<t hangText="Service Provider Security Controller:  ">TBD
(Editorial: Place holder for a split between controller and security 
controller definition.)
</t>
 
  
<t hangText="Tenant:  ">A tenant is 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. 
</t>

<t hangText="Vendor Facing Interface: ">The Vendor Facing Interface enables vendors to register their NSFs,
   along with the capabilities of their NSFs, with a logically
   centralized authority. 
</t>

<t hangText="Editorial note on all Virtual functions:  "> [MED] suggests 
removing virtual as the I2NSF does not 
make any assumptions about how things are created. 
Since this is a larger question - this section is left in 
with MED's note. 
</t> 

 <t hangText="Virtual NSF:  ">A NSF that is deployed as a distributed 
virtual device.  
</t>

<t hangText="Virtual Network Function (VNF):  ">A virtualized network component
 such as a router, switch, security box, or AAA Servier. 
</t>

<t hangText=" VNFM (VNF Manager):  ">Manager of virtual network functions
that creates, deletes, manages, and moves VNFs.</t>

<t hangText="VNFPool:  ">A collection of interchangeable VNFs 
(i.e., each VNF has the same set of capabilities).</t>


<t hangText="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.
[Editoris 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?]
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
      <t>No IANA considerations exist for this document. </t>
    </section>
 <section title="Security Considerations">
<t>
This is a terminology document with no security considerations. 
</t>
</section>
</middle>
<back>
 <references title="Informative References">
      &RFC2119;
      &RFC2975;
      &RFC3198;
	  &RFC3234;
	  &RFC3539;
	  &RFC4949;
      &RFC7297;   
	  &I-D.ietf-netmod-acl-model;
	  &I-D.ietf-opsawg-firewalls;
      &I-D.ietf-i2nsf-problem-and-use-cases;
  	  &I-D.ietf-i2nsf-gap-analysis;
	  &I-D.strassner-supa-generic-policy-info-model;
 
 	  </references>
</back>
</rfc>

PAFTECH AB 2003-20262026-04-24 04:25:17