Network Access Control List (ACL) YANG Data Modelivandean@gmail.comCisco Systemskkoushik@cisco.comJuniper Networkslyihuang@juniper.netCisco Systemsdblair@cisco.com
Operations and Management Area
NETMOD WGThis document describes a data model of Access Control List (ACL) basic building blocks.
Access Control List (ACL) is one of the basic elements to configure
device forwarding behavior. It is used in many networking concepts
such as Policy Based Routing, Firewalls etc.An ACL is an ordered set of rules that is used to filter traffic on a
networking device. Each rule is represented by an Access Control
Entry (ACE).Each ACE has a group of match criteria and a group of action criteria.The match criteria consist of a tuple of packet header match criteria and metadata match criteria.Packet header matches apply to fields visible in the packet such as
address or class of service or port numbers.Metadata matches apply to fields associated with the packet but
not in the packet header such as input interface or overall packet lengthThe actions specify what to do with the packet when the matching criteria is
met. These actions are any operations that would apply to the packet, such as counting, policing, or simply
forwarding.The list of potential actions is endless depending on the
innovations of the networked devices.Access Control List is also widely knowns as ACL (pronounce as [ak-uh l]) or Access List.
In this document, Access Control List, ACL and Access List are interchangeable.ACE: Access Control EntryACL: Access Control ListDSCP: Differentiated Services Code PointICMP: Internet Control Message ProtocolIP: Internet ProtocolIPv4: Internet Protocol version 4IPv6: Internet Protocol version 6MAC: Media Access ControlTCP: Transmission Control ProtocolThis document defines a YANG data model for the
configuration of ACLs. It is very important that model can be easily reused
between vendors and between applications.ACL implementations in every device may vary greatly in terms of the
filter constructs and actions that they support. Therefore this draft
proposes a simple model that can be augmented by standard extensions and
vendor proprietary models. Although different vendors have different ACL data models, there is a
common understanding of what access control list (ACL) is. A network
system usually have a list of ACLs, and each ACL contains an ordered
list of rules, also known as access list entries – ACEs. Each ACE has
a group of match criteria and a group of action criteria. The match
criteria consist of packet header matching and metadata matching.
Packet header matching applies to fields visible in the packet such
as address or class of service or port numbers. Metadata matching
applies to fields associated with the packet, but not in the packet
header such as input interface, packet length, or source or destination
prefix length. The actions can be any sort of operation from logging to
rate limiting or dropping to simply forwarding. Actions on the first
matching ACE are applied with no processing of subsequent ACEs. The
model also includes a container to hold overall operational state
for each ACL and operational state for each ACE. One ACL can be applied
to multiple targets within the device, such as interfaces of a networked
device, applications or features running in the device, etc. When applied
to interfaces of a networked device, the ACL is applied in a direction
which indicates if it should be applied to packet entering (input) or
leaving the device (output). An example in the appendix shows how to express
it in YANG model.This draft tries to address the commonalities between all vendors and
create a common model, which can be augmented with proprietary models.
The base model is very simple and with this design we hope to achieve
needed flexibility for each vendor to extend the base model.There are two YANG modules in the model. The first module, "ietf-access-control-list",
defines generic ACL aspects which are common to all ACLs regardless
of their type or vendor. In effect, the module can be viewed as
providing a generic ACL "superclass". It imports the second module,
"ietf-packet-fields". The match container in "ietf-access-control-list" uses groupings
in "ietf-packet-fields". If there is a need to define new "matches"
choice, such as IPFIX , the container "matches"
can be augmented."ietf-access-control-list" is the standard top level module for access
lists. The "access-lists" container stores a list of "acl". Each
"acl" has information identifying the access list by a name("acl-name")
and a list("access-list-entries") of rules associated
with the "acl-name". Each of the entries in the
list("access-list-entries"),
indexed by the string "rule-name", has containers
defining "matches" and "actions". The "matches" define criteria used to
identify patterns in "ietf-packet-fields". The "actions" define behavior
to undertake once a "match" has been identified.The packet fields module defines the necessary groups for matching on
fields in the packet including ethernet, ipv4, ipv6, transport layer
fields and metadata. Since the number of match criteria is
very large, the base draft does not include these directly but
references them by "uses" to keep the base module simple. In case more
match conditions are needed, those can be added by augmenting choices
within container "matches" in ietf-access-control-list.yang modelRequirement: Deny All traffic from 10.10.10.1 bound for host 10.10.10.255 from leaving.In order to achieve the requirement, an name Access Control List is needed. The acl and
aces can be described in CLI as the following:Here is the example acl configuration xml:
When a lower-port and an upper-port are both present, it represents a
range between lower-port and upper-port with both the lower-port and
upper-port are included. When only a lower-port presents, it represents
a single port.
With the follow XML snippet:
This represents source ports 16384,16385, 16386, and 16387.
With the follow XML snippet:
This represents source ports greater than/equal to 16384.With the follow XML snippet:
This represents port 21.
As Linux platform is becoming more popular as networking platform,
the Linux data model is changing. Previously ACLs in Linux were highly
protocol specific and different utilities were used (iptables,
ip6tables, arptables, ebtables), so each one had separate data model.
Recently, this has changed and a single utility, nftables, has been
developed. With a single application, it has a single data model for
filewall filters and it follows very similarly to the ietf-access-control
list module proposed in this draft. The nftables support input and output
ACEs and each ACE can be defined with match and action.
In the example below, it shows nftable configuration that accepts and
count packets. It contains a
There are many similarities between Linux nftables and IETF ACL
YANG data models. It should be fairly easy to do translation between
ACL YANG model described in this draft and Linux nftables.The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241] . The lowest
NETCONF layer is the secure transport layer and the mandatory-to-implement
secure transport is SSH [RFC6242] . The NETCONF
access control model [RFC6536] provides the means
to restrict access for particular NETCONF users to a pre-configured
subset of all available NETCONF protocol operations and content.There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., <edit-config>) to
these data nodes without proper protection can have a negative effect on
network operations.These are the subtrees and data nodes and their sensitivity/vulnerability:/access-lists/acl/access-list-entries: This list
specifies all the configured access list entries on the device.
Unauthorized write access to this list can allow intruders to access and
control the system. Unauthorized read access to this list can allow
intruders to spoof packets with authorized addresses thereby
compromising the system.This document registers a URI in the IETF XML registry [RFC3688] .
Following the format in RFC 3688, the following registration is
requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.This document registers a YANG module in the YANG Module Names
registry [RFC6020].name: ietf-access-control-list
namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list
prefix: ietf-acl
reference: RFC XXXX
name: ietf-packet-fields
namespace: urn:ietf:params:xml:ns:yang:ietf-packet-fields
prefix: ietf-packet-fields
reference: RFC XXXX
Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out
an initial IETF draft in several past IETF meetings. That draft included
an ACL YANG model structure and a rich set of match filters, and
acknowledged contributions by Louis Fourie, Dana Blair, Tula Kraiser,
Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, and Phil Shafer.
Many people have reviewed the various earlier drafts that made the draft
went into IETF charter.
Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana Blair
each evaluated the YANG model in previous draft separately and then work
together, to created a new ACL draft that can be supported by different
vendors. The new draft removes vendor specific features, and gives
examples to allow vendors to extend in their own proprietary ACL. The
earlier draft was superseded with the new one that received more
participation from many vendors.
Authors would like to thank Jason Sterne, Lada Lhotka, Juergen
Schoenwalder for their review of and suggestions to the draft.With proposed modular design, it is easy to extend the model with
other features. Those features can be standard features, like route
filters. Route filters match on specific IP addresses or ranges of
prefixes. Much like ACLs, they include some match criteria and
corresponding match action(s). For that reason, it is very simple to
extend existing ACL model with route filtering. The combination of a
route prefix and prefix length along with the type of match determines
how route filters are evaluated against incoming routes. Different
vendors have different match types and in this model we are using only
ones that are common across all vendors participating in this draft.
As in this example, the base ACL model can be extended with company
proprietary extensions, described in the next section.
Module "example-newco-acl" is an example of company proprietary
model that augments "ietf-acl" module. It shows how to use 'augment'
with an XPath expression to add additional match criteria, action
criteria, and default actions when no ACE matches found. All these
are company proprietary extensions or system feature extensions.
"example-newco-acl" is just an example and it is expected from
vendors to create their own proprietary models.The following figure is the tree structure of example-newco-acl.
In this example,
/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/
ietf-acl:ace/ietf-acl:matches
are augmented with a new choice, protocol-payload-choice.
The protocol-payload-choice uses a grouping with an enumeration of
all supported protocol values. In other example,
/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/
ietf-acl:ace/ietf-acl:actions
are augmented with new choice of actions.Draft authors expect that different vendors will provide their own
yang models as in the example above, which is the augmentation of the
base modelAccess control list typically does not exist in isolation. Instead,
they are associated with a certain scope in which they are applied,
for example, an interface of a set of interfaces. How to attach an
access control list to an interface (or other system artifact)
is outside the scope of this model, as it depends on the specifics of the
system model that is being applied. However, in general, the general
design pattern will involved adding a data node with a reference, or set
of references, to ACLs that are to be applied to the interface. For this
purpose, the type definition "access-control-list-ref" can be used.This is an example of attaching an Access Control List to an
interface.As vendors (or IETF) add more features to ACL, the model is
easily augmented. One of such augmentations can be to add
support for mixed type of ACLs, where acl-type-base can be
augmented like in example below: