I2NSF John Strassner
Internet Draft Liang Xia
Intended status: Standard Track Huawei
Expires: August 2015 February 10, 2015
Interface to Network Security Functions Information Model
draft-strassner-i2nfs-info-model-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 10, 2015.
Copyright Notice
Copyright (c) 2015 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
Strassner, et al. Expires August 10, 2015 [Page 1]
Internet-Draft I2NSF Information Model February 2015
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document describes an information model that defines the
salient managed entities and their relationships in an Interface to
Network Security Function (I2NSF) architecture. The information
model is independent of platform, language, and protocol, and serves
as a common consensual lexicon for the I2NFS architecture as well as
clients using this architecture. This enables multiple application-
specific data models (which are dependent on platform, language,
and/or protocol) to be built from this information model. The
advantage of doing so is to ensure that such data models will be
able to share and reuse consensually defined concepts, thereby
increasing interoperability.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 3
2.1. Acronyms ............................................... 4
2.2. Definitions ............................................ 4
2.2.1. Information Model ................................. 4
2.2.2. Data Model......................................... 5
2.2.3. Inheritance ....................................... 5
2.2.4. Relationship ...................................... 5
2.2.4.1. Association .................................. 5
2.2.4.2. Aggregation .................................. 5
2.2.4.3. Composition .................................. 5
2.2.5. Multiplicity ...................................... 6
2.3. Symbology .............................................. 6
2.3.1. Basic Symbols ..................................... 6
2.3.2. Relationship Multiplicity ......................... 6
2.3.3. Relationship Naming ............................... 7
2.3.4. Relationship Navigability ......................... 7
2.3.5. Relationships Implemented as Classes .............. 7
3. Design of the I2NSF Information Model ....................... 8
3.1. Overview ............................................... 8
3.2. I2NSF Clients ......................................... 10
3.3. Security Policy Layer ................................. 10
3.4. Context-Aware Policy Engine ........................... 10
3.5. Security Capability Layer ............................. 11
4. I2NSF Information Model Hierarchy .......................... 11
5. Usage Examples of the I2NSF Information Model .............. 11
Strassner, et al. Expires August 10, 2015 [Page 2]
Internet-Draft I2NSF Information Model February 2015
6. Security Considerations .................................... 11
7. IANA Considerations ........................................ 12
8. References ................................................. 12
8.1. Normative References .................................. 12
8.2. Informative References ................................ 12
9. Acknowledgments ............................................ 12
1. Introduction
Networks and networked applications are becoming increasingly
diverse and complex. Concurrently, operators are struggling to
deploy new services quickly, and require more powerful and robust
network management services and applications. Both of these problems
are exacerbated by the proliferation of vendor-specific devices and
data models.
While Yang offers an easier way to build data models, it lacks
several software abstractions that facilitate representing high-
level entities and relationships between such entities. UML
Information Models are the de facto method for defining entities and
relationships in a technologically-neutral manner. The use of an
information model increases interoperability by defining a common
lexicon of concepts, terms, entities, and relationships that all
clients and applications can use. Data Models created in Yang, as
well as in other technologies, can use the terms and concepts
defined in the information model to ensure that concepts defined in
different technologies can be identified and translated to each
other.
The I2NFS Information Model will define managed objects and
mechanisms to address the operational, administrative, and
management aspects of the managed objects.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Strassner, et al. Expires August 10, 2015 [Page 3]
Internet-Draft I2NSF Information Model February 2015
2.1. Acronyms
AAA - Authentication, Authorization, Accounting
ABAC - Attribute Based Access Control
I2NSF - Interface to Network Security Functions
Netconf - Network Configuration protocol
NSF - Network Security Function
OAM - Operational, Administrative, and Management
PAP - Policy Administration Point
PBAC - Policy Based Access Control
PDP - Policy Decision Point
PEP - Policy Enforcement Point
PIP - Policy Information Point
PR - Policy Repository
PXP - Policy Execution Point
RBAC - Role Based Access Control
UML - Unified Modeling Language
Yang - A data definition language for use with Netconf
2.2. Definitions
This section defines important terms that are used in this document.
2.2.1. Information Model
An information model is a representation of concepts of interest to
an environment in a form that is independent of platform, language,
and protocol.
Strassner, et al. Expires August 10, 2015 [Page 4]
Internet-Draft I2NSF Information Model February 2015
2.2.2. Data Model
A data model is a representation of concepts of interest to an
environment in a form that is dependent on platform, language,
and/or protocol (typically, but not necessarily, all three).
2.2.3. Inheritance
Inheritance makes an entity at a lower level of abstraction (e.g.,
the subclass) a type of an entity at a higher level of abstraction
(e.g., the superclass). A subclass does NOT change the
characteristics or behavior of the superclass that it inherits from.
However, a subclass MAY add new attributes and relationships that
distinguish it from the attributes and relationships defined by its
superclass.
2.2.4. Relationship
A relationship is a generic term that represents how a first set of
entities interact with a second set of entities. A recursive
relationship sets the first and second entity to the same entity.
There are three basic types of relationships, as defined in the
subsections below.
2.2.4.1. Association
An association represents a generic dependency between a first and a
second set of entities.
2.2.4.2. Aggregation
An aggregation is a stronger type (i.e., more restricted
semantically) of association, and represents a whole-part dependency
between a first and a second set of entities. In other words, three
objects are implied by an aggregation: the first entity, the second
entity, and a new third entity that represents the combination of
the first and second entities. The entity owning the aggregation is
referred to as the "aggregate", and the entity that is aggregated is
referred to as the "part".
2.2.4.3. Composition
A composition is a stronger type (i.e., more restricted semantically)
of aggregation, and represents a whole-part dependency with two
important behaviors. First, an instance of the part is included in
at most one instance of the aggregate at a time. Second, any action
performed on the composite entity (i.e., the aggregate) is
Strassner, et al. Expires August 10, 2015 [Page 5]
Internet-Draft I2NSF Information Model February 2015
propagated to its constituent part objects. For example, if the
composite entity is deleted, then all of its constituent part
entities are also deleted. This is not true of aggregations or
associations - in both, only the entity being deleted is actually
removed, and the other entities are unaffected.
2.2.5. Multiplicity
A specification of the range of allowable cardinalities that a set
of entities may assume. This is always a pair of ranges, such as 1 -
1 or 0..n - 2..5.
2.3. Symbology
In order to unambiguously represent information in this document,
ASCII art will be used. This art will use the following special
symbols.
2.3.1. Basic Symbols
Indentation: this will be used to indicate hierarchy levels
Inheritance: represented by --|> (e.g., subclass -I> superclass)
Association: represented by --A- (e.g., ClassA --A- ClassB)
Aggregation: represented by --Ag- (e.g., ClassA --Ag- ClassB)
Composition: represented by --C- (e.g., ClassA --C- ClassB)
2.3.2. Relationship Multiplicity
Relationships MUST have a specified multiplicity, and can be
represented as follows:
--------- ---------
| | 0..1 1..n | |
| Class A |---------------A-| Class B |
| | BDependsOnA | |
--------- ---------
Figure 1. Illustrating a Non-Directed Association.
Strassner, et al. Expires August 10, 2015 [Page 6]
Internet-Draft I2NSF Information Model February 2015
2.3.3. Relationship Naming
Relationships MUST be named. This is to facilitate their
implementation as named managed objects. The name SHOULD be in
InitCaps. In Figure 1, Class B depends on Class A (e.g., an event
must happen to A before B can take action).
2.3.4. Relationship Navigability
Relationships MAY indicate a constraint on which set of entities can
communicate with the other set of entities in a relationship. If
there is no such constraint, then the symbology in Section 2.3.1,
illustrated by Figure 1 in Section 2.3.2, is sufficient. Otherwise,
an arrow, denoted by the right angle character (i.e., ">"), is used.
Relationships with constraint and a specified multiplicity can be
represented as follows:
--------- ---------
| | 0..1 1..n | |
| Class A |---------------A->| Class B |
| | BDependsOnA | |
--------- ---------
Figure 2. Illustrating a Directed Association.
In this case, Entities of Class A can communicate with Class B; the
reverse is not allowed.
2.3.5. Relationships Implemented as Classes
A relationship MAY be realized as a class. This is typically called
an "association class", regardless of whether the association is an
association, an aggregation, or a composition. This is illustrated as
follows:
Strassner, et al. Expires August 10, 2015 [Page 7]
Internet-Draft I2NSF Information Model February 2015
---------
| Class C |
---------
|
AC
--------- | ---------
| | 0..1 | 1..n | |
| Class A |----------------A->| Class B |
| | BDependsOnA | |
---------- ---------
Figure 3. Illustrating an Association Class.
In Figure 3, Class C is an association class, and represents the
realization of the association named BDependsOnA. Conceptually, this
means that the relationship between Classes A and B is complex, and
requires a class to represent it. For example, class attributes MAY
be used to define how Class B depends on Class A.
3. Design of the I2NSF Information Model
This section describes the I2NSF Information Model. It first
provides an architectural overview of the main entities involved.
Then, it defines an object-oriented information model for
representing the entities and their relationships.
3.1. Overview
The operation of I2NSF may be conceptualized as shown in Figure 4.
Strassner, et al. Expires August 10, 2015 [Page 8]
Internet-Draft I2NSF Information Model February 2015
----------------- ------------
| I2NSF Clients | | Info Model |<--------+
----------------- ------------ |
/ \ |
| |
| Intent-based Security Policy |
| |
\ / |
------------------------- ------------- |
| Security Policy Layer | <-------> | Data Models |<-----+
------------------------- ------------- |
/ \ / \ |
| | |
| Policy to Device Translation | |
| | |
\ / \ / |
----------------------------- --------------- |
| Context-Aware Policy Engine | <-----> | Data Models |<---+
----------------------------- --------------- |
/ \ / \ |
| | |
| Device Capabilities | |
| | |
\ / \ / |
----------------------------- --------------- |
| Security Capability Layer | <-----> | Data Models |<---+
----------------------------- ---------------
Figure 4. Conceptual Operation of the I2NSF.
An I2NSF client is a user, application, process, or similar entity
that wants to invoke a physical or virtual Network Security Function
for OAM purposes. This results from the I2NSF Security Policy Layer
exposing a set of security capabilities of one or more network
devices. The I2NSF client does not have to be aware of which set of
security devices is present or is being used; all the I2NSF client
needs to be cognizant of is which network security functions are
required for a given flow.
The Context-Aware Policy Engine uses information about the subject
and target of the policy, the current context, the type of operation
desired, and any other required information, and translates the
(high-level) intent of the I2NSF client to the capabilities of the
network security devices.
The Intent-based Security Policy is a declarative specification of
the security functions required by an I2NSF client. Since multiple
Strassner, et al. Expires August 10, 2015 [Page 9]
Internet-Draft I2NSF Information Model February 2015
devices can have non-interoperable data models that describe their
capabilities, I2NSF uses an information model to represent all
concepts that are used by I2NSF clients, applications, and the
system itself. This enables each of the three layers shown in Figure
4 to (in principle) have their own data model to represent their
functionality in an efficient manner. The information model serves
as a lexicon that enables different entities in the I2NSF
architecture to map the same or similar terms to different
expressions from different data models.
The following subsections define important architectural entities in
each layer in more detail.
3.2. I2NSF Clients
3.3. Security Policy Layer
3.4. Context-Aware Policy Engine
The purpose of I2NSF is to ensure that only properly authorized and
validated requests to perform operations on Resources and Services
are allowed.
Strassner, et al. Expires August 10, 2015 [Page 10]
Internet-Draft I2NSF Information Model February 2015
----------- 1 -------- 7 -----
| Requestor |---->| PEP |---->| PXP |
----------- -------- -----
| / \
2 | | 6
| |
\ / |
-------- 3 --------------
| |---->| |
| CADE |<----| PIP |
| | 5 | |
-------- --------------
/ \ / \ / \
4a| 4b| 4c|
| | |
| | |
--- --- ---
| S || E || R |
--- --- ---
Figure 5. High-Level Overview of the I2NSF Access Control Engine.
3.5. Security Capability Layer
4. I2NSF Information Model Hierarchy
TBD
5. Usage Examples of the I2NSF Information Model
TBD
6. Security Considerations
TBD
Strassner, et al. Expires August 10, 2015 [Page 11]
Internet-Draft I2NSF Information Model February 2015
7. IANA Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
John Strassner
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95138
USA
email: john.sc.strassner@huawei.com
Liang Xia
Huawei Technologies
email: Frank.xialiang@huawei.com
Strassner, et al. Expires August 10, 2015 [Page 12]