idnits 2.17.1 draft-bogdanovic-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 36 instances of too long lines in the document, the longest one being 24 characters in excess of 72. == There are 2 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 377: '... 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 193 has weird spacing: '...er-port ine...' == Line 196 has weird spacing: '...er-port ine...' == Line 247 has weird spacing: '...keyword enu...' -- The document date (October 7, 2014) is 3489 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: April 10, 2015 Brocade Communications System 6 L. Huang 7 D. Blair 8 Cisco Systems 9 October 7, 2014 11 Network Access Control List (ACL) YANG Data Model 12 draft-bogdanovic-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 April 10, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. IETF-ACL module . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Packet Header module . . . . . . . . . . . . . . . . . . 10 61 4.3. A company proprietary module example . . . . . . . . . . 14 62 4.4. An ACL Example . . . . . . . . . . . . . . . . . . . . . 16 63 5. Extending existing model for route filtering . . . . . . . . 17 64 6. Linux nftables . . . . . . . . . . . . . . . . . . . . . . . 19 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 68 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 21 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 71 11.2. Informative References . . . . . . . . . . . . . . . . . 21 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 74 1. Introduction 76 Access Control List (ACL) is one of the basic elements to configure 77 device forwarding behavior. It is used in many networking concepts 78 such as Policy Based Routing, Firewalls etc. 80 An ACL is an ordered set of rules that is used to filter traffic on a 81 networking device. Each rule is represented by an Access Control 82 Entry (ACE). 84 Each ACE has a group of match criteria and a group of action 85 criteria. 87 The match criteria consist of a tuple of packet header match criteria 88 and metadata match criteria. 90 o Packet header matches apply to fields visible in the packet such 91 as address or class of service or port numbers. 93 o Metadata matches apply to fields associated with the packet but 94 not in the packet header such as input interface or overall packet 95 length 97 The actions specify what to do with the packet when the matching 98 criteria is met. These actions are any operations that would apply 99 to the packet, such as counting, policing, or simply forwarding.The 100 list of potential actions is endless depending on the innovations of 101 the networked devices. 103 1.1. Definitions and Acronyms 105 ACE: Access Control Entry 107 ACL: Access Control List 109 AFI: Address Field Identifier 111 DSCP: Differentiated Services Code Point 113 ICMP: Internet Control Message Protocol 115 IP: Internet Protocol 117 IPv4: Internet Protocol version 4 119 IPv6: Internet Protocol version 6 121 MAC: Media Access Control 123 TCP: Transmission Control Protocol 125 2. Problem Statement 127 This document defines a YANG [RFC6020] data model for the 128 configuration of ACLs. It is very important that model can be easily 129 reused between vendors and between applications. 131 ACL implementations in every device may vary greatly in terms of the 132 filter constructs and actions that they support. Therefore this 133 draft proposes a simple model that can be augmented by vendor 134 proprietary models. 136 3. Design of the ACL Model 138 Although different vendors have different ACL data models, there is a 139 common understanding of what access control list (ACL) is. A network 140 system ususally have a list of ACLs, and each ACL contains an ordered 141 list of rules, also known as access list entries - ACEs. Each ACE 142 has a group of match criteria and a group of action criteria. The 143 match criteria consist of packet header matching and metadata 144 matching. Packet header matching applies to fields visible in the 145 packet such as address or class of service or port numbers. Metadata 146 matching applies to fields associated with the packet, but not in the 147 packet header such as input interface, packet length, or source or 148 destination prefix length. The actions can be any sort of operation 149 from logging to rate limiting or dropping to simply forwarding. 150 Actions on the first matching ACE are applied with no processing of 151 subsequent ACEs. The model also includes overall operational state 152 for the ACL and operational state for each ACE, targets where the ACL 153 applied. One ACL can be applied to multiple targets within the 154 device, such as interfaces of a networked device, applications or 155 features running in the device, etc. When applied to interfaces of a 156 networked device, the ACL is applied in a direction which indicates 157 if it should be applied to packet entering (input) or leaving the 158 device (output). 160 This draft tries to address the commonalities between all vendors and 161 create a common model, which can be augmented with proprietary 162 models. The base model is very simple and with this design we hope 163 to achieve needed flexibility for each vendor to extend the base 164 model. 166 3.1. ACL Modules 168 There are three YANG modules in the model. The first module, "ietf- 169 acl", defines generic ACL aspects which are common to all ACLs 170 regardless of their type or vendor. In effect, the module can be 171 viewed as providing a generic ACL "superclass". It imports the 172 second module, "packet-headers". The match container in "ietf-acl" 173 uses groupings in "packet-headers". The "packet-headers" modules can 174 easily be extended to reuse definitions from other modules such as 175 IPFIX [RFC5101] or migrate proprietary augmented module definitions 176 into the standard module. 178 module: ietf-acl 179 +--rw access-lists 180 +--rw access-list* [acl-name] 181 +--rw acl-name string 182 +--rw acl-type? acl-type 183 +--ro acl-oper-data 184 | +--ro match-counter? ietf:counter64 185 | +--ro targets* string 186 +--rw access-list-entries 187 +--rw access-list-entry* [rule-name] 188 +--rw rule-name string 189 +--rw matches 190 | +--rw (ace-type)? 191 | | +--:(ace-ip) 192 | | | +--rw source-port-range 193 | | | | +--rw lower-port inet:port-number 194 | | | | +--rw upper-port? inet:port-number 195 | | | +--rw destination-port-range 196 | | | | +--rw lower-port inet:port-number 197 | | | | +--rw upper-port? inet:port-number 198 | | | +--rw dscp? inet:dscp 199 | | | +--rw ip-protocol? uint8 200 | | | +--rw (ace-ip-version)? 201 | | | +--:(ace-ipv4) 202 | | | | +--rw destination-ipv4-address? 203 inet:ipv4-prefix 204 | | | | +--rw source-ipv4-address? 205 inet:ipv4-prefix 206 | | | +--:(ace-ipv6) 207 | | | +--rw destination-ipv6-address? 208 inet:ipv6-prefix 209 | | | +--rw source-ipv6-address? 210 inet:ipv6-prefix 211 | | | +--rw flow-label? inet:ipv6-flow-label 212 | | +--:(ace-eth) 213 | | +--rw destination-mac-address? 214 yang:mac-address 215 | | +--rw destination-mac-address-mask? 216 yang:mac-address 217 | | +--rw source-mac-address? 218 yang:mac-address 219 | | +--rw source-mac-address-mask? 220 yang:mac-address 221 | +--rw input-interface? string 222 | +--rw absolute 223 | +--rw start? yang:date-and-time 224 | +--rw end? yang:date-and-time 225 | +--rw active? boolean 226 +--rw actions 227 | +--rw (packet-handling)? 228 | +--:(deny) 229 | | +--rw deny? empty 230 | +--:(permit) 231 | +--rw permit? empty 232 +--ro ace-oper-data 233 +--ro match-counter? ietf:counter64 235 Module "newco-acl" is an example of company proprietary model, that 236 augments "ietf-acl" module. It shows how to add additional match 237 criteria, action criteria, and default actions when no ACE matches 238 found. All these are company proprietary extensions or system 239 feature extensions. "newco-acl" is just an example and it is expected 240 from vendors to create their own propietary models. 242 module: newco-acl 243 augment /ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:matches: 244 +--rw (protocol_payload_choice)? 245 +--:(protocol_payload) 246 +--rw protocol_payload* [value_keyword] 247 +--rw value_keyword enumeration 248 augment /ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:actions: 249 +--rw (action)? 250 +--:(count) 251 | +--rw count? string 252 +--:(policer) 253 | +--rw policer? string 254 +--:(hiearchical-policer) 255 +--rw hierarchitacl-policer? string 256 augment /ietf-acl:access-lists/ietf-acl:access-list: 257 +--rw default-actions 258 +--rw deny? empty 260 4. ACL YANG Models 262 4.1. IETF-ACL module 264 "ietf-acl" is the standard top level module for Access lists. It has 265 a container for "access-list" to store access list information. This 266 container has information identifying the access list by a name("acl- 267 name") and a list("access-list-entries") of rules associated with the 268 "acl-name". Each of the entries in the list("access-list-entries") 269 indexed by the string "rule-name" have containers defining "matches" 270 and "actions". The "matches" define criteria used to identify 271 patterns in "packet-fields". The "actions" define behavior to 272 undertake once a "match" has been identified. 274 module ietf-acl { 275 yang-version 1; 277 namespace "urn:ietf:params:xml:ns:yang:ietf-acl"; 279 prefix acl; 281 import ietf-yang-types { 282 prefix "ietf"; 283 } 285 import packet-fields { 286 prefix "packet-fields"; 288 } 290 organization 291 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 293 contact 294 "WG Web: http://tools.ietf.org/wg/netmod/ 295 WG List: netmod@ietf.org 297 WG Chair: Juergen Schoenwaelder 298 j.schoenwaelder@jacobs-university.de 300 WG Chair: Tom Nadeau 301 tnadeau@lucidvision.com 303 Editor: Dean Bogdanovic 304 deanb@juniper.net 306 Editor: Kiran Agrahara Sreenivasa 307 kkoushik@brocade.com 309 Editor: Lisa Huang 310 yihuan@cisco.com 312 Editor: Dana Blair 313 dblair@cisco.com"; 315 description 316 "This YANG module defines a component that describing the 317 configuration of Access Control Lists (ACLs)."; 319 revision 2014-10-10 { 320 description "Creating base model for netmod."; 321 reference 322 "RFC 6020: YANG - A Data Modeling Language for the 323 Network Configuration Protocol (NETCONF)"; 324 } 326 identity acl-base { 327 description "Base acl type for all ACL type identifiers."; 328 } 330 identity ip-acl { 331 base "acl:acl-base"; 332 description "layer 3 ACL type"; 333 } 334 identity eth-acl { 335 base "acl:acl-base"; 336 description "layer 2 ACL type"; 337 } 339 typedef acl-type { 340 type identityref { 341 base "acl-base"; 342 } 343 description 344 "This type is used to refer to an Access Control List 345 (ACL) type"; 346 } 348 typedef acl-ref { 349 type leafref { 350 path "/acl:access-lists/acl:access-list/acl:acl-name"; 351 } 352 description "This type is used by data models that 353 need to referenced an acl"; 354 } 356 container access-lists { 357 description 358 "Access control lists."; 360 list access-list { 361 key acl-name; 362 description " 363 An access list (acl) is an ordered list of 364 access list entries (ace). Each ace has a 365 sequence number to define the order, list 366 of match criteria, and a list of actions. 367 Since there are several kinds of acls 368 implementeded with different attributes for 369 each and different for each vendor, this 370 model accomodates customizing acls for 371 each kind and for each vendor. 372 "; 374 leaf acl-name { 375 type string; 376 description "The name of access-list. 377 A device MAY restrict the length and value of 378 this name, possibly space and special 379 characters are not allowed."; 380 } 382 leaf acl-type { 383 type acl-type; 384 description "Type of ACL"; 385 } 387 container acl-oper-data { 388 config false; 390 description "Overall ACL operational data"; 391 leaf match-counter { 392 type ietf:counter64; 393 description "Total match count for ACL"; 394 } 396 leaf-list targets { 397 type string; 398 description "List of targets where ACL is applied"; 399 } 400 } 402 container access-list-entries { 403 description "The access-list-entries container contains 404 a list of access-list-entry(ACE)."; 406 list access-list-entry { 407 key rule-name; 408 ordered-by user; 410 description "List of access list entries(ACE)"; 411 leaf rule-name { 412 type string; 413 description "Entry name."; 414 } 416 container matches { 417 description "Define match criteria"; 418 choice ace-type { 419 description "Type of ace."; 420 case ace-ip { 421 uses packet-fields:acl-ip-header-fields; 422 choice ace-ip-version { 423 description "Choice of IP version."; 424 case ace-ipv4 { 425 uses packet-fields:acl-ipv4-header-fields; 426 } 427 case ace-ipv6 { 428 uses packet-fields:acl-ipv6-header-fields; 429 } 430 } 431 } 432 case ace-eth { 433 uses packet-fields:acl-eth-header-fields; 434 } 435 } 436 uses packet-fields:metadata; 437 } 439 container actions { 440 description "Define action criteria"; 441 choice packet-handling { 442 default deny; 444 description "Packet handling action."; 445 case deny { 446 leaf deny { 447 type empty; 448 description "Deny action."; 449 } 450 } 451 case permit { 452 leaf permit { 453 type empty; 454 description "Permit action."; 455 } 456 } 457 } 458 } 460 container ace-oper-data { 461 config false; 463 description "Per ace operational data"; 464 leaf match-counter { 465 type ietf:counter64; 466 description "Number of matches for an ace"; 467 } 468 } 469 } 470 } 471 } 472 } 473 } 475 4.2. Packet Header module 477 The packet fields module defines the necessary groups for matching on 478 fields in the packet including ethernet, ipv4, ipv6, transport layer 479 fields and metadata. These groupings can be augmented to include 480 other proprietary matching criteria. Since the number of match 481 criteria is very large, the base draft does not include these 482 directly but references them by "uses" to keep the base module 483 simple. 485 module packet-fields { 486 yang-version 1; 488 namespace "urn:ietf:params:xml:ns:yang:packet-fields"; 490 prefix packet-fields; 492 import ietf-inet-types { 493 prefix "inet"; 494 } 496 import ietf-yang-types { 497 prefix "yang"; 498 } 500 revision 2014-10-10 { 501 description "Initial version of packet fields used by access-lists"; 502 } 504 grouping acl-transport-header-fields { 505 description "Transport header fields"; 507 container source-port-range { 508 description "inclusive range of source ports"; 509 leaf lower-port { 510 mandatory true; 511 type inet:port-number; 512 } 513 leaf upper-port { 514 type inet:port-number; 515 } 516 } 518 container destination-port-range { 519 description "inclusive range of destination ports"; 520 leaf lower-port { 521 mandatory true; 522 type inet:port-number; 523 } 524 leaf upper-port { 525 type inet:port-number; 526 } 527 } 529 } 531 grouping acl-ip-header-fields { 532 description "Header fields common to ipv4 and ipv6"; 534 uses acl-transport-header-fields; 536 leaf dscp { 537 type inet:dscp; 538 } 540 leaf ip-protocol { 541 type uint8; 542 } 544 } 546 grouping acl-ipv4-header-fields { 547 description "fields in IPv4 header"; 549 leaf destination-ipv4-address { 550 type inet:ipv4-prefix; 551 } 553 leaf source-ipv4-address { 554 type inet:ipv4-prefix; 555 } 557 } 559 grouping acl-ipv6-header-fields { 560 description "fields in IPv6 header"; 562 leaf destination-ipv6-address { 563 type inet:ipv6-prefix; 564 } 566 leaf source-ipv6-address { 567 type inet:ipv6-prefix; 568 } 570 leaf flow-label { 571 type inet:ipv6-flow-label; 572 } 574 } 576 grouping acl-eth-header-fields { 577 description "fields in ethernet header"; 579 leaf destination-mac-address { 580 type yang:mac-address; 581 } 583 leaf destination-mac-address-mask { 584 type yang:mac-address; 585 } 587 leaf source-mac-address { 588 type yang:mac-address; 589 } 591 leaf source-mac-address-mask { 592 type yang:mac-address; 593 } 594 } 596 grouping timerange { 597 description "Define time range entries to restrict 598 the access. The time range is identified by a name 599 and then referenced by a function, so that those 600 time restrictions are imposed on the function itself."; 602 container absolute { 603 description 604 "Absolute time and date that 605 the associated function starts 606 going into effect."; 608 leaf start { 609 type yang:date-and-time; 610 description 611 "Start time and date"; 612 } 613 leaf end { 614 type yang:date-and-time; 615 description "Absolute end time and date"; 616 } 617 leaf active { 618 type boolean; 619 default "true"; 620 description 621 "Specify the associated function 622 active or inactive state when 623 starts going into effect"; 624 } 626 } // container absolute 627 } //grouping timerange 629 grouping metadata { 630 description "Fields associated with a packet but not in the header"; 632 leaf input-interface { 633 description "Packet was received on this interface"; 634 type string; 635 } 636 uses timerange; 637 } 638 } 640 4.3. A company proprietary module example 642 In the figure below is an example how proprietary models can be 643 created on top of base ACL module. It is a simple example of how to 644 use 'augment' with an XPath expression which extends instances of a 645 particular type. In this example, all /ietf-acl:access-list/ietf-acl 646 :access-list-entries/ietf-acl:matches are augmented with a new 647 choice, protocol-payload-choice. The protocol-payload-choice uses a 648 grouping with an enumeration of all supported protocol values. In 649 other example, /ietf-acl:access-list/ietf-acl:access-list-entries/ 650 ietf-acl:actions are augmented with new choice of actions. Here is 651 an inclusive list of cases listed within a choice statement. 653 module newco-acl { 654 yang-version 1; 656 namespace "urn:newco:params:xml:ns:yang:newco-acl"; 658 prefix newco-acl; 660 import ietf-acl { 661 prefix "ietf-acl"; 662 } 664 revision 2014-05-21{ 665 description "creating newo proprietary extensions to ietf-acl model"; 666 } 668 augment "/ietf-acl:access-lists/ietf-acl:access-list 669 /ietf-acl:access-list-entries/ietf-acl:access-list-entry/ietf-acl:matches" { 670 description "Newco proprietry simple filter matches"; 671 choice protocol-payload-choice { 672 list protocol-payload { 673 key value-keyword; 674 ordered-by user; 675 description "Match protocol payload"; 676 uses match-simple-payload-protocol-value; 677 } 678 } 679 } 681 augment "/ietf-acl:access-lists/ietf-acl:access-list 682 /ietf-acl:access-list-entries/ietf-acl:access-list-entry/ietf-acl:actions" { 683 description "Newco proprietary simple filter actions"; 684 choice action { 685 case count { 686 description "Count the packet in the named counter"; 687 leaf count { 688 type string; 689 } 690 } 691 case policer { 692 description "Name of policer to use to rate-limit traffic"; 693 leaf policer { 694 type string; 695 } 696 } 697 case hiearchical-policer { 698 description "Name of hierarchical policer to use to rate-limit traffic"; 699 leaf hierarchitacl-policer{ 700 type string; 701 } 702 } 703 } 704 } 706 augment "/ietf-acl:access-lists/ietf-acl:access-list" { 707 container default-actions { 708 description "Actions that occur if no access-list entry is matched."; 709 leaf deny { 710 type empty; 711 } 712 } 713 } 715 grouping match-simple-payload-protocol-value { 716 leaf value-keyword { 717 description "(null)"; 718 type enumeration { 719 enum icmp { 720 description "Internet Control Message Protocol"; 721 } 722 enum icmp6 { 723 description "Internet Control Message Protocol Version 6"; 724 } 725 enum range { 726 description "Range of values"; 727 } 728 } 729 } 730 } 731 } 733 Dratf authors expect that different vendors will provide their own 734 yang models as in the example above, which is the extension of the 735 base model 737 4.4. An ACL Example 739 Requirement: Deny All traffic from 1.1.1.1 bound for host 2.2.2.2 740 from leaving. 742 In order to achieve the requirement, an name access control list is 743 needed. The acl and aces can be described in CLI as the following: 745 access-list ip iacl 746 deny tcp host 1.1.1.1 host 2.2.2.2 748 Figure 1 750 Here is the example acl configuration xml: 752 753 // replace with IANA namespace when assigned 754 755 756 757 758 759 760 761 762 sample-ip-acl 763 764 765 telnet-block-rule 766 767 2.2.2.2/32 768 1.1.1.1/32 769 770 771 772 773 774 775 776 777 778 779 780 782 Figure 2 784 5. Extending existing model for route filtering 786 Route filters match on specific IP addresses or ranges of prefixes. 787 Much like ACLs, they include some match criteria and corresponding 788 match action(s). For that reason, it is very simple to extend 789 existing ACL model with route filtering. The combination of a route 790 prefix and prefix length along with the type of match determines how 791 route filters are evaluated against incoming routes. Different 792 vendors have different match types and in this model we are using 793 only ones that are common across all vendors participating in this 794 draft. It is easy to extend the model below in the same way how the 795 base ACL model can be extended with company proprietary extensions, 796 described in the next section. 798 module ietf-route-filter { 799 yang-version 1; 800 namespace "urn:ietf:params:xml:ns:yang:ietf-route-filter"; 802 prefix ietf-route-filter; 804 import ietf-inet-types { 805 prefix "ietf-types"; 806 } 808 import ietf-acl { 809 prefix "ietf-acl"; 810 } 811 organization 812 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 814 contact 815 "WG Web: http://tools.ietf.org/wg/netmod/ 816 WG List: netmod@ietf.org 818 WG Chair: Juergen Schoenwaelder 819 j.schoenwaelder@jacobs-university.de 821 WG Chair: Tom Nadeau 822 tnadeau@lucidvision.com 824 Editor: Dean Bogdanovic 825 deanb@juniper.net 827 Editor: Kiran Agrahara Sreenivasa 828 kkoushik@brocade.com 830 Editor: Lisa Huang 831 yihuan@cisco.com 833 Editor: Dana Blair 834 dblair@cisco.com"; 836 description " 837 This module describes route filter as a collection of 838 match prefixes. When specifying a match prefix, you 839 can specify an exact match with a particular route or 840 a less precise match. You can configure either a 841 common action that applies to the entire list or an 842 action associated with each prefix. 843 "; 845 revision 2014-08-15 { 846 description "creating Route-Filter extensions to ietf-acl model"; 847 reference " "; 849 } 851 augment "/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:matches"{ 852 description " 853 This module augments the matches container in the ietf-acl 854 module with route filter specific actions 855 "; 856 choice route-prefix{ 857 description "Define route filter match criteria"; 858 case range { 859 description " 860 Route falls between the lower prefix/prefix-length and the upper 861 prefix/prefix-length. 862 "; 863 choice ipv4-range { 864 description "Defines the lower IPv4 prefix/prefix range"; 865 leaf v4-lower-bound { 866 type ietf-types:ipv4-prefix; 867 description "Defines the lower IPv4 prefix/prefix length"; 868 } 869 leaf v4-upper-bound { 870 type ietf-types:ipv4-prefix; 871 description "Defines the upper IPv4 prefix/prefix length"; 872 } 873 } 874 choice ipv6-range { 875 description "Defines the IPv6 prefix/prefix range"; 876 leaf v6-lower-bound { 877 type ietf-types:ipv6-prefix; 878 description "Defines the lower IPv6 prefix/prefix length"; 879 } 880 leaf v6-upper-bound { 881 type ietf-types:ipv6-prefix; 882 description "Defines the upper IPv6 prefix/prefix length"; 883 } 884 } 885 } 886 } 887 } 888 } 890 6. Linux nftables 892 As Linux platform is becoming more popular as networking platform, 893 the Linux data model is changing. Previously ACLs in Linux were 894 highly protocol specific and different utilities were used for it 895 (iptables, ip6tables, arptables, ebtables). Recently, this has 896 changed and a single utility, nftables, has been provided. This 897 utility follows very similarly the same base model as proposed in 898 this draft. The nftables support input and output ACEs and each ACE 899 can be defined with match and action. 901 7. Security Considerations 903 The YANG module defined in this memo is designed to be accessed via 904 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 905 is the secure transport layer and the mandatory-to-implement secure 906 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 907 model [RFC6536] [RFC6536] provides the means to restrict access for 908 particular NETCONF users to a pre-configured subset of all available 909 NETCONF protocol operations and content. 911 There are a number of data nodes defined in the YANG module which are 912 writable/creatable/deletable (i.e., config true, which is the 913 default). These data nodes may be considered sensitive or vulnerable 914 in some network environments. Write operations (e.g., ) 915 to these data nodes without proper protection can have a negative 916 effect on network operations. 918 TBD: List specific Subtrees and data nodes and their sensitivity/ 919 vulnerability. 921 8. IANA Considerations 923 This document registers a URI in the IETF XML registry [RFC3688] 924 [RFC3688]. Following the format in RFC 3688, the following 925 registration is requested to be made: 927 URI: urn:ietf:params:xml:ns:yang:ietf-acl 929 Registrant Contact: The IESG. 931 XML: N/A, the requested URI is an XML namespace. 933 This document registers a YANG module in the YANG Module Names 934 registry [RFC6020]. 936 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-acl 937 prefix: ietf-acl reference: RFC XXXX 939 9. Acknowledgements 941 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 942 an initial IETF draf in several past IETF meetings. That draft 943 included an ACL YANG model structure and a rich set of match filters, 944 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 945 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 946 and Phil Shafer. Many people have reviewed the various earlier 947 drafts that made the draft went into IETF charter. 949 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 950 Blair each evaluated the YANG model in previous draft separately and 951 then work together, to created a new ACL draft that can be supported 952 by different vendors. The new draft removes vendor specific 953 features, and gives examples to allow vendors to extend in their own 954 proporitory ACL. The earlier draft was superseded with the new one 955 that received more participation from many vendors. 957 10. Change log [RFC Editor: Please remove] 959 11. References 961 11.1. Normative References 963 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 964 January 2004. 966 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 967 Network Configuration Protocol (NETCONF)", RFC 6020, 968 October 2010. 970 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 971 Bierman, "Network Configuration Protocol (NETCONF)", RFC 972 6241, June 2011. 974 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 975 Shell (SSH)", RFC 6242, June 2011. 977 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 978 Protocol (NETCONF) Access Control Model", RFC 6536, March 979 2012. 981 11.2. Informative References 983 [RFC5101] Claise, B., "Specification of the IP Flow Information 984 Export (IPFIX) Protocol for the Exchange of IP Traffic 985 Flow Information", RFC 5101, January 2008. 987 Authors' Addresses 989 Dean Bogdanovic 990 Juniper Networks 992 Email: deanb@juniper.net 993 Kiran Agrahara Sreenivasa 994 Brocade Communications System 996 Email: kkoushik@brocade.com 998 Lisa Huang 999 Cisco Systems 1001 Email: yihuan@cisco.com 1003 Dana Blair 1004 Cisco Systems 1006 Email: dblair@cisco.com