Network Access Control List (ACL) YANG Data
ModelVolta Networksivandean@gmail.comCisco Systems, Incmjethanandani@gmail.comGeneral Electriclyihuang16@gmail.comCisco Systems, Inc.agarwaso@cisco.comCisco Systems, INcdblair@cisco.com
Operations and Management Area
NETMOD WGThis document describes a data model of Access Control List (ACL)
basic building blocks.Editorial Note (To be removed by RFC Editor)This draft contains many 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. Please note that no other RFC
Editor instructions are specified anywhere else in this document.Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements"XXXX" --> the assigned RFC value for this draft.Revision date in model (Oct 12, 2016) needs to get updated with
the date the draft gets approved. The date also needs to get
reflected on the line with <CODE BEGINS>.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 can have metadata match criteria as well.Packet header matches apply to fields visible in the packet such
as address or class of service or port numbers.In case vendor supports it, 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 used interchangeably.The matching of filters and actions in an ACE/ACL are triggered only
after application/attachment of the ACL to an interface, VRF, vty/tty
session, QoS policy, routing protocols amongst various other config
attachment points. Once attached, it is used for filtering traffic using
the match criteria in the ACE's and taking appropriate action(s) that
have been configured against that ACE. In order to apply an ACL to any
attachment point, vendors would have to augment the ACL YANG model.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 used by applications/attachments.ACL implementations in every device may vary greatly in terms of the
filter constructs and actions that they support. Therefore this draft
proposes a 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. It as also possible for ACE
to match on metadata, if supported by the vendor. 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 simple and with this design we hope to achieve enough
flexibility for each vendor to extend the base model. The use of feature
statements in the document allows vendors to advertise match rules they
support.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".
The combination of if-feature checks and must statements allow for the
selection of relevant match fields that a user can define rules
for.If there is a need to define new "matches" choice, such as IPFIX, the container "matches" can be
augmented.For a reference to the annotations used in the diagram below, see
YANG Tree
Diagrams."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. In addition to permit and deny for
actions, a logging option allows for a match to be logged that can be
used to determine which rule was matched upon.The packet fields module defines the necessary groups for matching
on fields in the packet including ethernet, ipv4, ipv6, and transport
layer fields. The 'acl-type' node determines which of these fields get
included for any given ACL with the exception of TCP, UDP and ICMP
header fields. Those fields can be used in conjunction with any of the
above layer 2 or layer 3 fields.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 model.Requirement: Deny tcp traffic from 10.10.10.1/24, destined to
11.11.11.1/24.Here is the acl configuration xml for this Access Control List:The acl and aces can be described in CLI as the following: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 and less
than equal to 65535.With the follow XML snippet:This represents port 21.The YANG module defined in this memo is designed to be accessed via
the NETCONF . The lowest NETCONF layer is
the secure transport layer and the mandatory-to-implement secure
transport is SSH. The NETCONF Access
Control Model ( NACM) 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 . Following the format in RFC 3688, the following
registration is requested to be made:URI: urn:ietf:params:xml:ns:yang:ietf-access-control-listURI: urn:ietf:params:xml:ns:yang:ietf-packet-fieldsRegistrant 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 XXXXname: ietf-packet-fields namespace:
urn:ietf:params:xml:ns:yang:ietf-packet-fields prefix:
ietf-packet-fields reference: RFC XXXXAlex 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, and David Bannister for their review of and suggestions to
the draft.The current model does not support the concept of "containers"
used to contain multiple addresses per rule entry.The current model defines 'any' rule as a presence container,
allowing a user to define any 'any' rule.The model defines 'ether-type' node as a string. Ideally, this
should be a well defined list of all Ethernet Types assigned by
IEEE.Should this draft include route-policy definition as defined in
draft-ietf-rtgwg-policy-model?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.Access 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.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, as well how
to attach an Access Control List to an interface. 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 two new choices,
protocol-payload-choice and metadata. The protocol-payload-choice uses
a grouping with an enumeration of all supported protocol values.
Metadata matches apply to fields associated with the packet but not in
the packet header such as input interface or overall packet length. 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 modelAs 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: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.The example in can be configured using
nftable tool as below.The configuration entries added in nftable would be.We can see that there are many similarities between Linux nftables
and IETF ACL YANG data models and its extension models. It should be
fairly easy to do translation between ACL YANG model described in this
draft and Linux nftables.