--- 1/draft-ietf-netmod-acl-model-15.txt 2018-02-02 18:13:32.002454420 -0800 +++ 2/draft-ietf-netmod-acl-model-16.txt 2018-02-02 18:13:32.098456725 -0800 @@ -1,23 +1,23 @@ NETMOD WG M. Jethanandani Internet-Draft Intended status: Standards Track L. Huang -Expires: July 20, 2018 General Electric +Expires: August 6, 2018 General Electric S. Agarwal Cisco Systems, Inc. D. Blair Cisco Systems, INc - January 16, 2018 + February 2, 2018 Network Access Control List (ACL) YANG Data Model - draft-ietf-netmod-acl-model-15 + draft-ietf-netmod-acl-model-16 Abstract This document describes a data model of Access Control List (ACL) basic building blocks. 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 @@ -43,21 +43,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 https://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 July 20, 2018. + This Internet-Draft will expire on August 6, 2018. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,35 +69,34 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Understanding ACL's Filters and Actions . . . . . . . . . . . 4 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 5 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. IETF Access Control List module . . . . . . . . . . . . . 9 - 4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 22 - 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 33 - 4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 34 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 - 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 9.2. Informative References . . . . . . . . . . . . . . . . . 38 - Appendix A. Extending ACL model examples . . . . . . . . . . . . 38 - A.1. A company proprietary module example . . . . . . . . . . 38 - A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 42 - A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 + 4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 23 + 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 35 + 4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 36 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 8.2. Informative References . . . . . . . . . . . . . . . . . 41 + Appendix A. Extending ACL model examples . . . . . . . . . . . . 42 + A.1. A company proprietary module example . . . . . . . . . . 42 + A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 45 + A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction Access Control List (ACL) is one of the basic elements used to configure device forwarding behavior. It is used in many networking technologies such as Policy Based Routing, Firewalls etc. An ACL is an ordered-by-user set of rules that is used to filter traffic on a networking device. Each rule is represented by an Access Control Entry (ACE). @@ -148,21 +147,21 @@ IPv4: Internet Protocol version 4 IPv6: Internet Protocol version 6 MAC: Media Access Control TCP: Transmission Control Protocol 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 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. 3. Understanding ACL's Filters and Actions @@ -190,21 +189,21 @@ applied in a direction which indicates if it should be applied to packet entering (input) or leaving the device (output). An example in the appendix shows how to express it in YANG model. This draft tries to address the commonalities between all vendors and create a common model, which can be augmented with proprietary models. The base model is simple and with this design we hope to achieve enough flexibility for each vendor to extend the base model. The use of feature statements in the model allows vendors to - advertise match rules they are capable and willing 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 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". 3.1. ACL Modules @@ -242,118 +241,131 @@ | | | | yang:mac-address | | | +--rw source-mac-address? | | | | yang:mac-address | | | +--rw source-mac-address-mask? | | | | yang:mac-address | | | +--rw ethertype? | | | eth:ethertype | | +--rw (l3)? | | | +--:(ipv4) | | | | +--rw ipv4 {match-on-ipv4}? - | | | | +--rw dscp? - | | | | | inet:dscp - | | | | +--rw ecn? - | | | | | uint8 - | | | | +--rw length? - | | | | | uint16 - | | | | +--rw ttl? - | | | | | uint8 - | | | | +--rw protocol? - | | | | | uint8 - | | | | +--rw source-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-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? + | | | | +--rw dscp? inet:dscp + | | | | +--rw ecn? uint8 + | | | | +--rw length? uint16 + | | | | +--rw ttl? uint8 + | | | | +--rw protocol? uint8 + | | | | +--rw ihl? uint8 + | | | | +--rw flags? bits + | | | | +--rw offset? uint16 + | | | | +--rw identification? uint16 + | | | | +--rw (destination-network)? + | | | | | +--:(destination-ipv4-network) + | | | | | +--rw destination-ipv4-network? | | | | | inet:ipv4-prefix + | | | | +--rw (source-network)? + | | | | +--:(source-ipv4-network) | | | | +--rw source-ipv4-network? | | | | inet:ipv4-prefix | | | +--:(ipv6) | | | +--rw ipv6 {match-on-ipv6}? - | | | +--rw dscp? - | | | | inet:dscp - | | | +--rw ecn? - | | | | uint8 - | | | +--rw length? - | | | | uint16 - | | | +--rw ttl? - | | | | uint8 - | | | +--rw protocol? - | | | | uint8 - | | | +--rw source-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-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? + | | | +--rw dscp? inet:dscp + | | | +--rw ecn? uint8 + | | | +--rw length? uint16 + | | | +--rw ttl? uint8 + | | | +--rw protocol? uint8 + | | | +--rw (destination-network)? + | | | | +--:(destination-ipv6-network) + | | | | +--rw destination-ipv6-network? | | | | inet:ipv6-prefix - | | | +--rw source-ipv6-network? + | | | +--rw (source-network)? + | | | | +--:(source-ipv6-network) + | | | | +--rw source-ipv6-network? | | | | inet:ipv6-prefix | | | +--rw flow-label? | | | inet:ipv6-flow-label | | +--rw (l4)? | | | +--:(tcp) | | | | +--rw tcp {match-on-tcp}? - | | | | +--rw sequence-number? uint32 - | | | | +--rw acknowledgement-number? uint32 - | | | | +--rw data-offset? uint8 - | | | | +--rw reserved? uint8 - | | | | +--rw flags? bits - | | | | +--rw window-size? uint16 - | | | | +--rw urgent-pointer? uint16 - | | | | +--rw options? uint32 + | | | | +--rw sequence-number? + | | | | | uint32 + | | | | +--rw acknowledgement-number? + | | | | | uint32 + | | | | +--rw data-offset? + | | | | | uint8 + | | | | +--rw reserved? + | | | | | 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) | | | | +--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) | | | +--rw icmp {match-on-icmp}? | | | +--rw type? uint8 | | | +--rw code? uint8 | | | +--rw rest-of-header? uint32 | | +--rw egress-interface? if:interface-ref | | +--rw ingress-interface? if:interface-ref | +--rw actions | | +--rw forwarding identityref | | +--rw logging? identityref @@ -407,34 +419,36 @@ has been identified. In addition to permit and deny for actions, a logging option allows for a match to be logged that can be used to determine which rule was matched upon. The model also defines the ability for ACL's to be attached to a particular interface. Statistics in the ACL can be collected for an "ace" or for an "interface". The feature statements defined for statistics can be used to determine whether statistics are being collected per "ace", or per "interface". - 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]. + + file "ietf-access-control-list@2018-02-02.yang" module ietf-access-control-list { yang-version 1.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; - + prefix pf; } import ietf-interfaces { prefix if; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; @@ -460,21 +474,21 @@ 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 2018-01-16 { + revision 2018-02-02 { description "Initial version."; reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Identities */ @@ -818,71 +833,112 @@ If no matches are defined in a particular container, then any packet will match that container. If no matches are specified at all in an ACE, then any packet will match the ACE."; choice l2 { container eth { when "derived-from(../../../../type, " + "'acl:eth-acl-type')"; if-feature match-on-eth; - uses packet-fields:acl-eth-header-fields; + uses pf:acl-eth-header-fields; description "Rule set that matches ethernet headers."; } description "Match layer 2 headers, for example ethernet header fields."; } choice l3 { container ipv4 { when "derived-from(../../../../type, " + "'acl:ipv4-acl-type')"; if-feature match-on-ipv4; - uses packet-fields:acl-ip-header-fields; - uses packet-fields:acl-ipv4-header-fields; + uses pf:acl-ip-header-fields; + uses pf:acl-ipv4-header-fields; description "Rule set that matches IPv4 headers."; + } container ipv6 { when "derived-from(../../../../type, " + "'acl:ipv6-acl-type')"; if-feature match-on-ipv6; - uses packet-fields:acl-ip-header-fields; - uses packet-fields:acl-ipv6-header-fields; + uses pf:acl-ip-header-fields; + uses pf:acl-ipv6-header-fields; description "Rule set that matches IPv6 headers."; } description "Choice of either ipv4 or ipv6 headers"; } choice l4 { container 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 + "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 { 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 "Rule set that matches UDP headers."; } container icmp { if-feature match-on-icmp; - uses packet-fields:acl-icmp-header-fields; + uses pf:acl-icmp-header-fields; description "Rule set that matches ICMP headers."; } description "Choice of TCP, UDP or ICMP headers."; } leaf egress-interface { type if:interface-ref; description @@ -1022,26 +1075,35 @@ included for any given ACL with the exception of TCP, UDP and ICMP header fields. Those fields can be used in conjunction with any of the above layer 2 or layer 3 fields. Since the number of match criteria is very large, the base draft does not include these directly but references them by "uses" to keep the base module simple. In case more match conditions are needed, those can be added by augmenting choices within container "matches" in ietf-access-control-list.yang model. - 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]. + + file "ietf-packet-fields@2018-02-02.yang" module ietf-packet-fields { + yang-version 1.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; } import ietf-ethertypes { prefix eth; @@ -1074,21 +1137,21 @@ 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 2018-01-16 { + revision 2018-02-02 { description "Initial version."; reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Typedefs */ typedef operator { @@ -1216,30 +1280,20 @@ reference "RFC 719, RFC 2460"; } leaf protocol { type uint8; description "Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header."; 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 { description "Fields in IPv4 header."; leaf ihl { type uint8 { range "5..60"; } @@ -1276,55 +1330,83 @@ } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } - leaf identification { type uint16; description "An identifying value assigned by the sender to aid in assembling the fragments of a datagram."; } + choice destination-network { + case destination-ipv4-network { leaf destination-ipv4-network { type inet:ipv4-prefix; description "Destination IPv4 address prefix."; } + } + description + "Choice of specifying a destination IPv4 address or + referring to a group of IPv4 destination addresses."; + } + choice source-network { + case source-ipv4-network { leaf source-ipv4-network { type inet:ipv4-prefix; description "Source IPv4 address prefix."; } } + description + "Choice of specifying a source IPv4 address or + referring to a group of IPv4 source addresses."; + } + } grouping acl-ipv6-header-fields { description "Fields in IPv6 header"; + choice destination-network { + case destination-ipv6-network { leaf destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } + } + description + "Choice of specifying a destination IPv6 address + or referring to a group of IPv6 destination + addresses."; + } + choice source-network { + case source-ipv6-network { leaf source-ipv6-network { type inet:ipv6-prefix; description "Source IPv6 address prefix."; } + } + description + "Choice of specifying a source IPv6 address or + referring to a group of IPv6 source addresses."; + } leaf flow-label { type inet:ipv6-flow-label; description "IPv6 Flow label."; } reference "RFC 4291: IP Version 6 Addressing Architecture RFC 4007: IPv6 Scoped Address Architecture RFC 5952: A Recommendation for IPv6 Address Text @@ -1406,21 +1489,21 @@ description "Reserved for future use."; } leaf flags { type bits { bit ns { position 0; description "ECN-nonce concealment protection"; - reference "RFC 3540)."; + reference "RFC 3540"; } bit cwr { position 1; description "Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism."; reference "RFC 3168"; } @@ -1667,27 +1751,31 @@ neq 21 5. Security Considerations - The YANG module defined in this memo is designed to be accessed via - the NETCONF [RFC6241]. The lowest NETCONF layer is the secure - transport layer and the mandatory-to-implement secure transport is - SSH [RFC6242]. 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. + The YANG module specified in this document is defines a schema for + data that is designed to be accessed via network management protocol + such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF + layer is the secure transport layer and the mandatory-to-implement + secure transport is SSH [RFC6242]. The lowest RESTCONF layer is + HTTPS, and the mandatory-to-implement secure transport is TLS + [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 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., ) 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: @@ -1698,29 +1786,28 @@ Unauthorized read access to this list can allow intruders to spoof packets with authorized addresses thereby compromising the system. 6. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list - URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names - registry [RFC6020]. + registry YANG [RFC6020]. name: ietf-access-control-list namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl reference: RFC XXXX name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf- packet-fields prefix: ietf-packet-fields reference: RFC XXXX 7. Acknowledgements @@ -1737,53 +1824,111 @@ 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. -8. Open Issues +8. References - o The current model does not support the concept of "containers" - used to contain multiple addresses per rule entry. +8.1. Normative References -9. References + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + . -9.1. Normative References + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + . + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + + [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, + . + + [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, + . + + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit + Congestion Notification (ECN) Signaling with Nonces", + RFC 3540, DOI 10.17487/RFC3540, June 2003, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and + B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, + DOI 10.17487/RFC4007, March 2005, + . + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . -9.2. Informative References + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + + [RFC7223] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + +8.2. Informative References [I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- ietf-netmod-yang-tree-diagrams-04 (work in progress), December 2017. [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 2008, . @@ -1847,21 +1990,21 @@ } organization "Newco model group."; contact "abc@newco.com"; description "This YANG module augments IETF ACL Yang."; - revision 2018-01-16 { + revision 2018-02-02 { 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:aces/ietf-acl:ace/" + @@ -1988,21 +2131,22 @@ this draft and Linux nftables. A.3. Ethertypes 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. - file "ietf-ethertypes@2018-01-16.yang" + file "ietf-ethertypes@2018-02-02.yang" + module ietf-ethertypes { namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; prefix ie; organization "IETF NETMOD (NETCONF Data Modeling Language)"; contact "WG Web: WG List: @@ -2012,23 +2156,24 @@ description "This module contains the common definitions for the Ethertype used by different modules. It is a placeholder module, till such time that IEEE starts a project to define these Ethertypes and publishes a standard. At that time this module can be deprecated."; - revision 2018-01-16 { + revision 2018-02-02 { description "Initial revision."; + reference "RFC XXXX: IETF Ethertype YANG Data Module."; } typedef ethertype { type union { type uint16; type enumeration { enum ipv4 { value 2048;