A Policy-based Network Access Control
draft-ma-opsawg-ucl-acl-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Qiufang Ma , Qin Wu , Mohamed Boucadair , Daniel King | ||
| Last updated | 2023-03-09 | ||
| Replaced by | draft-ietf-opsawg-ucl-acl | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ma-opsawg-ucl-acl-02
OPSAWG Q. Ma
Internet-Draft Q. Wu
Intended status: Standards Track Huawei
Expires: 11 September 2023 M. Boucadair
Orange
D. King
Lancaster University
10 March 2023
A Policy-based Network Access Control
draft-ma-opsawg-ucl-acl-02
Abstract
This document defines a YANG module for policy-based network access
control, which provides consistent and efficient enforcement of
network access control policies based on group identity. Moreover,
this document defines a mechanism to ease the maintenance of the
mapping between a user-group identifier and a set of IP/MAC addresses
to enforce policy-based network access control.
Also, the document defines a common schedule YANG module which is
designed to be applicable for policy activation based on date and
time conditions.
In addition, the document defines a RADIUS attribute that is used to
communicate the user group identifier as part of identification and
authorization information.
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 https://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 11 September 2023.
Ma, et al. Expires 11 September 2023 [Page 1]
Internet-Draft A Policy-based NACL March 2023
Copyright Notice
Copyright (c) 2023 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Sample Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Policy-based Network Access Control . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Endpoint Group . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. User Group . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Device Group . . . . . . . . . . . . . . . . . . . . 9
5. Modules Overview . . . . . . . . . . . . . . . . . . . . . . 9
5.1. The Schedule YANG Module . . . . . . . . . . . . . . . . 9
5.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 10
5.2. The UCL Extension to the ACL Model . . . . . . . . . . . 13
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. The "ietf-schedule" YANG Module . . . . . . . . . . . . . 14
6.2. The "ietf-ucl-acl" YANG Module . . . . . . . . . . . . . 21
7. User Access Control Group ID RADIUS Attribute . . . . . . . . 27
8. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10.1. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Examples Usage . . . . . . . . . . . . . . . . . . . 34
A.1. Configuring the Controller Using Group based ACL . . . . 34
A.2. Configuring a PEP Using Group based ACL . . . . . . . . . 36
A.3. Configuring the PEP Using Address based ACL . . . . . . . 39
Appendix B. Changes between Revisions . . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Ma, et al. Expires 11 September 2023 [Page 2]
Internet-Draft A Policy-based NACL March 2023
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
With the increased adoption of remote access technologies (e.g.,
Virtual Private Networks (VPNs)) and Bring Your Own Device (BYOD)
policies, enterprises adopted more flexibility related to how, where,
and when employees work and collaborate. However, more flexibility
comes with increased risks. Enabling office flexibility (e.g.,
mobility across many access locations) for large-scale employees
induces a set of challenges compared to conventional network access
management approaches. Examples of such challenges are listed below:
* Endpoints do not have a stable IP address. For example, Wireless
LAN (WLAN) and VPN clients, as well as back-end Virtual Machine
(VM)-based servers, can move; their IP addresses could change as a
result. This means that relying on IP/transport fields (e.g., the
5-tuple) is inadequate to ensure consistent and efficient security
policy enforcement. IP address-based policies may not be flexible
enough to accommodate endpoints with volatile IP addresses.
* With the massive adoption of teleworking, there is now a need to
apply different security policies to the same set of users under
different circumstances (e.g., prevent relaying attacks against a
local attachment point to the Enterprise network). For example,
network access might be granted based upon criteria such as users'
access location, source network reputation, users' role, time-of-
day, type of network device used (e.g., corporate issued device
versus personal device), device's security posture, etc. This
means the network needs to recognize the users' identity and their
current context, and map the users to their correct access
entitlement to the network.
This document defines a common schedule YANG module which is designed
to be applicable for policy activation based on date and time
conditions. This model is designed with the intent to be reusable in
other scheduling contexts.
Section 5.2 defines a YANG module for policy-based Network Access
Control, which extends the IETF Access Control Lists (ACLs) module
defined in [RFC8519]. This module can be used to ensure consistent
enforcement of ACL policies based on the group identity.
This document defines also a mechanism to establish a mapping between
the user-group identifier (ID) and common IP packet headers and other
enclosed packet data (e.g., MAC address) to execute the policy-based
access control.
Ma, et al. Expires 11 September 2023 [Page 3]
Internet-Draft A Policy-based NACL March 2023
Last, the document defines a Remote Authentication Dial-in User
Service (RADIUS) [RFC2865] attribute that is used to communicate the
user group identifier as part of identification and authorization
information (Section 7).
As the ACL notion has been generalized, not to be device-specific,
but also be defined at network/administrative domain levels
[I-D.dbb-netmod-acl], the YANG module for policy-based network access
control defined in Section 5.2 does not limit how it can be used.
The YANG data models in this document conform to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342].
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The meanings of the symbols in tree diagrams are defined in
[RFC8340].
The document uses the terms defined in [RFC8519].
In the current version of the document, the term "endpoint" refers
also to a host device or end user that actually connect to a network.
While host device here refers to servers, IoTs and other devices
owned by the enterprise.
3. Sample Usage
Access to some networks (e.g., Enterprise networks) requires to
recognize the users' identities no matter how, where, and when they
connect to the network resources. Then, the network maps the
(connecting) users to their access authorization rights. Such rights
are defined following local policies. As discussed in Section 1,
because (1) there is a large number of users and (2) the source IP
addresses of the same user are in different network segments,
deploying a network access control policy for each IP address or
network segment is heavy workload. An alternate approach is to
configure endpoint groups to classify users and enterprise devices
and associate ACLs with endpoint groups so that endpoints in each
group can share a group of ACL rules. This approach greatly reduces
the workload of the administrators and optimizes the ACL resources.
Ma, et al. Expires 11 September 2023 [Page 4]
Internet-Draft A Policy-based NACL March 2023
The Network ACLs (NACLs) can be provisioned on devices using specific
mechanisms, such as [RFC8519] or [I-D.dbb-netmod-acl].
NACL policies may need to vary over time. For example, companies may
restrict (or grant) employees access to specific internal or external
resources during work hours, while another policy is adopted during
off-hours and weekends. A network administrator may also require to
enforce traffic shaping (Section 2.3.3.3 of [RFC2475]) and policing
(Section 2.3.3.4 of [RFC2475]) during peak hours in order not to
affect other data services.
4. Policy-based Network Access Control
4.1. Overview
To provide real-time and consistent enforcement of access control
policies, the following functional entities and interfaces are
involved:
* A Service Orchestrator which coordinates the overall service,
including security policies. The service may be connectivity or
any other resources that can be hosted and offered by a network.
* An SDN Controller which is responsible for maintaining endpoint-
group based ACLs and mapping the endpoint-group to the associated
attributes information (e.g., IP/MAC address). An SDN Controller
also behaves as a Policy Decision Point (PDP) [RFC3198] and pushes
the required access control policies to relevant Policy
Enforcement Points (PEPs). A PDP is also known as "policy server"
[RFC2753].
An SDN Controller may interact with an Authentication,
Authorization and Accounting (AAA) server or a Network Access
Server (NAS).
* A Network Access Server (NAS) entity which handles authentication
requests. The NAS interacts with an AAA server to complete user
authentication using protocols like RADIUS [RFC2865]. When access
is granted, the AAA server provides the group identifier (group
ID) to which the user belongs when the user first logs onto the
network. A new RADIUS attribute is defined in Section 7 for this
purpose.
Ma, et al. Expires 11 September 2023 [Page 5]
Internet-Draft A Policy-based NACL March 2023
* The AAA server provides a collection of authentication,
authorization, and accounting functions. The AAA server is
responsible for centralized user information management. The AAA
server is preconfigured with user credentials (e.g., user name and
password), possible group identities and related user attributes
(users may be divided into different groups based on different
user attributes).
* The Policy Enforcement Point (PEP) [RFC3198] is the central entity
which is responsible for enforcing appropriate access control
policies. In some cases, a PEP may map incoming packets to their
associated source or destination endpoint-group IDs, and acts on
the endpoint-group ID based ACL policies, e.g., a NAS as the PEP
or a group identifier could be carried in packet header (see
Section 6.2.3 in [I-D.ietf-nvo3-encap]). While in other cases,
the SDN controller maps the group ID to the related common packet
header and delivers IP/MAC address based ACL policies to the
required PEPs.
Multiple PEPs may be involved in a network.
A PEP exposes a NETCONF interface to the SDN Controller [RFC6241].
Figure 1 provides the overall architecture and procedure for policy-
based access control management.
Ma, et al. Expires 11 September 2023 [Page 6]
Internet-Draft A Policy-based NACL March 2023
+------------+
|Orchestrator|
+------+-----+
Service | (Step 1)
------------------------------------------+-------------
------------------------------------------+-------------
Network |
(Step 4) |
+-------+ +--------+ +--------+-----------+
|User #1+--+ | AAA | | SDN Controller |
+-------+ | | Server +-----+ (PDP) |
| +----+---+ +--------+-----------+
| | |
| | +---------------+(Step 5)
(Step 2) | |(Step 3) | |
| | | |
| +-+-----------+---------------+------------+
| | +----------------------+ +--------------+|
+-------+ +--------+ | Network Access Server| |firewall, etc.||
|User #2+-----------+ | (NAS) | +--------------+|
+-------+ | +----------------------+ |
| (PEP) |
+------------------------------------------+
Figure 1: An Architecture for Group-based Policy Management
In reference to Figure 1, the following typical flow is experienced:
Step 1: Administrators (or the Orchestrator) configure an SDN
controller with network-level ACLs using the YANG module defined in
Section 5.2. An example of this is provided in Appendix A.1.
Step 2: When a user first logs onto the network, the user is required
to be authenticated (e.g., using user name and password) at the NAS.
Step 3: The authentication request is then relayed to the AAA server
using protocols like RADIUS [RFC2865]. It is assumed that the AAA
server has been appropriately configured to store user credentials,
e.g., user name, password, group information and other user
attributes. If the authentication request succeeds, the user is
placed in a user-group which is returned to the network access server
as the authentication result (see Section 7). If the authentication
fails, the user is not assigned any user- group, which also means
that the user has no access; or the user is assigned a special group
with very limited access permissions for the network (as a function
of the local policy). ACLs are enforced so that flows from that IP
address are discarded (or rate-limited) by the network. In some
implementations, AAA server can be integrated with an SDN controller.
Ma, et al. Expires 11 September 2023 [Page 7]
Internet-Draft A Policy-based NACL March 2023
Step 4: Either the AAA server or the NAS notify the SDN controller
the mapping between the user-group ID and related common packet
header attributes (e.g., IP/MAC address).
Step 5: Either group or IP/MAC address based access control policies
are maintained on relevant PEPs under the controller's management.
Whether the PEP enforces the group or IP/MAC address based ACL is
implementation specific. Either type of ACL policies may exist on
the PEP. Appendix A.2 and Appendix A.3 elaborate on each case.
4.2. Endpoint Group
4.2.1. User Group
The user-group ID is an identifier that represents the collective
identity of a group of users. It is determined by a set of
predefined policy criteria (e.g., source IP address, geolocation
data, time of day, or device certificate). Users may be moved to
different user-groups if their composite attributes, environment,
and/or local enterprise policy change.
A user is authenticated, and classified at the AAA server, and
assigned to a user-group. A user's group membership may change as
aspects of the user change. For example, if the user-group
membership is determined solely by the source IP address, then a
given user's user-group ID will change when the user moves to a new
IP address that falls outside of the range of addresses of the
previous user-group.
This document does not make any assumption about how user groups are
defined. Such considerations are deployment specific and are out of
scope. However, and for illustration purposes, Table 1 shows an
example of how user-group definitions may be characterized. User-
groups may share several common criteria. That is, user-group
criteria are not mutually exclusive. For example, the policy
criteria of user-groups R&D Regular and R&D BYOD may share the same
set of users that belong to the R&D organization, and differ only in
the type of clients (firm-issued clients vs. users' personal
clients). Likewise, the same user may be assigned to different user-
groups depending on the time of day or the type of day (e.g.,
weekdays versus weekends), etc.
Ma, et al. Expires 11 September 2023 [Page 8]
Internet-Draft A Policy-based NACL March 2023
+============+==========+===================================+
| Group Name | Group ID | Group Role |
+============+==========+===================================+
| R&D | 10 | R&D employees |
+------------+----------+-----------------------------------+
| R&D BYOD | 11 | Personal devices of R&D employees |
+------------+----------+-----------------------------------+
| Sales | 20 | Sales employees |
+------------+----------+-----------------------------------+
| VIP | 30 | VIP employees |
+------------+----------+-----------------------------------+
Table 1: User-Group Example
4.2.2. Device Group
The device-group ID is an identifier that represents the collective
identity of a group of enterprise end devices. An enterprise device
could be an server that hosts applications or software that deliver
services to enterprise users. It could also be an enterprise IoT
device that serve a limited purpose, e.g., a printer that allows
users to scan, print and send emails. Table 2 shows an example of
how device-group definitions may be characterized.
+================+==========+===========================+
| Group Name | Group ID | Group Type |
+================+==========+===========================+
| Workflow | 40 | Workflow resource servers |
+----------------+----------+---------------------------+
| R&D Resource | 50 | R&D resource servers |
+----------------+----------+---------------------------+
| Sales Resource | 54 | Sales resource servers |
+----------------+----------+---------------------------+
Table 2: Device-Group Example
Users accessing to enterprise device should be strictly controlled.
Matching abstract device group ID instead of specified addresses in
ACL polices helps shield the consequences of address change (e.g.,
back-end Virtual Machine (VM)-based server migration).
5. Modules Overview
5.1. The Schedule YANG Module
This module defines a common schedule YANG module. It is inspired
from the "period of time" and "recurrence rule" format defined in
[RFC5545].
Ma, et al. Expires 11 September 2023 [Page 9]
Internet-Draft A Policy-based NACL March 2023
This module is defined as a standalone module rather than as part of
the UCL module with the intention that the time/date definition can
be reused.
Figure 2 provides an overview of the tree structure of the "ietf-
schedule" module.
module: ietf-schedule
grouping period:
+-- period-of-time
+-- (forms)?
+--:(period-explicit)
| +-- explicit-start? yang:date-and-time
| +-- explicit-end? yang:date-and-time
+--:(period-start)
+-- start? yang:date-and-time
+-- duration? duration
grouping recurrence:
+-- recurrence
+-- freq enumeration
+-- (recurrence-bound)?
| +--:(until)
| | +-- until? union
| +--:(count)
| +-- count? uint32
+-- interval? uint32
+-- bysecond* uint32
+-- byminute* uint32
+-- byhour* uint32
+-- byday* [weekday]
| +-- direction* int32
| +-- weekday? schedule:weekday
+-- bymonthday* int32
+-- byyearday* int32
+-- byyearweek* int32
+-- byyearmonth* uint32
+-- bysetpos* int32
+-- wkst? schedule:weekday
Figure 2: Schedule Tree Structure
5.1.1. Examples
The following subsections provide some examples to illustrate the use
of the period and recurrence formats defined as YANG groupings. Only
the message body is provided with JSON used for encoding [RFC7951].
Ma, et al. Expires 11 September 2023 [Page 10]
Internet-Draft A Policy-based NACL March 2023
5.1.1.1. Period of Time
The example of a period that starts at 08:00:00 UTC, on January 1,
2023 and ends at 18:00:00 UTC on December 31, 2025 is encoded as
follows:
{
"period-of-time": {
"explicit-start": "2023-01-01T08:00:00Z",
"explicit-end": "2025-12-01T18:00:00Z"
}
}
An example of a period that starts at 08:00:00 UTC, on January 1,
2023 and lasts 15 days and 5 hours and 20 minutes is encoded as
follows:
{
"period-of-time": {
"start": "2023-01-01T08:00:00Z",
"duration": "P15DT05:20:00"
}
}
Now, consider the example of a period that starts at 08:00:00 UTC, on
January 1, 2023 and lasts 20 weeks:
{
"period-of-time": {
"start": "2023-01-01T08:00:00Z",
"duration": "P20W"
}
}
5.1.1.2. Recurrence Rule
The following snippet can be used to indicate a daily recurrent in
December:
{
"recurrence": {
"freq": "daily",
"byyearmonth": [12]
}
}
The following snippet can be used to indicate 10 occurrences that
occur every last Saturday of the month:
Ma, et al. Expires 11 September 2023 [Page 11]
Internet-Draft A Policy-based NACL March 2023
{
"recurrence": {
"freq": "monthly",
"count": 10,
"byday": [
{
"direction": [-1],
"weekday": "saturday"
}
]
}
}
The following indicates the example of a recurrence that occurs on
the last workday of the month until December 25, 2023:
{
"recurrence": {
"freq": "monthly",
"until": "2023-12-25",
"byday": [
{ "weekday": "monday" },
{ "weekday": "tuesday" },
{ "weekday": "wednesday" },
{ "weekday": "thursday" },
{ "weekday": "friday" }
],
"bysetpos": [-1]
}
}
Every other week on Tuesday and Sunday, the week starts from Monday:
{
"recurrence": {
"freq": "weekly",
"interval": 2,
"byday": [
{ "weekday": "tuesday" },
{ "weekday": "sunday" }
],
"wkst": "monday"
}
}
Ma, et al. Expires 11 September 2023 [Page 12]
Internet-Draft A Policy-based NACL March 2023
5.2. The UCL Extension to the ACL Model
Figure 3 provides the tree structure of the "ietf-ucl-acl" module.
module: ietf-ucl-acl
augment /acl:acls/acl:acl:
+--rw endpoint-groups
+--rw endpoint-group* [group-id]
+--rw group-id uint32
+--rw (group-type)?
+--:(user-group)
| +--rw user-group
| +--rw role? string
+--:(device-group)
+--rw device-group
+--rw device-type? string
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw endpoint-group {match-on-group}?
+--rw source-group-id? leafref
+--rw destination-group-id? leafref
augment /acl:acls/acl:acl/acl:aces/acl:ace:
+--rw time-range {time-condition}?
+--rw (time-range-type)?
+--:(periodic-range)
| +--rw recurrence
| +--rw freq enumeration
| +--rw (recurrence-bound)?
| | +--:(until)
| | | +--rw until? union
| | +--:(count)
| | +--rw count? uint32
| +--rw interval? uint32
| +--rw bysecond* uint32
| +--rw byminute* uint32
| +--rw byhour* uint32
| +--rw byday* [weekday]
| | +--rw direction* int32
| | +--rw weekday schedule:weekday
| +--rw bymonthday* int32
| +--rw byyearday* int32
| +--rw byyearweek* int32
| +--rw byyearmonth* uint32
| +--rw bysetpos* int32
| +--rw wkst* schedule:weekday
| +--rw duration? schedule:duration
+--:(absolute-range)
+--rw period-of-time
Ma, et al. Expires 11 September 2023 [Page 13]
Internet-Draft A Policy-based NACL March 2023
+--rw (forms)?
+--:(period-explicit)
| +--rw explicit-start? yang:date-and-time
| +--rw explicit-end? yang:date-and-time
+--:(period-start)
+--rw start? yang:date-and-time
+--rw duration? duration
Figure 3: UCL Extension
This module specifies an extension to the IETF ACL model [RFC8519]
such that the UCL group index can be referenced by augmenting the
"match" data node.
6. YANG Modules
6.1. The "ietf-schedule" YANG Module
This module imports types defined in [I-D.ietf-netmod-rfc6991-bis].
<CODE BEGINS>
file=ietf-schedule@2023-01-19.yang
module ietf-schedule {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schedule";
prefix schedule;
import ietf-yang-types {
prefix yang;
revision-date 2023-01-23;
reference
"RFC XXXX: Common YANG Data Types";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>";
description
"This YANG module defines two groupings for iCalendar (Internet
Calendaring and Scheduling Core Object Specification) data
types:period of time and recurrence rule, for representing and
exchanging calendaring and scheduling information. The YANG
module complies with sections 3.3.9 and 3.3.10 in RFC 5545.
Future extensions may define more as needed.
Copyright (c) 2023 IETF Trust and the persons identified
Ma, et al. Expires 11 September 2023 [Page 14]
Internet-Draft A Policy-based NACL March 2023
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
revision 2023-01-19 {
description
"Initial revision.";
reference
"RFC XXXX: A Policy-based Network Access Control";
}
typedef weekday {
type enumeration {
enum sunday {
value 0;
description
"Sunday of the week.";
}
enum monday {
value 1;
description
"Monday of the week.";
}
enum tuesday {
value 2;
description
"Tuesday of the week.";
}
enum wednesday {
value 3;
description
"Wednesday of the week.";
}
enum thursday {
value 4;
description
"Thursday of the week.";
}
enum friday {
Ma, et al. Expires 11 September 2023 [Page 15]
Internet-Draft A Policy-based NACL March 2023
value 5;
description
"Friday of the week.";
}
enum saturday {
value 6;
description
"Saturday of the week.";
}
}
description
"Seven days of the week.";
}
typedef duration {
type string {
pattern '((\+)?|\-)P((([0-9]+)D)?(T(0[0-9]|1[0-9]|2[0-3])'
+ ':[0-5][0-9]:[0-5][0-9]))|P([0-9]+)W';
}
description
"Duration of the time. The format can represent nominal
durations (weeks and days) and accurate durations (hours,
minutes, and seconds). Note that this value type doesn't
support the 'Y' and 'M' designators to specify durations in
terms of years and months. Negative durations are typically
used to schedule an alarm to trigger before an associated time.";
reference
"RFC 5545: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)";
}
grouping period {
description
"This grouping is defined for period of time property.";
reference
"RFC 5545: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)";
container period-of-time {
description
"This container is defined to identify period values that
contain a precise period of time.";
choice forms {
description
"Two forms of period of time.";
case period-explicit {
description
"A period of time is identified by its start and its
Ma, et al. Expires 11 September 2023 [Page 16]
Internet-Draft A Policy-based NACL March 2023
end.";
leaf explicit-start {
type yang:date-and-time;
description
"Period start time.";
}
leaf explicit-end {
type yang:date-and-time;
description
"Period end time.";
}
}
case period-start {
description
"A period of time is defined by a start and a
positive duration of time.";
leaf start {
type yang:date-and-time;
description
"Period start time.";
}
leaf duration {
type duration {
pattern 'P((([0-9]+)D)?(T(0[0-9]|1[0-9]|2[0-3])'
+ ':[0-5][0-9]:[0-5][0-9]))|P([0-9]+)W';
}
description
"A positive duration of the time.";
}
}
}
}
}
grouping recurrence {
description
"This grouping is defined to identify properties that
contain a recurrence rule specification";
reference
"RFC 5545: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)";
container recurrence {
description
"Recurrence rule definition.";
leaf freq {
type enumeration {
enum secondly {
value 1;
Ma, et al. Expires 11 September 2023 [Page 17]
Internet-Draft A Policy-based NACL March 2023
description
"Repeating events based on an interval of a second
or more.";
}
enum minutely {
value 2;
description
"Repeating events based on an interval of a minute
or more.";
}
enum hourly {
value 3;
description
"Repeating events based on an interval of an hour
or more.";
}
enum daily {
value 4;
description
"Repeating events based on an interval of a day or
more.";
}
enum weekly {
value 5;
description
"Repeating events based on an interval of a week or
more.";
}
enum monthly {
value 6;
description
"Repeating events based on an interval of a month or
more.";
}
enum yearly {
value 7;
description
"Repeating events based on an interval of a year or
more.";
}
}
mandatory true;
description
"This parameter is defined to identify the type of
recurrence rule.";
}
choice recurrence-bound {
description
Ma, et al. Expires 11 September 2023 [Page 18]
Internet-Draft A Policy-based NACL March 2023
"Modes to bound the recurrence rule. If no choice is
indicated, the recurrence rule is considered to repeat
forever.";
case until {
description
"This case defines a way that bounds the recurrence
rule in an inclusive manner.";
leaf until {
type union {
type yang:date-no-zone;
type yang:date-and-time;
}
description
"This parameter specifies a date-no-zone or
date-time value to bounds the recurrence. The
specified value becomes the last instance of the
recurrence.";
}
}
case count {
description
"This case defines the number of occurrences at which
to range-bound the recurrence.";
leaf count {
type uint32;
description
"The positive number of occurrences at which to
range-bound the recurrence.";
}
}
}
leaf interval {
type uint32;
default "1";
description
"A positive integer representing at which intervals the
recurrence rule repeats. The default value is '1',
meaning every second for a secondly rule, every minute
for a minutely rule, every hour for an hourly rule, every
day for a daily rule, every week for a weekly rule, every
month for a monthly rule, and every year for a yearly
rule.";
}
leaf-list bysecond {
type uint32 {
range "0..60";
}
description
Ma, et al. Expires 11 September 2023 [Page 19]
Internet-Draft A Policy-based NACL March 2023
"A list of seconds within a minute.";
}
leaf-list byminute {
type uint32 {
range "0..59";
}
description
"A list of minutes within an hour.";
}
leaf-list byhour {
type uint32 {
range "0..23";
}
description
"Specify a list of hours of the day.";
}
list byday {
key "weekday";
description
"Specify a list of days of the week.";
leaf-list direction {
when '(enum-value(../../freq) = 6) or ' +
'(enum-value(../../freq) = 7) and not(../../byyearweek)';
type int32 {
range "-53..-1|1..53";
}
description
"When specified, it indicates the nth occurrence of a
specific day within the MONTHLY or YEARLY 'RRULE'. For
example, within a MONTHLY rule, +1 monday represents the
first monday within the month, whereas -1 monday
represents the last monday of the month.";
}
leaf weekday {
type schedule:weekday;
description
"Corresponding to seven days of the week.";
}
}
leaf-list bymonthday {
type int32 {
range "-31..-1|1..31";
}
description
"Specifies a list of days of the month.";
}
leaf-list byyearday {
Ma, et al. Expires 11 September 2023 [Page 20]
Internet-Draft A Policy-based NACL March 2023
type int32 {
range "-366..-1|1..366";
}
description
"Specifies a list of days of the year.";
}
leaf-list byyearweek {
when 'enum-value(../freq)=7';
type int32 {
range "-53..-1|1..53";
}
description
"Specifies a list of weeks of the year.";
}
leaf-list byyearmonth {
type uint32 {
range "1..12";
}
description
"Specifies a list of months of the year.";
}
leaf-list bysetpos {
type int32 {
range "-366..-1|1..366";
}
description
"Specifies a list of values that corresponds to the nth
occurrence within the set of recurrence instances
specified by the rule. It must only be used in conjunction
with another byXXX rule part.";
}
leaf wkst {
type schedule:weekday;
default "monday";
description
"Specifies the day on which the workweek starts.";
}
}
}
}
<CODE ENDS>
6.2. The "ietf-ucl-acl" YANG Module
This module imports types defined in [RFC6991], [RFC8194], and
[RFC8519].
Ma, et al. Expires 11 September 2023 [Page 21]
Internet-Draft A Policy-based NACL March 2023
<CODE BEGINS>
file=ietf-ucl-acl@2023-01-19.yang
module ietf-ucl-acl {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ucl-acl";
prefix uacl;
import ietf-access-control-list {
prefix acl;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)";
}
import ietf-schedule {
prefix schedule;
reference
"RFC XXXX: A Policy-based Network Access Control";
}
organization
"IETF OPSWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>";
description
"This YANG module augments the IETF access control lists(ACLs)
module and is meant to ensure consistent enforcement of ACL
policies based on the group identity.
Copyright (c) 2023 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
revision 2023-01-19 {
description
"Initial revision.";
reference
"RFC XXXX: A Policy-based Network Access Control";
Ma, et al. Expires 11 September 2023 [Page 22]
Internet-Draft A Policy-based NACL March 2023
}
identity group-acl-type {
if-feature "group";
base acl:acl-base;
description
"An ACL that matches based on an endpoint group identity,
which can represent the collective identity of a group of
authenticated users or enterprise end devices. An endpoint
group identity may be carried in the outer/inner packet
header(e.g., via NVO3 encapsulation), but may not correspond
to any field in the packet header.";
}
identity mixed-ipv4-group-type {
if-feature "mixed-ipv4-group";
base acl:ipv4-acl-type;
base uacl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in IPv4 headers and endpoint group identities, which can
represent the collective identity of a group of authenticated
users or enterprise end devices. Matching on Layer 4 header
fields may also exist in the ACEs.";
}
identity mixed-ipv6-group-type {
if-feature "mixed-ipv6-group";
base acl:ipv6-acl-type;
base uacl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in IPv6 headers and endpoint group identities, which can
represent the collective identity of a group of authenticated
users or enterprise end devices. Matching on Layer 4 header
fields may also exist in the ACEs.";
}
identity mixed-ipv4-ipv6-group-type {
if-feature "mixed-ipv4-ipv6-group";
base acl:ipv4-acl-type;
base acl:ipv6-acl-type;
base uacl:group-acl-type;
description
"An ACL that contains a mix of entries that match on fields
in IPv4 headers, IPv6 headers and endpoint group identities,
which can represent the collective identity of a group of
authenticated users or enterprise end devices. Matching on
Layer 4 header fields may also exist in the ACEs.";
}
feature match-on-group {
Ma, et al. Expires 11 September 2023 [Page 23]
Internet-Draft A Policy-based NACL March 2023
description
"The device can support matching on endpoint groups.";
}
feature group {
if-feature "uacl:match-on-group";
description
"Plain group ACL supported.";
}
feature mixed-ipv4-group {
if-feature "acl:match-on-ipv4 and uacl:match-on-group";
description
"IPv4 and group ACL combinations supported.";
}
feature mixed-ipv6-group {
if-feature "acl:match-on-ipv6 and uacl:match-on-group";
description
"IPv6 and group ACL combinations supported.";
}
feature mixed-ipv4-ipv6-group {
if-feature "acl:match-on-ipv4 and acl:match-on-ipv6 and " + "
uacl:match-on-group";
description
"IPv4, IPv6 and group ACL combinations supported.";
}
feature time-condition {
description
"The device can support a time condition based ACL policy
enforcement.";
}
augment "/acl:acls/acl:acl" {
description
"add a new container to store endpoint group information.";
container endpoint-groups {
description
"Container definition for the endpoint group.";
list endpoint-group {
key "group-id";
description
"Definition of the endpoint group list.";
leaf group-id {
type uint32 {
range "0..4294967294";
}
description
"The endpoint group ID that uniquely identifies an
endpoint group.";
Ma, et al. Expires 11 September 2023 [Page 24]
Internet-Draft A Policy-based NACL March 2023
}
choice group-type {
description
"Choice of each different type of endpoint.";
case user-group {
description
"The employee that actually connects to the network.";
container user-group {
description
"Defines the user-group container.";
leaf role {
type string;
description
"The common role of this user-group.";
}
}
}
case device-group {
description
"The static resources in a network, such as a specific
application.";
container device-group {
description
"Defines the device-group container.";
leaf device-type {
type string;
description
"The type of the static resource.";
}
}
}
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
description
"Add another choice to allow ace match based on endpoint group
id.";
container endpoint-group {
when "derived-from-or-self(/acl:acls/acl:acl/acl:type, "
+ "'uacl:group-acl-type')";
if-feature "match-on-group";
description
"Add new match types.";
leaf source-group-id {
type leafref {
Ma, et al. Expires 11 September 2023 [Page 25]
Internet-Draft A Policy-based NACL March 2023
path "../../../../../endpoint-groups/endpoint-group/"+
"group-id";
}
description
"The matched source endpoint group ID.";
}
leaf destination-group-id {
type leafref {
path "../../../../../endpoint-groups/endpoint-group/"+
"group-id";
}
description
"The matched destination endpoint group ID.";
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace" {
if-feature "time-condition";
description
"Add a new parameter to the Access Control Entry (ACE).";
container time-range {
description
"This container defines when the access control
entry rules are in effect.
If it is not configured, the access control entry
is immediately and always in effect.";
choice time-range-type {
description
"Choice based on the type of the time range.";
case periodic-range {
description
"A periodic range of time to take effect.";
uses schedule:recurrence {
augment recurrence {
description
"Add a parameter to specify the duration of each
recurrence trigger.";
leaf duration {
type schedule:duration {
pattern '((\+)?|\-)PT(0[0-9]|1[0-9]|2[0-3]):'
+ '[0-5][0-9]:[0-5][0-9]';
}
description
"A duration of time in terms of days when policies
are activated in each occurrence.";
}
Ma, et al. Expires 11 September 2023 [Page 26]
Internet-Draft A Policy-based NACL March 2023
}
}
}
case absolute-range {
description
"A single precise period of time to take effect.";
uses schedule:period;
}
}
}
}
}
<CODE ENDS>
7. User Access Control Group ID RADIUS Attribute
The User-Access-Group-ID RADIUS attribute and its embedded TLVs are
defined with globally unique names. The definition of the attribute
follows the guidelines in Section 2.7.1 of [RFC6929]. This attribute
is used to indicate the user-group ID to be used by the NAS. When
the User-Access-Group-ID RADIUS attribute is present in the RADIUS
Access-Accept, the system applies the related access control to the
users after it authenticates.
The value fields of the Attribute are encoded in clear and not
encrypted as, for example, Tunnel- Password Attribute [RFC2868].
The User-Access-Group-ID Attribute is of type "string" as defined in
Section 3.5 of [RFC8044].
The User-Access-Group-ID Attribute MAY appear in a RADIUS Access-
Accept packet. It MAY also appear in a RADIUS Access-Request packet
as a hint to the RADIUS server to indicate a preference. However,
the server is not required to honor such a preference.
The User-Access-Group-ID Attribute MAY appear in a RADIUS CoA-Request
packet.
The User-Access-Group-ID Attribute MAY appear in a RADIUS Accounting-
Request packet.
The User-Access-Group-ID Attribute MUST NOT appear in any other
RADIUS packet.
The User-Access-Group-ID Attribute is structured as follows:
Ma, et al. Expires 11 September 2023 [Page 27]
Internet-Draft A Policy-based NACL March 2023
Type
241
Length
This field indicates the total length, in octets, of all fields of
this attribute, including the Type, Length, Extended-Type, and the
"Value".
Extended-Type
TBA1
Value
This field contains the user group ID.
The User-Access-Group-ID Attribute is associated with the following
identifier: 241.TBA1.
8. RADIUS Attributes
The following table provides a guide as what type of RADIUS packets
that may contain User-Access-Group-ID Attribute, and in what
quantity.
Access- Access- Access- Challenge Acct. # Attribute
Request Accept Reject Request
0+ 0+ 0 0 0+ 241.TBA1 User-Access-Group-ID
CoA-Request CoA-ACK CoA-NACK # Attribute
0+ 0 0 241.TBA2 User-Access-Group-ID
The following table defines the meaning of the above table entries:
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
9. Security Considerations
Ma, et al. Expires 11 September 2023 [Page 28]
Internet-Draft A Policy-based NACL March 2023
9.1. YANG
The YANG modules specified in this document defines schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
The "ietf-schedule" module defines a set of types and groupings.
These nodes are intended to be reused by other YANG modules. The
module by itself does not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the "ietf- schedule" module
that need to be considered.
There are a number of data nodes defined in the "ietf-ucl-acl" YANG
module that are writable, creatable, and deletable (i.e., config
true, which is the default). These data nodes may be considered
sensitive or vulnerable in some network environments. Write
operations to these data nodes could have a negative effect on
network and security operations.
* TBC
* TBC
Some of the readable data nodes in the "ietf-ucl-acl" YANG module may
be considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
* <list subtrees and data nodes and state why they are sensitive>
* <list subtrees and data nodes and state why they are sensitive>
9.2. RADIUS
RADIUS-related security considerations are discussed in [RFC2865].
Ma, et al. Expires 11 September 2023 [Page 29]
Internet-Draft A Policy-based NACL March 2023
This document targets deployments where a trusted relationship is in
place between the RADIUS client and server with communication
optionally secured by IPsec or Transport Layer Security (TLS)
[RFC6614].
10. IANA Considerations
10.1. YANG
This document registers the following URIs in the "IETF XML Registry"
[RFC3688].
URI: urn:ietf:params:xml:ns:yang:ietf-schedule
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ucl-acl
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020].
name: ietf-schedule
namespace: urn:ietf:params:xml:ns:yang:ietf-schedule
prefix: schedule
maintained by IANA: N
reference: RFC XXXX
name: ietf-ucl-acl
namespace: urn:ietf:params:xml:ns:yang:ietf-ucl-acl
prefix: uacl
maintained by IANA: N
reference: RFC XXXX
10.2. RADIUS
This document requests IANA to assign a new RADIUS attribute types
from the IANA registry "Radius Attribute Types" [RADIUS-Types]:
+==========+======================+===========+===============+
| Value | Description | Data Type | Reference |
+==========+======================+===========+===============+
| 241.TBA1 | User-Access-Group-ID | string | This-Document |
+----------+----------------------+-----------+---------------+
Table 3: RADIUS Attribute
Ma, et al. Expires 11 September 2023 [Page 30]
Internet-Draft A Policy-based NACL March 2023
11. References
11.1. Normative References
[I-D.ietf-netmod-rfc6991-bis]
Schönwälder, J., "Common YANG Data Types", Work in
Progress, Internet-Draft, draft-ietf-netmod-rfc6991-bis-
15, 23 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc6991-bis-15>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<https://www.rfc-editor.org/info/rfc6929>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
Ma, et al. Expires 11 September 2023 [Page 31]
Internet-Draft A Policy-based NACL March 2023
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/info/rfc8044>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194,
August 2017, <https://www.rfc-editor.org/info/rfc8194>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>.
11.2. Informative References
[I-D.dbb-netmod-acl]
de Dios, O. G., Barguil, S., and M. Boucadair, "Extensions
to the Access Control Lists (ACLs) YANG Model", Work in
Progress, Internet-Draft, draft-dbb-netmod-acl-03, 24
October 2022, <https://datatracker.ietf.org/doc/html/
draft-dbb-netmod-acl-03>.
Ma, et al. Expires 11 September 2023 [Page 32]
Internet-Draft A Policy-based NACL March 2023
[I-D.ietf-nvo3-encap]
Boutros, S. and D. E. Eastlake, "Network Virtualization
Overlays (NVO3) Encapsulation Considerations", Work in
Progress, Internet-Draft, draft-ietf-nvo3-encap-09, 7
October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-nvo3-encap-09>.
[I-D.smith-vxlan-group-policy]
Smith, M. and L. Kreeger, "VXLAN Group Policy Option",
Work in Progress, Internet-Draft, draft-smith-vxlan-group-
policy-05, 22 October 2018,
<https://datatracker.ietf.org/doc/html/draft-smith-vxlan-
group-policy-05>.
[I-D.yizhou-anima-ip-to-access-control-groups]
Li, Y., Shen, L., and Y. Zhou, "Autonomic IP Address To
Access Control Group ID Mapping", Work in Progress,
Internet-Draft, draft-yizhou-anima-ip-to-access-control-
groups-02, 15 November 2021,
<https://datatracker.ietf.org/doc/html/draft-yizhou-anima-
ip-to-access-control-groups-02>.
[I-D.you-i2nsf-user-group-based-policy]
You, J., Zarny, M., Jacquenet, C., Boucadair, M., Li, Y.,
Strassner, J., and S. Majee, "User-group-based Security
Policy for Service Layer", Work in Progress, Internet-
Draft, draft-you-i2nsf-user-group-based-policy-02, 8 July
2016, <https://datatracker.ietf.org/doc/html/draft-you-
i2nsf-user-group-based-policy-02>.
[NIST-ABAC]
Hu, V. C., "Guide to Attribute Based Access Control (ABAC)
Definition and Considerations", January 2014,
<https://www.iana.org/assignments/media-types>.
[RADIUS-Types]
IANA, "RADIUS Types",
<http://www.iana.org/assignments/radius-types>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753,
DOI 10.17487/RFC2753, January 2000,
<https://www.rfc-editor.org/info/rfc2753>.
Ma, et al. Expires 11 September 2023 [Page 33]
Internet-Draft A Policy-based NACL March 2023
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
<https://www.rfc-editor.org/info/rfc2868>.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <https://www.rfc-editor.org/info/rfc3198>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Examples Usage
A.1. Configuring the Controller Using Group based ACL
Let's consider an organization that would like to restrict the access
of R&D employees that bring personally owned devices (BYOD) into the
workplace.
The access requirements are as follows:
* Permit traffic from R&D BYOD of employees, destined to R&D
employees' devices every work day from 8:00 to 18:00.
* Deny traffic from R&D BYOD of employees, destined to finance
servers located in the enterprise DC network starting at 8:30:00
of January 20, 2023 with an offset of -08:00 from UTC (Pacific
Standard Time) and ending at 18:00:00 in Pacific Standard Time on
December 31, 2023.
Ma, et al. Expires 11 September 2023 [Page 34]
Internet-Draft A Policy-based NACL March 2023
The following example illustrates the configuration of the SDN
controller using the group-based ACL:
<?xml version="1.0" encoding="utf-8"?>
<acls xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list"
xmlns:uacl="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<acl>
<name>sample-group-acl</name>
<type>uacl:group-acl-type</type>
<endpoint-groups
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<endpoint-group>
<group-id>20</group-id>
<user-group>
<role>R&D</role>
</user-group>
</endpoint-group>
<endpoint-group>
<group-id>22</group-id>
<user-group>
<role>R&D BYOD</role>
</user-group>
</endpoint-group>
<endpoint-group>
<group-id>50</group-id>
<device-group>
<device-type>finance server</device-type>
</device-group>
</endpoint-group>
</endpoint-groups>
<aces>
<ace>
<name>rule1</name>
<matches>
<endpoint-group
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<source-group-id>22</source-group-id>
<destination-group-id>20</destination-group-id>
</endpoint-group>
</matches>
<actions>
<forwarding>accept</forwarding>
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<recurrence>
<freq>daily</freq>
<byhour>8</byhour>
Ma, et al. Expires 11 September 2023 [Page 35]
Internet-Draft A Policy-based NACL March 2023
<byday>
<weekday>monday</weekday>
</byday>
<byday>
<weekday>tuesday</weekday>
</byday>
<byday>
<weekday>wednesday</weekday>
</byday>
<byday>
<weekday>thursday</weekday>
</byday>
<byday>
<weekday>friday</weekday>
</byday>
<duration>PT10:00:00</duration>
</recurrence>
</time-range>
</ace>
<ace>
<name>rule2</name>
<matches>
<endpoint-group
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<source-group-id>22</source-group-id>
<destination-group-id>50</destination-group-id>
</endpoint-group>
</matches>
<actions>
<forwarding>reject</forwarding>
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<period-of-time>
<explicit-start>2023-01-20T08:30:00-08:00</explicit-start>
<explicit-end>2023-12-31T18:00:00-08:00</explicit-end>
</period-of-time>
</time-range>
</ace>
</aces>
</acl>
</acls>
A.2. Configuring a PEP Using Group based ACL
This section illustrates an example to configure a PEP using the
group-based ACL.
Ma, et al. Expires 11 September 2023 [Page 36]
Internet-Draft A Policy-based NACL March 2023
The PEP which enforces group-based ACL may acquire group identities
from the AAA server if working as a NAS authenticating both the
source endpoint and the destination endpoint users. Another case for
a PEP enforcing a group-based ACL is to obtain the group identity of
the source endpoint directly from the packet field
[I-D.smith-vxlan-group-policy]. This does not intend to be
exhaustive.
Assume the mapping between device group ID and IP addresses is
predefined or acquired via device authentication. The following
example shows ACL configurations delivered from the controller to the
PEP. This example is consistent with the example presented in
Appendix A.1.
<?xml version="1.0" encoding="utf-8"?>
<acls xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list"
xmlns:uacl="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<acl>
<name>sample-group-acl</name>
<type>uacl:mixed-ipv4-group-type</type>
<endpoint-groups
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<endpoint-group>
<group-id>20</group-id>
<user-group>
<role>R&D</role>
</user-group>
</endpoint-group>
<endpoint-group>
<group-id>22</group-id>
<user-group>
<role>R&D BYOD</role>
</user-group>
</endpoint-group>
</endpoint-groups>
<aces>
<ace>
<name>rule1</name>
<matches>
<endpoint-group
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<source-group-id>22</source-group-id>
<destination-group-id>20</destination-group-id>
</endpoint-group>
</matches>
<actions>
<forwarding>accept</forwarding>
Ma, et al. Expires 11 September 2023 [Page 37]
Internet-Draft A Policy-based NACL March 2023
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<recurrence>
<freq>daily</freq>
<byhour>8</byhour>
<byday>
<weekday>monday</weekday>
</byday>
<byday>
<weekday>tuesday</weekday>
</byday>
<byday>
<weekday>wednesday</weekday>
</byday>
<byday>
<weekday>thursday</weekday>
</byday>
<byday>
<weekday>friday</weekday>
</byday>
<duration>PT10:00:00</duration>
</recurrence>
</time-range>
</ace>
<ace>
<name>rule2</name>
<matches>
<endpoint-group
xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<source-group-id>22</source-group-id>
</endpoint-group>
<ipv4>
<destination-ipv4-network>10.1.1.0/24</destination\
-ipv4-network>
</ipv4>
</matches>
<actions>
<forwarding>reject</forwarding>
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<period-of-time>
<explicit-start>2023-01-20T08:30:00-08:00</explicit-start>
<explicit-end>2023-12-31T18:00:00-08:00</explicit-end>
</period-of-time>
</time-range>
</ace>
</aces>
</acl>
Ma, et al. Expires 11 September 2023 [Page 38]
Internet-Draft A Policy-based NACL March 2023
</acls>
A.3. Configuring the PEP Using Address based ACL
The section illustrates an example of configuring a PEP using IP
address based ACL. IP address based access control policies could be
applied to the PEP that may not understand the group information,
e.g., firewall.
Assume an employee in the R&D department accesses the network
wirelessly from a non-corporate laptop using IP address 192.168.1.10.
The SDN controller associates the user group to which the employee
belongs with the user address according to step 1 to 4 in
Section 4.1.
Assume the mapping between device group ID and IP addresses is
predefined or acquired via device authentication. The following
example shows IPv4 address based ACL configurations delivered from
the controller to the PEP. This example is consistent with the
example presented in Appendix A.1.
<?xml version="1.0" encoding="utf-8"?>
<acls xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-group-acl</name>
<type>ipv4-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<ipv4>
<destination-ipv4-network>192.168.2.1/24</destination\
-ipv4-network>
<source-ipv4-network>192.168.1.1/24</source-ipv4-network>
</ipv4>
</matches>
<actions>
<forwarding>accept</forwarding>
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<recurrence>
<freq>daily</freq>
<byhour>8</byhour>
<byday>
<weekday>monday</weekday>
</byday>
<byday>
Ma, et al. Expires 11 September 2023 [Page 39]
Internet-Draft A Policy-based NACL March 2023
<weekday>tuesday</weekday>
</byday>
<byday>
<weekday>wednesday</weekday>
</byday>
<byday>
<weekday>thursday</weekday>
</byday>
<byday>
<weekday>friday</weekday>
</byday>
<duration>PT10:00:00</duration>
</recurrence>
</time-range>
</ace>
<ace>
<name>rule2</name>
<matches>
<ipv4>
<destination-ipv4-network>10.1.1.0/24</destination\
-ipv4-network>
<source-ipv4-network>192.168.1.1/24</source-ipv4-network>
</ipv4>
</matches>
<actions>
<forwarding>reject</forwarding>
</actions>
<time-range xmlns="urn:ietf:params:xml:ns:yang:ietf-ucl-acl">
<period-of-time>
<explicit-start>2023-01-20T08:30:00-08:00</explicit-start>
<explicit-end>2023-12-31T18:00:00-08:00</explicit-end>
</period-of-time>
</time-range>
</ace>
</aces>
</acl>
</acls>
Appendix B. Changes between Revisions
v01 - v02
* Add more examples.
v00 - v01
* Define a common schedule yang module and reuse in UCL yang module
to support time/date-based activation condition.
Ma, et al. Expires 11 September 2023 [Page 40]
Internet-Draft A Policy-based NACL March 2023
* Either group-based or address-based ACL policies could be enforced
at PEP, and allow group-based ACL policies maintained at the
network controller.
* Optimize the process in section 4.1.
* Extend ACL module to support a generalized endpoint-group to cover
both end users (e.g., enterprise employees) and enterprise hosts
(e.g., IoT devices or servers);
* Simplify the definition of group in UCL model with only the most
necessary group ID retained.
Acknowledgments
This work has benefited from the discussions of User-group-based
Security Policy over the years. In particular,
[I-D.you-i2nsf-user-group-based-policy] and
[I-D.yizhou-anima-ip-to-access-control-groups] provide mechanisms to
establish a mapping between the IP address/prefix of users and access
control group IDs.
Jianjie You, Myo Zarny, Christian Jacquenet, Mohamed Boucadair, and
Yizhou Li contributed to an earlier version of
[I-D.you-i2nsf-user-group-based-policy]. We would like to thank the
authors of that draft on modern network access control mechanisms for
material that assisted in thinking about this document.
The authors would like to thank Joe Clarke, Bill Fenner, Benoit
Claise, Rob Wilton, and David Somers-Harris for their valuable
comments and great input to this work.
Authors' Addresses
Qiufang Ma
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: maqiufang1@huawei.com
Ma, et al. Expires 11 September 2023 [Page 41]
Internet-Draft A Policy-based NACL March 2023
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Jiangsu
210012
China
Email: bill.wu@huawei.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Daniel King
Lancaster University
United Kingdom
Email: d.king@lancaster.ac.uk
Ma, et al. Expires 11 September 2023 [Page 42]