Network Access Control List (ACL) YANG Data
Modelmjethanandani@gmail.comGeneral Electriclyihuang16@gmail.comCisco Systems, Inc.sagarwal12@gmail.comCisco Systems, Inc.dblair@cisco.com
Operations and Management Area
NETMOD WGThis document defines a data model for Access Control List (ACL). ACL
is a ordered-by-user set of rules, used to configure the forwarding
behavior in device. Each rule is used to find a match on a packet, and
define actions that will be performed on the packet.Access Control List (ACL) is one of the basic elements used to
configure device forwarding behavior. It is used in many networking
technologies such as Policy Based Routing, Firewalls etc.An ACL is an ordered-by-user 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 capabilities 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 other than an interface, vendors would have to augment
the ACL YANG model.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 both in this
draft and in the YANG models under the revision statement.Revision date in model, in the format 2018-03-03 needs to get
updated with the date the draft gets approved. The date also needs
to get reflected on the line with <CODE BEGINS>.Replace "I-D.ietf-netmod-yang-tree-diagrams" with the assigned
RFC number.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 ProtocolUDP: User Datagram ProtocolThe 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 when,
and only when, they appear in all capitals, as shown here.This document defines a YANG data model
for the configuration of ACLs. It is very important that model can be
used easily 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 Control Entries (ACE). 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 model allows vendors to
advertise match rules they are capable and willing to support. There are
two sets of feature statements a device needs to advertise. The first
set of feature statements specify the capability of the device. These
include features such as "Device can support ethernet headers" or
"Device can support of IPv4 headers". The second set of feature
statements specify the combinations of headers the device is willing to
support. These include features such as "Plain IPv6 ACL supported" or
"Ethernet, IPv4 and IPv6 ACL combinations supported".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"
to specify match fields such as port numbers or protocol. 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
("name") and a list ("aces") of rules associated with the "name". Each
of the entries in the list ("aces"), indexed by the string "name", has
containers defining "matches" and "actions".The model defines several ACL types and actions in the form of
identities and features. Features are used by implementors to select
the ACL types the system can support and identities are used to
validate the types that have been selected. These types are implicitly
inherited by the "ace", thus safeguarding against misconfiguration of
"ace" types in an "acl".The "matches" define criteria used to identify patterns in
"ietf-packet-fields". The choice statements within the match container
allow for selection of one header within each of "l2", "l3", or "l4"
headers. 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 model also defines the ability for
ACL's to be attached to a particular interface.Statistics in the ACL can be collected for an "ace" or for an
"interface". The feature statements defined for statistics can be used
to determine whether statistics are being collected per "ace", or per
"interface".This module imports definitions from Common
YANG Data Types, and A YANG Data Model for Interface
Management.The packet fields module defines the necessary groups for matching
on fields in the packet including ethernet, ipv4, ipv6, and transport
layer fields. The "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.This module imports definitions from Common
YANG Data Types and references IP, ICMP, Definition of the Differentiated Services Field in
the IPv4 and IPv6 Headers, The Addition
of Explicit Congestion Notification (ECN) to IP, , IPv6 Scoped Address Architecture, IPv6 Addressing Architecture, A Recommendation for IPv6 Address Text
Representation, IPv6.Requirement: Deny tcp traffic from 192.0.2.0/24, destined to
198.51.100.0/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 example:This represents source ports 16384, 16385, 16386, and 16387.With the follow XML example:This represents source ports greater than or equal to 16384 and
less than equal to 65535.With the follow XML example:This represents port 21.With the following XML example, the configuration is specifying all
ports that are not equal to 21.The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocol such as
NETCONF or RESTCONF. The lowest NETCONF layer is the secure
transport layer and the mandatory-to-implement secure transport is SSH. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS.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/aces: This list specifies all the configured
access control 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 three URIs and three YANG module.This document registers three URI in the IETF XML registry . Following the format in
RFC 3688, the following registration is requested to be made:Registrant Contact: The IESG.XML: N/A, the requested URI is an XML namespace.This document registers three YANG module in the YANG Module Names
registry YANG.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 drafts separately, and
then worked together to created a ACL draft that was supported by
different vendors. That draft removed vendor specific features, and gave
examples to allow vendors to extend in their own proprietary ACL. The
earlier draft was superseded with this updated draft and received more
participation from many vendors.Authors would like to thank Jason Sterne, Lada Lhotka, Juergen
Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar
Nilsen-Nygaard for their review of and suggestions to the draft.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 are found. All these
are company proprietary extensions or system feature extensions.
"example-newco-acl" is just an example and it is expected that vendors
will 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:aces/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 overall packet length. In other example,
/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:actions
are augmented with new choice of actions.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.The ACL module is dependent on the definition of ethertypes. IEEE
owns the allocation of those ethertypes. This model is being included
here to enable definition of those types till such time that IEEE
takes up the task of publication of the model that defines those
ethertypes. At that time, this model can be deprecated.