--- 1/draft-ietf-netmod-acl-model-05.txt 2015-12-09 08:15:04.645508481 -0800 +++ 2/draft-ietf-netmod-acl-model-06.txt 2015-12-09 08:15:04.697509749 -0800 @@ -1,23 +1,23 @@ NETMOD WG D. Bogdanovic Internet-Draft Intended status: Standards Track K. Sreenivasa -Expires: April 19, 2016 Brocade Communications System +Expires: June 10, 2016 Cisco Systems L. Huang Juniper Networks D. Blair Cisco Systems - October 17, 2015 + December 8, 2015 Network Access Control List (ACL) YANG Data Model - draft-ietf-netmod-acl-model-05 + draft-ietf-netmod-acl-model-06 Abstract This document describes a data model of Access Control List (ACL) basic building blocks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 19, 2016. + This Internet-Draft will expire on June 10, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -107,22 +107,20 @@ 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 interchangeable. 1.1. Definitions and Acronyms ACE: Access Control Entry ACL: Access Control List - AFI: Address Field Identifier - DSCP: Differentiated Services Code Point ICMP: Internet Control Message Protocol IP: Internet Protocol IPv4: Internet Protocol version 4 IPv6: Internet Protocol version 6 @@ -156,21 +154,21 @@ 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 YNAG model. + 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 very simple and with this design we hope to achieve needed flexibility for each vendor to extend the base model. 3.1. ACL Modules There are two YANG modules in the model. The first module, "ietf- @@ -194,66 +192,62 @@ | | | | +--rw (ace-ip-version)? | | | | | +--:(ace-ipv4) | | | | | | +--rw destination-ipv4-network? inet:ipv4-prefix | | | | | | +--rw source-ipv4-network? inet:ipv4-prefix | | | | | +--:(ace-ipv6) | | | | | +--rw destination-ipv6-network? inet:ipv6-prefix | | | | | +--rw source-ipv6-network? inet:ipv6-prefix | | | | | +--rw flow-label? inet:ipv6-flow-label | | | | +--rw dscp? inet:dscp | | | | +--rw protocol? uint8 - | | | | +--rw source-port-range + | | | | +--rw source-port-range! | | | | | +--rw lower-port inet:port-number | | | | | +--rw upper-port? inet:port-number - | | | | +--rw destination-port-range + | | | | +--rw destination-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | +--:(ace-eth) | | | +--rw destination-mac-address? yang:mac-address | | | +--rw destination-mac-address-mask? yang:mac-address | | | +--rw source-mac-address? yang:mac-address | | | +--rw source-mac-address-mask? yang:mac-address | | +--rw input-interface? string - | | +--rw absolute-time - | | +--rw start? yang:date-and-time - | | +--rw end? yang:date-and-time - | | +--rw active? boolean | +--rw actions | | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--ro ace-oper-data | | +--ro match-counter? yang:counter64 | +--rw rule-name string +--rw acl-name string +--rw acl-type acl-type Figure 1 4. ACL YANG Models 4.1. IETF Access Contorl List module "ietf-access-control-list" is the standard top level module for - Access lists. The "access-lists" container stores a list of "acl". + access lists. The "access-lists" container stores a list of "acl". Each "acl" has information identifying the access list by a name("acl-name") and a list("access-list-entries") of rules associated with the "acl-name". Each of the entries in the list("access-list-entries"), indexed by the string "rule-name", has containers defining "matches" and "actions". The "matches" define criteria used to identify patterns in "ietf-packet-fields". The "actions" define behavior to undertake once a "match" has been identified. -file "ietf-access-control-list@2015-10-11.yang" +file "ietf-access-control-list@2015-12-08.yang" module ietf-access-control-list { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; prefix acl; import ietf-yang-types { prefix yang; } import ietf-packet-fields { prefix packet-fields; } @@ -262,40 +256,40 @@ contact "WG Web: http://tools.ietf.org/wg/netmod/ WG List: netmod@ietf.org WG Chair: Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de WG Chair: Tom Nadeau tnadeau@lucidvision.com Editor: Dean Bogdanovic ivandean@gmail.com Editor: Kiran Agrahara Sreenivasa - kkoushik@brocade.com + kkoushik@cisco.com Editor: Lisa Huang lyihuang@juniper.net Editor: Dana Blair dblair@cisco.com"; description "This YANG module defines a component that describing the configuration of Access Control Lists (ACLs). Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2015-03-17 { + revision 2015-12-08 { description "Base model for Network Access Control List (ACL)."; reference "RFC XXXX: Network Access Control List (ACL) YANG Data Model"; } identity acl-base { description "Base Access Control List type for all Access Control List type identifiers."; @@ -312,23 +306,24 @@ base acl:acl-base; description "ACL that primarily matches on fields from the IPv6 header (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv6-acl does not contain matches on fields in the ethernet header or the IPv4 header."; } identity eth-acl { base acl:acl-base; description - "ACL that primarily matches on fields in the ethernet header. - An acl of type eth-acl does not contain matches on fields in - the IPv4 header, IPv6 header or layer 4 headers."; + "ACL that primarily matches on fields in the ethernet header, + like 10/100/1000baseT or WiFi Access Control List. An acl of + type eth-acl does not contain matches on fields in the IPv4 + header, IPv6 header or layer 4 headers."; } typedef acl-type { type identityref { base acl-base; } description "This type is used to refer to an Access Control List (ACL) type"; } typedef access-control-list-ref { @@ -461,21 +457,21 @@ 4.2. IETF-PACKET-FIELDS module The packet fields module defines the necessary groups for matching on fields in the packet including ethernet, ipv4, ipv6, transport layer fields and metadata. 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 -file "ietf-packet-fields@2015-06-11.yang" + module ietf-packet-fields { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; prefix packet-fields; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } @@ -484,41 +480,41 @@ contact "WG Web: http://tools.ietf.org/wg/netmod/ WG List: netmod@ietf.org WG Chair: Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de WG Chair: Tom Nadeau tnadeau@lucidvision.com Editor: Dean Bogdanovic deanb@juniper.net Editor: Kiran Agrahara Sreenivasa - kkoushik@brocade.com + kkoushik@cisco.com Editor: Lisa Huang lyihuang@juniper.net Editor: Dana Blair dblair@cisco.com"; description "This YANG module defines groupings that are used by ietf-access-control-list YANG module. Their usage is not limited to ietf-access-control-list and can be used anywhere as applicable. Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2015-06-11 { + revision 2015-12-08 { description "Initial version of packet fields used by ietf-access-control-list"; reference "RFC XXXX: Network Access Control List (ACL) YANG Data Model"; } grouping acl-transport-header-fields { description "Transport header fields"; @@ -527,52 +523,54 @@ description "Inclusive range representing source ports to be used. When only lower-port is present, it represents a single port."; leaf lower-port { type inet:port-number; mandatory true; description "Lower boundary for port."; } leaf upper-port { + type inet:port-number; must ". >= ../lower-port" { error-message "The upper-port must be greater than or equal to lower-port"; } - type inet:port-number; description "Upper boundary for port . If existing, the upper port must be greater or equal to lower-port."; } } container destination-port-range { presence "Enables setting destination port range"; description "Inclusive range representing destination ports to be used. When only lower-port is present, it represents a single port."; leaf lower-port { type inet:port-number; mandatory true; description "Lower boundary for port."; } leaf upper-port { + type inet:port-number; must ". >= ../lower-port" { error-message "The upper-port must be greater than or equal to lower-port"; } - type inet:port-number; + description "Upper boundary for port. If existing, the upper port must be greater or equal to lower-port"; } } + } grouping acl-ip-header-fields { description "IP header fields common to ipv4 and ipv6"; leaf dscp { type inet:dscp; description "Value of dscp."; } leaf protocol { @@ -639,65 +637,33 @@ } leaf source-mac-address-mask { type yang:mac-address; description "Source IEEE 802 MAC address mask."; } reference "IEEE 802: IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture."; } - grouping timerange { - description - "Time range contains time - segments to allow access-control-list to be - active/inactive when the system time - is between the range."; - container absolute-time { - description - "Absolute time and date that - the associated function starts - going into effect."; - leaf start { - type yang:date-and-time; - description - "Absolute start time and date"; - } - leaf end { - type yang:date-and-time; - description - "Absolute end time and date"; - } - leaf active { - type boolean; - default "true"; - description - "This object indicates whether the - the ACL will be active(true) or - inactive(false) during this time range."; - } - } - } + grouping metadata { description "Fields associated with a packet whick are not in the header."; leaf input-interface { type string; description "Packet was received on this interface."; } - uses timerange; } } - 4.3. An ACL Example Requirement: Deny All traffic from 10.10.10.1 bound for host 10.10.10.255 from leaving. In order to achieve the requirement, an name Access Control List is needed. The acl and aces can be described in CLI as the following: access-list ip sample-ip-acl deny tcp host 10.10.10.1 host 10.10.10.255 @@ -729,24 +695,20 @@ - - - - rule1 @@ -932,54 +894,54 @@ prefixes. Much like ACLs, they include some match criteria and corresponding match action(s). For that reason, it is very simple to extend existing ACL model with route filtering. The combination of a route prefix and prefix length along with the type of match determines how route filters are evaluated against incoming routes. Different vendors have different match types and in this model we are using only ones that are common across all vendors participating in this draft. As in this example, the base ACL model can be extended with company proprietary extensions, described in the next section. -file "ietf-example-ext-route-filter@2015-02-14.yang" - -module ietf-example-ext-route-filter { + file "example-ext-route-filter@2015-12-08.yang" + module example-ext-route-filter { yang-version 1; - namespace "urn:ietf:params:xml:ns:yang:ietf-example-ext-route-filter"; - prefix ietf-example-ext-route-filter; + namespace "urn:ietf:params:xml:ns:yang:example-ext-route-filter"; + prefix example-ext-route-filter; import ietf-inet-types { prefix "inet"; } import ietf-access-control-list { prefix "ietf-acl"; } + organization - "Route modele group."; + "Route model group."; contact "abc@abc.com"; description " This module describes route filter as a collection of match prefixes. When specifying a match prefix, you can specify an exact match with a particular route or a less precise match. You can configure either a common action that applies to the entire list or an action associated with each prefix. "; - revision 2015-05-03 { + revision 2015-12-08 { description "Creating Route-Filter extension model based on ietf-access-control-list model"; reference " "; } - augment "/ietf-acl:access-lists/ietf-acl:acl/ - ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches"{ + augment "/ietf-acl:access-lists/ietf-acl:acl/" + + "ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches"{ description " This module augments the matches container in the ietf-acl module with route filter specific actions "; choice route-prefix{ description "Define route filter match criteria"; case range { description " Route falls between the lower prefix/prefix-length and the upperprefix/prefix-length."; @@ -1027,122 +989,136 @@ The following figure is the tree structure of example-newco-acl. In this example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- list-entries/ ietf-acl:ace/ietf-acl:matches are augmented with a new choice, protocol-payload-choice. The protocol-payload-choice uses a grouping with an enumeration of all supported protocol values. In other example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- list-entries/ ietf-acl:ace/ietf-acl:actions are augmented with new choice of actions. module: example-newco-acl - augment /ietf-acl:access-lists/ietf-acl:acl/ - ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches: +augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ +ietf-acl:ace/ietf-acl:matches: +--rw (protocol-payload-choice)? +--:(protocol-payload) +--rw protocol-payload* [value-keyword] +--rw value-keyword enumeration - augment /ietf-acl:access-lists/ietf-acl:acl/ - ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:actions: + augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ + ietf-acl:ace/ietf-acl:actions: +--rw (action)? +--:(count) | +--rw count? string +--:(policer) | +--rw policer? string +--:(hiearchical-policer) +--rw hierarchitacl-policer? string augment /ietf-acl:access-lists/ietf-acl:acl: +--rw default-actions +--rw deny? empty -file "newco-acl@2015-03-04.yang" - +file "newco-acl@2015-12-08.yang" module example-newco-acl { yang-version 1; namespace "urn:newco:params:xml:ns:yang:example-newco-acl"; prefix example-newco-acl; - import ietf-acl { + import ietf-access-control-list { prefix "ietf-acl"; } - revision 2015-05-03{ - description "Creating NewCo proprietary extensions to ietf-acl model"; - } + organization + "Newco model group."; - augment "/ietf-acl:access-lists/ietf-acl:access-list - /ietf-acl:access-list-entries/ - ietf-acl:access-list-entry/ietf-acl:matches" { + contact + "abc@newco.com"; + description + "This YANG module augment IETF ACL Yang."; + + revision 2015-12-08{ + description + "Creating NewCo proprietary extensions to ietf-acl model"; + reference + "RFC XXXX: Network Access Control List (ACL) + YANG Data Model"; + } + augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches" { description "Newco proprietary simple filter matches"; choice protocol-payload-choice { + description ""; list protocol-payload { key value-keyword; ordered-by user; description "Match protocol payload"; uses match-simple-payload-protocol-value; } - } } - augment "/ietf-acl:access-lists/ietf-acl:access-list/ - ietf-acl:access-list-entries/ietf-acl:access-list-entry/ - ietf-acl:actions" { + augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:actions" { description "Newco proprietary simple filter actions"; choice action { + description ""; case count { description "Count the packet in the named counter"; leaf count { type string; + description ""; } } case policer { description "Name of policer to use to rate-limit traffic"; leaf policer { type string; + description ""; } } case hiearchical-policer { description "Name of hierarchical policer to use to rate-limit traffic"; leaf hierarchitacl-policer{ type string; + description ""; } } } } - augment "/ietf-acl:access-lists/ietf-acl:access-list" { + augment "/ietf-acl:access-lists/ietf-acl:acl" { + description "Newco proprietary default action"; container default-actions { - description "Actions that occur if no access-list entry is matched."; + description + "Actions that occur if no access-list entry is matched."; leaf deny { type empty; + description ""; } } } grouping match-simple-payload-protocol-value { + description "Newco proprietary payload"; leaf value-keyword { - description "(null)"; type enumeration { enum icmp { description "Internet Control Message Protocol"; } enum icmp6 { description "Internet Control Message Protocol Version 6"; - } enum range { description "Range of values"; } } + + description "(null)"; } } } Draft authors expect that different vendors will provide their own yang models as in the example above, which is the augmentation of the base model A.3. Attaching Access Control List to interfaces @@ -1231,22 +1207,22 @@ layer 4 header fields may also exist in the list."; } Authors' Addresses Dean Bogdanovic Email: ivandean@gmail.com Kiran Agrahara Sreenivasa - Brocade Communications System + Cisco Systems - Email: kkoushik@brocade.com + Email: kkoushik@cisco.com Lisa Huang Juniper Networks Email: lyihuang@juniper.net Dana Blair Cisco Systems Email: dblair@cisco.com