idnits 2.17.1 draft-ietf-netmod-acl-model-07.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 18 instances of too long lines in the document, the longest one being 36 characters in excess of 72. == There are 5 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 355: '...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 206 has weird spacing: '...er-port ine...' == Line 209 has weird spacing: '...er-port ine...' == Line 989 has weird spacing: '...keyword enu...' -- The document date (March 11, 2016) is 2968 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 4 Intended status: Standards Track K. Sreenivasa 5 Expires: September 12, 2016 Cisco Systems 6 L. Huang 7 Juniper Networks 8 D. Blair 9 Cisco Systems 10 March 11, 2016 12 Network Access Control List (ACL) YANG Data Model 13 draft-ietf-netmod-acl-model-07 15 Abstract 17 This document describes a data model of Access Control List (ACL) 18 basic building blocks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Design of the ACL Model . . . . . . . . . . . . . . . . . . . 4 58 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. IETF Access Contorl List module . . . . . . . . . . . . . 6 61 4.2. IETF-PACKET-FIELDS module . . . . . . . . . . . . . . . . 10 62 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 15 63 4.4. Port Range Usage Example . . . . . . . . . . . . . . . . 15 64 5. Linux nftables . . . . . . . . . . . . . . . . . . . . . . . 16 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 9.2. Informative References . . . . . . . . . . . . . . . . . 19 71 Appendix A. Extending ACL model examples . . . . . . . . . . . . 19 72 A.1. Example of extending existing model for route filtering . 19 73 A.2. A company proprietary module example . . . . . . . . . . 21 74 A.3. Attaching Access Control List to interfaces . . . . . . . 24 75 A.4. Example to augment model with mixed ACL type . . . . . . 26 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 78 1. Introduction 80 Access Control List (ACL) is one of the basic elements to configure 81 device forwarding behavior. It is used in many networking concepts 82 such as Policy Based Routing, Firewalls etc. 84 An ACL is an ordered set of rules that is used to filter traffic on a 85 networking device. Each rule is represented by an Access Control 86 Entry (ACE). 88 Each ACE has a group of match criteria and a group of action 89 criteria. 91 The match criteria consist of a tuple of packet header match criteria 92 and metadata match criteria. 94 o Packet header matches apply to fields visible in the packet such 95 as address or class of service or port numbers. 97 o Metadata matches apply to fields associated with the packet but 98 not in the packet header such as input interface or overall packet 99 length 101 The actions specify what to do with the packet when the matching 102 criteria is met. These actions are any operations that would apply 103 to the packet, such as counting, policing, or simply forwarding.The 104 list of potential actions is endless depending on the innovations of 105 the networked devices. 107 Access Control List is also widely knowns as ACL (pronounce as [ak-uh 108 l]) or Access List. In this document, Access Control List, ACL and 109 Access List are interchangeable. 111 1.1. Definitions and Acronyms 113 ACE: Access Control Entry 115 ACL: Access Control List 117 DSCP: Differentiated Services Code Point 119 ICMP: Internet Control Message Protocol 121 IP: Internet Protocol 123 IPv4: Internet Protocol version 4 125 IPv6: Internet Protocol version 6 127 MAC: Media Access Control 129 TCP: Transmission Control Protocol 131 2. Problem Statement 133 This document defines a YANG [RFC6020] data model for the 134 configuration of ACLs. It is very important that model can be easily 135 reused between vendors and between applications. 137 ACL implementations in every device may vary greatly in terms of the 138 filter constructs and actions that they support. Therefore this 139 draft proposes a simple model that can be augmented by standard 140 extensions and vendor proprietary models. 142 3. Design of the ACL Model 144 Although different vendors have different ACL data models, there is a 145 common understanding of what access control list (ACL) is. A network 146 system usually have a list of ACLs, and each ACL contains an ordered 147 list of rules, also known as access list entries - ACEs. Each ACE 148 has a group of match criteria and a group of action criteria. The 149 match criteria consist of packet header matching and metadata 150 matching. Packet header matching applies to fields visible in the 151 packet such as address or class of service or port numbers. Metadata 152 matching applies to fields associated with the packet, but not in the 153 packet header such as input interface, packet length, or source or 154 destination prefix length. The actions can be any sort of operation 155 from logging to rate limiting or dropping to simply forwarding. 156 Actions on the first matching ACE are applied with no processing of 157 subsequent ACEs. The model also includes a container to hold overall 158 operational state for each ACL and operational state for each ACE. 159 One ACL can be applied to multiple targets within the device, such as 160 interfaces of a networked device, applications or features running in 161 the device, etc. When applied to interfaces of a networked device, 162 the ACL is applied in a direction which indicates if it should be 163 applied to packet entering (input) or leaving the device (output). 164 An example in the appendix shows how to express it in YANG model. 166 This draft tries to address the commonalities between all vendors and 167 create a common model, which can be augmented with proprietary 168 models. The base model is very simple and with this design we hope 169 to achieve needed flexibility for each vendor to extend the base 170 model. 172 3.1. ACL Modules 174 There are two YANG modules in the model. The first module, "ietf- 175 access-control-list", defines generic ACL aspects which are common to 176 all ACLs regardless of their type or vendor. In effect, the module 177 can be viewed as providing a generic ACL "superclass". It imports 178 the second module, "ietf-packet-fields". The match container in 179 "ietf-access-control-list" uses groupings in "ietf-packet-fields". 180 If there is a need to define new "matches" choice, such as IPFIX 181 [RFC5101], the container "matches" can be augmented. 183 module: ietf-access-control-list 184 +--rw access-lists 185 +--rw acl* [acl-type acl-name] 186 +--rw acl-name string 187 +--rw acl-type acl-type 188 +--ro acl-oper-data 189 +--rw access-list-entries 190 +--rw ace* [rule-name] 191 +--rw rule-name string 192 +--rw matches 193 | +--rw (ace-type)? 194 | | +--:(ace-ip) 195 | | | +--rw (ace-ip-version)? 196 | | | | +--:(ace-ipv4) 197 | | | | | +--rw destination-ipv4-network? inet:ipv4-prefix 198 | | | | | +--rw source-ipv4-network? inet:ipv4-prefix 199 | | | | +--:(ace-ipv6) 200 | | | | +--rw destination-ipv6-network? inet:ipv6-prefix 201 | | | | +--rw source-ipv6-network? inet:ipv6-prefix 202 | | | | +--rw flow-label? inet:ipv6-flow-label 203 | | | +--rw dscp? inet:dscp 204 | | | +--rw protocol? uint8 205 | | | +--rw source-port-range! 206 | | | | +--rw lower-port inet:port-number 207 | | | | +--rw upper-port? inet:port-number 208 | | | +--rw destination-port-range! 209 | | | +--rw lower-port inet:port-number 210 | | | +--rw upper-port? inet:port-number 211 | | +--:(ace-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? if:interface-ref 217 +--rw actions 218 | +--rw (packet-handling)? 219 | +--:(deny) 220 | | +--rw deny? empty 221 | +--:(permit) 222 | +--rw permit? empty 223 +--ro ace-oper-data 224 +--ro match-counter? yang:counter64 226 Figure 1 228 4. ACL YANG Models 230 4.1. IETF Access Contorl List module 232 "ietf-access-control-list" is the standard top level module for 233 access lists. The "access-lists" container stores a list of "acl". 234 Each "acl" has information identifying the access list by a 235 name("acl-name") and a list("access-list-entries") of rules 236 associated with the "acl-name". Each of the entries in the 237 list("access-list-entries"), indexed by the string "rule-name", has 238 containers defining "matches" and "actions". The "matches" define 239 criteria used to identify patterns in "ietf-packet-fields". The 240 "actions" define behavior to undertake once a "match" has been 241 identified. 243 file "ietf-access-control-list@2016-02-18.yang" 244 module ietf-access-control-list { 245 yang-version "1.1"; 246 namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; 247 prefix acl; 248 import ietf-yang-types { 249 prefix yang; 250 } 251 import ietf-packet-fields { 252 prefix packet-fields; 253 } 254 organization "IETF NETMOD (NETCONF Data Modeling Language) 255 Working Group"; 256 contact 257 "WG Web: http://tools.ietf.org/wg/netmod/ 258 WG List: netmod@ietf.org 259 WG Chair: Juergen Schoenwaelder 260 j.schoenwaelder@jacobs-university.de 261 WG Chair: Tom Nadeau 262 tnadeau@lucidvision.com 263 Editor: Dean Bogdanovic 264 ivandean@gmail.com 265 Editor: Kiran Agrahara Sreenivasa 266 kkoushik@cisco.com 267 Editor: Lisa Huang 268 lyihuang@juniper.net 269 Editor: Dana Blair 270 dblair@cisco.com"; 271 description 272 "This YANG module defines a component that describing the 273 configuration of Access Control Lists (ACLs). 274 Copyright (c) 2016 IETF Trust and the persons identified as 275 the document authors. All rights reserved. 277 Redistribution and use in source and binary forms, with or 278 without modification, is permitted pursuant to, and subject 279 to the license terms contained in, the Simplified BSD 280 License set forth in Section 4.c of the IETF Trust's Legal 281 Provisions Relating to IETF Documents 282 (http://trustee.ietf.org/license-info). 283 This version of this YANG module is part of RFC XXXX; see 284 the RFC itself for full legal notices."; 285 revision 2016-02-18 { 286 description 287 "Base model for Network Access Control List (ACL)."; 288 reference 289 "RFC XXXX: Network Access Control List (ACL) 290 YANG Data Model"; 291 } 292 identity acl-base { 293 description 294 "Base Access Control List type for all Access Control List type 295 identifiers."; 296 } 297 identity ipv4-acl { 298 base acl:acl-base; 299 description 300 "ACL that primarily matches on fields from the IPv4 header 301 (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP 302 destination port). An acl of type ipv4-acl does not contain 303 matches on fields in the ethernet header or the IPv6 header."; 304 } 305 identity ipv6-acl { 306 base acl:acl-base; 307 description 308 "ACL that primarily matches on fields from the IPv6 header 309 (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP 310 destination port). An acl of type ipv6-acl does not contain 311 matches on fields in the ethernet header or the IPv4 header."; 312 } 313 identity eth-acl { 314 base acl:acl-base; 315 description 316 "ACL that primarily matches on fields in the ethernet header, 317 like 10/100/1000baseT or WiFi Access Control List. An acl of 318 type eth-acl does not contain matches on fields in the IPv4 319 header, IPv6 header or layer 4 headers."; 320 } 321 typedef acl-type { 322 type identityref { 323 base acl-base; 324 } 325 description 326 "This type is used to refer to an Access Control List 327 (ACL) type"; 328 } 329 typedef access-control-list-ref { 330 type leafref { 331 path "/access-lists/acl/acl-name"; 332 } 333 description 334 "This type is used by data models that need to reference an 335 Access Control List"; 336 } 337 container access-lists { 338 description 339 "This is a top level container for Access Control Lists. 340 It can have one or more Access Control Lists."; 341 list acl { 342 key "acl-type acl-name"; 343 description 344 "An Access Control List(ACL) is an ordered list of 345 Access List Entries (ACE). Each Access Control Entry has a 346 list of match criteria and a list of actions. 347 Since there are several kinds of Access Control Lists 348 implemented with different attributes for 349 different vendors, this 350 model accommodates customizing Access Control Lists for 351 each kind and for each vendor."; 352 leaf acl-name { 353 type string; 354 description 355 "The name of access-list. A device MAY restrict the length 356 and value of this name, possibly space and special 357 characters are not allowed."; 358 } 359 leaf acl-type { 360 type acl-type; 361 description 362 "Type of access control list. Indicates the primary intended 363 type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) 364 used in the list instance."; 365 } 366 container acl-oper-data { 367 config false; 368 description 369 "Overall Access Control List operational data"; 370 } 371 container access-list-entries { 372 description 373 "The access-list-entries container contains 374 a list of access-list-entries(ACE)."; 375 list ace { 376 key "rule-name"; 377 ordered-by user; 378 description 379 "List of access list entries(ACE)"; 380 leaf rule-name { 381 type string; 382 description 383 "A unique name identifying this Access List 384 Entry(ACE)."; 385 } 386 container matches { 387 description 388 "Definitions for match criteria for this Access List 389 Entry."; 390 choice ace-type { 391 description 392 "Type of access list entry."; 393 case ace-ip { 394 description "IP Access List Entry."; 395 choice ace-ip-version { 396 description 397 "IP version used in this Acess List Entry."; 398 case ace-ipv4 { 399 uses packet-fields:acl-ipv4-header-fields; 400 } 401 case ace-ipv6 { 402 uses packet-fields:acl-ipv6-header-fields; 403 } 404 } 405 uses packet-fields:acl-ip-header-fields; 406 } 407 case ace-eth { 408 description 409 "Ethernet Access List entry."; 410 uses packet-fields:acl-eth-header-fields; 411 } 412 } 413 uses packet-fields:metadata; 414 } 415 container actions { 416 description 417 "Definitions of action criteria for this Access List 418 Entry."; 419 choice packet-handling { 420 default "deny"; 421 description 422 "Packet handling action."; 423 case deny { 424 leaf deny { 425 type empty; 426 description 427 "Deny action."; 428 } 429 } 430 case permit { 431 leaf permit { 432 type empty; 433 description 434 "Permit action."; 435 } 436 } 437 } 438 } 439 container ace-oper-data { 440 config false; 441 description 442 "Operational data for this Access List Entry."; 443 leaf match-counter { 444 type yang:counter64; 445 description 446 "Number of matches for this Access List Entry"; 447 } 448 } 449 } 450 } 451 } 452 } 453 } 454 456 4.2. IETF-PACKET-FIELDS module 458 The packet fields module defines the necessary groups for matching on 459 fields in the packet including ethernet, ipv4, ipv6, transport layer 460 fields and metadata. Since the number of match criteria is very 461 large, the base draft does not include these directly but references 462 them by "uses" to keep the base module simple. In case more match 463 conditions are needed, those can be added by augmenting choices 464 within container "matches" in ietf-access-control-list.yang model 466 file "ietf-packet-fields@2016-02-18.yang" 467 module ietf-packet-fields { 468 yang-version "1.1"; 469 namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; 470 prefix packet-fields; 471 import ietf-inet-types { 472 prefix inet; 473 } 474 import ietf-yang-types { 475 prefix yang; 476 } 477 import ietf-interfaces { 478 prefix if; 479 } 480 organization "IETF NETMOD (NETCONF Data Modeling Language) Working 481 Group"; 482 contact 483 "WG Web: http://tools.ietf.org/wg/netmod/ 484 WG List: netmod@ietf.org 485 WG Chair: Juergen Schoenwaelder 486 j.schoenwaelder@jacobs-university.de 487 WG Chair: Tom Nadeau 488 tnadeau@lucidvision.com 489 Editor: Dean Bogdanovic 490 deanb@juniper.net 491 Editor: Kiran Agrahara Sreenivasa 492 kkoushik@cisco.com 493 Editor: Lisa Huang 494 lyihuang@juniper.net 495 Editor: Dana Blair 496 dblair@cisco.com"; 497 description 498 "This YANG module defines groupings that are used by 499 ietf-access-control-list YANG module. Their usage is not 500 limited to ietf-access-control-list and can be 501 used anywhere as applicable. 502 Copyright (c) 2016 IETF Trust and the persons identified as 503 the document authors. All rights reserved. 504 Redistribution and use in source and binary forms, with or 505 without modification, is permitted pursuant to, and subject 506 to the license terms contained in, the Simplified BSD 507 License set forth in Section 4.c of the IETF Trust's Legal 508 Provisions Relating to IETF Documents 509 (http://trustee.ietf.org/license-info). 510 This version of this YANG module is part of RFC XXXX; see 511 the RFC itself for full legal notices."; 512 revision 2016-02-18 { 513 description 514 "Initial version of packet fields used by 515 ietf-access-control-list"; 516 reference 517 "RFC XXXX: Network Access Control List (ACL) 518 YANG Data Model"; 519 } 520 grouping acl-transport-header-fields { 521 description 522 "Transport header fields"; 523 container source-port-range { 524 presence "Enables setting source port range"; 525 description 526 "Inclusive range representing source ports to be used. 527 When only lower-port is present, it represents a single port."; 528 leaf lower-port { 529 type inet:port-number; 530 mandatory true; 531 description 532 "Lower boundary for port."; 533 } 534 leaf upper-port { 535 type inet:port-number; 536 must ". >= ../lower-port" { 537 error-message 538 "The upper-port must be greater than or equal to lower-port"; 539 description "Upper boundary port value check."; 540 } 541 description 542 "Upper boundary for port. If existing, the upper port 543 must be greater or equal to lower-port."; 544 } 545 } 546 container destination-port-range { 547 presence "Enables setting destination port range"; 548 description 549 "Inclusive range representing destination ports to be used. When 550 only lower-port is present, it represents a single port."; 551 leaf lower-port { 552 type inet:port-number; 553 mandatory true; 554 description 555 "Lower boundary for port."; 556 } 557 leaf upper-port { 558 type inet:port-number; 559 must ". >= ../lower-port" { 560 error-message 561 "The upper-port must be greater than or equal to lower-port"; 562 description "Upper boundary port value check."; 563 } 564 description 565 "Upper boundary for port. If existing, the upper port must 566 be greater or equal to lower-port"; 567 } 568 } 569 } 570 grouping acl-ip-header-fields { 571 description 572 "IP header fields common to ipv4 and ipv6"; 573 leaf dscp { 574 type inet:dscp; 575 description 576 "Value of dscp."; 577 } 578 leaf protocol { 579 type uint8; 580 description 581 "Internet Protocol number."; 582 } 583 uses acl-transport-header-fields; 584 } 585 grouping acl-ipv4-header-fields { 586 description 587 "Fields in IPv4 header."; 588 leaf destination-ipv4-network { 589 type inet:ipv4-prefix; 590 description 591 "Destination IPv4 address prefix."; 592 } 593 leaf source-ipv4-network { 594 type inet:ipv4-prefix; 595 description 596 "Source IPv4 address prefix."; 597 } 598 } 599 grouping acl-ipv6-header-fields { 600 description 601 "Fields in IPv6 header"; 602 leaf destination-ipv6-network { 603 type inet:ipv6-prefix; 604 description 605 "Destination IPv6 address prefix."; 606 } 607 leaf source-ipv6-network { 608 type inet:ipv6-prefix; 609 description 610 "Source IPv6 address prefix."; 611 } 612 leaf flow-label { 613 type inet:ipv6-flow-label; 614 description 615 "IPv6 Flow label."; 616 } 617 reference 618 "RFC 4291: IP Version 6 Addressing Architecture 619 RFC 4007: IPv6 Scoped Address Architecture 620 RFC 5952: A Recommendation for IPv6 Address Text Representation"; 621 } 622 grouping acl-eth-header-fields { 623 description 624 "Fields in Ethernet header."; 625 leaf destination-mac-address { 626 type yang:mac-address; 627 description 628 "Destination IEEE 802 MAC address."; 629 } 630 leaf destination-mac-address-mask { 631 type yang:mac-address; 632 description 633 "Destination IEEE 802 MAC address mask."; 634 } 635 leaf source-mac-address { 636 type yang:mac-address; 637 description 638 "Source IEEE 802 MAC address."; 639 } 640 leaf source-mac-address-mask { 641 type yang:mac-address; 642 description 643 "Source IEEE 802 MAC address mask."; 644 } 645 reference 646 "IEEE 802: IEEE Standard for Local and Metropolitan Area 647 Networks: Overview and Architecture."; 648 } 650 grouping metadata { 651 description 652 "Fields associated with a packet whick are not in 653 the header."; 654 leaf input-interface { 655 type if:interface-ref { 656 require-instance false; 657 } 658 description 659 "Packet was received on this interface."; 661 } 662 } 663 } 664 666 4.3. An ACL Example 668 Requirement: Deny All traffic from 10.10.10.1/24. 670 Here is the acl configuration xml for this Access Control List: 672 673 674 675 676 sample-ipv4-acl 677 ipv4-acl 678 679 680 rule1 681 682 683 10.10.10.1/24 684 685 686 687 688 689 690 691 692 693 695 The acl and aces can be described in CLI as the following: 697 access-list ip sample-ip-acl 698 deny tcp 10.10.10.1/24 any 700 4.4. Port Range Usage Example 702 When a lower-port and an upper-port are both present, it represents a 703 range between lower-port and upper-port with both the lower-port and 704 upper-port are included. When only a lower-port presents, it 705 represents a single port. 707 With the follow XML snippet: 709 710 16384 711 16387 712 714 This represents source ports 16384,16385, 16386, and 16387. 716 With the follow XML snippet: 718 719 16384 720 65535 721 723 This represents source ports greater than/equal to 16384. 725 With the follow XML snippet: 727 728 21 729 731 This represents port 21. 733 5. Linux nftables 735 As Linux platform is becoming more popular as networking platform, 736 the Linux data model is changing. Previously ACLs in Linux were 737 highly protocol specific and different utilities were used (iptables, 738 ip6tables, arptables, ebtables), so each one had separate data model. 739 Recently, this has changed and a single utility, nftables, has been 740 developed. With a single application, it has a single data model for 741 filewall filters and it follows very similarly to the ietf-access- 742 control list module proposed in this draft. The nftables support 743 input and output ACEs and each ACE can be defined with match and 744 action. 746 The example in Section 4.3 can be configured using nftable tool as 747 below. 749 nft add table ip filter 750 nft add chain filter input 751 nft add rule ip filter input ip protocol tcp ip saddr 10.10.10.1/24 drop 753 The configuration entries added in nftable would be. 755 table ip filter { 756 chain input { 757 ip protocol tcp ip saddr 10.10.10.1/24 drop 758 } 759 } 761 We can see that there are many similarities between Linux nftables 762 and IETF ACL YANG data models and its extension models. It should be 763 fairly easy to do translation between ACL YANG model described in 764 this draft and Linux nftables. 766 6. Security Considerations 768 The YANG module defined in this memo is designed to be accessed via 769 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 770 is the secure transport layer and the mandatory-to-implement secure 771 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 772 model [RFC6536] [RFC6536] provides the means to restrict access for 773 particular NETCONF users to a pre-configured subset of all available 774 NETCONF protocol operations and content. 776 There are a number of data nodes defined in the YANG module which are 777 writable/creatable/deletable (i.e., config true, which is the 778 default). These data nodes may be considered sensitive or vulnerable 779 in some network environments. Write operations (e.g., ) 780 to these data nodes without proper protection can have a negative 781 effect on network operations. 783 These are the subtrees and data nodes and their sensitivity/ 784 vulnerability: 786 /access-lists/acl/access-list-entries: This list specifies all the 787 configured access list entries on the device. Unauthorized write 788 access to this list can allow intruders to access and control the 789 system. Unauthorized read access to this list can allow intruders to 790 spoof packets with authorized addresses thereby compromising the 791 system. 793 7. IANA Considerations 795 This document registers a URI in the IETF XML registry [RFC3688] 796 [RFC3688]. Following the format in RFC 3688, the following 797 registration is requested to be made: 799 URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list 801 URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields 802 Registrant Contact: The IESG. 804 XML: N/A, the requested URI is an XML namespace. 806 This document registers a YANG module in the YANG Module Names 807 registry [RFC6020]. 809 name: ietf-access-control-list namespace: 810 urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl 811 reference: RFC XXXX 813 name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf- 814 packet-fields prefix: ietf-packet-fields reference: RFC XXXX 816 8. Acknowledgements 818 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 819 an initial IETF draft in several past IETF meetings. That draft 820 included an ACL YANG model structure and a rich set of match filters, 821 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 822 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 823 and Phil Shafer. Many people have reviewed the various earlier 824 drafts that made the draft went into IETF charter. 826 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 827 Blair each evaluated the YANG model in previous draft separately and 828 then work together, to created a new ACL draft that can be supported 829 by different vendors. The new draft removes vendor specific 830 features, and gives examples to allow vendors to extend in their own 831 proprietary ACL. The earlier draft was superseded with the new one 832 that received more participation from many vendors. 834 Authors would like to thank Jason Sterne, Lada Lhotka, Juergen 835 Schoenwalder for their review of and suggestions to the draft. 837 9. References 839 9.1. Normative References 841 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 842 DOI 10.17487/RFC3688, January 2004, 843 . 845 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 846 the Network Configuration Protocol (NETCONF)", RFC 6020, 847 DOI 10.17487/RFC6020, October 2010, 848 . 850 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 851 and A. Bierman, Ed., "Network Configuration Protocol 852 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 853 . 855 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 856 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 857 . 859 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 860 Protocol (NETCONF) Access Control Model", RFC 6536, 861 DOI 10.17487/RFC6536, March 2012, 862 . 864 9.2. Informative References 866 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 867 Export (IPFIX) Protocol for the Exchange of IP Traffic 868 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 869 2008, . 871 Appendix A. Extending ACL model examples 873 A.1. Example of extending existing model for route filtering 875 With proposed modular design, it is easy to extend the model with 876 other features. Those features can be standard features, like route 877 filters. Route filters match on specific IP addresses or ranges of 878 prefixes. Much like ACLs, they include some match criteria and 879 corresponding match action(s). For that reason, it is very simple to 880 extend existing ACL model with route filtering. The combination of a 881 route prefix and prefix length along with the type of match 882 determines how route filters are evaluated against incoming routes. 883 Different vendors have different match types and in this model we are 884 using only ones that are common across all vendors participating in 885 this draft. As in this example, the base ACL model can be extended 886 with company proprietary extensions, described in the next section. 888 file "example-ext-route-filter@2016-02-18.yang" 889 module example-ext-route-filter { 890 yang-version 1; 891 namespace "urn:ietf:params:xml:ns:yang:example-ext-route-filter"; 892 prefix example-ext-route-filter; 893 import ietf-inet-types { 894 prefix "inet"; 895 } 896 import ietf-access-control-list { 897 prefix "ietf-acl"; 899 } 901 organization 902 "Route model group."; 904 contact 905 "abc@abc.com"; 907 description " 908 This module describes route filter as a collection of 909 match prefixes. When specifying a match prefix, you 910 can specify an exact match with a particular route or 911 a less precise match. You can configure either a 912 common action that applies to the entire list or an 913 action associated with each prefix. 914 "; 915 revision 2016-02-18 { 916 description 917 "Creating Route-Filter extension model based on 918 ietf-access-control-list model"; 919 reference " "; 920 } 921 augment "/ietf-acl:access-lists/ietf-acl:acl/" 922 + "ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches"{ 923 description " 924 This module augments the matches container in the ietf-acl 925 module with route filter specific actions 926 "; 927 choice route-prefix{ 928 description "Define route filter match criteria"; 929 case range { 930 description 931 "Route falls between the lower prefix/prefix-length 932 and the upperprefix/prefix-length."; 933 choice ipv4-range { 934 description "Defines the IPv4 prefix range"; 935 leaf v4-lower-bound { 936 type inet:ipv4-prefix; 937 description 938 "Defines the lower IPv4 prefix/prefix length"; 939 } 940 leaf v4-upper-bound { 941 type inet:ipv4-prefix; 942 description 943 "Defines the upper IPv4 prefix/prefix length"; 944 } 945 } 946 choice ipv6-range { 947 description "Defines the IPv6 prefix/prefix range"; 948 leaf v6-lower-bound { 949 type inet:ipv6-prefix; 950 description 951 "Defines the lower IPv6 prefix/prefix length"; 952 } 953 leaf v6-upper-bound { 954 type inet:ipv6-prefix; 955 description 956 "Defines the upper IPv6 prefix/prefix length"; 957 } 958 } 959 } 960 } 961 } 962 } 964 A.2. A company proprietary module example 966 Module "example-newco-acl" is an example of company proprietary model 967 that augments "ietf-acl" module. It shows how to use 'augment' with 968 an XPath expression to add additional match criteria, action 969 criteria, and default actions when no ACE matches found. All these 970 are company proprietary extensions or system feature extensions. 971 "example-newco-acl" is just an example and it is expected from 972 vendors to create their own proprietary models. 974 The following figure is the tree structure of example-newco-acl. In 975 this example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- 976 list-entries/ ietf-acl:ace/ietf-acl:matches are augmented with a new 977 choice, protocol-payload-choice. The protocol-payload-choice uses a 978 grouping with an enumeration of all supported protocol values. In 979 other example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- 980 list-entries/ ietf-acl:ace/ietf-acl:actions are augmented with new 981 choice of actions. 983 module: example-newco-acl 984 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ 985 ietf-acl:ace/ietf-acl:matches: 986 +--rw (protocol-payload-choice)? 987 +--:(protocol-payload) 988 +--rw protocol-payload* [value-keyword] 989 +--rw value-keyword enumeration 990 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ 991 ietf-acl:ace/ietf-acl:actions: 992 +--rw (action)? 993 +--:(count) 994 | +--rw count? string 995 +--:(policer) 996 | +--rw policer? string 997 +--:(hiearchical-policer) 998 +--rw hierarchitacl-policer? string 999 augment /ietf-acl:access-lists/ietf-acl:acl: 1000 +--rw default-actions 1001 +--rw deny? empty 1003 file "newco-acl@2016-02-18.yang" 1004 module example-newco-acl { 1005 yang-version 1; 1007 namespace "urn:newco:params:xml:ns:yang:example-newco-acl"; 1009 prefix example-newco-acl; 1011 import ietf-access-control-list { 1012 prefix "ietf-acl"; 1013 } 1015 organization 1016 "Newco model group."; 1018 contact 1019 "abc@newco.com"; 1020 description 1021 "This YANG module augment IETF ACL Yang."; 1023 revision 2016-02-18{ 1024 description 1025 "Creating NewCo proprietary extensions to ietf-acl model"; 1026 reference 1027 "RFC XXXX: Network Access Control List (ACL) 1028 YANG Data Model"; 1029 } 1030 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches" { 1031 description "Newco proprietary simple filter matches"; 1032 choice protocol-payload-choice { 1033 description ""; 1034 list protocol-payload { 1035 key value-keyword; 1036 ordered-by user; 1037 description "Match protocol payload"; 1038 uses match-simple-payload-protocol-value; 1039 } 1040 } 1041 } 1043 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:actions" { 1044 description "Newco proprietary simple filter actions"; 1045 choice action { 1046 description ""; 1047 case count { 1048 description "Count the packet in the named counter"; 1049 leaf count { 1050 type string; 1051 description ""; 1052 } 1053 } 1054 case policer { 1055 description "Name of policer to use to rate-limit traffic"; 1056 leaf policer { 1057 type string; 1058 description ""; 1059 } 1060 } 1061 case hiearchical-policer { 1062 description "Name of hierarchical policer to use to 1063 rate-limit traffic"; 1064 leaf hierarchitacl-policer{ 1065 type string; 1066 description ""; 1067 } 1068 } 1069 } 1070 } 1072 augment "/ietf-acl:access-lists/ietf-acl:acl" { 1073 description "Newco proprietary default action"; 1074 container default-actions { 1075 description 1076 "Actions that occur if no access-list entry is matched."; 1077 leaf deny { 1078 type empty; 1079 description ""; 1080 } 1081 } 1082 } 1084 grouping match-simple-payload-protocol-value { 1085 description "Newco proprietary payload"; 1086 leaf value-keyword { 1087 type enumeration { 1088 enum icmp { 1089 description "Internet Control Message Protocol"; 1090 } 1091 enum icmp6 { 1092 description "Internet Control Message Protocol Version 6"; 1093 } 1094 enum range { 1095 description "Range of values"; 1096 } 1097 } 1099 description "(null)"; 1100 } 1101 } 1102 } 1104 Draft authors expect that different vendors will provide their own 1105 yang models as in the example above, which is the augmentation of the 1106 base model 1108 A.3. Attaching Access Control List to interfaces 1110 Access control list typically does not exist in isolation. Instead, 1111 they are associated with a certain scope in which they are applied, 1112 for example, an interface of a set of interfaces. How to attach an 1113 access control list to an interface (or other system artifact) is 1114 outside the scope of this model, as it depends on the specifics of 1115 the system model that is being applied. However, in general, the 1116 general design pattern will involved adding a data node with a 1117 reference, or set of references, to ACLs that are to be applied to 1118 the interface. For this purpose, the type definition "access- 1119 control-list-ref" can be used. 1121 This is an example of attaching an Access Control List to an 1122 interface. 1124 import ietf-access-control-list { 1125 prefix "ietf-acl"; 1126 } 1127 import ietf-interface { 1128 prefix "ietf-if"; 1129 } 1130 import ietf-yang-types { 1131 prefix "yang"; 1132 } 1134 augment "/ietf-if:interfaces/ietf-if:interface" { 1135 description "Apply ACL to interfaces"; 1136 container acl{ 1137 description "ACL related properties."; 1138 leaf acl-name { 1139 type ietf-acl:acl-ref; 1140 mandatory true; 1141 description "Access Control List name."; 1142 } 1143 leaf match-counter { 1144 type yang:counter64; 1145 config false; 1146 description 1147 "Total match count for Access Control 1148 List on this interface"; 1149 } 1150 choice direction { 1151 leaf in { type empty;} 1152 leaf out { type empty;} 1153 } 1154 } 1155 } 1156 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:acl-oper-data" { 1157 description 1158 "This is an example on how to apply acl to a target to collect 1159 operational data"; 1160 container targets{ 1161 choice interface{ 1162 leaf-list interface-name{ 1163 type ietf-if:interface-ref; 1164 } 1165 } 1166 } 1167 } 1169 A.4. Example to augment model with mixed ACL type 1171 As vendors (or IETF) add more features to ACL, the model is easily 1172 augmented. One of such augmentations can be to add support for mixed 1173 type of ACLs, where acl-type-base can be augmented like in example 1174 below: 1176 identity mixed-l3-acl { 1177 base "access-control-list:acl-type-base"; 1178 description "ACL that contains a mix of entries that 1179 primarily match on fields in IPv4 headers and entries 1180 that primarily match on fields in IPv6 headers. 1181 Matching on layer 4 header fields may also exist in the 1182 list. An acl of type mixed-l3-acl does not contain 1183 matches on fields in the ethernet header."; 1184 } 1186 identity mixed-l2-l3-acl { 1187 base "access-control-list:acl-type-base"; 1188 description "ACL that contains a mix of entries that 1189 primarily match on fields in ethernet headers, entries 1190 that primarily match on fields in IPv4 headers, and entries 1191 that primarily match on fields in IPv6 headers. Matching on 1192 layer 4 header fields may also exist in the list."; 1193 } 1195 Authors' Addresses 1197 Dean Bogdanovic 1199 Email: ivandean@gmail.com 1201 Kiran Agrahara Sreenivasa 1202 Cisco Systems 1204 Email: kkoushik@cisco.com 1206 Lisa Huang 1207 Juniper Networks 1209 Email: lyihuang@juniper.net 1210 Dana Blair 1211 Cisco Systems 1213 Email: dblair@cisco.com