idnits 2.17.00 (12 Aug 2021) /tmp/idnits59353/draft-ietf-netmod-acl-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 58 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 368: '...s-list. A device MAY restrict the leng...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 196 has weird spacing: '...er-port ine...' == Line 199 has weird spacing: '...er-port ine...' == Line 1033 has weird spacing: '...keyword enu...' -- The document date (March 5, 2015) is 2634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD WG D. Bogdanovic 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track K. Sreenivasa 5 Expires: September 6, 2015 Brocade Communications System 6 L. Huang 7 D. Blair 8 Cisco Systems 9 March 5, 2015 11 Network Access Control List (ACL) YANG Data Model 12 draft-ietf-netmod-acl-model-02 14 Abstract 16 This document describes a data model of Access Control List (ACL) 17 basic building blocks. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 6, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 55 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Design of the ACL Model . . . . . . . . . . . . . . . . . . . 3 57 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. IETF-ACL module . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. IETF-PACKET-FIELDS module . . . . . . . . . . . . . . . . 11 61 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 16 62 4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 17 63 5. Linux nftables . . . . . . . . . . . . . . . . . . . . . . . 17 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 69 9.2. Informative References . . . . . . . . . . . . . . . . . 19 70 Appendix A. Extending ACL model examples . . . . . . . . . . . . 20 71 A.1. Example of extending existing model for route filtering . 20 72 A.2. A company proprietary module example . . . . . . . . . . 22 73 A.3. Attaching Access Control List to interfaces . . . . . . . 25 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 76 1. Introduction 78 Access Control List (ACL) is one of the basic elements to configure 79 device forwarding behavior. It is used in many networking concepts 80 such as Policy Based Routing, Firewalls etc. 82 An ACL is an ordered set of rules that is used to filter traffic on a 83 networking device. Each rule is represented by an Access Control 84 Entry (ACE). 86 Each ACE has a group of match criteria and a group of action 87 criteria. 89 The match criteria consist of a tuple of packet header match criteria 90 and metadata match criteria. 92 o Packet header matches apply to fields visible in the packet such 93 as address or class of service or port numbers. 95 o Metadata matches apply to fields associated with the packet but 96 not in the packet header such as input interface or overall packet 97 length 99 The actions specify what to do with the packet when the matching 100 criteria is met. These actions are any operations that would apply 101 to the packet, such as counting, policing, or simply forwarding.The 102 list of potential actions is endless depending on the innovations of 103 the networked devices. 105 1.1. Definitions and Acronyms 107 ACE: Access Control Entry 109 ACL: Access Control List 111 AFI: Address Field Identifier 113 DSCP: Differentiated Services Code Point 115 ICMP: Internet Control Message Protocol 117 IP: Internet Protocol 119 IPv4: Internet Protocol version 4 121 IPv6: Internet Protocol version 6 123 MAC: Media Access Control 125 TCP: Transmission Control Protocol 127 2. Problem Statement 129 This document defines a YANG [RFC6020] data model for the 130 configuration of ACLs. It is very important that model can be easily 131 reused between vendors and between applications. 133 ACL implementations in every device may vary greatly in terms of the 134 filter constructs and actions that they support. Therefore this 135 draft proposes a simple model that can be augmented by vendor 136 proprietary models. 138 3. Design of the ACL Model 140 Although different vendors have different ACL data models, there is a 141 common understanding of what access control list (ACL) is. A network 142 system usually have a list of ACLs, and each ACL contains an ordered 143 list of rules, also known as access list entries - ACEs. Each ACE 144 has a group of match criteria and a group of action criteria. The 145 match criteria consist of packet header matching and metadata 146 matching. Packet header matching applies to fields visible in the 147 packet such as address or class of service or port numbers. Metadata 148 matching applies to fields associated with the packet, but not in the 149 packet header such as input interface, packet length, or source or 150 destination prefix length. The actions can be any sort of operation 151 from logging to rate limiting or dropping to simply forwarding. 152 Actions on the first matching ACE are applied with no processing of 153 subsequent ACEs. The model also includes overall operational state 154 for the ACL and operational state for each ACE, targets where the ACL 155 applied. One ACL can be applied to multiple targets within the 156 device, such as interfaces of a networked device, applications or 157 features running in the device, etc. When applied to interfaces of a 158 networked device, the ACL is applied in a direction which indicates 159 if it should be applied to packet entering (input) or leaving the 160 device (output). 162 This draft tries to address the commonalities between all vendors and 163 create a common model, which can be augmented with proprietary 164 models. The base model is very simple and with this design we hope 165 to achieve needed flexibility for each vendor to extend the base 166 model. 168 3.1. ACL Modules 170 There are two YANG modules in the model. The first module, "ietf- 171 acl", defines generic ACL aspects which are common to all ACLs 172 regardless of their type or vendor. In effect, the module can be 173 viewed as providing a generic ACL "superclass". It imports the 174 second module, "ietf-packet-fields". The match container in "ietf- 175 acl" uses groupings in "ietf-packet-fields". The "ietf-packet- 176 fields" modules can easily be extended to reuse definitions from 177 other modules such as IPFIX [RFC5101] or migrate proprietary 178 augmented module definitions into the standard module. 180 module: ietf-acl 181 +--rw access-lists 182 +--rw access-list* [access-control-list-name] 183 +--rw access-control-list-name string 184 +--rw access-control-list-type? access-control-list-type 185 +--ro access-control-list-oper-data 186 | +--ro (targets)? 187 | +--:(interface-name) 188 | +--ro interface-name* string 189 +--rw access-list-entries 190 +--rw access-list-entry* [rule-name] 191 +--rw rule-name string 192 +--rw matches 193 | +--rw (access-list-entries-type)? 194 | | +--:(access-list-entries-ip) 195 | | | +--rw source-port-range 196 | | | | +--rw lower-port inet:port-number 197 | | | | +--rw upper-port? inet:port-number 198 | | | +--rw destination-port-range 199 | | | | +--rw lower-port inet:port-number 200 | | | | +--rw upper-port? inet:port-number 201 | | | +--rw dscp? inet:dscp 202 | | | +--rw protocol? uint8 203 | | | +--rw (access-list-entries-ip-version)? 204 | | | +--:(access-list-entries-ipv4) 205 | | | | +--rw destination-ipv4-network? inet:ipv4-prefix 206 | | | | +--rw source-ipv4-network? inet:ipv4-prefix 207 | | | +--:(access-list-entries-ipv6) 208 | | | +--rw destination-ipv6-network? inet:ipv6-prefix 209 | | | +--rw source-ipv6-network? inet:ipv6-prefix 210 | | | +--rw flow-label? inet:ipv6-flow-label 211 | | +--:(access-list-entries-eth) 212 | | +--rw destination-mac-address? yang:mac-address 213 | | +--rw destination-mac-address-mask? yang:mac-address 214 | | +--rw source-mac-address? yang:mac-address 215 | | +--rw source-mac-address-mask? yang:mac-address 216 | +--rw input-interface? string 217 | +--rw absolute 218 | +--rw start? yang:date-and-time 219 | +--rw end? yang:date-and-time 220 | +--rw active? boolean 221 +--rw actions 222 | +--rw (packet-handling)? 223 | +--:(deny) 224 | | +--rw deny? empty 225 | +--:(permit) 226 | +--rw permit? empty 227 +--ro access-list-entries-oper-data 228 +--ro match-counter? yang:counter64 230 4. ACL YANG Models 232 4.1. IETF-ACL module 234 "ietf-acl" is the standard top level module for Access lists. It has 235 a container for "access-list" to store access list information. This 236 container has information identifying the access list by a name("acl- 237 name") and a list("access-list-entries") of rules associated with the 238 "acl-name". Each of the entries in the list("access-list-entries") 239 indexed by the string "rule-name" have containers defining "matches" 240 and "actions". The "matches" define criteria used to identify 241 patterns in "ietf-packet-fields". The "actions" define behavior to 242 undertake once a "match" has been identified. 244 file "ietf-acl@2015-03-04.yang" 245 module ietf-acl { 246 yang-version 1; 248 namespace "urn:ietf:params:xml:ns:yang:ietf-acl"; 250 prefix access-control-list; 252 import ietf-yang-types { 253 prefix "yang"; 255 } 257 import ietf-packet-fields { 258 prefix "packet-fields"; 259 } 261 organization 262 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 264 contact 265 "WG Web: http://tools.ietf.org/wg/netmod/ 266 WG List: netmod@ietf.org 268 WG Chair: Juergen Schoenwaelder 269 j.schoenwaelder@jacobs-university.de 271 WG Chair: Tom Nadeau 272 tnadeau@lucidvision.com 274 Editor: Dean Bogdanovic 275 deanb@juniper.net 277 Editor: Kiran Agrahara Sreenivasa 278 kkoushik@brocade.com 280 Editor: Lisa Huang 281 yihuan@cisco.com 283 Editor: Dana Blair 284 dblair@cisco.com"; 286 description 287 "This YANG module defines a component that describing the 288 configuration of Access Control Lists (ACLs). 290 Copyright (c) 2015 IETF Trust and the persons identified as 291 the document authors. All rights reserved. 293 Redistribution and use in source and binary forms, with or 294 without modification, is permitted pursuant to, and subject 295 to the license terms contained in, the Simplified BSD 296 License set forth in Section 4.c of the IETF Trust's Legal 297 Provisions Relating to IETF Documents 298 (http://trustee.ietf.org/license-info). 300 This version of this YANG module is part of RFC XXXX; see 301 the RFC itself for full legal notices."; 303 // RFC Ed.: replace XXXX with actual RFC number and remove this 304 // note. 306 revision 2015-03-04 { 307 description "Base model for Network Access Control List (ACL)."; 308 reference 309 "RFC XXXX: Network Access Control List (ACL) 310 YANG Data Model"; 311 } 313 identity access-control-list-base { 314 description "Base access control list type for all access control list type 315 identifiers."; 316 } 318 identity IP-access-control-list { 319 base "access-control-list:access-control-list-base"; 320 description "IP-access control list is common name for layer 3 and 4 access 321 control list types. It is common among vendors to call 3-tupple or 5 tupple 322 IP access control lists"; 323 } 325 identity eth-access-control-list { 326 base "access-control-list:access-control-list-base"; 327 description "Ethernet access control list is name for layer 2 Ethernet 328 technology access control list types, like 10/100/1000baseT or WiFi 329 access control list"; 330 } 332 typedef access-control-list-type { 333 type identityref { 334 base "access-control-list-base"; 335 } 336 description 337 "This type is used to refer to an Access Control List 338 (ACL) type"; 339 } 341 typedef access-control-list-ref { 342 type leafref { 343 path "/access-lists/access-list/access-control-list-name"; 344 } 345 description "This type is used by data models that need to referenced an 346 access control list"; 348 } 350 container access-lists { 351 description 352 "This is top level container for Access Control Lists. It can have one 353 or more Access Control List."; 355 list access-list { 356 key access-control-list-name; 357 description "An access list (acl) is an ordered list of 358 access list entries (ACE). Each access control entries has a 359 list of match criteria, and a list of actions. 360 Since there are several kinds of access control lists 361 implemented with different attributes for 362 each and different for each vendor, this 363 model accommodates customizing access control lists for 364 each kind and for each vendor."; 366 leaf access-control-list-name { 367 type string; 368 description "The name of access-list. A device MAY restrict the length 369 and value of this name, possibly space and special characters are not 370 allowed."; 371 } 373 leaf access-control-list-type { 374 type access-control-list-type; 375 description "Type of access control list. When this 376 type is not explicitely specified, if vendor implementation permits, 377 the access control entires in the list can be mixed, 378 by containing L2, L3 and L4 entries"; 379 } 380 container access-control-list-oper-data { 381 config false; 382 description "Overall access control list operational data"; 384 choice targets{ 385 description "List of targets where access control list is applied"; 386 leaf-list interface-name { 387 type string; 388 description "Interfaces where access control list is applied"; 389 } 390 } 391 } 393 container access-list-entries { 394 description "The access-list-entries container contains 395 a list of access-list-entry(ACE)."; 397 list access-list-entry { 398 key rule-name; 399 ordered-by user; 400 description "List of access list entries(ACE)"; 401 leaf rule-name { 402 type string; 403 description "Entry name."; 404 } 406 container matches { 407 description "Define match criteria"; 408 choice access-list-entries-type { 409 description "Type of access list entry."; 410 case access-list-entries-ip { 411 uses packet-fields:access-control-list-ip-header-fields; 412 choice access-list-entries-ip-version { 413 description "Choice of IP version."; 414 case access-list-entries-ipv4 { 415 uses packet-fields:access-control-list-ipv4-header-fields; 416 } 417 case access-list-entries-ipv6 { 419 uses packet-fields:access-control-list-ipv6-header-fields; 420 } 421 } 422 } 423 case access-list-entries-eth { 424 description "Ethernet MAC address entry."; 425 uses packet-fields:access-control-list-eth-header-fields; 426 } 427 } 428 uses packet-fields:metadata; 429 } 431 container actions { 432 description "Define action criteria"; 433 choice packet-handling { 434 default deny; 436 description "Packet handling action."; 437 case deny { 438 leaf deny { 439 type empty; 440 description "Deny action."; 442 } 443 } 444 case permit { 445 leaf permit { 446 type empty; 447 description "Permit action."; 448 } 449 } 450 } 451 } 453 container access-list-entries-oper-data { 454 config false; 456 description "Per access list entries operational data"; 457 leaf match-counter { 458 type yang:counter64; 459 description "Number of matches for an access list entry"; 460 } 461 } 462 } 463 } 464 } 465 } 466 } 468 469 4.2. IETF-PACKET-FIELDS module 471 The packet fields module defines the necessary groups for matching on 472 fields in the packet including ethernet, ipv4, ipv6, transport layer 473 fields and metadata. These groupings can be augmented to include 474 other proprietary matching criteria. Since the number of match 475 criteria is very large, the base draft does not include these 476 directly but references them by "uses" to keep the base module 477 simple. 479 file "ietf-packet-fields@2015-03-04.yang" 481 module ietf-packet-fields { 482 yang-version 1; 484 namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; 486 prefix packet-fields; 488 import ietf-inet-types { 489 prefix "inet"; 491 } 493 import ietf-yang-types { 494 prefix "yang"; 495 } 497 organization 498 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 500 contact 501 "WG Web: http://tools.ietf.org/wg/netmod/ 502 WG List: netmod@ietf.org 504 WG Chair: Juergen Schoenwaelder 505 j.schoenwaelder@jacobs-university.de 507 WG Chair: Tom Nadeau 508 tnadeau@lucidvision.com 510 Editor: Dean Bogdanovic 511 deanb@juniper.net 513 Editor: Kiran Agrahara Sreenivasa 514 kkoushik@brocade.com 516 Editor: Lisa Huang 517 yihuan@cisco.com 519 Editor: Dana Blair 521 dblair@cisco.com"; 523 description 524 "This YANG module defines groupings that used by ietf-acl 525 but not limited to acl. 527 Copyright (c) 2015 IETF Trust and the persons identified as 528 the document authors. All rights reserved. 530 Redistribution and use in source and binary forms, with or 531 without modification, is permitted pursuant to, and subject 532 to the license terms contained in, the Simplified BSD 533 License set forth in Section 4.c of the IETF Trust's Legal 534 Provisions Relating to IETF Documents 535 (http://trustee.ietf.org/license-info). 537 This version of this YANG module is part of RFC XXXX; see 538 the RFC itself for full legal notices."; 540 // RFC Ed.: replace XXXX with actual RFC number and remove this 541 // note. 543 revision 2015-03-04 { 544 description "Initial version of packet fields used by 545 access-lists"; 546 reference 547 "RFC XXXX: Network Access Control List (ACL) 548 YANG Data Model"; 549 } 551 grouping access-control-list-transport-header-fields { 552 description "Transport header fields"; 554 container source-port-range { 555 description "inclusive range of source ports"; 556 leaf lower-port { 557 type inet:port-number; 558 mandatory true; 559 description "Lower boundary."; 560 } 561 leaf upper-port { 562 type inet:port-number; 563 description "Upper boundary. If exist, upper port must be greater or 564 equal to lower port."; 566 } 567 } 569 container destination-port-range { 570 description "inclusive range of destination ports"; 571 leaf lower-port { 572 type inet:port-number; 573 mandatory true; 574 description "Lower boundary."; 575 } 576 leaf upper-port { 577 type inet:port-number; 578 description "Upper boundary."; 579 } 580 } 581 } 583 grouping access-control-list-ip-header-fields { 584 description "Header fields common to ipv4 and ipv6"; 586 uses access-control-list-transport-header-fields; 588 leaf dscp { 589 type inet:dscp; 591 description "Value of dscp."; 592 } 594 leaf protocol { 595 type uint8; 596 description "Internet Protocol number."; 597 } 599 } 601 grouping access-control-list-ipv4-header-fields { 602 description "fields in IPv4 header"; 604 leaf destination-ipv4-network { 605 type inet:ipv4-prefix; 606 description "One or more ip addresses."; 607 } 609 leaf source-ipv4-network { 610 type inet:ipv4-prefix; 611 description "One or more ip addresses."; 612 } 614 } 616 grouping access-control-list-ipv6-header-fields { 617 description "fields in IPv6 header"; 619 leaf destination-ipv6-network { 620 type inet:ipv6-prefix; 621 description "One or more ip addresses."; 622 } 624 leaf source-ipv6-network { 625 type inet:ipv6-prefix; 626 description "One or more ip addresses."; 627 } 629 leaf flow-label { 630 type inet:ipv6-flow-label; 631 description "Flow label."; 632 } 634 } 636 grouping access-control-list-eth-header-fields { 638 description "fields in ethernet header"; 640 leaf destination-mac-address { 641 type yang:mac-address; 642 description "Mac addresses."; 643 } 645 leaf destination-mac-address-mask { 646 type yang:mac-address; 647 description "Mac addresses mask."; 648 } 650 leaf source-mac-address { 651 type yang:mac-address; 652 description "Mac addresses."; 653 } 655 leaf source-mac-address-mask { 656 type yang:mac-address; 657 description "Mac addresses mask."; 658 } 659 } 661 grouping timerange { 662 description "Time range contains time 663 segments to allow access-control-list to be 664 active/inactive when the system time 665 is within the time segments."; 667 container absolute { 668 description 669 "Absolute time and date that 670 the associated function starts 671 going into effect."; 673 leaf start { 674 type yang:date-and-time; 675 description 676 "Start time and date"; 677 } 678 leaf end { 679 type yang:date-and-time; 680 description "Absolute end time and date"; 681 } 682 leaf active { 683 type boolean; 684 default "true"; 685 description 687 "Specify the associated function 689 active or inactive state when 690 starts going into effect"; 691 } 692 } // container absolute 693 } //grouping timerange 695 grouping metadata { 696 description "Fields associated with a packet but not in 697 the header"; 699 leaf input-interface { 700 type string; 701 description "Packet was received on this interface"; 702 } 703 uses timerange; 704 } 705 } 707 708 4.3. An ACL Example 710 Requirement: Deny All traffic from 10.10.10.1 bound for host 711 10.10.10.255 from leaving. 713 In order to achieve the requirement, an name access control list is 714 needed. The acl and aces can be described in CLI as the following: 716 access-list ip iacl 717 deny tcp host 10.10.10.1 host 10.10.10.255 719 Figure 1 721 Here is the example acl configuration xml: 723 724 // replace with IANA namespace when assigned 725 726 727 728 729 730 731 732 733 sample-ip-acl 734 735 736 telnet-block-rule 737 738 10.10.10.255/24 739 10.10.10.1/24 740 741 742 743 744 745 746 747 748 749 750 751 753 Figure 2 755 4.4. Port Range Usage Example 757 When a lower-port and an upper-port are both present, it represents a 758 range between lower-port and upper-port with both the lower-port and 759 upper-port are included. When only a lower-port presents, it 760 represents a single port. 762 With the follow XML snippet: 764 765 16384 766 16387 767 769 This represents source ports 16384,16385, 16386, and 16387. 771 With the follow XML snippet: 773 774 16384 775 65535 776 778 This represents source ports greater than/equal to 16384. 780 With the follow XML snippet: 782 783 21 784 786 This represents port 21. 788 5. Linux nftables 790 As Linux platform is becoming more popular as networking platform, 791 the Linux data model is changing. Previously ACLs in Linux were 792 highly protocol specific and different utilities were used for it 793 (iptables, ip6tables, arptables, ebtables). Recently, this has 794 changed and a single utility, nftables, has been provided. This 795 utility follows very similarly the same base model as proposed in 796 this draft. The nftables support input and output ACEs and each ACE 797 can be defined with match and action. 799 6. Security Considerations 801 The YANG module defined in this memo is designed to be accessed via 802 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 803 is the secure transport layer and the mandatory-to-implement secure 804 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 805 model [RFC6536] [RFC6536] provides the means to restrict access for 806 particular NETCONF users to a pre-configured subset of all available 807 NETCONF protocol operations and content. 809 There are a number of data nodes defined in the YANG module which are 810 writable/creatable/deletable (i.e., config true, which is the 811 default). These data nodes may be considered sensitive or vulnerable 812 in some network environments. Write operations (e.g., ) 813 to these data nodes without proper protection can have a negative 814 effect on network operations. 816 These are the subtrees and data nodes and their sensitivity/ 817 vulnerability: 819 /ietf-acl:access-lists/access-list/access-list-entries: This list 820 specifies all the configured access list entries on the device. 821 Unauthorized write access to this list can allow intruders to access 822 and control the system. Unauthorized read access to this list can 823 allow intruders to spoof packets with authorized addresses thereby 824 compromising the system. 826 7. IANA Considerations 828 This document registers a URI in the IETF XML registry [RFC3688] 829 [RFC3688]. Following the format in RFC 3688, the following 830 registration is requested to be made: 832 URI: urn:ietf:params:xml:ns:yang:ietf-acl 834 URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields 836 Registrant Contact: The IESG. 838 XML: N/A, the requested URI is an XML namespace. 840 This document registers a YANG module in the YANG Module Names 841 registry [RFC6020]. 843 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-acl 844 prefix: ietf-acl reference: RFC XXXX 845 name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf- 846 packet-fields prefix: ietf-packet-fields reference: RFC XXXX 848 8. Acknowledgements 850 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 851 an initial IETF draft in several past IETF meetings. That draft 852 included an ACL YANG model structure and a rich set of match filters, 853 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 854 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 855 and Phil Shafer. Many people have reviewed the various earlier 856 drafts that made the draft went into IETF charter. 858 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 859 Blair each evaluated the YANG model in previous draft separately and 860 then work together, to created a new ACL draft that can be supported 861 by different vendors. The new draft removes vendor specific 862 features, and gives examples to allow vendors to extend in their own 863 proprietary ACL. The earlier draft was superseded with the new one 864 that received more participation from many vendors. 866 9. References 868 9.1. Normative References 870 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 871 January 2004. 873 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 874 Network Configuration Protocol (NETCONF)", RFC 6020, 875 October 2010. 877 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 878 Bierman, "Network Configuration Protocol (NETCONF)", RFC 879 6241, June 2011. 881 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 882 Shell (SSH)", RFC 6242, June 2011. 884 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 885 Protocol (NETCONF) Access Control Model", RFC 6536, March 886 2012. 888 9.2. Informative References 890 [RFC5101] Claise, B., "Specification of the IP Flow Information 891 Export (IPFIX) Protocol for the Exchange of IP Traffic 892 Flow Information", RFC 5101, January 2008. 894 Appendix A. Extending ACL model examples 896 A.1. Example of extending existing model for route filtering 898 With proposed modular design, it is easy to extend the model with 899 other features. Those features can be standard features, like route 900 filters. Route filters match on specific IP addresses or ranges of 901 prefixes. Much like ACLs, they include some match criteria and 902 corresponding match action(s). For that reason, it is very simple to 903 extend existing ACL model with route filtering. The combination of a 904 route prefix and prefix length along with the type of match 905 determines how route filters are evaluated against incoming routes. 906 Different vendors have different match types and in this model we are 907 using only ones that are common across all vendors participating in 908 this draft. As in this example, the base ACL model can be extended 909 with company proprietary extensions, described in the next section. 911 file "std-ext-route-filter@2015-02-14.yang" 913 module std-ext-route-filter { 914 yang-version 1; 916 namespace "urn:ietf:params:xml:ns:yang:ietf-route-filter"; 918 prefix std-ext-route-filter; 920 import ietf-inet-types { 921 prefix "inet"; 922 } 924 import ietf-acl { 925 prefix "ietf-acl"; 926 } 927 organization 928 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 930 contact 931 "WG Web: http://tools.ietf.org/wg/netmod/ 932 WG List: netmod@ietf.org 934 WG Chair: Juergen Schoenwaelder 935 j.schoenwaelder@jacobs-university.de 937 WG Chair: Tom Nadeau 938 tnadeau@lucidvision.com 940 Editor: Dean Bogdanovic 941 deanb@juniper.net 942 Editor: Kiran Agrahara Sreenivasa 943 kkoushik@brocade.com 945 Editor: Lisa Huang 946 yihuan@cisco.com 948 Editor: Dana Blair 949 dblair@cisco.com"; 951 description " 952 This module describes route filter as a collection of 953 match prefixes. When specifying a match prefix, you 954 can specify an exact match with a particular route or 955 a less precise match. You can configure either a 956 common action that applies to the entire list or an 957 action associated with each prefix. 958 "; 960 revision 2015-02-14 { 961 description "creating Route-Filter extension model based on ietf-acl model"; 962 reference " "; 963 } 965 augment "/ietf-acl:access-lists/ietf-acl:access-list 966 /ietf-acl:access-list-entries/ 967 ietf-acl:access-list-entry/ietf-acl:matches"{ 968 description " 969 This module augments the matches container in the ietf-acl 970 module with route filter specific actions 971 "; 972 choice route-prefix{ 973 description "Define route filter match criteria"; 974 case range { 975 description " 976 Route falls between the lower prefix/prefix-length and the upper 977 prefix/prefix-length. 978 "; 979 choice ipv4-range { 980 description "Defines the lower IPv4 prefix/prefix range"; 981 leaf v4-lower-bound { 982 type inet:ipv4-prefix; 983 description "Defines the lower IPv4 prefix/prefix length"; 984 } 985 leaf v4-upper-bound { 986 type inet:ipv4-prefix; 987 description "Defines the upper IPv4 prefix/prefix length"; 988 } 989 } 990 choice ipv6-range { 991 description "Defines the IPv6 prefix/prefix range"; 992 leaf v6-lower-bound { 993 type inet:ipv6-prefix; 994 description "Defines the lower IPv6 prefix/prefix length"; 995 } 996 leaf v6-upper-bound { 997 type inet:ipv6-prefix; 998 description "Defines the upper IPv6 prefix/prefix length"; 999 } 1000 } 1001 } 1002 } 1003 } 1004 } 1005 1007 A.2. A company proprietary module example 1009 Module "newco-acl" is an example of company proprietary model that 1010 augments "ietf-acl" module. It shows how to use 'augment' with an 1011 XPath expression to add additional match criteria, action criteria, 1012 and default actions when no ACE matches found. All these are company 1013 proprietary extensions or system feature extensions. "newco-acl" is 1014 just an example and it is expected from vendors to create their own 1015 proprietary models. 1017 The following figure is the tree structure of newco-acl. In this 1018 example, ietf-acl:access-lists/ietf-acl:access-list/ietf-acl:access- 1019 list-entries/ietf-acl:access-list-entry/ietf-acl:matches: are 1020 augmented with a new choice, protocol-payload-choice. The protocol- 1021 payload-choice uses a grouping with an enumeration of all supported 1022 protocol values. In other example, ietf-acl:access-lists/ietf-acl 1023 :access-list/ietf-acl:access-list-entries/ietf-acl:access-list-entry/ 1024 ietf-acl:actions are augmented with new choice of actions. 1026 module: newco-acl 1027 augment /ietf-acl:access-lists/ietf-acl:access-list 1028 /ietf-acl:access-list-entries/ 1029 ietf-acl:access-list-entry/ietf-acl:matches: 1030 +--rw (protocol-payload-choice)? 1031 +--:(protocol-payload) 1032 +--rw protocol-payload* [value-keyword] 1033 +--rw value-keyword enumeration 1034 augment /ietf-acl:access-lists/ietf-acl:access-list 1035 /ietf-acl:access-list-entries/ 1036 ietf-acl:access-list-entry/ietf-acl:actions: 1037 +--rw (action)? 1038 +--:(count) 1039 | +--rw count? string 1040 +--:(policer) 1041 | +--rw policer? string 1042 +--:(hiearchical-policer) 1043 +--rw hierarchitacl-policer? string 1044 augment /ietf-acl:access-lists/ietf-acl:access-list: 1045 +--rw default-actions 1046 +--rw deny? empty 1048 file "newco-acl@2015-03-04.yang" 1050 module newco-acl { 1051 yang-version 1; 1053 namespace "urn:newco:params:xml:ns:yang:newco-acl"; 1055 prefix newco-acl; 1057 import ietf-acl { 1058 prefix "ietf-acl"; 1059 } 1061 revision 2015-03-04{ 1062 description "creating NewCo proprietary extensions to ietf-acl model"; 1063 } 1065 augment "/ietf-acl:access-lists/ietf-acl:access-list 1066 /ietf-acl:access-list-entries/ 1067 ietf-acl:access-list-entry/ietf-acl:matches" { 1068 description "Newco proprietary simple filter matches"; 1069 choice protocol-payload-choice { 1070 list protocol-payload { 1071 key value-keyword; 1072 ordered-by user; 1073 description "Match protocol payload"; 1074 uses match-simple-payload-protocol-value; 1075 } 1076 } 1077 } 1079 augment "/ietf-acl:access-lists/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:access-list-entry/ietf-acl:actions" { 1080 description "Newco proprietary simple filter actions"; 1081 choice action { 1082 case count { 1083 description "Count the packet in the named counter"; 1084 leaf count { 1085 type string; 1086 } 1087 } 1088 case policer { 1089 description "Name of policer to use to rate-limit traffic"; 1090 leaf policer { 1091 type string; 1092 } 1093 } 1094 case hiearchical-policer { 1095 description "Name of hierarchical policer to use to 1096 rate-limit traffic"; 1097 leaf hierarchitacl-policer{ 1098 type string; 1099 } 1100 } 1101 } 1102 } 1104 augment "/ietf-acl:access-lists/ietf-acl:access-list" { 1105 container default-actions { 1106 description "Actions that occur if no access-list entry is matched."; 1107 leaf deny { 1108 type empty; 1109 } 1110 } 1111 } 1113 grouping match-simple-payload-protocol-value { 1114 leaf value-keyword { 1115 description "(null)"; 1116 type enumeration { 1117 enum icmp { 1118 description "Internet Control Message Protocol"; 1119 } 1120 enum icmp6 { 1121 description "Internet Control Message Protocol Version 6"; 1123 } 1124 enum range { 1125 description "Range of values"; 1126 } 1127 } 1128 } 1129 } 1130 } 1132 1134 Draft authors expect that different vendors will provide their own 1135 yang models as in the example above, which is the extension of the 1136 base model 1138 A.3. Attaching Access Control List to interfaces 1140 Access control list typically does not exist in isolation. Instead, 1141 they are associated with a certain scope in which they are applied, 1142 for example, an interface of a set of interfaces. How to attach an 1143 SPF to an interface (or other system artifact) is outside the scope 1144 of this model, as it depends on the specifics of the system model 1145 that is being applied. However, in general, the general design 1146 pattern will involved adding a dada node with a reference, or set of 1147 references, to ACLs that are to be applied to the interface. For 1148 this purpose, the type definition "access-control-list-ref" can be 1149 used. 1151 This is an example of attaching an access control list to an 1152 interface. 1154 file "interface model augmentation with ACL 1155 @2015-03-04.yang" 1156 import ietf-acl { 1157 prefix "ietf-acl"; 1158 } 1159 import ietf-interface { 1160 prefix "ietf-if"; 1161 } 1162 import ietf-yang-types { 1163 prefix "yang"; 1164 } 1166 augment "/ietf-if:interfaces/ietf-if:interface" { 1167 description "Apply acl to interfaces"; 1168 container acl{ 1169 description "ACL related properties."; 1170 leaf acl-name { 1171 type ietf-acl:access-control-list-ref; 1172 mandatory true; 1173 description "Access Control List name."; 1174 } 1175 leaf match-counter { 1176 type yang:counter64; 1177 config false; 1178 description "Total match count for access control list "; 1179 } 1180 choice direction { 1181 leaf in { type empty;} 1182 leaf out { type empty;} 1183 } 1184 } 1185 } 1186 1188 Authors' Addresses 1190 Dean Bogdanovic 1191 Juniper Networks 1193 Email: deanb@juniper.net 1195 Kiran Agrahara Sreenivasa 1196 Brocade Communications System 1198 Email: kkoushik@brocade.com 1199 Lisa Huang 1200 Cisco Systems 1202 Email: yihuan@cisco.com 1204 Dana Blair 1205 Cisco Systems 1207 Email: dblair@cisco.com