draft-ietf-i2nsf-terminology-03.txt   draft-ietf-i2nsf-terminology-04.txt 
I2NSF S. Hares I2NSF S. Hares
Internet-Draft J. Strassner Internet-Draft J. Strassner
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: September 07, 2017 D. Lopez Expires: January 07, 2018 D. Lopez
Telefonica I+D Telefonica I+D
L. Xia L. Xia
Huawei Huawei
H. Birkholz H. Birkholz
Fraunhofer SIT Fraunhofer SIT
March 07, 2017 July 03, 2017
Interface to Network Security Functions (I2NSF) Terminology Interface to Network Security Functions (I2NSF) Terminology
draft-ietf-i2nsf-terminology-03.txt draft-ietf-i2nsf-terminology-04.txt
Abstract Abstract
This document defines a set of terms that are used for the Interface This document defines a set of terms that are used for the Interface
to Network Security Functions (I2NSF) effort. to Network Security Functions (I2NSF) effort.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on September 07, 2017. This Internet-Draft will expire on January 07, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Informative References . . . . . . . . . . . . . . . . . 11 6.1. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document defines the terminology for the Interface to Network This document defines the terminology for the Interface to Network
Security Functions (I2NSF) effort. This section provides some Security Functions (I2NSF) effort. This section provides some
background on I2NSF; a detailed problem statement can be found in background on I2NSF; a detailed problem statement can be found in
[I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to
previous work can be found in [I-D.ietf-i2nsf-gap-analysis]. previous work can be found in [I-D.ietf-i2nsf-gap-analysis].
Enterprises are now considering using network security functions Enterprises are now considering using network security functions
skipping to change at page 3, line 28 skipping to change at page 3, line 28
Abstraction: The definition of the salient characteristics and Abstraction: The definition of the salient characteristics and
behavior of an object that distinguish it from all other types of behavior of an object that distinguish it from all other types of
objects. It manages complexity by exposing common properties objects. It manages complexity by exposing common properties
between objects and processes while hiding detail that is not between objects and processes while hiding detail that is not
relevant. relevant.
Access Control: Protection of system resources against unauthorized Access Control: Protection of system resources against unauthorized
access; a process by which use of system resources is regulated access; a process by which use of system resources is regulated
according to a security policy, and is permitted by only according to a security policy, and is permitted by only
authorized entities (users, programs, processes, or other systems) authorized entities (e.g., users, programs, processes, or other
according to that policy [RFC4949]. systems) according to that policy [RFC4949].
Access Control List (ACL): This is a mechanism that implements Access Control List (ACL): This is a mechanism that implements
access control for a system resource by enumerating the system access control for a system resource by enumerating the system
entities that are permitted to access the resource and stating, entities that are permitted to access the resource and stating,
either implicitly or explicitly, the access modes granted to each either implicitly or explicitly, the access modes granted to each
entity [RFC4949]. A YANG description is defined in entity [RFC4949]. A YANG description is defined in
[I-D.ietf-netmod-acl-model]. [I-D.ietf-netmod-acl-model].
Accounting: The act of collecting information on resource usage for Accounting: The act of collecting information on resource usage for
the purpose of trend analysis, auditing, billing, or cost the purpose of trend analysis, auditing, billing, or cost
allocation ([RFC2975] [RFC3539]). allocation ([RFC2975] [RFC3539]).
Assertion: Defined by the ITU in [X.1252] as "a statement made by Assertion: Defined by the ITU in [X.1252] as "a statement made by
an entity without accompanying evidence of its validity". In the an entity without accompanying evidence of its validity". In the
context of I2NSF, an assertion MAY include metadata about all or context of I2NSF, an assertion may include metadata about all or
part of the assertion (e.g., context of the assertion, or about part of the assertion (e.g., context of the assertion, or about
timestamp indicating the point in time the assertion was timestamp indicating the point in time the assertion was
created). The validity of an assertion cannot be verified. created). The validity of an assertion cannot be verified.
(from [I-D.ietf-sacm-terminology]). (from [I-D.ietf-sacm-terminology]).
Attestation: The process of validating the integrity of a computing Attestation: The process of validating the integrity of a computing
device. See also Direct Anonymous Attestation. device. See also Direct Anonymous Attestation, Remote Attestation.
Authentication: Defined in [RFC4949] as "the process of verifying Authentication: Defined in [RFC4949] as "the process of verifying
a claim that a system entity or system resource has a certain a claim that a system entity or system resource has a certain
attribute value." (from [I-D.ietf-sacm-terminology]). attribute value." (from [I-D.ietf-sacm-terminology]).
Authorization: Defined in [RFC4949] as "an approval that is granted Authorization: Defined in [RFC4949] as "an approval that is granted
to a system entity to access a system resource." to a system entity to access a system resource."
(from [I-D.ietf-sacm-terminology]). (from [I-D.ietf-sacm-terminology]).
Business-to-Business (B2B). A type of transaction in which one Business-to-Business (B2B). A type of transaction in which one
skipping to change at page 4, line 30 skipping to change at page 4, line 30
company. company.
Bespoke security management: Security management systems that are Bespoke security management: Security management systems that are
made to fit a particular customer. made to fit a particular customer.
Boolean Clause: A logical statement that evaluates to either TRUE Boolean Clause: A logical statement that evaluates to either TRUE
or FALSE. Also called Boolean Expression. or FALSE. Also called Boolean Expression.
Capability: A set of features that are available from an I2NSF Capability: A set of features that are available from an I2NSF
Component. These functions may, but do not have to, be used. All Component. These functions may, but do not have to, be used. All
Capabilities are announced through the I2NSF Registration Capabilities are announced using the I2NSF Registration
Interface. Examples are Capabilities that are available from an Interface.
NSF Server.
Client: See I2NSF Consumer.
Client-Facing Interface: See I2NSF Consumer-Facing Interface.
Component: An encapsulation of software that communicates using Component: An encapsulation of software that communicates using
Interfaces. A Component may be implemented by hardware and/or Interfaces. A Component may be implemented by hardware and/or
software, and be represented using a set of classes. In general, software, and be represented using a set of classes. In general,
a Component encapsulates a set of data structures and a set of a Component encapsulates a set of data structures and a set of
algorithms that implement the function(s) that it provides. algorithms that implement the function(s) that it provides.
Constraint: A Constraint is a limitation or restriction. Constraint: A Constraint is a limitation or restriction.
Constraints may be associated with any type of object (e.g., Constraints may be associated with any type of object (e.g.,
Events, Conditions, and Actions in Policy Rules). Events, Conditions, and Actions in Policy Rules).
skipping to change at page 5, line 48 skipping to change at page 5, line 43
Data Integrity: Defined in [RFC4949] as "the property that data has Data Integrity: Defined in [RFC4949] as "the property that data has
not been changed, destroyed, or lost in an unauthorized or not been changed, destroyed, or lost in an unauthorized or
accidental manner." accidental manner."
Data Model: A representation of concepts of interest to an Data Model: A representation of concepts of interest to an
environment in a form that is dependent on data repository, data environment in a form that is dependent on data repository, data
definition language, query language, implementation language, and definition language, query language, implementation language, and
protocol (typically one or more of these ). Note the difference protocol (typically one or more of these ). Note the difference
between a data **model** and a data **structure**. between a data **model** and a data **structure**.
[I-D.ietf-supa-generic-policy-info-model]. [I-D.ietf-supa-generic-policy-data-model].
Data Plane: In the context of I2NSF, the Data Plane is an Data Plane: In the context of I2NSF, the Data Plane is an
architectural Component that provides operational functions to architectural Component that provides operational functions to
enable an I2NSF Component to provide and consume packets and enable an I2NSF Component to provide and consume packets and
flows. See also: Control Plane, Management Plane. flows. See also: Control Plane, Management Plane.
Data Provenance: A historical record of the sources, origins and Data Provenance: A historical record of the sources, origins and
evolution of data that is influenced by inputs, entities, evolution of data that is influenced by inputs, entities,
functions and processes. functions and processes.
Data Structure: A low-level building block that is used in Data Structure: A low-level building block that is used in
programming to implement an algorithm. A data model typically programming to implement an algorithm. It defines how data is
contains multiple types of data structures; however, a data organized. A data model typically contains multiple types of
structure does not contain a data model. Note the difference data structures; however, a data structure does not contain a
between a data **model** and a data **structure**. data model. Note the difference between a data **model** and a
data **structure**.
Domain: A collection of Entities that share a common purpose. In
addition, each constituent Entity in a Domain is both uniquely
addressable and uniquely identifiable within that Domain.
Direct Anonymous Attestation (DAA): A cryptographic primitive that Direct Anonymous Attestation (DAA): A cryptographic primitive that
enables remote authentication of a trusted computer without enables remote authentication of a trusted computer without
compromising the privacy of that computer's user(s). See also compromising the privacy of that computer's user(s). See also
attestation. attestation, remote attestation.
Firewall (FW): A function that restricts data communication traffic Firewall (FW): A function that restricts data communication traffic
to and from one of the connected networks (the one said to be to and from one of the connected networks (the one said to be
'inside' the firewall), and thus protects that network's system 'inside' the firewall), and thus protects that network's system
resources against threats from the other network (the one that resources against threats from the other network (the one that
is said to be 'outside' the firewall) [RFC4949]. is said to be 'outside' the firewall) [RFC4949].
[I-D.ietf-opsawg-firewalls] [I-D.ietf-opsawg-firewalls]
Flow: A set of information (e.g., packets) that are related in a 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 fundamental manner (e.g., sent from the same source and sent to
skipping to change at page 7, line 43 skipping to change at page 7, line 43
I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF
Component that contains functions to provide information to other Component that contains functions to provide information to other
I2NSF Components. Examples include providing I2NSF Policy Rules I2NSF Components. Examples include providing I2NSF Policy Rules
to other I2NSF Components. See also: I2NSF Consumer-Facing to other I2NSF Components. See also: I2NSF Consumer-Facing
Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role. Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role.
I2NSF Consumer-Facing Interface: An Interface dedicated to I2NSF Consumer-Facing Interface: An Interface dedicated to
requesting information from I2NSF Producers. This is typically requesting information from I2NSF Producers. This is typically
defined per I2NSF administrative domain. For example, this defined per I2NSF administrative domain. For example, this
Interface could be used to request a set of I2NSF Flow Security Interface could be used to request a set of I2NSF Flow Security
Policy Rules from an I2NSF Controller, or from one or more Policy Rules from a Controller, or from one or more
individual NSFs. See also: I2NSF Consumer, I2NSF Provider, I2NSF individual NSFs. See also: I2NSF Consumer, I2NSF Provider,
NSF-Facing Interface, Interface. I2NSF NSF-Facing Interface, Interface.
I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is
said to be directly consummable if a network device can execute said to be directly consummable if a network device can execute
it without translating its content or structure. See also I2NSF it without translating its content or structure. See also I2NSF
Indirectly Consummable Policy Rule, I2NSF Policy Rule. Indirectly Consummable Policy Rule, I2NSF Policy Rule.
I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is
said to be indirectly consummable if a network device can NOT said to be indirectly consummable if a network device can NOT
execute it without first translating its content or structure. See execute it without first translating its content or structure. See
also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule. also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
be evaluated or not. Examples of an I2NSF Event include time and be evaluated or not. Examples of an I2NSF Event include time and
user actions (e.g. logon, logoff, and actions that violate an user actions (e.g. logon, logoff, and actions that violate an
ACL). (based on [I-D.ietf-supa-generic-policy-info-model]). ACL). (based on [I-D.ietf-supa-generic-policy-info-model]).
See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule. See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule.
I2NSF Management System: I2NSF Consumers and Producers operate I2NSF Management System: I2NSF Consumers and Producers operate
within the scope of a network management system, which serves as within the scope of a network management system, which serves as
a collection and distribution point for I2NSF security a collection and distribution point for I2NSF security
provisioning, monitoring, and other operations. provisioning, monitoring, and other operations.
I2NSF NSF-Facing Interface: An Interface dedicated to providing I2NSF
Services. For example, this could provide Anti-Virus, (D)DoS, or
IPS Services. This is also called the "NSF-Facing Interface".
See also: Interface, I2NSF Consumer Interface.
I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement
that is used as a means to monitor and control the changing and/or that is used as a means to monitor and control the changing and/or
maintaining of the state of one or more managed objects. It maintaining of the state of one or more managed objects. It
consists of three Boolean clauses (Event, Condition, and Action). consists of three Boolean clauses (Event, Condition, and Action).
In this context, "manage" means that one or more of the following In this context, "manage" means that one or more of the following
six fundamental operations are supported: create, read, write, six fundamental operations are supported: create, read, write,
delete, start, and stop). Note that for this release of I2NSF, delete, start, and stop). Note that for this release of I2NSF,
only imperative policy rules are in scope. An example of an I2NSF only imperative policy rules are in scope. An example of an I2NSF
Policy Rule is, in pseudo-code: Policy Rule is, in pseudo-code:
IF <event-clause> is TRUE IF <event-clause> is TRUE
IF <condition-clause> is TRUE IF <condition-clause> is TRUE
THEN execute <action-clause> THEN execute <action-clause>
END-IF END-IF
END-IF END-IF
This is based on [I-D.draft-ietf-supa-generic-policy-info-model]. This is based on [I-D.ietf-supa-generic-policy-info-model].
I2NSF Producer: A Producer is a Role that is assigned to an I2NSF I2NSF Producer: A Producer is a Role that is assigned to an I2NSF
Component that contains functions to send information and/or Component that contains functions to send information and/or
commands to another I2NSF Component (e.g., for describing, commands to another I2NSF Component (e.g., for describing,
communicating, and/or executing policies, or for transmitting communicating, and/or executing policies, or for transmitting
data). See also: I2NSF Consumer, I2NSF Consumer-Facing Interface, data). See also: I2NSF Consumer, I2NSF Consumer-Facing Interface,
I2NSF Producer, I2NSF Producer-Facing Interface, Role. I2NSF Producer, I2NSF Producer-Facing Interface, Role.
I2NSF Producer-Facing Interface: See NSF-Facing Interface.
I2NSF Registry: A repository where I2NSF data and metadata I2NSF Registry: A repository where I2NSF data and metadata
information are stored and maintained. I2NSF Components can information are stored and maintained. I2NSF Components can
connect to the I2NSF Registry using the I2NSF Registration connect to the I2NSF Registry using the I2NSF Registration
Interface; the actions that an I2NSF Component can performing Interface; the actions that an I2NSF Component can performing
SHOULD be defined using an Access Control mechanism. Examples SHOULD be defined using an Access Control mechanism. Examples
of information that SHOULD be registered include Capability data, of information that SHOULD be registered include Capability data,
as well as consistent defintions of data and I2NSF Components. as well as consistent defintions of data and I2NSF Components.
See also: Access Control, I2NSF Component, I2NSF Consumer, See also: Access Control, I2NSF Component, I2NSF Consumer,
I2NSF Provider, I2NSF Registration Interface. I2NSF Provider, I2NSF Registration Interface.
skipping to change at page 9, line 17 skipping to change at page 9, line 27
I2NSF Components. See also: I2NSF Component, I2NSF Consumer, I2NSF Components. See also: I2NSF Component, I2NSF Consumer,
I2NSF Provider, I2NSF Registry. I2NSF Provider, I2NSF Registry.
I2NSF Service: A set of functions, provided by an I2NSF Component, I2NSF Service: A set of functions, provided by an I2NSF Component,
which provides data communication, processing, storage, which provides data communication, processing, storage,
presentation, maniuplation, or other functions that can be presentation, maniuplation, or other functions that can be
consumed by I2NSF Components. Exemplary I2NSF Services include consumed by I2NSF Components. Exemplary I2NSF Services include
Anti-Virus, Authentication, Authorization, Firewall, and IPS Anti-Virus, Authentication, Authorization, Firewall, and IPS
Services. See also: I2NSF Component, Interface. Services. See also: I2NSF Component, Interface.
IDS: Intrusion Detection System (see below).
IPS: Intrusion Protection System (see below).
Information Model: A representation of concepts of interest to an Information Model: A representation of concepts of interest to an
environment in a form that is independent of data repository, environment in a form that is independent of data repository,
data definition language, query language, implementation language, data definition language, query language, implementation language,
and protocol. See also: Data Model. and protocol. See also: Data Model.
(from [I-D.ietf-supa-generic-policy-info-model]). (from [I-D.ietf-supa-generic-policy-info-model]).
Interface: A set of operations one object knows it can invoke on, Interface: A set of operations one object knows it can invoke on,
and expose to, another object. It is a subset of all operations and expose to, another object. It is a subset of all operations
that a given object implements. The same object may have multiple that a given object implements. The same object may have multiple
types of interfaces to serve different purposes. types of interfaces to serve different purposes.
skipping to change at page 9, line 46 skipping to change at page 10, line 5
See also: Interface. See also: Interface.
Intrusion Detection System (IDS): A system that detects network Intrusion Detection System (IDS): A system that detects network
intrusions via a variety of filters, monitors, and/or probes. An intrusions via a variety of filters, monitors, and/or probes. An
IDS may be stateful or stateless. See also: IPS. IDS may be stateful or stateless. See also: IPS.
Intrusion Protection System (IPS): A system that protects against Intrusion Protection System (IPS): A system that protects against
network intrusions. An IPS may be stateful or stateless. network intrusions. An IPS may be stateful or stateless.
See also: IDS. See also: IDS.
Management Domain: A collection Entities that share a common
purpose, which has the following three behavioral features:
1) a set of administrators are assigned to govern the Entities
that are contained in a Management Domain
2) a set of application are defined that are responsible for
executing one or more governance operations
3) a set of management mechanisms, such as Policy Rules, are
defined to govern the behavior of the Entities contained
in the Mangement Domain.
Management Plane: In the context of I2NSF, the Management Plane is Management Plane: In the context of I2NSF, the Management Plane is
an architectural Component that provides common functions to an architectural Component that provides common functions to
define the behavior of I2NSF Components. The primary use of the define the behavior of I2NSF Components. The primary use of the
Management Plane is to transport behavioral commands, and supply Management Plane is to formulate behavioral commands and forward
OAM data, for making decisions that affect behavior. Examples them to the Control Plane. The Control Plane then translates them
include modifying the configuration of an I2NSF Component and into a form that can be consumed by I2NSF components. The
transporting OAM data. See also: Control Plane, Data Plane. Management Plane may also instantiate and manage I2NSF Policy
Rules. The Management Plane is also responsible for handling and
acting on OAM data, which may influence the decision-making
processes in the I2NSF Control Plane and other I2NSF Components.
See also: Control Plane, Data Plane.
Metadata: Data that provides information about other data. Metadata: Data that provides information about other data.
Examples include IETF network management protocols (e.g. NETCONF, Examples include IETF network management protocols (e.g. NETCONF,
RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF
security interface may utilize Metadata to describe and/or security interface may utilize Metadata to describe and/or
prescribe characteristics and behavior of the YANG data models. prescribe characteristics and behavior of the YANG data models.
Middlebox: Any intermediary device performing functions other Middlebox: Any intermediary device performing functions other
than the normal, standard functions of an IP router on the than the normal, standard functions of an IP router on the
datagram path between a source host and destination host datagram path between a source host and destination host
skipping to change at page 10, line 39 skipping to change at page 11, line 11
Object Constraint Language (OCL): A constraint programming language Object Constraint Language (OCL): A constraint programming language
that is used to specify restrictions on functionality. (from that is used to specify restrictions on functionality. (from
http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html)
Profile: A structured representation of information that uses a Profile: A structured representation of information that uses a
pre-defined set of capabilities of an object, typically in a pre-defined set of capabilities of an object, typically in a
specific context. Zero or more Capabilities may be changed at specific context. Zero or more Capabilities may be changed at
runtime. This may be used to simplify how this object interacts runtime. This may be used to simplify how this object interacts
with other objects in its environment. with other objects in its environment.
Remote Attestation: A functoin that enables changes to an Entity to
be detected by authorized parties (e.g., applications or users).
Direct Anonymous Attestation preserves the privacy of the user,
whereas remote attestation may not. See also: Attestation,
Direct Anonymous Attestation.
Role: An abstraction of a Component that models context-specific Role: An abstraction of a Component that models context-specific
views and responsibilities of an object as separate Role objects. views and responsibilities of an object as separate Role objects.
Role objects can optionally be attached to, and removed from, the Role objects can optionally be attached to, and removed from, the
object that the Role object describes at runtime. This provides object that the Role object describes at runtime. This provides
three important benefits. First, it enables different behavior three important benefits. First, it enables different behavior
to be supported by the same Component for different contexts. to be supported by the same Component for different contexts.
Second, it enables the behavior of a Component to be adjusted Second, it enables the behavior of a Component to be adjusted
dynamically (i.e., at runtime, in response to changes in context) dynamically (i.e., at runtime, in response to changes in context)
by using one or more Roles to define the behavior desired for by using one or more Roles to define the behavior desired for
each context. Third, it decouples the Roles of a Component from each context. Third, it decouples the Roles of a Component from
skipping to change at page 11, line 18 skipping to change at page 11, line 46
4. Security Considerations 4. Security Considerations
This is a terminology document with no security considerations. This is a terminology document with no security considerations.
5. Contributors 5. Contributors
The following people contributed to creating this document, and are The following people contributed to creating this document, and are
listed in alphabetical order: listed in alphabetical order:
Adrian Farrel, Linda Dunbar Adrian Farrel, Christian Jacquenet, Linda Dunbar,
Mohammed Boucadair
6. References 6. References
6.1. Informative References 6.1. Informative References
[I-D.ietf-i2nsf-gap-analysis] [I-D.ietf-i2nsf-gap-analysis]
Hares, S., Moskowitz, R., and Zhang, D., "Analysis of Hares, S., Moskowitz, R., and Zhang, D., "Analysis of
Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03
(work in progress), March 2017. (work in progress), March 2017.
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
Jacquenet, "I2NSF Problem Statement and Use cases", draft- Jacquenet, "I2NSF Problem Statement and Use cases", draft-
skipping to change at page 11, line 32 skipping to change at page 12, line 14
6.1. Informative References 6.1. Informative References
[I-D.ietf-i2nsf-gap-analysis] [I-D.ietf-i2nsf-gap-analysis]
Hares, S., Moskowitz, R., and Zhang, D., "Analysis of Hares, S., Moskowitz, R., and Zhang, D., "Analysis of
Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03
(work in progress), March 2017. (work in progress), March 2017.
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
Jacquenet, "I2NSF Problem Statement and Use cases", draft- Jacquenet, "I2NSF Problem Statement and Use cases", draft-
ietf-i2nsf-problem-and-use-cases-09 (work in progress), ietf-i2nsf-problem-and-use-cases-16 (work in progress),
February 2017. May 2017.
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D.,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-09 (work in progress), draft-ietf-netmod-acl-model-11 (work in progress),
February 2017. June 2017.
[I-D.ietf-opsawg-firewalls] [I-D.ietf-opsawg-firewalls]
Baker, F. and P. Hoffman, "On Firewalls in Internet Baker, F. and P. Hoffman, "On Firewalls in Internet
Security", draft-ietf-opsawg-firewalls-01 (work in Security", draft-ietf-opsawg-firewalls-01 (work in
progress), October 2012. progress), October 2012.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N.,
"Secure Automation and Continuous Monitoring (SACM) "Secure Automation and Continuous Monitoring (SACM)
Terminology", draft-ietf-sacm-terminology-11, Terminology", draft-ietf-sacm-terminology-12,
September 2016 March 2017
[I-D.ietf-supa-generic-policy-data-model]
Strassner, J., Halpern, J., and S. van der Meer, "Generic
Policy Data Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-
data-model-04 (work in progress), June 2017.
[I-D.ietf-supa-generic-policy-info-model] [I-D.ietf-supa-generic-policy-info-model]
Strassner, J., Halpern, J., and J. Coleman, "Generic Strassner, J., Halpern, J., and S. van der Meer, "Generic
Policy Information Model for Simplified Use of Policy Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy- Abstractions (SUPA)", draft-ietf-supa-generic-policy-
info-model-02 (work in progress), January 2017. info-model-03 (work in progress), May 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, DOI 10.17487/RFC2975, Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
October 2000, <http://www.rfc-editor.org/info/rfc2975>. October 2000, <http://www.rfc-editor.org/info/rfc2975>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
 End of changes. 28 change blocks. 
49 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/