OPSAWG                                                             Q. Ma
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                  Huawei
Expires: 9 December 2023                                    M. Boucadair
                                                                  Orange
                                                                 D. King
                                                    Lancaster University
                                                             7 June 2023


                 A Policy-based Network Access Control
                     draft-ma-opsawg-ucl-acl-03

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 9 December 2023.





Ma, et al.               Expires 9 December 2023                [Page 1]


Internet-Draft             A Policy-based NACL                 June 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
     1.1.  Editorial Note (To be removed by RFC Editor)  . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Sample Usage  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Policy-based Network Access Control . . . . . . . . . . . . .   6
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Endpoint Group  . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  User Group  . . . . . . . . . . . . . . . . . . . . .   8
       4.2.2.  Device Group  . . . . . . . . . . . . . . . . . . . .   9
   5.  Modules Overview  . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  The Schedule YANG Module  . . . . . . . . . . . . . . . .  10
       5.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  The UCL Extension to the ACL Model  . . . . . . . . . . .  14
   6.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  The "ietf-schedule" YANG Module . . . . . . . . . . . . .  16
     6.2.  The "ietf-ucl-acl" YANG Module  . . . . . . . . . . . . .  24
   7.  User Access Control Group ID RADIUS Attribute . . . . . . . .  29
   8.  RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . .  30
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
     9.1.  YANG  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
     9.2.  RADIUS  . . . . . . . . . . . . . . . . . . . . . . . . .  32
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
     10.1.  YANG . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     10.2.  RADIUS . . . . . . . . . . . . . . . . . . . . . . . . .  33
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     11.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Appendix A.  Examples Usage . . . . . . . . . . . . . . . . . . .  37
     A.1.  Configuring the Controller Using Group based ACL  . . . .  37
     A.2.  Configuring a PEP Using Group based ACL . . . . . . . . .  39
     A.3.  Configuring the PEP Using Address based ACL . . . . . . .  41
   Appendix B.  Changes between Revisions  . . . . . . . . . . . . .  43



Ma, et al.               Expires 9 December 2023                [Page 2]


Internet-Draft             A Policy-based NACL                 June 2023


   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44

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) introduces a set of challenges
   for large-scale enterprises 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 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 that 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 (Section 6.1)
   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.  In particular, the
   groupings can be reused by other modules.

   Section 6.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.







Ma, et al.               Expires 9 December 2023                [Page 3]


Internet-Draft             A Policy-based NACL                 June 2023


   The ACL concept has been generalized to be device-nonspecific, and
   can be defined at network/administrative domain level
   [I-D.ietf-netmod-acl-extensions].  To allow for all applications of
   ACLs, the YANG module for policy-based network ACL defined in
   Section 6.2 does not limit how it can be used.

   This document also defines a mechanism to establish a mapping between
   (1) the user group identifier (ID) and (2) common IP packet header
   fields and other encapsulating packet data (e.g., MAC address) to
   execute the policy-based access control.

   Additionally, 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).

   Although the document cites MAC addresses as an example in some
   sections, the document does not make assumptions about which
   identifiers are used to trigger ACLs.  These examples should not be
   considered as recommendations.  Readers should be aware that MAC-
   based ACLs can be bypassed by flushing out the MAC address.  Other
   implications related to the change of MAC addresses are discussed in
   [I-D.ietf-madinas-use-cases].

   The YANG data models in this document conform to the Network
   Management Datastore Architecture (NMDA) defined in [RFC8342].

1.1.  Editorial Note (To be removed by RFC Editor)

   Note to the RFC Editor: This section is to be removed prior to
   publication.

   This document contains placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   Please apply the following replacements:

   *  XXXX --> the assigned RFC number for this draft

   *  YYYY --> the assigned RFC number for [I-D.ietf-netmod-rfc6991-bis]

   *  2023-01-19 --> the actual date of the publication of this document







Ma, et al.               Expires 9 December 2023                [Page 4]


Internet-Draft             A Policy-based NACL                 June 2023


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 following definitions and acronyms defined in
   [RFC8519]:

   *  Access Control Entry (ACE)

   *  Access Control List (ACL)

   The following terms are used throughout this document:

   *  User group based ACL (UCL):  A YANG data model for policy-based
         network access control that specifies an extension to the IETF
         ACL model defined in [RFC8519].  It allows policy enforcement
         based on the group identity, which can be used both at the
         network device level and at the network/administrative domain
         level.

   *  Endpoint:  refers to a host device or end user that actually
         connects to a network.  Host device 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) a user may have
   different source IP addresses in different network segments,
   deploying a network access control policy for each IP address or
   network segment is a 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 9 December 2023                [Page 5]


Internet-Draft             A Policy-based NACL                 June 2023


   The Network ACLs (NACLs) can be provisioned on devices using specific
   mechanisms, such as [RFC8519] or [I-D.ietf-netmod-acl-extensions].

   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

   The architecture of a system that provides real-time and consistent
   enforcement of access control policies is shown in Figure 1.  This
   architecture includes the following functional entities and
   interfaces:

   *  A service orchestrator which coordinates the overall service,
      including security policies.  The service may be connectivity or
      any other access to 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.

   *  The AAA server provides a collection of authentication,
      authorization, and accounting functions.  The AAA server is
      responsible for centralized user information management.  The AAA



Ma, et al.               Expires 9 December 2023                [Page 6]


Internet-Draft             A Policy-based NACL                 June 2023


      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 of [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 [RFC6241] to an SDN controller.

   Figure 1 provides the overall architecture and procedure for policy-
   based access control management.

                                          +------------+
                                          |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



Ma, et al.               Expires 9 December 2023                [Page 7]


Internet-Draft             A Policy-based NACL                 June 2023


   In reference to Figure 1, the following typical flow is experienced:

   Step 1: Administrators (or a service orchestrator) configure an SDN
   controller with network-level ACLs using the YANG module defined in
   Section 6.2.  An example is provided in Appendix A.1.

   Step 2: When a user first logs onto the network, he/she 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 a protocol such as 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 the identity of 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.

   Step 4: Either the AAA server or the NAS notifies an SDN controller
   of 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 SDN controller's
   management.  Whether the PEP enforces the group or IP/MAC address
   based ACL is implementation specific.  Both types of ACL policy 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 is determined by a set of predefined policy criteria
   (e.g., source IP address, geolocation data, time of day, or device
   certificate).  It uses an identifier (user group ID) to represent the
   collective identity of a group of users.  Users may be moved to
   different user-groups if their composite attributes, environment,
   and/or local enterprise policy change.






Ma, et al.               Expires 9 December 2023                [Page 8]


Internet-Draft             A Policy-based NACL                 June 2023


   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 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.

       +============+==========+===================================+
       | 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 a 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.







Ma, et al.               Expires 9 December 2023                [Page 9]


Internet-Draft             A Policy-based NACL                 June 2023


         +================+==========+===========================+
         | 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 an 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 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].

   This module is defined as a standalone module rather than as part of
   the UCL 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.




















Ma, et al.               Expires 9 December 2023               [Page 10]


Internet-Draft             A Policy-based NACL                 June 2023


          module: ietf-schedule

            grouping period:
              +-- period-of-time
                 +-- period-start?            yang:date-and-time
                 +-- (period-type)?
                    +--:(period-explicit)
                    |  +-- period-end?        yang:date-and-time
                    +--:(period-duration)
                       +-- period-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

   The "period-of-time" allows a time period to be represented using
   either a start ("period-start") and end date and time ("period-end"),
   or a start ("period-start") and a positive time duration ("period-
   duration").

   The "recurrence" indicates the scheduling recurrence of an event.
   The repetition can be scoped by a specified end time or by a count of
   occurences, and the frequency identifies the type of recurrence rule.
   For example, a "daily" frequency value specifies repeating events
   based on an interval of a day or more.  The interval represents at
   which intervals the recurrence rule repeats.  For example, within a
   daily recurrence rule, an interval value of "8" means every eight
   days.




Ma, et al.               Expires 9 December 2023               [Page 11]


Internet-Draft             A Policy-based NACL                 June 2023


   An array of the bysecond (or byminut, byhour) specifies a list of
   seconds within a minute (or minutes within an hour, hours of the
   day).

   The parameter "byday" specifies a list of days of the week, with an
   optional direction which indicates the nth occurrence of a specific
   day within the "monthly" or "yearly" frequency.  For example, within
   a "monthly" rule, the "weekday" with a value of "monday" and the
   "direction" with a value of "-1" represents the last Monday of the
   month.

   An array of the "bymonthday" (or byyearday", "byyearweek", or
   "byyearmonth") specifies a list of days of the month (or days of the
   year, weeks of the year, or months of the year).

   The "bysetpos" conveys a list of values that corresponds to the nth
   occurrence within the set of recurrence instances to be specified.
   For example, in a "monthly" recurrence rule, the "byday" data node
   specifies every Monday of the week, the "bysetpos" with value of "-1"
   represents the last Monday of the month.  Not setting the "bysetpos"
   data node represents every Monday of the month.

   The "wkst" data node specifies the day on which the week starts.
   This is significant when a "weekly" recurrence rule has an interval
   greater than 1, and a "byday" data node is specified.  This is also
   significant when in a "yearly" rule and a "byyearweek" is specified.
   The default value is "monday".

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].

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": {
       "period-start": "2023-01-01T08:00:00Z",
       "period-end": "2025-12-01T18:00:00Z"
     }
   }





Ma, et al.               Expires 9 December 2023               [Page 12]


Internet-Draft             A Policy-based NACL                 June 2023


   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": {
       "period-start": "2023-01-01T08:00:00Z",
       "period-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": {
       "period-start": "2023-01-01T08:00:00Z",
       "period-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:

   {
     "recurrence": {
       "freq": "monthly",
       "count": 10,
       "byday": [
         {
           "direction": [-1],
           "weekday": "saturday"
         }
       ]
     }
   }



Ma, et al.               Expires 9 December 2023               [Page 13]


Internet-Draft             A Policy-based NACL                 June 2023


   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]
     }
   }

   The following depicts the example of a recurrence that occurs every
   other week on Tuesday and Sunday, the week starts from Monday:

   {
     "recurrence": {
       "freq": "weekly",
       "interval": 2,
       "byday": [
         { "weekday": "tuesday" },
         { "weekday": "sunday" }
       ],
       "wkst": "monday"
     }
   }

5.2.  The UCL Extension to the ACL Model

   This module specifies an extension to the IETF ACL model [RFC8519].
   This extension adds endpoint groups so that an endpoint group index
   can be matched upon, and also enable access control policy activation
   based on date and time conditions.

   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



Ma, et al.               Expires 9 December 2023               [Page 14]


Internet-Draft             A Policy-based NACL                 June 2023


               +--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
                     +--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




Ma, et al.               Expires 9 December 2023               [Page 15]


Internet-Draft             A Policy-based NACL                 June 2023


   The first part of the data model augments the "acl" list in the IETF
   ACL model [RFC8519] with a "endpoint-groups" container having a list
   of "endpoint group" inside, each entry has a "group-id" that uniquely
   identifies the endpoint group.  The choice statement controls the
   selection of group type between "user-group" or "device-group".

   The second part of the data model augments the "matches" container in
   the IETF ACL model [RFC8519] so that a source and/or destination
   endpoint group index can be referenced as the match criteria.

   The third part of the data model augments the "ace" list in the IETF
   ACL model [RFC8519] with date and time specific parameters to allow
   ACE to be activated based on a date/time condition.  Two types of
   time range are defined, which reuse "recurrence" and "period"
   groupings defined in the "ietf-schedule" YANG module, respectively.
   Note that the data model augments the definition of "recurrence"
   grouping with a "duration" data node to specify the duration of time
   for each occurrence the policy activation is triggered.

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 YYYY: 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



Ma, et al.               Expires 9 December 2023               [Page 16]


Internet-Draft             A Policy-based NACL                 June 2023


        exchanging calendaring and scheduling information. The YANG
        module complies with Sections 3.3.9 and 3.3.10 of RFC 5545.

        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";
     }

     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;



Ma, et al.               Expires 9 December 2023               [Page 17]


Internet-Draft             A Policy-based NACL                 June 2023


           description
             "Thursday of the week.";
         }
         enum friday {
           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 designated by 'W' and days designated by 'D')
          and accurate durations (hours:minutes:seconds follows the
          designator 'T').

          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), Sections 3.3.6 and
                    3.8.6.3";
     }

     grouping period {
       description
         "This grouping is defined for period of time property.";
       reference
         "RFC 5545: Internet Calendaring and Scheduling Core Object
                    Specification (iCalendar), Section 3.3.9";
       container period-of-time {
         description



Ma, et al.               Expires 9 December 2023               [Page 18]


Internet-Draft             A Policy-based NACL                 June 2023


           "This container is defined to identify period values that
            contain a precise period of time.";
         leaf period-start {
           type yang:date-and-time;
           description
             "Period start time.";
         }
         choice period-type {
           description
             "Indicates the type of the time period. Two types are
               supported.";
           case period-explicit {
             description
               "A period of time is identified by its start and its
                end. 'period-start' indicates the period start.";
             leaf period-end {
               type yang:date-and-time;
               description
                 "Period end time.";
             }
           }
           case period-duration {
             description
               "A period of time is defined by a start and a
                positive duration of time.";
             leaf period-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. This value is
                  equivalent to the format of duration type except that
                  the value cannot be negative.";
             }
           }
         }
       }
     }

     grouping recurrence {
       description
         "This grouping is defined to identify properties that contain a
         recurrence rule.";
       reference
         "RFC 5545: Internet Calendaring and Scheduling Core Object
          Specification (iCalendar), Section 3.3.10";
       container recurrence {



Ma, et al.               Expires 9 December 2023               [Page 19]


Internet-Draft             A Policy-based NACL                 June 2023


         description
           "Recurrence rule definition.";
         leaf freq {
           type enumeration {
             enum secondly {
               value 1;
               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;



Ma, et al.               Expires 9 December 2023               [Page 20]


Internet-Draft             A Policy-based NACL                 June 2023


           description
             "This parameter is defined to identify the type of
              recurrence rule.";
         }
         choice recurrence-bound {
           description
             "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.";



Ma, et al.               Expires 9 December 2023               [Page 21]


Internet-Draft             A Policy-based NACL                 June 2023


         }
         leaf-list bysecond {
           type uint32 {
             range "0..60";
           }
           description
             "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 {



Ma, et al.               Expires 9 December 2023               [Page 22]


Internet-Draft             A Policy-based NACL                 June 2023


             range "-31..-1|1..31";
           }
           description
             "Specifies a list of days of the month.";
         }
         leaf-list byyearday {
           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 by the rule part.";
         }
         leaf wkst {
           type schedule:weekday;
           default "monday";
           description
             "Specifies the day on which the workweek starts.";
         }
       }
     }
   }
   <CODE ENDS>




Ma, et al.               Expires 9 December 2023               [Page 23]


Internet-Draft             A Policy-based NACL                 June 2023


6.2.  The "ietf-ucl-acl" YANG Module

   This module imports types and groupings defined in the "ietf-
   schedule" YANG module in Section 6.1.  It also augments the IETF ACL
   YANG module defined in [RFC8519].

   <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.";



Ma, et al.               Expires 9 December 2023               [Page 24]


Internet-Draft             A Policy-based NACL                 June 2023


     revision 2023-01-19 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: A Policy-based Network Access Control";
     }

     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,



Ma, et al.               Expires 9 December 2023               [Page 25]


Internet-Draft             A Policy-based NACL                 June 2023


          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 {
       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
         "Adds 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 {



Ma, et al.               Expires 9 December 2023               [Page 26]


Internet-Draft             A Policy-based NACL                 June 2023


               range "0..4294967294";
             }
             description
               "The endpoint group ID that uniquely identifies an
                endpoint group.";
           }
           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
                     "Specifies 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
         "Specifies how a source and/or destination endpoint group index
          can be referenced as the match criteria in the ACEs.";
       container endpoint-group {
         when "derived-from-or-self(/acl:acls/acl:acl/acl:type, "
            + "'uacl:group-acl-type')";



Ma, et al.               Expires 9 December 2023               [Page 27]


Internet-Draft             A Policy-based NACL                 June 2023


         if-feature "match-on-group";
         description
           "Add new match types.";
         leaf source-group-id {
           type leafref {
             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]';



Ma, et al.               Expires 9 December 2023               [Page 28]


Internet-Draft             A Policy-based NACL                 June 2023


                   }
                   description
                     "A duration of time in terms of days when policies
                      are activated in each occurrence.";
                 }
               }
             }
           }
           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.



Ma, et al.               Expires 9 December 2023               [Page 29]


Internet-Draft             A Policy-based NACL                 June 2023


   The User-Access-Group-ID Attribute is structured as follows:

   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 9 December 2023               [Page 30]


Internet-Draft             A Policy-based NACL                 June 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.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   *  /acl:acls/acl:acl/uacl:endpoint-groups/uacl:endpoint-group:  This
         list specifies all the endpoint group entries.  Unauthorized
         write access to this list can allow intruders to modify the
         entries so as to forge an endpoint group that does not exist or
         maliciously delete an existing endpoint group, which could be
         used to craft an attack.

   *  /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/uacl:endpoint-
      group:  This subtree specifies a source and/or endpoint group
         index as match criteria in the ACEs.  Unauthorized write access
         to this data node may allow intruders to modify the group
         identity so as to permit access that should not be permitted,
         or deny access that should be permitted.








Ma, et al.               Expires 9 December 2023               [Page 31]


Internet-Draft             A Policy-based NACL                 June 2023


  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:

   *  /acl:acls/acl:acl/acl:aces/acl:ace/uacl:time-range:  This subtree
         specifies when the access control entry rules are in effect.
         An unauthorized read access of the list will allow the attacker
         to determine which rules are in effect, to better craft an
         attack.

9.2.  RADIUS

   RADIUS-related security considerations are discussed in [RFC2865].

   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].













Ma, et al.               Expires 9 December 2023               [Page 32]


Internet-Draft             A Policy-based NACL                 June 2023


           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

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>.






Ma, et al.               Expires 9 December 2023               [Page 33]


Internet-Draft             A Policy-based NACL                 June 2023


   [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>.

   [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>.

   [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>.



Ma, et al.               Expires 9 December 2023               [Page 34]


Internet-Draft             A Policy-based NACL                 June 2023


   [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.ietf-madinas-use-cases]
              Henry, J. and Y. Lee, "Randomized and Changing MAC Address
              Use Cases and Requirements", Work in Progress, Internet-
              Draft, draft-ietf-madinas-use-cases-05, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
              use-cases-05>.

   [I-D.ietf-netmod-acl-extensions]
              de Dios, O. G., Barguil, S., Boucadair, M., and Q. Wu,
              "Extensions to the Access Control Lists (ACLs) YANG
              Model", Work in Progress, Internet-Draft, draft-ietf-
              netmod-acl-extensions-01, 10 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              acl-extensions-01>.

   [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-



Ma, et al.               Expires 9 December 2023               [Page 35]


Internet-Draft             A Policy-based NACL                 June 2023


              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>.

   [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>.

   [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>.





Ma, et al.               Expires 9 December 2023               [Page 36]


Internet-Draft             A Policy-based NACL                 June 2023


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.

   The following example illustrates the configuration of an SDN
   controller using the group-based ACL:

   =============== NOTE: '\' line wrapping per RFC 8792 ================

   <?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&amp;D</role>
           </user-group>
         </endpoint-group>
         <endpoint-group>
           <group-id>22</group-id>
           <user-group>
             <role>R&amp;D BYOD</role>
           </user-group>
         </endpoint-group>
         <endpoint-group>
           <group-id>50</group-id>
           <device-group>



Ma, et al.               Expires 9 December 2023               [Page 37]


Internet-Draft             A Policy-based NACL                 June 2023


             <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>
               <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>



Ma, et al.               Expires 9 December 2023               [Page 38]


Internet-Draft             A Policy-based NACL                 June 2023


           </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.

   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 example 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.

   =============== NOTE: '\' line wrapping per RFC 8792 ================

   <?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>



Ma, et al.               Expires 9 December 2023               [Page 39]


Internet-Draft             A Policy-based NACL                 June 2023


           <user-group>
             <role>R&amp;D</role>
           </user-group>
         </endpoint-group>
         <endpoint-group>
           <group-id>22</group-id>
           <user-group>
             <role>R&amp;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>
           </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>



Ma, et al.               Expires 9 December 2023               [Page 40]


Internet-Draft             A Policy-based NACL                 June 2023


           <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>
   </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.







Ma, et al.               Expires 9 December 2023               [Page 41]


Internet-Draft             A Policy-based NACL                 June 2023


   =============== NOTE: '\' line wrapping per RFC 8792 ================

   <?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>
                 <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>



Ma, et al.               Expires 9 December 2023               [Page 42]


Internet-Draft             A Policy-based NACL                 June 2023


               <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.

   *  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.








Ma, et al.               Expires 9 December 2023               [Page 43]


Internet-Draft             A Policy-based NACL                 June 2023


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


   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







Ma, et al.               Expires 9 December 2023               [Page 44]


Internet-Draft             A Policy-based NACL                 June 2023


   Daniel King
   Lancaster University
   United Kingdom
   Email: d.king@lancaster.ac.uk















































Ma, et al.               Expires 9 December 2023               [Page 45]