idnits 2.17.1 draft-ietf-netmod-acl-model-06.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 441: '...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 203 has weird spacing: '...er-port ine...' == Line 206 has weird spacing: '...er-port ine...' == Line 1004 has weird spacing: '...keyword enu...' -- The document date (December 8, 2015) is 3063 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: June 10, 2016 Cisco Systems 6 L. Huang 7 Juniper Networks 8 D. Blair 9 Cisco Systems 10 December 8, 2015 12 Network Access Control List (ACL) YANG Data Model 13 draft-ietf-netmod-acl-model-06 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 June 10, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 17 64 5. Linux nftables . . . . . . . . . . . . . . . . . . . . . . . 17 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 70 9.2. Informative References . . . . . . . . . . . . . . . . . 20 71 Appendix A. Extending ACL model examples . . . . . . . . . . . . 20 72 A.1. Example of extending existing model for route filtering . 20 73 A.2. A company proprietary module example . . . . . . . . . . 22 74 A.3. Attaching Access Control List to interfaces . . . . . . . 25 75 A.4. Example to augment model with mixed ACL type . . . . . . 27 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 +--ro acl-oper-data 187 +--rw access-list-entries 188 | +--rw ace* [rule-name] 189 | +--rw matches 190 | | +--rw (ace-type)? 191 | | | +--:(ace-ip) 192 | | | | +--rw (ace-ip-version)? 193 | | | | | +--:(ace-ipv4) 194 | | | | | | +--rw destination-ipv4-network? inet:ipv4-prefix 195 | | | | | | +--rw source-ipv4-network? inet:ipv4-prefix 196 | | | | | +--:(ace-ipv6) 197 | | | | | +--rw destination-ipv6-network? inet:ipv6-prefix 198 | | | | | +--rw source-ipv6-network? inet:ipv6-prefix 199 | | | | | +--rw flow-label? inet:ipv6-flow-label 200 | | | | +--rw dscp? inet:dscp 201 | | | | +--rw protocol? uint8 202 | | | | +--rw source-port-range! 203 | | | | | +--rw lower-port inet:port-number 204 | | | | | +--rw upper-port? inet:port-number 205 | | | | +--rw destination-port-range! 206 | | | | +--rw lower-port inet:port-number 207 | | | | +--rw upper-port? inet:port-number 208 | | | +--:(ace-eth) 209 | | | +--rw destination-mac-address? yang:mac-address 210 | | | +--rw destination-mac-address-mask? yang:mac-address 211 | | | +--rw source-mac-address? yang:mac-address 212 | | | +--rw source-mac-address-mask? yang:mac-address 213 | | +--rw input-interface? string 214 | +--rw actions 215 | | +--rw (packet-handling)? 216 | | +--:(deny) 217 | | | +--rw deny? empty 218 | | +--:(permit) 219 | | +--rw permit? empty 220 | +--ro ace-oper-data 221 | | +--ro match-counter? yang:counter64 222 | +--rw rule-name string 223 +--rw acl-name string 224 +--rw acl-type acl-type 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@2015-12-08.yang" 244 module ietf-access-control-list { 245 yang-version 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) 2015 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 2015-12-08 { 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 container acl-oper-data { 353 config false; 354 description 355 "Overall Access Control List operational data"; 356 } 357 container access-list-entries { 358 description 359 "The access-list-entries container contains 360 a list of access-list-entries(ACE)."; 361 list ace { 362 key "rule-name"; 363 ordered-by user; 364 description 365 "List of access list entries(ACE)"; 366 container matches { 367 description 368 "Definitions for match criteria for this Access List 369 Entry."; 370 choice ace-type { 371 description 372 "Type of access list entry."; 374 case ace-ip { 375 description "IP Access List Entry."; 376 choice ace-ip-version { 377 description 378 "IP version used in this Acess List Entry."; 379 case ace-ipv4 { 380 uses packet-fields:acl-ipv4-header-fields; 381 } 382 case ace-ipv6 { 383 uses packet-fields:acl-ipv6-header-fields; 384 } 385 } 386 uses packet-fields:acl-ip-header-fields; 387 } 388 case ace-eth { 389 description 390 "Ethernet Access List entry."; 391 uses packet-fields:acl-eth-header-fields; 392 } 393 } 394 uses packet-fields:metadata; 395 } 396 container actions { 397 description 398 "Definitions of action criteria for this Access List 399 Entry."; 400 choice packet-handling { 401 default "deny"; 402 description 403 "Packet handling action."; 404 case deny { 405 leaf deny { 406 type empty; 407 description 408 "Deny action."; 409 } 410 } 411 case permit { 412 leaf permit { 413 type empty; 414 description 415 "Permit action."; 416 } 417 } 418 } 419 } 420 container ace-oper-data { 421 config false; 422 description 423 "Operational data for this Access List Entry."; 424 leaf match-counter { 425 type yang:counter64; 426 description 427 "Number of matches for this Access List Entry"; 428 } 429 } 430 leaf rule-name { 431 type string; 432 description 433 "A unique name identifying this Access List 434 Entry(ACE)."; 435 } 436 } 437 } 438 leaf acl-name { 439 type string; 440 description 441 "The name of access-list. A device MAY restrict the length 442 and value of this name, possibly space and special 443 characters are not allowed."; 444 } 445 leaf acl-type { 446 type acl-type; 447 description 448 "Type of access control list. Indicates the primary intended 449 type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) 450 used in the list instance."; 451 } 452 } 453 } 454 } 455 457 4.2. IETF-PACKET-FIELDS module 459 The packet fields module defines the necessary groups for matching on 460 fields in the packet including ethernet, ipv4, ipv6, transport layer 461 fields and metadata. Since the number of match criteria is very 462 large, the base draft does not include these directly but references 463 them by "uses" to keep the base module simple. In case more match 464 conditions are needed, those can be added by augmenting choices 465 within container "matches" in ietf-access-control-list.yang model 467 468 module ietf-packet-fields { 469 yang-version 1; 470 namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; 471 prefix packet-fields; 472 import ietf-inet-types { 473 prefix inet; 474 } 475 import ietf-yang-types { 476 prefix yang; 477 } 478 organization "IETF NETMOD (NETCONF Data Modeling Language) Working 479 Group"; 480 contact 481 "WG Web: http://tools.ietf.org/wg/netmod/ 482 WG List: netmod@ietf.org 483 WG Chair: Juergen Schoenwaelder 484 j.schoenwaelder@jacobs-university.de 485 WG Chair: Tom Nadeau 486 tnadeau@lucidvision.com 487 Editor: Dean Bogdanovic 488 deanb@juniper.net 489 Editor: Kiran Agrahara Sreenivasa 490 kkoushik@cisco.com 491 Editor: Lisa Huang 492 lyihuang@juniper.net 493 Editor: Dana Blair 494 dblair@cisco.com"; 495 description 496 "This YANG module defines groupings that are used by 497 ietf-access-control-list YANG module. Their usage is not 498 limited to ietf-access-control-list and can be 499 used anywhere as applicable. 500 Copyright (c) 2015 IETF Trust and the persons identified as 501 the document authors. All rights reserved. 502 Redistribution and use in source and binary forms, with or 503 without modification, is permitted pursuant to, and subject 504 to the license terms contained in, the Simplified BSD 505 License set forth in Section 4.c of the IETF Trust's Legal 506 Provisions Relating to IETF Documents 507 (http://trustee.ietf.org/license-info). 508 This version of this YANG module is part of RFC XXXX; see 509 the RFC itself for full legal notices."; 510 revision 2015-12-08 { 511 description 512 "Initial version of packet fields used by 513 ietf-access-control-list"; 514 reference 515 "RFC XXXX: Network Access Control List (ACL) 516 YANG Data Model"; 517 } 518 grouping acl-transport-header-fields { 519 description 520 "Transport header fields"; 521 container source-port-range { 522 presence "Enables setting source port range"; 523 description 524 "Inclusive range representing source ports to be used. 525 When only lower-port is present, it represents a single port."; 526 leaf lower-port { 527 type inet:port-number; 528 mandatory true; 529 description 530 "Lower boundary for port."; 531 } 532 leaf upper-port { 533 type inet:port-number; 534 must ". >= ../lower-port" { 535 error-message 536 "The upper-port must be greater than or equal to lower-port"; 537 } 538 description 539 "Upper boundary for port . If existing, the upper port 540 must be greater or equal to lower-port."; 541 } 542 } 543 container destination-port-range { 544 presence "Enables setting destination port range"; 545 description 546 "Inclusive range representing destination ports to be used. When 547 only lower-port is present, it represents a single port."; 548 leaf lower-port { 549 type inet:port-number; 550 mandatory true; 551 description 552 "Lower boundary for port."; 553 } 554 leaf upper-port { 555 type inet:port-number; 556 must ". >= ../lower-port" { 557 error-message 558 "The upper-port must be greater than or equal to lower-port"; 559 } 561 description 562 "Upper boundary for port. If existing, the upper port must 563 be greater or equal to lower-port"; 564 } 565 } 567 } 568 grouping acl-ip-header-fields { 569 description 570 "IP header fields common to ipv4 and ipv6"; 571 leaf dscp { 572 type inet:dscp; 573 description 574 "Value of dscp."; 575 } 576 leaf protocol { 577 type uint8; 578 description 579 "Internet Protocol number."; 580 } 581 uses acl-transport-header-fields; 582 } 583 grouping acl-ipv4-header-fields { 584 description 585 "Fields in IPv4 header."; 586 leaf destination-ipv4-network { 587 type inet:ipv4-prefix; 588 description 589 "Destination IPv4 address prefix."; 590 } 591 leaf source-ipv4-network { 592 type inet:ipv4-prefix; 593 description 594 "Source IPv4 address prefix."; 595 } 596 } 597 grouping acl-ipv6-header-fields { 598 description 599 "Fields in IPv6 header"; 600 leaf destination-ipv6-network { 601 type inet:ipv6-prefix; 602 description 603 "Destination IPv6 address prefix."; 604 } 605 leaf source-ipv6-network { 606 type inet:ipv6-prefix; 607 description 608 "Source IPv6 address prefix."; 609 } 610 leaf flow-label { 611 type inet:ipv6-flow-label; 612 description 613 "IPv6 Flow label."; 614 } 615 reference 616 "RFC 4291: IP Version 6 Addressing Architecture 617 RFC 4007: IPv6 Scoped Address Architecture 618 RFC 5952: A Recommendation for IPv6 Address Text Representation"; 619 } 620 grouping acl-eth-header-fields { 621 description 622 "Fields in Ethernet header."; 623 leaf destination-mac-address { 624 type yang:mac-address; 625 description 626 "Destination IEEE 802 MAC address."; 627 } 628 leaf destination-mac-address-mask { 629 type yang:mac-address; 630 description 631 "Destination IEEE 802 MAC address mask."; 632 } 633 leaf source-mac-address { 634 type yang:mac-address; 635 description 636 "Source IEEE 802 MAC address."; 637 } 638 leaf source-mac-address-mask { 639 type yang:mac-address; 640 description 641 "Source IEEE 802 MAC address mask."; 642 } 643 reference 644 "IEEE 802: IEEE Standard for Local and Metropolitan Area 645 Networks: Overview and Architecture."; 646 } 648 grouping metadata { 649 description 650 "Fields associated with a packet whick are not in 651 the header."; 652 leaf input-interface { 653 type string; 654 description 655 "Packet was received on this interface."; 656 } 657 } 658 } 659 660 4.3. An ACL Example 662 Requirement: Deny All traffic from 10.10.10.1 bound for host 663 10.10.10.255 from leaving. 665 In order to achieve the requirement, an name Access Control List is 666 needed. The acl and aces can be described in CLI as the following: 668 access-list ip sample-ip-acl 669 deny tcp host 10.10.10.1 host 10.10.10.255 671 Here is the example acl configuration xml: 673 674 675 676 677 678 679 680 681 682 10.10.10.255/24 683 684 685 10.10.10.1/24 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 rule1 714 715 716 sample-ipv4-acl 717 ipv4-acl 718 719 720 722 4.4. Port Range Usage Example 724 When a lower-port and an upper-port are both present, it represents a 725 range between lower-port and upper-port with both the lower-port and 726 upper-port are included. When only a lower-port presents, it 727 represents a single port. 729 With the follow XML snippet: 731 732 16384 733 16387 734 736 This represents source ports 16384,16385, 16386, and 16387. 738 With the follow XML snippet: 740 741 16384 742 65535 743 745 This represents source ports greater than/equal to 16384. 747 With the follow XML snippet: 749 750 21 751 753 This represents port 21. 755 5. Linux nftables 757 As Linux platform is becoming more popular as networking platform, 758 the Linux data model is changing. Previously ACLs in Linux were 759 highly protocol specific and different utilities were used (iptables, 760 ip6tables, arptables, ebtables), so each one had separate data model. 761 Recently, this has changed and a single utility, nftables, has been 762 developed. With a single application, it has a single data model for 763 filewall filters and it follows very similarly to the ietf-access- 764 control list module proposed in this draft. The nftables support 765 input and output ACEs and each ACE can be defined with match and 766 action. 768 In the example below, it shows nftable configuration that accepts and 769 count packets. It contains a 771 table ip filter { 772 chain output { 773 type filter hook output priority 0; 774 counter packets 1 bytes 84 accept 775 } 776 } 778 There are many similarities between Linux nftables and IETF ACL YANG 779 data models. It should be fairly easy to do translation between ACL 780 YANG model described in this draft and Linux nftables. 782 6. Security Considerations 784 The YANG module defined in this memo is designed to be accessed via 785 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 786 is the secure transport layer and the mandatory-to-implement secure 787 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 788 model [RFC6536] [RFC6536] provides the means to restrict access for 789 particular NETCONF users to a pre-configured subset of all available 790 NETCONF protocol operations and content. 792 There are a number of data nodes defined in the YANG module which are 793 writable/creatable/deletable (i.e., config true, which is the 794 default). These data nodes may be considered sensitive or vulnerable 795 in some network environments. Write operations (e.g., ) 796 to these data nodes without proper protection can have a negative 797 effect on network operations. 799 These are the subtrees and data nodes and their sensitivity/ 800 vulnerability: 802 /access-lists/acl/access-list-entries: This list specifies all the 803 configured access list entries on the device. Unauthorized write 804 access to this list can allow intruders to access and control the 805 system. Unauthorized read access to this list can allow intruders to 806 spoof packets with authorized addresses thereby compromising the 807 system. 809 7. IANA Considerations 811 This document registers a URI in the IETF XML registry [RFC3688] 812 [RFC3688]. Following the format in RFC 3688, the following 813 registration is requested to be made: 815 URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list 816 URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields 818 Registrant Contact: The IESG. 820 XML: N/A, the requested URI is an XML namespace. 822 This document registers a YANG module in the YANG Module Names 823 registry [RFC6020]. 825 name: ietf-access-control-list namespace: 826 urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl 827 reference: RFC XXXX 829 name: ietf-packet-fields namespace: urn:ietf:params:xml:ns:yang:ietf- 830 packet-fields prefix: ietf-packet-fields reference: RFC XXXX 832 8. Acknowledgements 834 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 835 an initial IETF draft in several past IETF meetings. That draft 836 included an ACL YANG model structure and a rich set of match filters, 837 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 838 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 839 and Phil Shafer. Many people have reviewed the various earlier 840 drafts that made the draft went into IETF charter. 842 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 843 Blair each evaluated the YANG model in previous draft separately and 844 then work together, to created a new ACL draft that can be supported 845 by different vendors. The new draft removes vendor specific 846 features, and gives examples to allow vendors to extend in their own 847 proprietary ACL. The earlier draft was superseded with the new one 848 that received more participation from many vendors. 850 Authors would like to thank Jason Sterne, Lada Lhotka, Juergen 851 Schoenwalder for their review of and suggestions to the draft. 853 9. References 855 9.1. Normative References 857 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 858 DOI 10.17487/RFC3688, January 2004, 859 . 861 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 862 the Network Configuration Protocol (NETCONF)", RFC 6020, 863 DOI 10.17487/RFC6020, October 2010, 864 . 866 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 867 and A. Bierman, Ed., "Network Configuration Protocol 868 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 869 . 871 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 872 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 873 . 875 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 876 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 877 10.17487/RFC6536, March 2012, 878 . 880 9.2. Informative References 882 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 883 Export (IPFIX) Protocol for the Exchange of IP Traffic 884 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 885 2008, . 887 Appendix A. Extending ACL model examples 889 A.1. Example of extending existing model for route filtering 891 With proposed modular design, it is easy to extend the model with 892 other features. Those features can be standard features, like route 893 filters. Route filters match on specific IP addresses or ranges of 894 prefixes. Much like ACLs, they include some match criteria and 895 corresponding match action(s). For that reason, it is very simple to 896 extend existing ACL model with route filtering. The combination of a 897 route prefix and prefix length along with the type of match 898 determines how route filters are evaluated against incoming routes. 899 Different vendors have different match types and in this model we are 900 using only ones that are common across all vendors participating in 901 this draft. As in this example, the base ACL model can be extended 902 with company proprietary extensions, described in the next section. 904 file "example-ext-route-filter@2015-12-08.yang" 905 module example-ext-route-filter { 906 yang-version 1; 907 namespace "urn:ietf:params:xml:ns:yang:example-ext-route-filter"; 908 prefix example-ext-route-filter; 909 import ietf-inet-types { 910 prefix "inet"; 911 } 912 import ietf-access-control-list { 913 prefix "ietf-acl"; 914 } 916 organization 917 "Route model group."; 919 contact 920 "abc@abc.com"; 922 description " 923 This module describes route filter as a collection of 924 match prefixes. When specifying a match prefix, you 925 can specify an exact match with a particular route or 926 a less precise match. You can configure either a 927 common action that applies to the entire list or an 928 action associated with each prefix. 929 "; 930 revision 2015-12-08 { 931 description 932 "Creating Route-Filter extension model based on 933 ietf-access-control-list model"; 934 reference " "; 935 } 936 augment "/ietf-acl:access-lists/ietf-acl:acl/" 937 + "ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches"{ 938 description " 939 This module augments the matches container in the ietf-acl 940 module with route filter specific actions 941 "; 942 choice route-prefix{ 943 description "Define route filter match criteria"; 944 case range { 945 description 946 "Route falls between the lower prefix/prefix-length 947 and the upperprefix/prefix-length."; 948 choice ipv4-range { 949 description "Defines the IPv4 prefix range"; 950 leaf v4-lower-bound { 951 type inet:ipv4-prefix; 952 description 953 "Defines the lower IPv4 prefix/prefix length"; 954 } 955 leaf v4-upper-bound { 956 type inet:ipv4-prefix; 957 description 958 "Defines the upper IPv4 prefix/prefix length"; 959 } 960 } 961 choice ipv6-range { 962 description "Defines the IPv6 prefix/prefix range"; 963 leaf v6-lower-bound { 964 type inet:ipv6-prefix; 965 description 966 "Defines the lower IPv6 prefix/prefix length"; 967 } 968 leaf v6-upper-bound { 969 type inet:ipv6-prefix; 970 description 971 "Defines the upper IPv6 prefix/prefix length"; 972 } 973 } 974 } 975 } 976 } 977 } 979 A.2. A company proprietary module example 981 Module "example-newco-acl" is an example of company proprietary model 982 that augments "ietf-acl" module. It shows how to use 'augment' with 983 an XPath expression to add additional match criteria, action 984 criteria, and default actions when no ACE matches found. All these 985 are company proprietary extensions or system feature extensions. 986 "example-newco-acl" is just an example and it is expected from 987 vendors to create their own proprietary models. 989 The following figure is the tree structure of example-newco-acl. In 990 this example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- 991 list-entries/ ietf-acl:ace/ietf-acl:matches are augmented with a new 992 choice, protocol-payload-choice. The protocol-payload-choice uses a 993 grouping with an enumeration of all supported protocol values. In 994 other example, /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access- 995 list-entries/ ietf-acl:ace/ietf-acl:actions are augmented with new 996 choice of actions. 998 module: example-newco-acl 999 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ 1000 ietf-acl:ace/ietf-acl:matches: 1001 +--rw (protocol-payload-choice)? 1002 +--:(protocol-payload) 1003 +--rw protocol-payload* [value-keyword] 1004 +--rw value-keyword enumeration 1005 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ 1006 ietf-acl:ace/ietf-acl:actions: 1007 +--rw (action)? 1008 +--:(count) 1009 | +--rw count? string 1010 +--:(policer) 1011 | +--rw policer? string 1012 +--:(hiearchical-policer) 1013 +--rw hierarchitacl-policer? string 1014 augment /ietf-acl:access-lists/ietf-acl:acl: 1015 +--rw default-actions 1016 +--rw deny? empty 1018 file "newco-acl@2015-12-08.yang" 1019 module example-newco-acl { 1020 yang-version 1; 1022 namespace "urn:newco:params:xml:ns:yang:example-newco-acl"; 1024 prefix example-newco-acl; 1026 import ietf-access-control-list { 1027 prefix "ietf-acl"; 1028 } 1030 organization 1031 "Newco model group."; 1033 contact 1034 "abc@newco.com"; 1035 description 1036 "This YANG module augment IETF ACL Yang."; 1038 revision 2015-12-08{ 1039 description 1040 "Creating NewCo proprietary extensions to ietf-acl model"; 1041 reference 1042 "RFC XXXX: Network Access Control List (ACL) 1043 YANG Data Model"; 1044 } 1045 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:matches" { 1046 description "Newco proprietary simple filter matches"; 1047 choice protocol-payload-choice { 1048 description ""; 1049 list protocol-payload { 1050 key value-keyword; 1051 ordered-by user; 1052 description "Match protocol payload"; 1053 uses match-simple-payload-protocol-value; 1054 } 1055 } 1056 } 1058 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:access-list-entries/ietf-acl:ace/ietf-acl:actions" { 1059 description "Newco proprietary simple filter actions"; 1060 choice action { 1061 description ""; 1062 case count { 1063 description "Count the packet in the named counter"; 1064 leaf count { 1065 type string; 1066 description ""; 1067 } 1068 } 1069 case policer { 1070 description "Name of policer to use to rate-limit traffic"; 1071 leaf policer { 1072 type string; 1073 description ""; 1074 } 1075 } 1076 case hiearchical-policer { 1077 description "Name of hierarchical policer to use to 1078 rate-limit traffic"; 1079 leaf hierarchitacl-policer{ 1080 type string; 1081 description ""; 1082 } 1083 } 1084 } 1085 } 1087 augment "/ietf-acl:access-lists/ietf-acl:acl" { 1088 description "Newco proprietary default action"; 1089 container default-actions { 1090 description 1091 "Actions that occur if no access-list entry is matched."; 1092 leaf deny { 1093 type empty; 1094 description ""; 1095 } 1096 } 1097 } 1099 grouping match-simple-payload-protocol-value { 1100 description "Newco proprietary payload"; 1101 leaf value-keyword { 1102 type enumeration { 1103 enum icmp { 1104 description "Internet Control Message Protocol"; 1105 } 1106 enum icmp6 { 1107 description "Internet Control Message Protocol Version 6"; 1108 } 1109 enum range { 1110 description "Range of values"; 1111 } 1112 } 1114 description "(null)"; 1115 } 1116 } 1117 } 1119 Draft authors expect that different vendors will provide their own 1120 yang models as in the example above, which is the augmentation of the 1121 base model 1123 A.3. Attaching Access Control List to interfaces 1125 Access control list typically does not exist in isolation. Instead, 1126 they are associated with a certain scope in which they are applied, 1127 for example, an interface of a set of interfaces. How to attach an 1128 access control list to an interface (or other system artifact) is 1129 outside the scope of this model, as it depends on the specifics of 1130 the system model that is being applied. However, in general, the 1131 general design pattern will involved adding a data node with a 1132 reference, or set of references, to ACLs that are to be applied to 1133 the interface. For this purpose, the type definition "access- 1134 control-list-ref" can be used. 1136 This is an example of attaching an Access Control List to an 1137 interface. 1139 import ietf-access-control-list { 1140 prefix "ietf-acl"; 1141 } 1142 import ietf-interface { 1143 prefix "ietf-if"; 1144 } 1145 import ietf-yang-types { 1146 prefix "yang"; 1147 } 1149 augment "/ietf-if:interfaces/ietf-if:interface" { 1150 description "Apply ACL to interfaces"; 1151 container acl{ 1152 description "ACL related properties."; 1153 leaf acl-name { 1154 type ietf-acl:acl-ref; 1155 mandatory true; 1156 description "Access Control List name."; 1157 } 1158 leaf match-counter { 1159 type yang:counter64; 1160 config false; 1161 description 1162 "Total match count for Access Control 1163 List on this interface"; 1164 } 1165 choice direction { 1166 leaf in { type empty;} 1167 leaf out { type empty;} 1168 } 1169 } 1170 } 1171 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:acl-oper-data" { 1172 description 1173 "This is an example on how to apply acl to a target to collect 1174 operational data"; 1175 container targets{ 1176 choice interface{ 1177 leaf-list interface-name{ 1178 type ietf-if:interface-ref; 1179 } 1180 } 1181 } 1182 } 1184 A.4. Example to augment model with mixed ACL type 1186 As vendors (or IETF) add more features to ACL, the model is easily 1187 augmented. One of such augmentations can be to add support for mixed 1188 type of ACLs, where acl-type-base can be augmented like in example 1189 below: 1191 identity mixed-l3-acl { 1192 base "access-control-list:acl-type-base"; 1193 description "ACL that contains a mix of entries that 1194 primarily match on fields in IPv4 headers and entries 1195 that primarily match on fields in IPv6 headers. 1196 Matching on layer 4 header fields may also exist in the 1197 list. An acl of type mixed-l3-acl does not contain 1198 matches on fields in the ethernet header."; 1199 } 1201 identity mixed-l2-l3-acl { 1202 base "access-control-list:acl-type-base"; 1203 description "ACL that contains a mix of entries that 1204 primarily match on fields in ethernet headers, entries 1205 that primarily match on fields in IPv4 headers, and entries 1206 that primarily match on fields in IPv6 headers. Matching on 1207 layer 4 header fields may also exist in the list."; 1208 } 1210 Authors' Addresses 1212 Dean Bogdanovic 1214 Email: ivandean@gmail.com 1216 Kiran Agrahara Sreenivasa 1217 Cisco Systems 1219 Email: kkoushik@cisco.com 1221 Lisa Huang 1222 Juniper Networks 1224 Email: lyihuang@juniper.net 1225 Dana Blair 1226 Cisco Systems 1228 Email: dblair@cisco.com