Network Access Control List (ACL) YANG Data
ModelVMwaremjethanandani@gmail.comCisco Systems, Inc.sagarwal12@gmail.comhuangyi_99@yahoo.comdana@blairhome.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 (PBR), 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 actions.The match criteria allow for definition of packet headers and
metadata, the contents of which must match the definitions.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 length of the packet as received over the
wire.The actions specify what to do with the packet when the matching
criteria are 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 the application/attachment of the ACL to an interface, VRF,
vty/tty session, QoS policy, or routing protocols, amongst various other
configuration attachment points. Once attached, it is used for filtering
traffic using the match criteria in the ACEs 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-10-01 needs to get
updated with the date the draft gets approved. The date also needs
to get reflected on the line with <CODE BEGINS>.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 ControlPBR: Policy Based RoutingTCP: 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 application/attachment models.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 actions. The match criteria allow
for definition of contents of the 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 matching on Ethernet
headers" or "Device can support matching on 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 are 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, TCP, 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 modify the entries so as to permit
traffic that should not be permitted, or deny traffic that should be
permitted. The former may result in a DoS attack, or compromise the
device. The latter may result in a DoS attack. The impact of an
unauthorized read access of the list will allow the attacker to
determine which rules are in effect, to better craft an attack./acls/acl/aces/ace/actions/logging: This node specifies ability
to log packets that match this ace entry. Unauthorized write access
to this node can allow intruders to enable logging on one or many
ace entries, overwhelming the server in the process. Unauthorized
read access of this node can allow intruders to access logging
information, which could be used to craft an attack the server.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, actions,
and default actions for 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.