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). An
ACL is a user-ordered 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 user-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 allows for definition of packet headers and
metadata, all of which must be true for the match to occur.Packet header matches apply to fields visible in the packet such
as address or Class of Service (CoS) or port numbers.In case a 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 unbounded depending on the capabilities of the
networking 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-04-27 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 ListCoS: Class of ServiceDSCP: 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.For a reference to the annotations used in tree diagrams included
in this draft, please see YANG Tree
Diagrams.This document defines a YANG 1.1 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 has 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 allows for definition of packet headers or metadata, if
supported by the vendor. Packet header matching applies to fields
visible in the packet such as address or CoS 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 interface of a networking
device, applications or features running in the device, etc. When
applied to interfaces of a networked device, distinct ACLs are defined
for the ingress (input) or egress (output) interface.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 in design, and 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 a new "matches" choice, such as IPFIX, the container "matches" can be
augmented."ietf-access-control-list" module defines the "acls" container that
has 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 later be used to
determine which rule was matched upon. The model also defines the
ability for ACLs 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'
statement 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:Requirement: Accept all DNS traffic destined for 2001:db8::/32 on
port 53.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 included. When only a port is present, it represents a
port, with the operator specifying the range.The following XML example represents a configuration where TCP
traffic from source ports 16384, 16385, 16386, and 16387 is
dropped.The following XML example represents a configuration where all IPv4
ICMP echo requests are dropped.The following XML example represents a configuration of a single
port, port 21 that accepts TCP traffic.The following XML example represents a configuration specifying all
ports that are not equal to 21, that will drop TCP packets destined
for those ports.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:/acls/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 modules.This document registers three URIs 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 diagram of example-newco-acl. In
this example,
/ietf-acl:acls/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 another example,
/ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:actions
are augmented with a 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.