Internet DRAFT - draft-xia-i2nsf-service-interface-dm
draft-xia-i2nsf-service-interface-dm
I2NSF Liang Xia
Internet Draft John Strassner
Intended status: Standard Track Huawei
Dean Bogdanovic
Juniper Networks
Expires: August 2015 February 10, 2015
Data Model of Interface to Network Security Functions Service
Interface
draft-xia-i2nsf-service-interface-dm-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
Xia, et al. Expires August 10, 2015 [Page 1]
Internet-Draft I2NSF Security Policy DM February 2015
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This draft proposes a generic and intent-driven data model for NSF
security policy configuration used by I2NSF clients to negotiate
their security requirements with various kinds of entities that each
provide one or more NSFs. The Role Based Access Control (RBAC)
reference model [INCITS359 RBAC] is used to represent which
operations can be performed on what set of secured objects.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document ........................... 4
2.1. Terminology ............................................ 4
3. RBAC Overview ............................................... 5
4. I2NSF Security Policy Data .................................. 7
4.1. Overview ............................................... 7
4.2. Policy Rule ............................................ 8
4.2.1. ECAPolicyRule ..................................... 9
4.2.1.1. Events ....................................... 9
4.2.1.2. Conditions ................................... 9
4.2.1.3. Actions ..................................... 10
4.3. Using Policy Rules With RBAC .......................... 10
5. Interaction between Resources, Services, and RBAC .......... 12
6. System Control Using RBAC .................................. 12
7. I2NSF Security Policy Yang Structure ....................... 12
8. Use Examples of I2NSF Security Policy ...................... 12
9. Security Considerations .................................... 12
10. IANA Considerations ....................................... 12
11. References ................................................ 12
11.1. Normative References ................................. 12
11.2. Informative References ............................... 13
12. Acknowledgments ........................................... 13
1. Introduction
Due to the rapid development and deployment of cloud computing
services, the demand of cloud-based security services is also
rapidly growing. Cloud-based security customers can be enterprises
[I-D.zarny-i2nsf-data-center-use-cases], User Equipment (UE) of
mobile networks and Internet of Things (IoT) [I-D.qi-i2nsf-access-
network-usecase], residential access users [I-D.pastor-i2nsf-access-
usecases], and so on.
Xia, et al. Expires August 10, 2015 [Page 2]
Internet-Draft I2NSF Security Policy DM February 2015
Derived from [I-D.dunbar-i2nsf-problem-statement], it should have
two types of I2NSF interface to consider:
o Interface between I2NSF user/client with network controller: It's
a service-oriented interface, the main objective is to unify the
communication channel and the security service request
information model between various high-level applications (e.g.,
openstack, various BSS/OSS, etc) with various network controllers.
This interface is decoupled from various kinds of security device
and their device-level security functions. Currently, various
high-level applications have their own proprietary interfaces to
network controller. This will greatly hinder network controllers
interoperating (specifically, exchanging and reusing information)
in a cloud-based model. In addition, it will make their
management interoperability more difficult. A unified and
standard interface is needed;
o North-bound interface (NBI) provided by the network security
functions (NSFs) (e.g., FW, AAA, IPS, Anti-DOS, Anti-Virus, etc),
no matter whether the NSFs are contained within Virtual Machines
(VM) on servers or physical appliances. [I-D.xia-i2nsf-
capability-interface-IM] describes the information model used by
this type of interface. Any network entities (e.g., I2NSF clients,
network controller, etc) can use this interface to configure the
required security functions of NSFs. But, the current situation
is different NSF vendors have different proprietary interfaces,
supported by different information models to configure their
security functions.
For the I2NSF service interface, a more generic and intent-driven
approach for security policy configuration is required in order to
decouple security from the details of the infrastructure
configuration. This also makes it easier to administer and manage
security policies independent of device, vendor, and technology.
This draft proposes a generic and intent-driven data model for NSF
security policy configuration used by I2NSF clients to negotiate
their security requirements with network controllers. The Role Based
Access Control (RBAC) reference model [INCITS359 RBAC] is used to
represent which operations can be performed on what set of secured
objects. Section 3 briefly describes the RBAC approach. Section 4
defines the data model for configuration. Section 5 describes the
interaction between resources, services and RBAC. Section 6
clarifies the system control by using RBAC. Section 7 gives its
grammar. Section 8 includes some using examples to clarify how to
use the data model.
Xia, et al. Expires August 10, 2015 [Page 3]
Internet-Draft I2NSF Security Policy DM February 2015
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].
2.1. Terminology
AAA - Authentication, Authorization, Accounting
ACL - Access Control List
AD - Active Directory
ANSI - American National Standards Institute
DDoS - Distributed Denial of Services
FW - Firewall
I2NSF - Interface to Network Security Functions
INCITS - International Committee for Information Technology
Standards
IoT - Internet of Things
IPS - Intrusion Prevention System
LDAP - Lightweight Directory Access Protocol
NAT - Network Address Translation
NIST - National Institute of Standard Technology
NSF - Network Security Function
RBAC - Role Based Access Control
UE - User Equipment
URL - Uniform/Universal Resource Locator
VM - Virtual Machine
Xia, et al. Expires August 10, 2015 [Page 4]
Internet-Draft I2NSF Security Policy DM February 2015
3. RBAC Overview
Security administration can be costly and prone to error, due to the
high number of users, resources, and services that must be protected.
Trying to assign access control lists (ACLs) for each user on the
system individually cannot scale. With RBAC, security is managed at
a level that corresponds closely to the organization's structure.
Each user is assigned one or more roles, and each role is assigned
one or more privileges that define which operations can be performed
by that role. Conceptually, security administration with RBAC
consists of determining the operations that must be executed by
persons in particular jobs, defining which operations for which
objects can be abstracted into a set of permissions, assigning roles
to permissions, and assigning employees to the proper roles.
RBAC offers a number of benefits. While users, and the jobs that
they perform, change frequently, roles do not. RBAC thus lowers
maintenance costs and increases efficiency. It can be used to
address specific concerns, such as Separation of Duty, and provides
the ability to audit which role performed what operation on which
object at what time. It simplifies tracking user activity, and
enables stronger adherence to regulatory requirements through
ensuring the privacy and confidentiality of user activities.
The NIST model for RBAC was adopted as an American National Standard
by the American National Standards Institute, International
Committee for Information Technology Standards (ANSI/INCITS) on
February 11, 2004.
There are four levels of RBAC. Level 1, Core RBAC, defines a minimum
collection of RBAC elements, element sets, and relations in order to
achieve a Role-Based Access Control system. Figure 1 shows the
reference model of core RBAC. In addition, there are other advanced
levels of RBAC by extending the core RBAC.
Xia, et al. Expires August 10, 2015 [Page 5]
Internet-Draft I2NSF Security Policy DM February 2015
+------------------------------+
| |
| |
+-------+ +-------+ | +-------+ +-------+ |
| | UA | | PA | | | | | |
|USERS <------>ROLES <---------> | OPS <------> OBS | |
| | | | | | | | | |
+--\----+ +----A--+ | +-------+ +-------+ |
\ / | |
user_sessions / | PRMS |
\ / +------------------------------+
\ session_roles
\ /
\ /
+--V--V---+
| |
|SESSIONS |
| |
+---------+
Figure 1. Core RBAC Reference Model
The core RBAC includes the following data elements and mapping
relationships:
User - A user is defined as a human being. In this document, the
concept of a user can be extended to include machines, networks, or
intelligent autonomous agents.
Role - A role is a job function within the context of an
organization with some associated semantics regarding the authority
and responsibility conferred on the user assigned to the role.
Operations (OPS) - Each Object has a set of operations that are
governed by a permission assignment (e.g., read, write, delete, open
a file, execute).
Objects (OBS) - an object can be any system resource subject to
access control, such as a file, printer, terminal, database record,
computer, network, storage, etc.
Permissions (PRMS) - Permission is an approval to perform an
operation on one or more RBAC protected objects. Typically, if not
specified, then an object has no permissions.
Sessions - each session is a mapping between a user and an activated
subset of roles that are assigned to the user.
Xia, et al. Expires August 10, 2015 [Page 6]
Internet-Draft I2NSF Security Policy DM February 2015
User Assignment (UA) - a many-to-many relationship between users and
roles.
Permission Assignment (PA) - a many-to-many relationship between
roles and permissions.
Fundamentally, the RBAC model abstracts entities performing
operations on a set of protected objects as roles. This decouples
users from the operations that can be performed on a given object.
As such, a role is a means for naming many-to-many relationships
among individual or groups of users and permissions. In addition,
the core RBAC model defines a set of sessions, where each session is
a mapping between a user and an activated subset of roles that are
assigned to that user.
4. I2NSF Security Policy Data
4.1. Overview
RBAC is a mature and comprehensive reference model for implementing
access control. As such, it serves as a good foundation to design a
generic security policy data model. The security policy data model
should be expressed in an intent-driven style for making it user
friendly to decrease its complexity. In addition, the data model
should be kept simple by including only the essential logic elements.
RBAC provides inherent scalability, which the data model uses to
express I2NSF security policies. A high-level data model for I2NSF
security policy is shown in Figure 2.
Xia, et al. Expires August 10, 2015 [Page 7]
Internet-Draft I2NSF Security Policy DM February 2015
0..n+-----------+0..n
+-----+-----------+-------+PolicyRule +----------+----------------+----+
| | | +-----------+ | | |
| | |UAPolicy |PAPolicy | |
| | |0..n |0..n | |
| | +-----V--+ +-----V--+ | |
| | |UADetail| |PADetail| | |
| | +----*---+ +--*-----+ OPPolicy| |
| | * * | |
| |USPolicy * * | |
| | * * | |
| | +----+0..n * 0..n+----+0..n * 0..n+----------+ | |
| | |User+-------*------+Role+------*-------+Permission| | |
| | +--+-+UserAssignment+-+--+PermAssignment+--+------++ | |
| |0..n | | 0..n| 0..n| |0..n|
|+----V---+ |1 |0..n PermObject | | +----V---+|
||USDetail*** | +-------------+ ***OPDetail||
|+--------+ | | * PermOperation| +--------+|
| |0..n | 0..n*| 0..n| |
| +---+----+0..n | +-*-+--+ExecuteOn+-------+-+ |
| |Session +--*----------+ |Object+----*----+Operation| |
| +--------+ * SessionRole *------+0..n*0..n+---------+ |
|SRPolicy * * * |
| * +----*---+ +---*----+0..n EOPolicy |
| 0..n+-*------+ |PODetail| |EODetail<-------------------+
+------------->SRDetail| +----A---+ +--------+
+--------+ |
POPolicy |
--------------------------------+
Figure 2. High-Level Data Model for I2NSF Service Interface
4.2. Policy Rule
Policy Rules can be used to control how the fundamental operations
of RBAC (i.e., user-assignment and permission-assignment) are
performed. This uses the inherent scalability of the RBAC approach,
along with the consistency and scalability of policy management, to
provide a robust solution.
Note that Policy Rules could also be defined to govern the
population of key objects. For example, a policy rule could define
whether a particular Role is active for a particular session, or
Xia, et al. Expires August 10, 2015 [Page 8]
Internet-Draft I2NSF Security Policy DM February 2015
even whether a particular Role should be enabled, disabled, created,
or edited. This will be shown in future revisions of this draft.
For the purposes of this document, a policy rule is an intelligent
container. A policy rule can take several different forms (e.g.,
event-condition-action or goal). A future revision of this draft
will specify several options for structuring policy rules.
Regardless of what form the policy rule takes, it can operate on an
administrative domain. Within that domain, it can represent security
requirements, which can take several forms. For example, a security
requirement could represent a condition to check for, or actions to
take, given an event. An important advantage of this approach is to
decouple the structure of a security policy rule from how it is
implemented.
Security policies can be created and assigned to any NSFs depending
on specific requirements and scenarios. Any NSF can have zero or
more security policies. For example, a security policy can be
responsible for an enterprise branch, or can be used for the access
control to one set of services.
4.2.1. ECAPolicyRule
One type of policy rule is an Event-Condition-Action, or ECA, policy
rule. This type of rule has the following semantics:
WHEN an Event-Clause occurs:
IF the Condition-Clause evaluates to TRUE
THEN execute the Action-Clause
This type of policy rule contains three mandatory objects, plus
optional metadata.
4.2.1.1. Events
An Event is an atomic object that is aggregated by an ECAPolicyRule,
and is used to trigger the evaluation of its condition clause. This
enables an external application, such as a Policy Server, to
dynamically adjust the set of events that are being used to trigger
the evaluation of an ECAPolicyRule. For the purposes of this
document, one or more Events may be aggregated into an Event Clause
using standard Boolean operators (i.e., AND, OR, and NOT).
4.2.1.2. Conditions
A PolicyCondition is an atomic object that is aggregated by an
ECAPolicyRule, and is used to define the necessary state and/or
Xia, et al. Expires August 10, 2015 [Page 9]
Internet-Draft I2NSF Security Policy DM February 2015
prerequisites to test whether the PolicyActions aggregated by that
same ECAPolicyRule should be executed. If the PolicyCondition is
TRUE, then the PolicyActions aggregated by the ECAPolicyRule should
be executed. For the purposes of this document, one or more Events
may be aggregated into an Event Clause using standard Boolean
operators (i.e., AND, OR, and NOT).
4.2.1.3. Actions
A PolicyAction is an atomic object that is aggregated by an
ECAPolicyRule. It represents the necessary operations that should be
performed if the PolicyCondition clause of this ECAPolicyRule
evaluates to TRUE. These actions are applied to a set of managed
objects, and have the effect of either maintaining an existing state,
or transitioning to a new state, of those managed objects. For the
purposes of this document, one or more Events may be aggregated into
an Event Clause using standard Boolean operators (i.e., AND, OR, and
NOT).
4.3. Using Policy Rules With RBAC
Figure 3 shows a generic software design pattern, called the "Policy
Pattern", which defines how a set of PolicyRules (of any type and
structure) can be used to realize a dependency (called an
association) between managed entities. Note that the dependency can
be restricted (e.g., to a whole-part dependency, called an
aggregation, or to a composition).
Xia, et al. Expires August 10, 2015 [Page 10]
Internet-Draft I2NSF Security Policy DM February 2015
+-----------+
| |0..n
|PolicyRule +---------------+
| | UAPolicy |
+-----------+ |
|0..n
+------V---+
| |
| UADetail |
| |
+----------+
*
*
*
+---------+ * +---------+
| |0..n * 0..n| |
| User +-------------------+ Role |
| | UserAssignment | |
+---------+ +---------+
Figure 3. Generic Policy Pattern
In this approach, any dependency between two managed objects can be
represented as an association class. (Conceptually, an association
class means that the relationship between the two managed entities
is not simply a set of pointers, but is a managed entity in its own
right, and can be modeled as a class.) A set of PolicyRules can then
be related to the association class; this enables the PolicyRules to
(for example) control the values of attributes of the association
class, which changes the nature of the relationship between the two
managed entities.
For example, in Figure 3, the UserAssignment association is realized
as an association class called UADetail (denoted by the dotted line).
The UADetail class is related to PolicyRule via the UAPolicy
aggregation. Hence, in the above example, the PolicyRule can
configure attributes of the UADetail association class, which in
turn defines how the UserAssignment is implemented for this set of
User and Role.
The advantage of a Software Pattern is both its applicability as
well as its simplicity. Note that all seven RBAC relationships shown
in Figure 2 may be realized using this Pattern.
Policy Rules are used to control behavior. For example, they can be
used to enable (or disable) one or more Roles, Users, and
Permissions in a given context (e.g., a Session).
Xia, et al. Expires August 10, 2015 [Page 11]
Internet-Draft I2NSF Security Policy IM February 2015
A Policy Rule (of any type or structure) can be applied multiple
times on different places (e.g., links, devices, networks, vpns).
The use of Policy Rules to guarantee that consistent intent is
defined and enforced in the whole network, reduces the chances for
manual error, and decreases the overall configuration workload.
5. Interaction between Resources, Services, and RBAC
To be finished. This section will describe how Resources (e.g., a
port on a router), Services (e.g., a VPN), Users, Roles, and groups
of all of these objects, interact.
6. System Control Using RBAC
To be finished. This section will describe how Policy Rules are used
to manage and control Resources, Services, Users, Roles, and groups
of all of these objects.
7. I2NSF Security Policy Yang Structure
To be finished or moved into a separate draft.
8. Use Examples of I2NSF Security Policy
To be finished.
9. Security Considerations
To be finished.
10. IANA Considerations
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Xia, et al. Expires August 10, 2015 [Page 12]
Internet-Draft I2NSF Security Policy DM February 2015
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
11.2. Informative References
[INCITS359 RBAC] NIST/INCITS, "American National Standard for
Information Technology - Role Based Access Control",
INCITS 359, April, 2003
[I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF
Data Center Use Cases", Work in Progress, October 2014.
[I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated
Security with Access Network Use Case", Work in Progress,
October, 2014.
[I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use
Cases for an Open OAM Interface to Virtualized Security
Services", Work in Progress, October, 2014.
[I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface
to Network Security Functions Problem Statement", Work in
Progress, September, 2014.
12. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Liang Xia
Huawei
Email: Frank.xialiang@huawei.com
John Strassner
Huawei Technologies
2330 Central Expressway
Xia, et al. Expires August 10, 2015 [Page 13]
Internet-Draft I2NSF Security Policy DM February 2015
Santa Clara, CA 95138
USA
email: john.sc.strassner@huawei.com
Dean Bogdanovic
Juniper Networks
Email: deanb@juniper.net
Xia, et al. Expires August 10, 2015 [Page 14]
