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