I2nsf Working Group J. You
Internet-Draft J. Strassner
Intended status: Standards Track Huawei
Expires: January 19, 2017 M. Zarny
Independent
C. Jacquenet
France Telecom
S. Majee
F5 Networks
July 18, 2016
User-Group-based Security Policy for Capability Layer
draft-you-i2nsf-user-group-policy-capability-00
Abstract
This draft defines the I2NSF Capability APIs for implementing User-
Group-based Security Policies using the Event-Condition-Action
Policy Rule paradigm.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
You, et al. Expires January 19, 2017 [Page 1]
Internet-Draft UG Policy Capability Interface July 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Abbreviations and Acronyms . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 4
3.1. Alternative 1: Using Packet User-Group Labels . . . . . . 4
3.2. Alternative 2: Using User-group IDs Directly . . . . . . 5
4. ECA for User-group-based Security Policy . . . . . . . . . . 5
4.1. Information Model Design . . . . . . . . . . . . . . . . 6
4.2. FlowSpecECAPolicyRule Class Definition . . . . . . . . . 6
4.3 Event . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Condition . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Action . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. Traffic-rate Action . . . . . . . . . . . . . . . . . 8
4.5.2. Traffic-detail Action . . . . . . . . . . . . . . . . 9
4.5.3. Redirect Action . . . . . . . . . . . . . . . . . . . 9
4.5.4. Traffic-marking Action. . . . . . . . . . . . . . . . 9
4.6. Capability Layer Rules . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
In traditional networks, network access is typically controlled
through a combination of mechanisms. These include maintaining
separate static VLAN/IP subnet assignments per organization,
applying Control Lists (ACLs) on VLANs and/or IP subnets, and
leveraging Network Access Control(NAC). However, traditional access
control mechanisms ([I-D.ietf-i2nsf-problem-and-use-cases]) do not
work well with newer network paradigms and architectures. Most
network administrators have to manually plan and implement necessary
changes because little, if any, automation exists across diverse
sets of network security platforms.
You, et al. Expires January 19, 2017 [Page 2]
Internet-Draft UG Policy Capability Interface July 2016
[I-D.you-i2nsf-user-group-based-policy] discusses User-Group aware
Policy Control (UAPC). This facilitates consistent enforcement of
policies based on User-Group identity, since the User-Group IDs are
generated by a set of ECA Policy Rules. It also discusses how this
can be used in the I2NSF Service Layer [I-D.ietf-i2nsf-framework].
The UAPC mechanism calls for: (1) a User-Group identifier (e.g.,
source and destination IP address, time-of-day, device certificate,
or a combination of these and other similar attributes); (2) a
policy server service that maintains policies for defining and
managing user-groups as well as permissions associated with
user-groups; and (3) a logical security controller that is
responsible for managing Network Security Functions (NSFs), and
installing necessary policies on them.
This document proposes I2NSF capability layer APIs for implementing
User-Group-based security policies by using the Event-Condition-
Action (ECA) Policy Rule paradigm.
2. Terminology
This section contains terminology and definitions that are important
for understanding the technical content of this document.
2.1. Abbreviations and Acronyms
AAA: Authentication, Authorization, and Accounting
ECA: Event-Condition-Action
NSF: Network Security Function
UAPC: User-Group Aware Policy Control
VRF: Virtual Routing and Forwarding instance
2.2. Definitions
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. 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. For an ECA
Policy Rule, if the Event clause is TRUE, then the Condition
Clause MUST be evaluated.
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. For an
ECA Policy Rule, if the Condition clause is TRUE, then at least
one Action contained in this ECA Policy Rule MUST be evaluated.
You, et al. Expires January 19, 2017 [Page 3]
Internet-Draft UG Policy Capability Interface July 2016
Action: An Action is a set of purposeful activity that has
associated behavior. An Action, when used in the context of a
Policy Rule, may be executed when both the Event and the Condition
clauses of its owning Policy Rule evaluate to true. The execution
of this Action MAY be influenced by applicable metadata.
3. Overall Architecture
The Security Controller coordinates various network security-related
tasks on a set of NSFs under its administration, and invokes the set
of NSFs that are required to implement security for particular
packets.
The NSF may match on User-Group IDs in the packets, or it may match
on common packet header fields such as an n-tuple, and then map the
n-tuple to the appropriate User-Group ID supplied out-of-band by the
Security Controller. If the packet matches a specified User-Group
ID, the NSF enforces the corresponding policies.
The interface between the Security Controller and the NSF is called
the capability interface in the I2NSF context. This document
describes the I2NSF capability layer API for implementing User-Group-
based security policies by using policy rules that are defined in an
Event-Condition-Action (ECA) structure.
+--------+ +-----------+
| Policy +--------+ Security |
| Server | | Controller|
+----+---+ +-----+-----+
| |
+----+---+ |
| AAA | | NSF- Facing
| Server | | Interface
+--------+ |
|
+------------+-----------+-------+--------+-----------+
| | | | |
| | | | |
+----+----+ +----+---+ +----+---+ +----+---+ +----+---+
| Ingress | | NSF #1 | | NSF #2 | ... | NSF #n | | Egress |
+---------+ +--------+ +--------+ +--------+ +--------+
Figure 1. Functional Architecture
3.1. Option 1: Using Packet User-Group Labels
This option empoloys the User-Group Label (UGL), a packet header
field, to carry the User-Group ID. UGLs are disseminated using
the Registration Interface (see [I-D.ietf-i2nsf-terminology] and
[I-D.ietf-i2nsf-framework]).
You, et al. Expires January 19, 2017 [Page 4]
Internet-Draft UG Policy Capability Interface July 2016
UGLs work in a 'UGL-capable' domain. This is a domain in which all
NSFs residing in that domain support both the UGL field as well as
mapping the UGL field (and hence, the User-Group ID that the UGL
field represents) to a set of ECA Policy Rules.
In this alternative, the ingress NSF matches on common packet header
fields, such as an n-tuple, and then maps the n-tuple to the
appropriate User-Group ID supplied out-of-band by the Security
Controller. Then, the ingress NSF inserts the corresponding UGL
into the packet. The UGL is used by NSFs to make forwarding
decisions in the UGL-supported domain.
The UGL field can be inserted into the packet using, for example,
SFC encapsulation [I-D.ietf-sfc-nsh]. One benefit of option 1 is
that only edge NSFs need to do UGL insertion or removal; other NSFs
can easily enforce User-Group based policies based on the UGL
carried in the packet. If the UGL field does not match any policy,
a UGL-compliant NSF may apply a default policy, such as dropping or
forwarding, to the packet. For example, if no policy is matched,
firewalls typically will drop the packet, since Firewalls define a
deny action as the default action to use.
3.2. Option 2: Using User-0Group IDs Directly
This alternative option relies on all NSFs being able to identify
appropriate fields in a packet, map them to an appropriate User-
Group, and then use that User-Group to control actions on the packet.
In this option, User-Groups are disseminated using the Registration
Interface.
The Ingress NSF matches on common packet header fields, such as an
n-tuple, and then maps the n-tuple to the appropriate User-Group ID
(which is supplied out-of-band by the Security Controller). Then,
the ingress NSF enforces User-Group Policy Rules based on the
identified User-Group ID, without inserting any field into the
packet. Hence, option 2 requires all NSFs on the forwarding path to
support User-Group mapping. If the NSF fails to associate the packet
with a User-Group, it may use a default Policy Rule that is
associated with, for example, a default unknown User-Group. The
Policy associated with the default unknown User-Group should then be
enforced. For example, an unknown User-Group could be mapped to a
null VLAN, and a message sent to the appropriate Controller to
perform basic security checking on it and then assign a real
User-Group to the packet or flow (and a corresponding VLAN).
4. ECA for User-group-based Security Policy
This document uses Policy Rules, in the form of an Event-Condition-
Action (ECA) structure, to describe User-Group-based security
policies.
You, et al. Expires January 19, 2017 [Page 5]
Internet-Draft UG Policy Capability Interface July 2016
The fundamental constructs of ECA languages are reactive rules of the
form:
IF the event clause evaluates to TRUE
IF the condition clause evaluates to TRUE
THEN execute actions in the action clause
ENDIF
ENDIF
The Event clause, Condition clause, and Action clause collectively
form a three-tuple. The Event and Condition clauses are made up of
one or more Boolean statements. If the Event clause evaluates to
FALSE, execution stops. If the Event clause evaluates to TRUE, then
the Condition clause is evaluated. Once again, if the Condition
clause evaluates to FALSE, execution stops; otherwise, Actions in
the Policy Rule may be executed.
4.1. Information Model Design
The information model design for User-Group-based Security Policies
is based on the information model design of the capability interface
[I-D.draft-xia-i2nsf-capability-interface-im].
It is assumed that an external model, or set of models, is used to
define the concept of an ECA Policy Rule and its components (e.g.,
Event, Condition, and Action objects). A functional block diagram of
the ECA Model is shown in Figure 2 below:
+-------------------------+ 0..n 0..n +-----------------+
| |/ \ \| External Common |
| External ECA Info Model + A ---------------+ Superclass for |
| |\ / Aggregates /| ECA Objects |
+----------+--------------+ ECAObjects +--------+--------+
/ \ / \
| |
| |
+-----------+-----------+ +-------------+------+-----+
| SecurityECAPolicyRule | | | |
+-----------+-----------+ | | |
| +-----+----+ +------+----+ +-----+----+
| | External | | External | | External |
| | Event | | Condition | | Action |
| +-----+----+ +-----+-----+ +-----+----+
+------+---------+ | | |
| | | | |
+------+--------+ / \ / \ / \ / \
| FlowSpec | Other Security Security Other
| ECAPolicyRule | SecurityECA Events Conditions Actions
+---------------+ PolicyRules
Figure 2. High-Level Information Model Design
You, et al. Expires January 19, 2017 [Page 6]
Internet-Draft UG Policy Capability Interface July 2016
The SecurityECAPolicyRule is the top of the User-Group ECA Policy
Rule hierarchy. It inherits from the (external) generic ECA Policy
Rule to define Security ECA Policy Rules that are specific to
managing User-Groups. The SecurityECAPolicyRule contains all of the
attributes, methods, and relationships defined in its (generic)
superclass, and adds additional concepts that are required for
Network Security (these will be defined in the next version of this
draft).
The AggregatesECAObjects relationship defines the set of Events,
Conditions, and Actions that are aggregated by a specific
ECAPolicyRule. This aggregation is inherited by all subclasses of
SecurityECAPolicyRule.
This draft defines a single subclass of SecurityECAPolicyRule, called
FlowSpecECAPolicyRule. Additional ECA Policy Rules will be defined in
future versions of this draft.
This draft defines four subclasses of the (external) generic Action
class. Additional Event, Condition, and Action subclasses will be
defined in future versions of this draft. Note that any of the
Events, Conditions, and Actions defined in [I-D.draft-xia-i2nsf-
capability-interface-im] can also be used; this is because the
FlowSpecECAPolicyRule is really a container, which is meant to
aggregate Events, Conditions, and Actions. The Flow Spec Rule is
is thus generic; application-specific needs are provided by
choosing a suitable set of Events, Conditions, and Actions.
It is assumed that the (external) generic ECAPolicyRule class
defines basic information in the form of attributes, such as an
unique object ID, as well as a description and other basic, but
necessary, information. It is also assumed that the (external)
generic ECA Policy Rule is abstract; the SecurityECAPolicyRule is
also abstract. This enables data model optimizations to be made
while making this information model detailed but flexible and
extensible.
The SecurityECAPolicyRule defines network security policy as a
container that aggregates Event, Condition, and Action objects,
which are described in Sections 4.3, 4.4, and 4.5, respectively.
Events, Conditions, and Actions can be generic or security-specific.
Brief class descriptions of these classes are provided in the
following sub-sections. In addition, none of the ECAPolicyRule
subclasses will define attributes. This enables them to be viewed
as simple object containers, and hence, applicable to a wide
variety of content. It also means that the content of the function
is defined solely by the set of Events, Conditions, and Actions
that are contained by the particular subclass. This enables the
Policy Rule, with its aggregated set of Events, Conditions, and
Actions, to be treated as a reusable object.
You, et al. Expires January 19, 2017 [Page 7]
Internet-Draft UG Policy Capability Interface July 2016
4.2. FlowSpecECAPolicyRule Class Definition
The purpose of a FlowSpecECAPolicyRule is to define an ECA Policy
Rule that can invoke FlowSpecs as Actions. The set of invoked
Actions are triggered by a set of Events and Conditions. This ECA
Policy Rule serves as a reusable container, and hence, the set of
Events, Conditions, and Actions that it aggregates are also reused.
4.3. Event
Events are external stimuli, such as alarms, user actions (e.g.,
logon and logoff, or access requests), and packet arrival or
departure occurrences. A set of exemplary Events are defined in
[I-D.draft-xia-i2nsf-capability-interface-im].
4.4. Condition
Conditions are typically attributes or values that affect the state
of a managed entity. These include:
- n-tuple of the incoming packet
- cross checking with other data, such as correlation with
packets received from different ports or past time, or
- the current state of a flow
A set of exemplary Conditions are defined in
[I-D.draft-xia-i2nsf-capability-interface-im].
4.5. Action
This document defines a minimum set of Actions. The first set of
Actions are, based on [RFC5575] and [RFC7674]. This is not meant
to be an inclusive list of all possible Actions, but only a subset
that pertain specifically to flows, which can be interpreted
consistently across the network. Other Actions will be defined in
future versions of this document. An exemplary set of additional
Actions is defined in [I-D.draft-xia-i2nsf-capability-interface-im].
Note that [RFC5575] and [RFC7674] define a general procedure to
encode flow specification rules for aggregated traffic flows, so
that they can be distributed as BGP [RFC4271] network layer
reachability information.
4.5.1. Traffic-rate Action
The traffic-rate instructs a system to shape a certain stream to a
set of predefined bandwidth characteristics. This is implemented
using BGP extended community values attributes [RFC4360]. A
traffic-rate of 0 should result in all traffic for this particular
flow to be discarded.
You, et al. Expires January 19, 2017 [Page 8]
Internet-Draft UG Policy Capability Interface July 2016
4.5.2. Traffic-deetail Action
The traffic-detail enables traffic sampling and logging for a
particular flow. This is implemented using BGP extended community
values attributes [RFC4360].
4.5.3. Redirect Action
The Redirect allows the traffic to be redirected to a specified VRF
routing instance that lists the specified route-target in its import
policy. This is implemented using BGP extended community values
attributes [RFC4360].
4.5.4. Traffic-marking Action
The Traffic-marking instructs a system to modify the DSCP bits of a
transiting IP packet to the corresponding value. This is implemented
using BGP extended community values attributes [RFC4360].
4.6. Capability Layer Rules
This will be completed in the next version of this document.
5. Security Considerations
This document provides an Event-Condition-Action model for describing
user-group-based security policies. It is not intended to represent
any particular system design or implementation, nor does it define a
protocol, and as such it does not have any specific security
requirements.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
You, et al. Expires January 19, 2017 [Page 9]
Internet-Draft UG Policy Capability Interface July 2016
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <http://www.rfc-editor.org/info/rfc7674>.
8.2. Informative References
[I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
Jacquenet, "I2NSF Problem Statement and Use cases", draft-
ietf-i2nsf-problem-and-use-cases-01 (work in progress),
July 2016.
[I-D.ietf-i2nsf-framework]
Lopez, E., Lopez, D., Dunbar, L., Strassner, J., Zhuang,
J., Parrott, J., Krishnan, R., Durbha, S., "Framework for
Interface to Network Security Functions",
draft-ietf-i2nsf-framework-02 (work in progress),
July 2016
[I-D.ietf-sfc-nsh]
Quinn, P. and Elzur, U., "Network Service Header",
draft-ietf-sfc-nsh-05 (work in progress), May 2016.
[I-D.you-i2nsf-user-group-based-policy]
You, J., Zarny, M., Jacquenet, C., Boucadair, M., Yizhou,
L., Strassner, J., and S. Majee, "User-group-based
Security Policy for Service Layer", draft-you-i2nsf-user-
group-based-policy-02 (work in progress), July 2016.
[I-D.draft-xia-i2nsf-capability-interface-im]
Xia, L. Strassner, J., Li, K., Zhang, D., Lopez, E.,
Bouthors, N., Fang, L., "Information Model of Interface
to Network Security Functions Capability interface",
draft-xia-i2nsf-capability-interface-im-06 (work in
progress), July 2016
You, et al. Expires January 19, 2017 [Page 10]
Internet-Draft UG Policy Capability Interface July 2016
[I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., "Interface
to Network Security Functions (I2NSF) Terminology",
draft-ietf-i2nsf-terminology-01, July 2016
Authors' Addresses
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
John Strassner
Huawei
2330 Central Expressway
San Jose, CA
USA
Email: john.sc.strassner@huawei.com
Myo Zarny
Independent
Email: myo.zarny@gmail.com
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Sumandra Majee
F5 Networks
3545 N 1st St
San Jose, CA 95134
Email: S.Majee@f5.com
You, et al. Expires January 19, 2017 [Page 11]