draft-ietf-netmod-acl-model-15.txt   draft-ietf-netmod-acl-model-16.txt 
NETMOD WG M. Jethanandani NETMOD WG M. Jethanandani
Internet-Draft Internet-Draft
Intended status: Standards Track L. Huang Intended status: Standards Track L. Huang
Expires: July 20, 2018 General Electric Expires: August 6, 2018 General Electric
S. Agarwal S. Agarwal
Cisco Systems, Inc. Cisco Systems, Inc.
D. Blair D. Blair
Cisco Systems, INc Cisco Systems, INc
January 16, 2018 February 2, 2018
Network Access Control List (ACL) YANG Data Model Network Access Control List (ACL) YANG Data Model
draft-ietf-netmod-acl-model-15 draft-ietf-netmod-acl-model-16
Abstract Abstract
This document describes a data model of Access Control List (ACL) This document describes a data model of Access Control List (ACL)
basic building blocks. basic building blocks.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2018. This Internet-Draft will expire on August 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Understanding ACL's Filters and Actions . . . . . . . . . . . 4 3. Understanding ACL's Filters and Actions . . . . . . . . . . . 4
3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 5
4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 9 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. IETF Access Control List module . . . . . . . . . . . . . 9 4.1. IETF Access Control List module . . . . . . . . . . . . . 9
4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 22 4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 23
4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 33 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 35
4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 34 4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Extending ACL model examples . . . . . . . . . . . . 42
Appendix A. Extending ACL model examples . . . . . . . . . . . . 38 A.1. A company proprietary module example . . . . . . . . . . 42
A.1. A company proprietary module example . . . . . . . . . . 38 A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 45
A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 42 A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 46
A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Access Control List (ACL) is one of the basic elements used to Access Control List (ACL) is one of the basic elements used to
configure device forwarding behavior. It is used in many networking configure device forwarding behavior. It is used in many networking
technologies such as Policy Based Routing, Firewalls etc. technologies such as Policy Based Routing, Firewalls etc.
An ACL is an ordered-by-user set of rules that is used to filter 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 traffic on a networking device. Each rule is represented by an
Access Control Entry (ACE). Access Control Entry (ACE).
skipping to change at page 3, line 30 skipping to change at page 3, line 30
o Packet header matches apply to fields visible in the packet such o Packet header matches apply to fields visible in the packet such
as address or class of service or port numbers. as address or class of service or port numbers.
o In case vendor supports it, metadata matches apply to fields o In case vendor supports it, metadata matches apply to fields
associated with the packet but not in the packet header such as associated with the packet but not in the packet header such as
input interface or overall packet length input interface or overall packet length
The actions specify what to do with the packet when the matching The actions specify what to do with the packet when the matching
criteria is met. These actions are any operations that would apply criteria is met. These actions are any operations that would apply
to the packet, such as counting, policing, or simply forwarding.The to the packet, such as counting, policing, or simply forwarding. The
list of potential actions is endless depending on the capabilities of list of potential actions is endless depending on the capabilities of
the networked devices. the networked devices.
Access Control List is also widely knowns as ACL (pronounce as [ak-uh 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 l]) or Access List. In this document, Access Control List, ACL and
Access List are used interchangeably. Access List are used interchangeably.
The matching of filters and actions in an ACE/ACL are triggered only 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 after application/attachment of the ACL to an interface, VRF, vty/tty
session, QoS policy, routing protocols amongst various other config session, QoS policy, routing protocols amongst various other config
skipping to change at page 4, line 20 skipping to change at page 4, line 20
IPv4: Internet Protocol version 4 IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6 IPv6: Internet Protocol version 6
MAC: Media Access Control MAC: Media Access Control
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
2. Problem Statement 2. Problem Statement
This document defines a YANG [RFC6020] data model for the This document defines a YANG [RFC7950] data model for the
configuration of ACLs. It is very important that model can be used configuration of ACLs. It is very important that model can be used
easily by applications/attachments. easily by applications/attachments.
ACL implementations in every device may vary greatly in terms of the ACL implementations in every device may vary greatly in terms of the
filter constructs and actions that they support. Therefore this filter constructs and actions that they support. Therefore this
draft proposes a model that can be augmented by standard extensions draft proposes a model that can be augmented by standard extensions
and vendor proprietary models. and vendor proprietary models.
3. Understanding ACL's Filters and Actions 3. Understanding ACL's Filters and Actions
skipping to change at page 5, line 14 skipping to change at page 5, line 14
applied in a direction which indicates if it should be applied to applied in a direction which indicates if it should be applied to
packet entering (input) or leaving the device (output). An example packet entering (input) or leaving the device (output). An example
in the appendix shows how to express it in YANG model. in the appendix shows how to express it in YANG model.
This draft tries to address the commonalities between all vendors and This draft tries to address the commonalities between all vendors and
create a common model, which can be augmented with proprietary create a common model, which can be augmented with proprietary
models. The base model is simple and with this design we hope to models. The base model is simple and with this design we hope to
achieve enough flexibility for each vendor to extend the base model. achieve enough flexibility for each vendor to extend the base model.
The use of feature statements in the model allows vendors to The use of feature statements in the model allows vendors to
advertise match rules they are capable and willing support. There advertise match rules they are capable and willing to support. There
are two sets of feature statements a device needs to advertise. The are two sets of feature statements a device needs to advertise. The
first set of feature statements specify the capability of the device. first set of feature statements specify the capability of the device.
These include features such as "Device can support ethernet headers" These include features such as "Device can support ethernet headers"
or "Device can support of IPv4 headers". The second set of feature or "Device can support of IPv4 headers". The second set of feature
statements specify the combinations of headers the device is willing statements specify the combinations of headers the device is willing
to support. These include features such as "Plain IPv6 ACL to support. These include features such as "Plain IPv6 ACL
supported" or "Ethernet, IPv4 and IPv6 ACL combinations supported". supported" or "Ethernet, IPv4 and IPv6 ACL combinations supported".
3.1. ACL Modules 3.1. ACL Modules
skipping to change at page 6, line 18 skipping to change at page 6, line 18
| | | | yang:mac-address | | | | yang:mac-address
| | | +--rw source-mac-address? | | | +--rw source-mac-address?
| | | | yang:mac-address | | | | yang:mac-address
| | | +--rw source-mac-address-mask? | | | +--rw source-mac-address-mask?
| | | | yang:mac-address | | | | yang:mac-address
| | | +--rw ethertype? | | | +--rw ethertype?
| | | eth:ethertype | | | eth:ethertype
| | +--rw (l3)? | | +--rw (l3)?
| | | +--:(ipv4) | | | +--:(ipv4)
| | | | +--rw ipv4 {match-on-ipv4}? | | | | +--rw ipv4 {match-on-ipv4}?
| | | | +--rw dscp? | | | | +--rw dscp? inet:dscp
| | | | | inet:dscp | | | | +--rw ecn? uint8
| | | | +--rw ecn? | | | | +--rw length? uint16
| | | | | uint8 | | | | +--rw ttl? uint8
| | | | +--rw length? | | | | +--rw protocol? uint8
| | | | | uint16 | | | | +--rw ihl? uint8
| | | | +--rw ttl? | | | | +--rw flags? bits
| | | | | uint8 | | | | +--rw offset? uint16
| | | | +--rw protocol? | | | | +--rw identification? uint16
| | | | | uint8 | | | | +--rw (destination-network)?
| | | | +--rw source-port-range-or-operator | | | | | +--:(destination-ipv4-network)
| | | | | +--rw (port-range-or-operator)? | | | | | +--rw destination-ipv4-network?
| | | | | +--:(range) | | | | | inet:ipv4-prefix
| | | | | | +--rw lower-port inet:port-numb | | | | +--rw (source-network)?
er | | | | +--:(source-ipv4-network)
| | | | | | +--rw upper-port inet:port-numb | | | | +--rw source-ipv4-network?
er | | | | inet:ipv4-prefix
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port inet:port-numb
er
| | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port inet:port-numb
er
| | | | | | +--rw upper-port inet:port-numb
er
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port inet:port-numb
er
| | | | +--rw ihl?
| | | | | uint8
| | | | +--rw flags?
| | | | | bits
| | | | +--rw offset?
| | | | | uint16
| | | | +--rw identification?
| | | | | uint16
| | | | +--rw destination-ipv4-network?
| | | | | inet:ipv4-prefix
| | | | +--rw source-ipv4-network?
| | | | inet:ipv4-prefix
| | | +--:(ipv6) | | | +--:(ipv6)
| | | +--rw ipv6 {match-on-ipv6}? | | | +--rw ipv6 {match-on-ipv6}?
| | | +--rw dscp? | | | +--rw dscp? inet:dscp
| | | | inet:dscp | | | +--rw ecn? uint8
| | | +--rw ecn? | | | +--rw length? uint16
| | | | uint8 | | | +--rw ttl? uint8
| | | +--rw length? | | | +--rw protocol? uint8
| | | | uint16 | | | +--rw (destination-network)?
| | | +--rw ttl? | | | | +--:(destination-ipv6-network)
| | | | uint8 | | | | +--rw destination-ipv6-network?
| | | +--rw protocol? | | | | inet:ipv6-prefix
| | | | uint8 | | | +--rw (source-network)?
| | | +--rw source-port-range-or-operator | | | | +--:(source-ipv6-network)
| | | | +--rw (port-range-or-operator)? | | | | +--rw source-ipv6-network?
| | | | +--:(range) | | | | inet:ipv6-prefix
| | | | | +--rw lower-port inet:port-numb
er
| | | | | +--rw upper-port inet:port-numb
er
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port inet:port-numb
er
| | | +--rw destination-port-range-or-operator
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port inet:port-numb
er
| | | | | +--rw upper-port inet:port-numb
er
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port inet:port-numb
er
| | | +--rw destination-ipv6-network?
| | | | inet:ipv6-prefix
| | | +--rw source-ipv6-network?
| | | | inet:ipv6-prefix
| | | +--rw flow-label? | | | +--rw flow-label?
| | | inet:ipv6-flow-label | | | inet:ipv6-flow-label
| | +--rw (l4)? | | +--rw (l4)?
| | | +--:(tcp) | | | +--:(tcp)
| | | | +--rw tcp {match-on-tcp}? | | | | +--rw tcp {match-on-tcp}?
| | | | +--rw sequence-number? uint32 | | | | +--rw sequence-number?
| | | | +--rw acknowledgement-number? uint32 | | | | | uint32
| | | | +--rw data-offset? uint8 | | | | +--rw acknowledgement-number?
| | | | +--rw reserved? uint8 | | | | | uint32
| | | | +--rw flags? bits | | | | +--rw data-offset?
| | | | +--rw window-size? uint16 | | | | | uint8
| | | | +--rw urgent-pointer? uint16 | | | | +--rw reserved?
| | | | +--rw options? uint32 | | | | | uint8
| | | | +--rw flags?
| | | | | bits
| | | | +--rw window-size?
| | | | | uint16
| | | | +--rw urgent-pointer?
| | | | | uint16
| | | | +--rw options?
| | | | | uint32
| | | | +--rw (source-port)?
| | | | | +--:(source-port-range-or-operator)
| | | | | +--rw source-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | +--rw destination-port-range-or-opera
tor
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port
| | | | | | inet:port-number
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port
| | | | inet:port-number
| | | +--:(udp) | | | +--:(udp)
| | | | +--rw udp {match-on-udp}? | | | | +--rw udp {match-on-udp}?
| | | | +--rw length? uint16 | | | | +--rw length?
| | | | | uint16
| | | | +--rw (source-port)?
| | | | | +--:(source-port-range-or-operator)
| | | | | +--rw source-port-range-or-operator
| | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range)
| | | | | | +--rw lower-port
| | | | | | | inet:port-number
| | | | | | +--rw upper-port
| | | | | | inet:port-number
| | | | | +--:(operator)
| | | | | +--rw operator? operator
| | | | | +--rw port
| | | | | inet:port-number
| | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator)
| | | | +--rw destination-port-range-or-opera
tor
| | | | +--rw (port-range-or-operator)?
| | | | +--:(range)
| | | | | +--rw lower-port
| | | | | | inet:port-number
| | | | | +--rw upper-port
| | | | | inet:port-number
| | | | +--:(operator)
| | | | +--rw operator? operator
| | | | +--rw port
| | | | inet:port-number
| | | +--:(icmp) | | | +--:(icmp)
| | | +--rw icmp {match-on-icmp}? | | | +--rw icmp {match-on-icmp}?
| | | +--rw type? uint8 | | | +--rw type? uint8
| | | +--rw code? uint8 | | | +--rw code? uint8
| | | +--rw rest-of-header? uint32 | | | +--rw rest-of-header? uint32
| | +--rw egress-interface? if:interface-ref | | +--rw egress-interface? if:interface-ref
| | +--rw ingress-interface? if:interface-ref | | +--rw ingress-interface? if:interface-ref
| +--rw actions | +--rw actions
| | +--rw forwarding identityref | | +--rw forwarding identityref
| | +--rw logging? identityref | | +--rw logging? identityref
skipping to change at page 9, line 39 skipping to change at page 10, line 5
has been identified. In addition to permit and deny for actions, a 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 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 determine which rule was matched upon. The model also defines the
ability for ACL's to be attached to a particular interface. ability for ACL's to be attached to a particular interface.
Statistics in the ACL can be collected for an "ace" or for an Statistics in the ACL can be collected for an "ace" or for an
"interface". The feature statements defined for statistics can be "interface". The feature statements defined for statistics can be
used to determine whether statistics are being collected per "ace", used to determine whether statistics are being collected per "ace",
or per "interface". or per "interface".
<CODE BEGINS> file "ietf-access-control-list@2018-01-16.yang" This module imports definitions from Common YANG Data Types
[RFC6991], and A YANG Data Model for Interface Management [RFC7223].
<CODE BEGINS> file "ietf-access-control-list@2018-02-02.yang"
module ietf-access-control-list { module ietf-access-control-list {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
prefix acl; prefix acl;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-packet-fields { import ietf-packet-fields {
prefix packet-fields; prefix pf;
} }
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) "IETF NETMOD (NETCONF Data Modeling Language)
Working Group"; Working Group";
skipping to change at page 10, line 44 skipping to change at page 11, line 11
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-01-16 { revision 2018-02-02 {
description description
"Initial version."; "Initial version.";
reference reference
"RFC XXX: Network Access Control List (ACL) YANG Data Model."; "RFC XXX: Network Access Control List (ACL) YANG Data Model.";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 18, line 17 skipping to change at page 18, line 35
If no matches are defined in a particular container, If no matches are defined in a particular container,
then any packet will match that container. If no then any packet will match that container. If no
matches are specified at all in an ACE, then any matches are specified at all in an ACE, then any
packet will match the ACE."; packet will match the ACE.";
choice l2 { choice l2 {
container eth { container eth {
when "derived-from(../../../../type, " + when "derived-from(../../../../type, " +
"'acl:eth-acl-type')"; "'acl:eth-acl-type')";
if-feature match-on-eth; if-feature match-on-eth;
uses packet-fields:acl-eth-header-fields; uses pf:acl-eth-header-fields;
description description
"Rule set that matches ethernet headers."; "Rule set that matches ethernet headers.";
} }
description description
"Match layer 2 headers, for example ethernet "Match layer 2 headers, for example ethernet
header fields."; header fields.";
} }
choice l3 { choice l3 {
container ipv4 { container ipv4 {
when "derived-from(../../../../type, " + when "derived-from(../../../../type, " +
"'acl:ipv4-acl-type')"; "'acl:ipv4-acl-type')";
if-feature match-on-ipv4; if-feature match-on-ipv4;
uses packet-fields:acl-ip-header-fields; uses pf:acl-ip-header-fields;
uses packet-fields:acl-ipv4-header-fields; uses pf:acl-ipv4-header-fields;
description description
"Rule set that matches IPv4 headers."; "Rule set that matches IPv4 headers.";
} }
container ipv6 { container ipv6 {
when "derived-from(../../../../type, " + when "derived-from(../../../../type, " +
"'acl:ipv6-acl-type')"; "'acl:ipv6-acl-type')";
if-feature match-on-ipv6; if-feature match-on-ipv6;
uses packet-fields:acl-ip-header-fields; uses pf:acl-ip-header-fields;
uses packet-fields:acl-ipv6-header-fields; uses pf:acl-ipv6-header-fields;
description description
"Rule set that matches IPv6 headers."; "Rule set that matches IPv6 headers.";
} }
description description
"Choice of either ipv4 or ipv6 headers"; "Choice of either ipv4 or ipv6 headers";
} }
choice l4 { choice l4 {
container tcp { container tcp {
if-feature match-on-tcp; if-feature match-on-tcp;
uses packet-fields:acl-tcp-header-fields; uses pf:acl-tcp-header-fields;
choice source-port {
container source-port-range-or-operator {
uses pf:port-range-or-operator;
description
"Source port definition.";
}
description description
"Rule set that matches TCP headers."; "Choice of specifying the source port or referring to
a group of source ports.";
}
choice destination-port {
container destination-port-range-or-operator {
uses pf:port-range-or-operator;
description
"Destination port definition.";
}
description
"Choice of specifying a destination port or referring
to a group of destination ports.";
}
description
"Rule set that matches TCP headers.";
} }
container udp { container udp {
if-feature match-on-udp; if-feature match-on-udp;
uses packet-fields:acl-udp-header-fields; uses pf:acl-udp-header-fields;
choice source-port {
container source-port-range-or-operator {
uses pf:port-range-or-operator;
description
"Source port definition.";
}
description
"Choice of specifying the source port or referring to
a group of source ports.";
}
choice destination-port {
container destination-port-range-or-operator {
uses pf:port-range-or-operator;
description
"Destination port definition.";
}
description
"Choice of specifying a destination port or referring
to a group of destination ports.";
}
description description
"Rule set that matches UDP headers."; "Rule set that matches UDP headers.";
} }
container icmp { container icmp {
if-feature match-on-icmp; if-feature match-on-icmp;
uses packet-fields:acl-icmp-header-fields; uses pf:acl-icmp-header-fields;
description description
"Rule set that matches ICMP headers."; "Rule set that matches ICMP headers.";
} }
description description
"Choice of TCP, UDP or ICMP headers."; "Choice of TCP, UDP or ICMP headers.";
} }
leaf egress-interface { leaf egress-interface {
type if:interface-ref; type if:interface-ref;
description description
skipping to change at page 22, line 28 skipping to change at page 23, line 36
included for any given ACL with the exception of TCP, UDP and ICMP 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 header fields. Those fields can be used in conjunction with any of
the above layer 2 or layer 3 fields. the above layer 2 or layer 3 fields.
Since the number of match criteria is very large, the base draft does 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 not include these directly but references them by "uses" to keep the
base module simple. In case more match conditions are needed, those base module simple. In case more match conditions are needed, those
can be added by augmenting choices within container "matches" in can be added by augmenting choices within container "matches" in
ietf-access-control-list.yang model. ietf-access-control-list.yang model.
<CODE BEGINS> file "ietf-packet-fields@2018-01-16.yang" This module imports definitions from Common YANG Data Types [RFC6991]
and references IP [RFC0791], ICMP [RFC0792], IPv6 [RFC2460],
Definition of the Differentiated Services Field in the IPv4 and IPv6
Headers [RFC2474], The Addition of Explicit Congestion Notification
(ECN) to IP [RFC3168], Robust Explicit Congestion Notification
Signaling with Nonces [RFC3540], IPv6 Scoped Address Architecture
[RFC4007], IPv6 Addressing Architecture [RFC4291], A Recommendation
for IPv6 Address Text Representation [RFC5952].
<CODE BEGINS> file "ietf-packet-fields@2018-02-02.yang"
module ietf-packet-fields { module ietf-packet-fields {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields";
prefix packet-fields; prefix packet-fields;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-ethertypes { import ietf-ethertypes {
prefix eth; prefix eth;
skipping to change at page 23, line 31 skipping to change at page 24, line 51
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-01-16 { revision 2018-02-02 {
description description
"Initial version."; "Initial version.";
reference reference
"RFC XXX: Network Access Control List (ACL) YANG Data Model."; "RFC XXX: Network Access Control List (ACL) YANG Data Model.";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef operator { typedef operator {
skipping to change at page 26, line 30 skipping to change at page 27, line 49
reference "RFC 719, RFC 2460"; reference "RFC 719, RFC 2460";
} }
leaf protocol { leaf protocol {
type uint8; type uint8;
description description
"Internet Protocol number. Refers to the protocol of the "Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header."; payload. In IPv6, this field is known as 'next-header.";
reference "RFC 719, RFC 2460."; reference "RFC 719, RFC 2460.";
} }
container source-port-range-or-operator {
uses port-range-or-operator;
description
"Source port definition.";
}
container destination-port-range-or-operator {
uses port-range-or-operator;
description
"Destination port definition.";
}
} }
grouping acl-ipv4-header-fields { grouping acl-ipv4-header-fields {
description description
"Fields in IPv4 header."; "Fields in IPv4 header.";
leaf ihl { leaf ihl {
type uint8 { type uint8 {
range "5..60"; range "5..60";
} }
skipping to change at page 27, line 41 skipping to change at page 29, line 4
} }
leaf offset { leaf offset {
type uint16 { type uint16 {
range "20..65535"; range "20..65535";
} }
description description
"The fragment offset is measured in units of 8 octets (64 bits). "The fragment offset is measured in units of 8 octets (64 bits).
The first fragment has offset zero. The length is 13 bits"; The first fragment has offset zero. The length is 13 bits";
} }
leaf identification { leaf identification {
type uint16; type uint16;
description description
"An identifying value assigned by the sender to aid in "An identifying value assigned by the sender to aid in
assembling the fragments of a datagram."; assembling the fragments of a datagram.";
} }
leaf destination-ipv4-network { choice destination-network {
type inet:ipv4-prefix; case destination-ipv4-network {
leaf destination-ipv4-network {
type inet:ipv4-prefix;
description
"Destination IPv4 address prefix.";
}
}
description description
"Destination IPv4 address prefix."; "Choice of specifying a destination IPv4 address or
referring to a group of IPv4 destination addresses.";
} }
leaf source-ipv4-network { choice source-network {
type inet:ipv4-prefix; case source-ipv4-network {
leaf source-ipv4-network {
type inet:ipv4-prefix;
description
"Source IPv4 address prefix.";
}
}
description description
"Source IPv4 address prefix."; "Choice of specifying a source IPv4 address or
referring to a group of IPv4 source addresses.";
} }
} }
grouping acl-ipv6-header-fields { grouping acl-ipv6-header-fields {
description description
"Fields in IPv6 header"; "Fields in IPv6 header";
leaf destination-ipv6-network { choice destination-network {
type inet:ipv6-prefix; case destination-ipv6-network {
leaf destination-ipv6-network {
type inet:ipv6-prefix;
description
"Destination IPv6 address prefix.";
}
}
description description
"Destination IPv6 address prefix."; "Choice of specifying a destination IPv6 address
or referring to a group of IPv6 destination
addresses.";
} }
leaf source-ipv6-network { choice source-network {
type inet:ipv6-prefix; case source-ipv6-network {
leaf source-ipv6-network {
type inet:ipv6-prefix;
description
"Source IPv6 address prefix.";
}
}
description description
"Source IPv6 address prefix."; "Choice of specifying a source IPv6 address or
referring to a group of IPv6 source addresses.";
} }
leaf flow-label { leaf flow-label {
type inet:ipv6-flow-label; type inet:ipv6-flow-label;
description description
"IPv6 Flow label."; "IPv6 Flow label.";
} }
reference reference
"RFC 4291: IP Version 6 Addressing Architecture "RFC 4291: IP Version 6 Addressing Architecture
RFC 4007: IPv6 Scoped Address Architecture RFC 4007: IPv6 Scoped Address Architecture
skipping to change at page 30, line 27 skipping to change at page 32, line 19
description description
"Reserved for future use."; "Reserved for future use.";
} }
leaf flags { leaf flags {
type bits { type bits {
bit ns { bit ns {
position 0; position 0;
description description
"ECN-nonce concealment protection"; "ECN-nonce concealment protection";
reference "RFC 3540)."; reference "RFC 3540";
} }
bit cwr { bit cwr {
position 1; position 1;
description description
"Congestion Window Reduced (CWR) flag is set by "Congestion Window Reduced (CWR) flag is set by
the sending host to indicate that it received the sending host to indicate that it received
a TCP segment with the ECE flag set and had a TCP segment with the ECE flag set and had
responded in congestion control mechanism."; responded in congestion control mechanism.";
reference "RFC 3168"; reference "RFC 3168";
} }
skipping to change at page 36, line 16 skipping to change at page 38, line 16
<port-range-or-operator> <port-range-or-operator>
<operator> <operator>
<operator>neq</operator> <operator>neq</operator>
<port>21</port> <port>21</port>
</operator> </operator>
</port-range-or-operator> </port-range-or-operator>
</source-port-range-or-operator> </source-port-range-or-operator>
5. Security Considerations 5. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module specified in this document is defines a schema for
the NETCONF [RFC6241]. The lowest NETCONF layer is the secure data that is designed to be accessed via network management protocol
transport layer and the mandatory-to-implement secure transport is such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF
SSH [RFC6242]. The NETCONF Access Control Model ( NACM [RFC6536]) layer is the secure transport layer and the mandatory-to-implement
provides the means to restrict access for particular NETCONF users to secure transport is SSH [RFC6242]. The lowest RESTCONF layer is
a pre-configured subset of all available NETCONF protocol operations HTTPS, and the mandatory-to-implement secure transport is TLS
and content. [RFC5246].
The NETCONF Access Control Model (NACM [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 There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>) in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. effect on network operations.
These are the subtrees and data nodes and their sensitivity/ These are the subtrees and data nodes and their sensitivity/
vulnerability: vulnerability:
skipping to change at page 36, line 47 skipping to change at page 39, line 4
Unauthorized read access to this list can allow intruders to spoof Unauthorized read access to this list can allow intruders to spoof
packets with authorized addresses thereby compromising the system. packets with authorized addresses thereby compromising the system.
6. IANA Considerations 6. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is Following the format in RFC 3688, the following registration is
requested to be made: requested to be made:
URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list
URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry YANG [RFC6020].
name: ietf-access-control-list namespace: name: ietf-access-control-list namespace:
urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
reference: RFC XXXX reference: RFC XXXX
name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf- name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf-
packet-fields prefix: ietf-packet-fields reference: RFC XXXX packet-fields prefix: ietf-packet-fields reference: RFC XXXX
7. Acknowledgements 7. Acknowledgements
skipping to change at page 37, line 39 skipping to change at page 39, line 42
and then worked together to created a ACL draft that was supported by and then worked together to created a ACL draft that was supported by
different vendors. That draft removed vendor specific features, and different vendors. That draft removed vendor specific features, and
gave examples to allow vendors to extend in their own proprietary gave examples to allow vendors to extend in their own proprietary
ACL. The earlier draft was superseded with this updated draft and ACL. The earlier draft was superseded with this updated draft and
received more participation from many vendors. received more participation from many vendors.
Authors would like to thank Jason Sterne, Lada Lhotka, Juergen Authors would like to thank Jason Sterne, Lada Lhotka, Juergen
Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar
Nilsen-Nygaard for their review of and suggestions to the draft. Nilsen-Nygaard for their review of and suggestions to the draft.
8. Open Issues 8. References
o The current model does not support the concept of "containers" 8.1. Normative References
used to contain multiple addresses per rule entry.
9. References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
9.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003,
<https://www.rfc-editor.org/info/rfc3540>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
9.2. Informative References [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
8.2. Informative References
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-04 (work in progress), ietf-netmod-yang-tree-diagrams-04 (work in progress),
December 2017. December 2017.
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, DOI 10.17487/RFC5101, January Flow Information", RFC 5101, DOI 10.17487/RFC5101, January
2008, <https://www.rfc-editor.org/info/rfc5101>. 2008, <https://www.rfc-editor.org/info/rfc5101>.
skipping to change at page 40, line 5 skipping to change at page 43, line 20
} }
organization organization
"Newco model group."; "Newco model group.";
contact contact
"abc@newco.com"; "abc@newco.com";
description description
"This YANG module augments IETF ACL Yang."; "This YANG module augments IETF ACL Yang.";
revision 2018-01-16 { revision 2018-02-02 {
description description
"Creating NewCo proprietary extensions to ietf-acl model"; "Creating NewCo proprietary extensions to ietf-acl model";
reference reference
"RFC XXXX: Network Access Control List (ACL) "RFC XXXX: Network Access Control List (ACL)
YANG Data Model"; YANG Data Model";
} }
augment "/ietf-acl:access-lists/ietf-acl:acl/" + augment "/ietf-acl:access-lists/ietf-acl:acl/" +
"ietf-acl:aces/ietf-acl:ace/" + "ietf-acl:aces/ietf-acl:ace/" +
skipping to change at page 42, line 50 skipping to change at page 46, line 24
this draft and Linux nftables. this draft and Linux nftables.
A.3. Ethertypes A.3. Ethertypes
The ACL module is dependent on the definition of ethertypes. IEEE The ACL module is dependent on the definition of ethertypes. IEEE
owns the allocation of those ethertypes. This model is being owns the allocation of those ethertypes. This model is being
included here to enable definition of those types till such time that 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 IEEE takes up the task of publication of the model that defines those
ethertypes. At that time, this model can be deprecated. ethertypes. At that time, this model can be deprecated.
<CODE BEGINS> file "ietf-ethertypes@2018-01-16.yang" <CODE BEGINS> file "ietf-ethertypes@2018-02-02.yang"
module ietf-ethertypes { module ietf-ethertypes {
namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes";
prefix ie; prefix ie;
organization organization
"IETF NETMOD (NETCONF Data Modeling Language)"; "IETF NETMOD (NETCONF Data Modeling Language)";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
skipping to change at page 43, line 27 skipping to change at page 46, line 49
description description
"This module contains the common definitions for the "This module contains the common definitions for the
Ethertype used by different modules. It is a Ethertype used by different modules. It is a
placeholder module, till such time that IEEE placeholder module, till such time that IEEE
starts a project to define these Ethertypes starts a project to define these Ethertypes
and publishes a standard. and publishes a standard.
At that time this module can be deprecated."; At that time this module can be deprecated.";
revision 2018-01-16 { revision 2018-02-02 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: IETF Ethertype YANG Data Module."; "RFC XXXX: IETF Ethertype YANG Data Module.";
} }
typedef ethertype { typedef ethertype {
type union { type union {
type uint16; type uint16;
type enumeration { type enumeration {
enum ipv4 { enum ipv4 {
value 2048; value 2048;
 End of changes. 51 change blocks. 
169 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/