idnits 2.17.1 draft-ietf-rtgwg-policy-model-29.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 292 has weird spacing: '...h-lower uin...' == Line 293 has weird spacing: '...h-upper uin...' == Line 492 has weird spacing: '...h-lower uin...' == Line 493 has weird spacing: '...h-upper uin...' == Line 937 has weird spacing: '... enum add-m...' == (3 more instances...) -- The document date (June 18, 2021) is 1035 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'INTF-EXT-YANG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SUB-INTF-VLAN-YANG' == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Y. Qu 3 Internet-Draft Futurewei 4 Intended status: Standards Track J. Tantsura 5 Expires: December 20, 2021 Juniper Networks 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 June 18, 2021 12 A YANG Data Model for Routing Policy 13 draft-ietf-rtgwg-policy-model-29 15 Abstract 17 This document defines a YANG data model for configuring and managing 18 routing policies in a vendor-neutral way. The model provides a 19 generic routing policy framework which can be extended for specific 20 routing protocols using the YANG 'augment' mechanism. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 20, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 59 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 61 3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Route policy expression . . . . . . . . . . . . . . . . . . . 6 63 4.1. Defined sets for policy matching . . . . . . . . . . . . 6 64 4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8 66 4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9 67 5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10 69 7. YANG Module and Tree . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Routing Policy Model Tree . . . . . . . . . . . . . . . . 11 71 7.2. Routing policy model . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 76 11.1. Normative references . . . . . . . . . . . . . . . . . . 35 77 11.2. Informative references . . . . . . . . . . . . . . . . . 37 78 Appendix A. Routing protocol-specific policies . . . . . . . . . 37 79 Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 40 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 82 1. Introduction 84 This document describes a YANG [RFC7950] data model for routing 85 policy configuration based on operational usage and best practices in 86 a variety of service provider networks. The model is intended to be 87 vendor-neutral, to allow operators to manage policy configuration in 88 a consistent way in environments with routers supplied by multiple 89 vendors. 91 The YANG modules in this document conform to the Network Management 92 Datastore Architecture (NMDA) [RFC8342]. 94 1.1. Goals and approach 96 This model does not aim to be feature complete -- it is a subset of 97 the policy configuration parameters available in a variety of vendor 98 implementations, but supports widely used constructs for managing how 99 routes are imported, exported, and modified across different routing 100 protocols. The model development approach has been to examine actual 101 policy configurations in use across several operator networks. 102 Hence, the focus is on enabling policy configuration capabilities and 103 structure that are in wide use. 105 Despite the differences in details of policy expressions and 106 conventions in various vendor implementations, the model reflects the 107 observation that a relatively simple condition-action approach can be 108 readily mapped to several existing vendor implementations, and also 109 gives operators a familiar and straightforward way to express policy. 110 A side effect of this design decision is that other methods for 111 expressing policies are not considered. 113 Consistent with the goal to produce a data model that is vendor 114 neutral, only policy expressions that are deemed to be widely 115 available in existing major implementations are included in the 116 model. Those configuration items that are only available from a 117 single implementation are omitted from the model with the expectation 118 they will be available in separate vendor-provided modules that 119 augment the current model. 121 2. Terminology and Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Routing policy: A routing policy defines how routes are imported, 130 exported, modified, and advertised between routing protocol instances 131 or within a single routing protocol instance. 133 Policy chain: A policy chain is a sequence of policy definitions 134 (described in Section 4). They can be referenced from different 135 contexts. 137 Policy statement: Policy statements consist of a set of conditions 138 and actions (either of which may be empty). 140 The following terms are defined in [RFC8342]: 142 o client 144 o server 146 o configuration 148 o system state 150 o operational state 152 o intended configuration 154 The following terms are defined in [RFC7950]: 156 o action 158 o augment 160 o container 162 o container with presence 164 o data model 166 o data node 168 o feature 170 o leaf 172 o list 174 o mandatory node 176 o module 178 o schema tree 180 o RPC (Remote Procedure Call) operation 182 2.1. Tree Diagrams 184 Tree diagrams used in this document follow the notation defined in 185 [RFC8340]. 187 2.2. Prefixes in Data Node Names 189 In this document, names of data nodes, actions, and other data model 190 objects are often used without a prefix, as long as it is clear from 191 the context in which YANG module each name is defined. Otherwise, 192 names are prefixed using the standard prefix associated with the 193 corresponding YANG module, as shown in Table 1. 195 +---------+--------------------------------+----------------------+ 196 | Prefix | YANG module | Reference | 197 +---------+--------------------------------+----------------------+ 198 | if | ietf-interfaces | [RFC8343] | 199 | | | | 200 | rt | ietf-routing | [RFC8349] | 201 | | | | 202 | yang | ietf-yang-types | [RFC6991] | 203 | | | | 204 | inet | ietf-inet-types | [RFC6991] | 205 | | | | 206 | if-ext | ietf-if-extensions | [INTF-EXT-YANG] | 207 | | | | 208 | if-flex | ietf-if-flexible-encapsulation | [SUB-INTF-VLAN-YANG] | 209 +---------+--------------------------------+----------------------+ 211 Table 1: Prefixes and Corresponding YANG Modules 213 3. Model overview 215 The routing policy module has three main parts: 217 o A generic framework is provided to express policies as sets of 218 related conditions and actions. This includes match sets and 219 actions that are useful across many routing protocols. 221 o A structure that allows routing protocol models to add protocol- 222 specific policy conditions and actions though YANG augmentations 223 is also provided. There is a complete example of this for BGP 224 [RFC4271] policies in the proposed vendor-neutral BGP data model 225 [I-D.ietf-idr-bgp-model]. Appendix A provides an example of how 226 an augmentation for BGP policies might be accomplished. Note that 227 this section is not normative as the BGP model is still evolving. 229 o Finally, a reusable grouping is defined for attaching import and 230 export rules in the context of routing configuration for different 231 protocols, VRFs, etc. This also enables creation of policy chains 232 and expressing default policy behavior. In this document, policy 233 chains are sequences of policy definitions that are applied in 234 order (described in Section 4). 236 The module makes use of the standard Internet types, such as IP 237 addresses, autonomous system numbers, etc., defined in RFC 6991 238 [RFC6991]. 240 4. Route policy expression 242 Policies are expressed as a sequence of top-level policy definitions 243 each of which consists of a sequence of policy statements. Policy 244 statements in turn consist of simple condition-action tuples. 245 Conditions may include multiple match or comparison operations, and 246 similarly, actions may effect multiple changes to route attributes, 247 or indicate a final disposition of accepting or rejecting the route. 248 This structure is shown below. 250 +--rw routing-policy 251 +--rw policy-definitions 252 +--rw policy-definition* [name] 253 +--rw name string 254 +--rw statements 255 +--rw statement* [name] 256 +--rw name string 257 +--rw conditions 258 | ... 259 +--rw actions 260 ... 262 4.1. Defined sets for policy matching 264 The model provides a collection of generic sets that can be used for 265 matching in policy conditions. These sets are applicable for route 266 selection across multiple routing protocols. They may be further 267 augmented by protocol-specific models which have their own defined 268 sets. The defined sets include: 270 o prefix sets - Each prefix set defines a set of IP prefixes, each 271 with an associated IP prefix and netmask range (or exact length). 273 o neighbor sets - Each neighbor set defines a set of neighboring 274 nodes by their IP addresses. A neighbor set is used for selecting 275 routes based on the neighbors advertising the routes. 277 o tag set - Each tag set defines a set of generic tag values that 278 can be used in matches for filtering routes. 280 The model structure for defined sets is shown below. 282 +--rw routing-policy 283 +--rw defined-sets 284 | +--rw prefix-sets 285 | | +--rw prefix-set* [name] 286 | | +--rw name string 287 | | +--rw mode? enumeration 288 | | +--rw prefixes 289 | | +--rw prefix-list* [ip-prefix mask-length-lower 290 | | mask-length-upper] 291 | | +--rw ip-prefix inet:ip-prefix 292 | | +--rw mask-length-lower uint8 293 | | +--rw mask-length-upper uint8 294 | +--rw neighbor-sets 295 | | +--rw neighbor-set* [name] 296 | | +--rw name string 297 | | +--rw address* inet:ip-address 298 | +--rw tag-sets 299 | +--rw tag-set* [name] 300 | +--rw name string 301 | +--rw tag-value* tag-type 303 4.2. Policy conditions 305 Policy statements consist of a set of conditions and actions (either 306 of which may be empty). Conditions are used to match route 307 attributes against a defined set (e.g., a prefix set), or to compare 308 attributes against a specific value. The default action is to 309 reject-route. 311 Match conditions may be further modified using the match-set-options 312 configuration which allows network operators to change the behavior 313 of a match. Three options are supported: 315 o ALL - match is true only if the given value matches all members of 316 the set. 318 o ANY - match is true if the given value matches any member of the 319 set. 321 o INVERT - match is true if the given value does not match any 322 member of the given set. 324 Not all options are appropriate for matching against all defined sets 325 (e.g., match ALL in a prefix set does not make sense). In the model, 326 a restricted set of match options is used where applicable. 328 Comparison conditions may similarly use options to change how route 329 attributes should be tested, e.g., for equality or inequality, 330 against a given value. 332 While most policy conditions will be added by individual routing 333 protocol models via augmentation, this routing policy model includes 334 several generic match conditions and the ability to test which 335 protocol or mechanism installed a route (e.g., BGP, IGP, static, 336 etc.). The conditions included in the model are shown below. 338 +--rw routing-policy 339 +--rw policy-definitions 340 +--rw policy-definition* [name] 341 +--rw name string 342 +--rw statements 343 +--rw statement* [name] 344 +--rw conditions 345 | +--rw call-policy? 346 | +--rw source-protocol? 347 | +--rw match-interface 348 | | +--rw interface? 349 | +--rw match-prefix-set 350 | | +--rw prefix-set? 351 | | +--rw match-set-options? 352 | +--rw match-neighbor-set 353 | | +--rw neighbor-set? 354 | +--rw match-tag-set 355 | | +--rw tag-set? 356 | | +--rw match-set-options? 357 | +--rw match-route-type* identityref 359 4.3. Policy actions 361 When policy conditions are satisfied, policy actions are used to set 362 various attributes of the route being processed, or to indicate the 363 final disposition of the route, i.e., accept or reject. 365 Similar to policy conditions, the routing policy model includes 366 generic actions in addition to the basic route disposition actions. 367 These are shown below. 369 +--rw routing-policy 370 +--rw policy-definitions 371 +--rw policy-definition* [name] 372 +--rw statements 373 +--rw statement* [name] 374 +--rw actions 375 +--rw policy-result? policy-result-type 376 +--rw set-metric 377 | +--rw metric-modification? 378 | | metric-modification-type 379 | +--rw metric? uint32 380 +--rw set-metric-type 381 | +--rw metric-type? identityref 382 +--rw set-route-level 383 | +--rw route-level? identityref 384 +--rw set-route-preference? uint16 385 +--rw set-tag? tag-type 386 +--rw set-application-tag? tag-type 388 4.4. Policy subroutines 390 Policy 'subroutines' (or nested policies) are supported by allowing 391 policy statement conditions to reference other policy definitions 392 using the call-policy configuration. Called policies apply their 393 conditions and actions before returning to the calling policy 394 statement and resuming evaluation. The outcome of the called policy 395 affects the evaluation of the calling policy. If the called policy 396 results in an accept-route, then the subroutine returns an effective 397 Boolean true value to the calling policy. For the calling policy, 398 this is equivalent to a condition statement evaluating to a true 399 value and evaluation of the policy continues (see Section 5). Note 400 that the called policy may also modify attributes of the route in its 401 action statements. Similarly, a reject-route action returns false 402 and the calling policy evaluation will be affected accordingly. When 403 the end of the subroutine policy statements is reached, the default 404 route disposition action is returned (i.e., Boolean false for reject- 405 route). Consequently, a subroutine cannot explicitly accept or 406 reject a route. Rather, the called policy returns Boolean true if 407 its outcome is accept-route or Boolean false if its outcome is 408 reject-route. Route acceptance or rejection is solely determined by 409 the top-level policy. 411 Note that the called policy may itself call other policies (subject 412 to implementation limitations). The model does not prescribe a 413 nesting depth because this varies among implementations. For 414 example, an implementation may only support a single level of 415 subroutine recursion. As with any routing policy construction, care 416 must be taken with nested policies to ensure that the effective 417 return value results in the intended behavior. Nested policies are a 418 convenience in many routing policy constructions but creating 419 policies nested beyond a small number of levels (e.g., 2-3) is 420 discouraged. Also, implementations MUST validate to ensure that 421 there is no recursion amongst nested routing policies. 423 5. Policy evaluation 425 Evaluation of each policy definition proceeds by evaluating its 426 individual policy statements in order that they are defined. When 427 all the condition statements in a policy statement are satisfied, the 428 corresponding action statements are executed. If the actions include 429 either accept-route or reject-route actions, evaluation of the 430 current policy definition stops, and no further policy statement is 431 evaluated. If there are multiple policies in the policy chain, 432 subsequent policies are not evaluated. Policy chains are sequences 433 of policy definitions (as described in Section 4). 435 If the conditions are not satisfied, then evaluation proceeds to the 436 next policy statement. If none of the policy statement conditions 437 are satisfied, then evaluation of the current policy definition 438 stops, and the next policy definition in the chain is evaluated. 439 When the end of the policy chain is reached, the default route 440 disposition action is performed (i.e., reject-route unless an 441 alternate default action is specified for the chain). 443 Note that the route's pre-policy attributes are always used for 444 testing policy statement conditions. In other words, if actions 445 modify the policy application-specific attributes, those 446 modifications are not used for policy statement conditions. 448 6. Applying routing policy 450 Routing policy is applied by defining and attaching policy chains in 451 various routing contexts. Policy chains are sequences of policy 452 definitions (described in Section 4). They can be referenced from 453 different contexts. For example, a policy chain could be associated 454 with a routing protocol and used to control its interaction with its 455 protocol peers. Or it could be used to control the interaction 456 between a routing protocol and the local routing information base. A 457 policy chain has an associated direction (import or export), with 458 respect to the context in which it is referenced. 460 The routing policy model defines an apply-policy grouping that can be 461 imported and used by other models. As shown below, it allows 462 definition of import and export policy chains, as well as specifying 463 the default route disposition to be used when no policy definition in 464 the chain results in a final decision. 466 +--rw apply-policy 467 | +--rw import-policy* 468 | +--rw default-import-policy? default-policy-type 469 | +--rw export-policy* 470 | +--rw default-export-policy? default-policy-type 472 The default policy defined by the model is to reject the route for 473 both import and export policies. 475 7. YANG Module and Tree 477 7.1. Routing Policy Model Tree 479 The tree of the routing policy model is shown below. 481 module: ietf-routing-policy 482 rw routing-policy 483 +--rw defined-sets 484 | +--rw prefix-sets 485 | | +--rw prefix-set* [name mode] 486 | | +--rw name string 487 | | +--rw mode enumeration 488 | | +--rw prefixes 489 | | +--rw prefix-list* [ip-prefix mask-length-lower 490 | | mask-length-upper] 491 | | +--rw ip-prefix inet:ip-prefix 492 | | +--rw mask-length-lower uint8 493 | | +--rw mask-length-upper uint8 494 | +--rw neighbor-sets 495 | | +--rw neighbor-set* [name] 496 | | +--rw name string 497 | | +--rw address* inet:ip-address 498 | +--rw tag-sets 499 | +--rw tag-set* [name] 500 | +--rw name string 501 | +--rw tag-value* tag-type 502 +--rw policy-definitions 503 +--rw policy-definition* [name] 504 +--rw name string 505 +--rw statements 506 +--rw statement* [name] 507 +--rw name string 508 +--rw conditions 509 | +--rw call-policy? -> ../../../../../.. 510 | /policy-definitions 511 | /policy-definition/name 512 | +--rw source-protocol? identityref 513 | +--rw match-interface 514 | | +--rw interface? -> /if:interfaces/interface 515 | | /name 516 | +--rw match-prefix-set 517 | | +--rw prefix-set? -> ../../../../../../.. 518 | | /defined-sets/prefix-sets 519 | | /prefix-set/name 520 | | +--rw match-set-options? match-set-options-type 521 | +--rw match-neighbor-set 522 | | +--rw neighbor-set? -> ../../../../../../.. 523 | | /defined-sets/neighbor-sets 524 | | /neighbor-set/name 525 | +--rw match-tag-set 526 | | +--rw tag-set? -> ../../../../../../.. 527 | | /defined-sets/tag-sets 528 | | /tag-set/name 529 | | +--rw match-set-options? match-set-options-type 530 | +--rw match-route-type* identityref 531 +--rw actions 532 +--rw policy-result? policy-result-type 533 +--rw set-metric 534 | +--rw metric-modification? metric-modification-type 535 | +--rw metric? uint32 536 +--rw set-metric-type 537 | +--rw metric-type? identityref 538 +--rw set-route-level 539 | +--rw route-level? identityref 540 +--rw set-route-preference? uint16 541 +--rw set-tag? tag-type 542 +--rw set-application-tag? tag-type 544 7.2. Routing policy model 546 The following RFCs are not referenced in the document text but are 547 referenced in the ietf-routing-policy.yang module: [RFC2328], 548 [RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343]. 550 file "ietf-routing-policy@2021-06-18.yang" 551 module ietf-routing-policy { 553 yang-version "1.1"; 555 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 556 prefix rt-pol; 558 import ietf-inet-types { 559 prefix "inet"; 560 reference "RFC 6991: Common YANG Data Types"; 561 } 562 import ietf-yang-types { 563 prefix "yang"; 564 reference "RFC 6991: Common YANG Data Types"; 565 } 567 import ietf-interfaces { 568 prefix "if"; 569 reference "RFC 8343: A YANG Data Model for Interface 570 Management (NMDA Version)"; 571 } 573 import ietf-routing { 574 prefix "rt"; 575 reference "RFC 8349: A YANG Data Model for Routing 576 Management (NMDA Version)"; 577 } 579 organization 580 "IETF RTGWG - Routing Area Working Group"; 581 contact 582 "WG Web: 583 WG List: 585 Editor: Yingzhen Qu 586 587 Jeff Tantsura 588 589 Acee Lindem 590 591 Xufeng Liu 592 "; 594 description 595 "This module describes a YANG model for routing policy 596 configuration. It is a limited subset of all of the policy 597 configuration parameters available in the variety of vendor 598 implementations, but supports widely used constructs for 599 managing how routes are imported, exported, modified and 600 advertised across different routing protocol instances or 601 within a single routing protocol instance. This module is 602 intended to be used in conjunction with routing protocol 603 configuration modules (e.g., BGP) defined in other models. 605 This YANG module conforms to the Network Management 606 Datastore Architecture (NMDA), as described in RFC 8342. 608 Copyright (c) 2021 IETF Trust and the persons identified as 609 authors of the code. All rights reserved. 611 Redistribution and use in source and binary forms, with or 612 without modification, is permitted pursuant to, and subject to 613 the license terms contained in, the Simplified BSD License set 614 forth in Section 4.c of the IETF Trust's Legal Provisions 615 Relating to IETF Documents 616 (https://trustee.ietf.org/license-info). 618 This version of this YANG module is part of RFC XXXX; 619 see the RFC itself for full legal notices. 621 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 622 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 623 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 624 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 625 and only when, they appear in all capitals, as shown here."; 627 reference "RFC XXXX: A YANG Data Model for Routing Policy."; 629 revision "2021-06-18" { 630 description 631 "Initial revision."; 632 reference 633 "RFC XXXX: A YANG Data Model for Routing Policy Management."; 634 } 636 /* Identities */ 638 identity metric-type { 639 description 640 "Base identity for route metric types."; 641 } 643 identity ospf-type-1-metric { 644 base metric-type; 645 description 646 "Identity for the OSPF type 1 external metric types. It 647 is only applicable to OSPF routes."; 648 reference 649 "RFC 2328 - OSPF Version 2"; 650 } 652 identity ospf-type-2-metric { 653 base metric-type; 654 description 655 "Identity for the OSPF type 2 external metric types. It 656 is only applicable to OSPF routes."; 657 reference 658 "RFC 2328 - OSPF Version 2"; 660 } 662 identity isis-internal-metric { 663 base metric-type; 664 description 665 "Identity for the IS-IS internal metric types. It is only 666 applicable to IS-IS routes."; 667 reference 668 "RFC 5302 - Domain-Wide Prefix Distribution with 669 Two-Level IS-IS"; 670 } 672 identity isis-external-metric { 673 base metric-type; 674 description 675 "Identity for the IS-IS external metric types. It is only 676 applicable to IS-IS routes."; 677 reference 678 "RFC 5302 - Domain-Wide Prefix Distribution with 679 Two-Level IS-IS"; 680 } 682 identity route-level { 683 description 684 "Base identity for route import level."; 685 } 687 identity ospf-normal { 688 base route-level; 689 description 690 "Identity for OSPF importation into normal areas 691 It is only applicable to routes imported 692 into the OSPF protocol."; 693 reference 694 "RFC 2328 - OSPF Version 2"; 695 } 697 identity ospf-nssa-only { 698 base route-level; 699 description 700 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 701 importation. It is only applicable to routes imported 702 into the OSPF protocol."; 703 reference 704 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 705 } 707 identity ospf-normal-nssa { 708 base route-level; 709 description 710 "Identity for OSPF importation into both normal and NSSA 711 areas, it is only applicable to routes imported into 712 the OSPF protocol."; 713 reference 714 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 715 } 717 identity isis-level-1 { 718 base route-level; 719 description 720 "Identity for IS-IS Level 1 area importation. It is only 721 applicable to routes imported into the IS-IS protocol."; 722 reference 723 "RFC 5302 - Domain-Wide Prefix Distribution with 724 Two-Level IS-IS"; 725 } 727 identity isis-level-2 { 728 base route-level; 729 description 730 "Identity for IS-IS Level 2 area importation. It is only 731 applicable to routes imported into the IS-IS protocol."; 732 reference 733 "RFC 5302 - Domain-Wide Prefix Distribution with 734 Two-Level IS-IS"; 735 } 737 identity isis-level-1-2 { 738 base route-level; 739 description 740 "Identity for IS-IS Level 1 and Level 2 area importation. It 741 is only applicable to routes imported into the IS-IS 742 protocol."; 743 reference 744 "RFC 5302 - Domain-Wide Prefix Distribution with 745 Two-Level IS-IS"; 746 } 748 identity proto-route-type { 749 description 750 "Base identity for route type within a protocol."; 751 } 753 identity isis-level-1-type { 754 base proto-route-type; 755 description 756 "Identity for IS-IS Level 1 route type. It is only 757 applicable to IS-IS routes."; 758 reference 759 "RFC 5302 - Domain-Wide Prefix Distribution with 760 Two-Level IS-IS"; 761 } 763 identity isis-level-2-type { 764 base proto-route-type; 765 description 766 "Identity for IS-IS Level 2 route type. It is only 767 applicable to IS-IS routes."; 768 reference 769 "RFC 5302 - Domain-Wide Prefix Distribution with 770 Two-Level IS-IS"; 771 } 773 identity ospf-internal-type { 774 base proto-route-type; 775 description 776 "Identity for OSPF intra-area or inter-area route type. 777 It is only applicable to OSPF routes."; 778 reference 779 "RFC 2328 - OSPF Version 2"; 780 } 782 identity ospf-external-type { 783 base proto-route-type; 784 description 785 "Identity for OSPF external type 1/2 route type. 786 It is only applicable to OSPF routes."; 787 reference 788 "RFC 2328 - OSPF Version 2"; 789 } 791 identity ospf-external-t1-type { 792 base ospf-external-type; 793 description 794 "Identity for OSPF external type 1 route type. 795 It is only applicable to OSPF routes."; 796 reference 797 "RFC 2328 - OSPF Version 2"; 798 } 800 identity ospf-external-t2-type { 801 base ospf-external-type; 802 description 803 "Identity for OSPF external type 2 route type. 805 It is only applicable to OSPF routes."; 806 reference 807 "RFC 2328 - OSPF Version 2"; 808 } 810 identity ospf-nssa-type { 811 base proto-route-type; 812 description 813 "Identity for OSPF NSSA type 1/2 route type. 814 It is only applicable to OSPF routes."; 815 reference 816 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 817 } 819 identity ospf-nssa-t1-type { 820 base ospf-nssa-type; 821 description 822 "Identity for OSPF NSSA type 1 route type. 823 It is only applicable to OSPF routes."; 824 reference 825 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 826 } 828 identity ospf-nssa-t2-type { 829 base ospf-nssa-type; 830 description 831 "Identity for OSPF NSSA type 2 route type. 832 It is only applicable to OSPF routes."; 833 reference 834 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 835 } 837 identity bgp-internal { 838 base proto-route-type; 839 description 840 "Identity for routes learned from internal BGP (IBGP). 841 It is only applicable to BGP routes."; 842 reference 843 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 844 } 846 identity bgp-external { 847 base proto-route-type; 848 description 849 "Identity for routes learned from external BGP (EBGP). 850 It is only applicable to BGP routes."; 851 reference 852 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 854 } 856 /* Type Definitions */ 858 typedef default-policy-type { 859 type enumeration { 860 enum accept-route { 861 description 862 "Default policy to accept the route."; 863 } 864 enum reject-route { 865 description 866 "Default policy to reject the route."; 867 } 868 } 869 description 870 "Type used to specify route disposition in 871 a policy chain. This typedef is used in 872 the default import and export policy."; 873 } 875 typedef policy-result-type { 876 type enumeration { 877 enum accept-route { 878 description 879 "Policy accepts the route."; 880 } 881 enum reject-route { 882 description 883 "Policy rejects the route."; 884 } 885 } 886 description 887 "Type used to specify route disposition in 888 a policy chain."; 889 } 891 typedef tag-type { 892 type union { 893 type uint32; 894 type yang:hex-string; 895 } 896 description 897 "Type for expressing route tags on a local system, 898 including IS-IS and OSPF; may be expressed as either decimal 899 or hexadecimal integer."; 900 reference 901 "RFC 2328 - OSPF Version 2 902 RFC 5130 - A Policy Control Mechanism in IS-IS Using 903 Administrative Tags"; 904 } 906 typedef match-set-options-type { 907 type enumeration { 908 enum any { 909 description 910 "Match is true if given value matches any member 911 of the defined set."; 912 } 913 enum all { 914 description 915 "Match is true if given value matches all 916 members of the defined set."; 917 } 918 enum invert { 919 description 920 "Match is true if given value does not match any 921 member of the defined set."; 922 } 923 } 924 default any; 925 description 926 "Options that govern the behavior of a match statement. The 927 default behavior is any, i.e., the given value matches any 928 of the members of the defined set."; 929 } 931 typedef metric-modification-type { 932 type enumeration { 933 enum set-metric { 934 description 935 "Set the metric to the specified value."; 936 } 937 enum add-metric { 938 description 939 "Add the specified value to the existing metric. 940 If the result would overflow the maximum metric 941 (0xffffffff), set the metric to the maximum."; 942 } 943 enum subtract-metric { 944 description 945 "Subtract the specified value from the existing metric. If 946 the result would be less than 0, set the metric to 0."; 947 } 948 } 949 description 950 "Type used to specify how to set the metric given the 951 specified value."; 952 } 954 /* Groupings */ 956 grouping prefix { 957 description 958 "Configuration data for a prefix definition. 960 The combination of mask-length-lower and mask-length-upper 961 define a range for the mask length, or single 'exact' 962 length if mask-length-lower and mask-length-upper are 963 equal. 965 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 966 expressed as prefix: 192.0.2.0/24, 967 mask-length-lower=24, 968 mask-length-upper=26 970 Example: 192.0.2.0/24 (an exact match) would be 971 expressed as prefix: 192.0.2.0/24, 972 mask-length-lower=24, 973 mask-length-upper=24 975 Example: 2001:DB8::/32 through 2001:DB8::/64 would be 976 expressed as prefix: 2001:DB8::/32, 977 mask-length-lower=32, 978 mask-length-upper=64"; 980 leaf ip-prefix { 981 type inet:ip-prefix; 982 mandatory true; 983 description 984 "The IP prefix represented as an IPv6 or IPv4 network 985 number followed by a prefix length with an intervening 986 slash character as a delimiter. All members of the 987 prefix-set MUST be of the same address family as the 988 prefix-set mode."; 989 } 991 leaf mask-length-lower { 992 type uint8 { 993 range "0..128"; 994 } 995 description 996 "Mask length range lower bound. It MUST NOT be less than 997 the prefix length defined in ip-prefix."; 999 } 1000 leaf mask-length-upper { 1001 type uint8 { 1002 range "1..128"; 1003 } 1004 must "../mask-length-upper >= ../mask-length-lower" { 1005 error-message "The upper bound MUST NOT be less" 1006 + "than lower bound."; 1007 } 1008 description 1009 "Mask length range upper bound. It MUST NOT be less than 1010 lower bound."; 1011 } 1012 } 1014 grouping match-set-options-group { 1015 description 1016 "Grouping containing options relating to how a particular set 1017 will be matched."; 1019 leaf match-set-options { 1020 type match-set-options-type; 1021 description 1022 "Optional parameter that governs the behavior of the 1023 match operation."; 1024 } 1025 } 1027 grouping match-set-options-restricted-group { 1028 description 1029 "Grouping for a restricted set of match operation 1030 modifiers."; 1032 leaf match-set-options { 1033 type match-set-options-type { 1034 enum any { 1035 description 1036 "Match is true if given value matches any 1037 member of the defined set."; 1038 } 1039 enum invert { 1040 description 1041 "Match is true if given value does not match 1042 any member of the defined set."; 1043 } 1044 } 1045 description 1046 "Optional parameter that governs the behavior of the 1047 match operation. This leaf only supports matching on 1048 'any' member of the set or 'invert' the match. 1049 Matching on 'all' is not supported."; 1050 } 1051 } 1053 grouping match-interface-condition { 1054 description 1055 "This grouping provides interface match condition."; 1057 container match-interface { 1058 leaf interface { 1059 type leafref { 1060 path "/if:interfaces/if:interface/if:name"; 1061 } 1062 description 1063 "Reference to a base interface."; 1064 } 1065 description 1066 "Container for interface match conditions"; 1067 } 1068 } 1070 grouping match-route-type-condition { 1071 description 1072 "This grouping provides route-type match condition"; 1074 leaf-list match-route-type { 1075 type identityref { 1076 base proto-route-type; 1077 } 1078 description 1079 "Condition to check the protocol-specific type 1080 of route. This is normally used during route 1081 importation to select routes or to set protocol 1082 specific attributes based on the route type."; 1083 } 1084 } 1086 grouping prefix-set-condition { 1087 description 1088 "This grouping provides prefix-set conditions."; 1090 container match-prefix-set { 1091 leaf prefix-set { 1092 type leafref { 1093 path "../../../../../../../defined-sets/" + 1094 "prefix-sets/prefix-set/name"; 1096 } 1097 description 1098 "References a defined prefix set."; 1099 } 1100 uses match-set-options-restricted-group; 1102 description 1103 "Match a referenced prefix-set according to the logic 1104 defined in the match-set-options leaf."; 1105 } 1106 } 1108 grouping neighbor-set-condition { 1109 description 1110 "This grouping provides neighbor-set conditions."; 1112 container match-neighbor-set { 1113 leaf neighbor-set { 1114 type leafref { 1115 path "../../../../../../../defined-sets/neighbor-sets/" + 1116 "neighbor-set/name"; 1117 require-instance true; 1118 } 1119 description 1120 "References a defined neighbor set."; 1121 } 1123 description 1124 "Match a referenced neighbor set according to the logic 1125 defined in the match-set-options-leaf."; 1126 } 1127 } 1129 grouping tag-set-condition { 1130 description 1131 "This grouping provides tag-set conditions."; 1133 container match-tag-set { 1134 leaf tag-set { 1135 type leafref { 1136 path "../../../../../../../defined-sets/tag-sets" + 1137 "/tag-set/name"; 1138 require-instance true; 1139 } 1140 description 1141 "References a defined tag set."; 1142 } 1143 uses match-set-options-group; 1144 description 1145 "Match a referenced tag set according to the logic defined 1146 in the match-options-set leaf."; 1147 } 1148 } 1150 grouping apply-policy-import { 1151 description 1152 "Grouping for applying import policies."; 1154 leaf-list import-policy { 1155 type leafref { 1156 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1157 "rt-pol:policy-definition/rt-pol:name"; 1158 require-instance true; 1159 } 1160 ordered-by user; 1161 description 1162 "List of policy names in sequence to be applied on 1163 receiving redistributed routes from another routing protocol 1164 or receiving a routing update in the current context, e.g., 1165 for the current peer group, neighbor, address family, 1166 etc."; 1167 } 1169 leaf default-import-policy { 1170 type default-policy-type; 1171 default reject-route; 1172 description 1173 "Explicitly set a default policy if no policy definition 1174 in the import policy chain is satisfied."; 1175 } 1177 } 1179 grouping apply-policy-export { 1180 description 1181 "Grouping for applying export policies."; 1183 leaf-list export-policy { 1184 type leafref { 1185 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1186 "rt-pol:policy-definition/rt-pol:name"; 1187 require-instance true; 1188 } 1189 ordered-by user; 1190 description 1191 "List of policy names in sequence to be applied on 1192 redistributing routes from one routing protocol to another 1193 or sending a routing update in the current context, e.g., 1194 for the current peer group, neighbor, address family, 1195 etc."; 1196 } 1198 leaf default-export-policy { 1199 type default-policy-type; 1200 default reject-route; 1201 description 1202 "Explicitly set a default policy if no policy definition 1203 in the export policy chain is satisfied."; 1204 } 1205 } 1207 grouping apply-policy-group { 1208 description 1209 "Top level container for routing policy applications. This 1210 grouping is intended to be used in routing models where 1211 needed."; 1213 container apply-policy { 1214 description 1215 "Anchor point for routing policies in the model. 1216 Import and export policies are with respect to the local 1217 routing table, i.e., export (send) and import (receive), 1218 depending on the context."; 1220 uses apply-policy-import; 1221 uses apply-policy-export; 1223 } 1224 } 1226 container routing-policy { 1227 description 1228 "Top-level container for all routing policy."; 1230 container defined-sets { 1231 description 1232 "Predefined sets of attributes used in policy match 1233 statements."; 1235 container prefix-sets { 1236 description 1237 "Data definitions for a list of IPv4 or IPv6 1238 prefixes which are matched as part of a policy."; 1239 list prefix-set { 1240 key "name mode"; 1241 description 1242 "List of the defined prefix sets"; 1244 leaf name { 1245 type string; 1246 description 1247 "Name of the prefix set -- this is used as a label to 1248 reference the set in match conditions."; 1249 } 1251 leaf mode { 1252 type enumeration { 1253 enum ipv4 { 1254 description 1255 "Prefix set contains IPv4 prefixes only."; 1256 } 1257 enum ipv6 { 1258 description 1259 "Prefix set contains IPv6 prefixes only."; 1260 } 1261 } 1262 description 1263 "Indicates the mode of the prefix set, in terms of 1264 which address families (IPv4, IPv6, or both) are 1265 present. The mode provides a hint, all prefixes MUST 1266 be of the indicated type. The device MUST validate 1267 that all prefixes and reject the configuration if 1268 there is a discrepancy."; 1269 } 1271 container prefixes { 1272 description 1273 "Container for the list of prefixes in a policy 1274 prefix list. Since individual prefixes do not have 1275 unique actions, the order in which the prefix in 1276 prefix-list are matched has no impact on the outcome 1277 and is left to the implementation. A given prefix-set 1278 condition is satisfied if the input prefix matches 1279 any of the prefixes in the prefix-set."; 1281 list prefix-list { 1282 key "ip-prefix mask-length-lower mask-length-upper"; 1283 description 1284 "List of prefixes in the prefix set."; 1286 uses prefix; 1287 } 1289 } 1290 } 1291 } 1293 container neighbor-sets { 1294 description 1295 "Data definition for a list of IPv4 or IPv6 1296 neighbors which can be matched in a routing policy."; 1298 list neighbor-set { 1299 key "name"; 1300 description 1301 "List of defined neighbor sets for use in policies."; 1303 leaf name { 1304 type string; 1305 description 1306 "Name of the neighbor set -- this is used as a label 1307 to reference the set in match conditions."; 1308 } 1310 leaf-list address { 1311 type inet:ip-address; 1312 description 1313 "List of IP addresses in the neighbor set."; 1314 } 1315 } 1316 } 1318 container tag-sets { 1319 description 1320 "Data definitions for a list of tags which can 1321 be matched in policies."; 1323 list tag-set { 1324 key "name"; 1325 description 1326 "List of tag set definitions."; 1328 leaf name { 1329 type string; 1330 description 1331 "Name of the tag set -- this is used as a label to 1332 reference the set in match conditions."; 1333 } 1335 leaf-list tag-value { 1336 type tag-type; 1337 description 1338 "Value of the tag set member."; 1339 } 1340 } 1341 } 1342 } 1344 container policy-definitions { 1345 description 1346 "Enclosing container for the list of top-level policy 1347 definitions."; 1349 list policy-definition { 1350 key "name"; 1351 description 1352 "List of top-level policy definitions, keyed by unique 1353 name. These policy definitions are expected to be 1354 referenced (by name) in policy chains specified in 1355 import or export configuration statements."; 1357 leaf name { 1358 type string; 1359 description 1360 "Name of the top-level policy definition -- this name 1361 is used in references to the current policy."; 1362 } 1364 container statements { 1365 description 1366 "Enclosing container for policy statements."; 1368 list statement { 1369 key "name"; 1370 ordered-by user; 1371 description 1372 "Policy statements group conditions and actions 1373 within a policy definition. They are evaluated in 1374 the order specified (see the description of policy 1375 evaluation at the top of this module."; 1377 leaf name { 1378 type string; 1379 description 1380 "Name of the policy statement."; 1381 } 1383 container conditions { 1384 description 1385 "Condition statements for the current policy 1386 statement."; 1388 leaf call-policy { 1389 type leafref { 1390 path "../../../../../../" + 1391 "rt-pol:policy-definitions/" + 1392 "rt-pol:policy-definition/rt-pol:name"; 1393 require-instance true; 1394 } 1395 description 1396 "Applies the statements from the specified policy 1397 definition and then returns control to the current 1398 policy statement. Note that the called policy 1399 may itself call other policies (subject to 1400 implementation limitations). This is intended to 1401 provide a policy 'subroutine' capability. The 1402 called policy SHOULD contain an explicit or a 1403 default route disposition that returns an 1404 effective true (accept-route) or false 1405 (reject-route), otherwise the behavior may be 1406 ambiguous."; 1407 } 1409 leaf source-protocol { 1410 type identityref { 1411 base rt:control-plane-protocol; 1412 } 1413 description 1414 "Condition to check the protocol / method used to 1415 install the route into the local routing table."; 1416 } 1418 uses match-interface-condition; 1419 uses prefix-set-condition; 1420 uses neighbor-set-condition; 1421 uses tag-set-condition; 1422 uses match-route-type-condition; 1423 } 1425 container actions { 1426 description 1427 "Top-level container for policy action 1428 statements."; 1429 leaf policy-result { 1430 type policy-result-type; 1431 default reject-route; 1432 description 1433 "Select the final disposition for the route, 1434 either accept or reject."; 1435 } 1436 container set-metric { 1437 leaf metric-modification { 1438 type metric-modification-type; 1439 description 1440 "Indicates how to modify the metric."; 1441 } 1442 leaf metric { 1443 type uint32; 1444 description 1445 "Metric value to set, add, or subtract."; 1446 } 1447 description 1448 "Set the metric for the route."; 1449 } 1450 container set-metric-type { 1451 leaf metric-type { 1452 type identityref { 1453 base metric-type; 1454 } 1455 description 1456 "Route metric type."; 1457 } 1458 description 1459 "Set the metric type for the route."; 1460 } 1461 container set-route-level { 1462 leaf route-level { 1463 type identityref { 1464 base route-level; 1465 } 1466 description 1467 "Route import level."; 1468 } 1469 description 1470 "Set the level for importation or 1471 exportation of routes."; 1472 } 1473 leaf set-route-preference { 1474 type uint16; 1475 description 1476 "Set the preference for the route. It is also 1477 known as 'administrative distance', allows for 1478 selecting the preferred route among routes with 1479 the same destination prefix. A smaller value is 1480 more preferred."; 1482 } 1483 leaf set-tag { 1484 type tag-type; 1485 description 1486 "Set the tag for the route."; 1487 } 1488 leaf set-application-tag { 1489 type tag-type; 1490 description 1491 "Set the application tag for the route. 1492 The application-specific tag is an additional tag 1493 that can be used by applications that require 1494 semantics and/or policy different from that of the 1495 tag. For example, the tag is usually automatically 1496 advertised in OSPF AS-External Link State 1497 Advertisements (LSAs) while this application-specific 1498 tag is not advertised implicitly."; 1499 } 1500 } 1501 } 1502 } 1503 } 1504 } 1505 } 1506 } 1507 1509 8. Security Considerations 1511 The YANG module specified in this document defines a schema for data 1512 that is designed to be accessed via network management protocols such 1513 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1514 is the secure transport layer, and the mandatory-to-implement secure 1515 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1516 is HTTPS, and the mandatory-to-implement secure transport is TLS 1517 [RFC8446]. 1519 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 1520 to restrict access for particular NETCONF or RESTCONF users to a pre- 1521 configured subset of all available NETCONF or RESTCONF protocol 1522 operations and content. 1524 There are a number of data nodes defined in this YANG module that are 1525 writable/creatable/deletable (i.e., config true, which is the 1526 default). These data nodes may be considered sensitive or vulnerable 1527 in some network environments. Write operations (e.g., edit-config) 1528 to these data nodes without proper protection can have a negative 1529 effect on network operations. These are the subtrees and data nodes 1530 and their sensitivity/vulnerability: 1532 /routing-policy 1534 /routing-policy/defined-sets/prefix-sets -- Modification to 1535 prefix-sets could result in a Denial-of-Service (DoS) attack. An 1536 attacker may try to modify prefix-sets and redirect or drop 1537 traffic. Redirection of traffic could be used as part of a more 1538 elaborate attack to either collect sensitive information or 1539 masquerade a service. Additionally, a control-plane DoS attack 1540 could be accomplished by allowing a large number of routes to be 1541 leaked into a routing protocol domian (e.g., BGP). 1543 /routing-policy/defined-sets/neighbor-sets -- Modification to the 1544 neighbor-sets could be used to mount a DoS attack or more 1545 elaborate attack as with prefix-sets. For example, a DoS attack 1546 could be mounted by changing the neighbor-set from which routes 1547 are accepted. 1549 /routing-policy/defined-sets/tag-sets -- Modification to the tag- 1550 sets could be used to mount a DoS attack. Routes with certain 1551 tags might be redirected or dropped. The implications are similar 1552 to prefix-sets and neighbor-sets. However, the attack may be more 1553 difficult to detect as the routing policy usage of route tags and 1554 intent must be understood to recognize the breach. Conversely, 1555 the implications of prefix-set or neighbor set modification are 1556 easier to recognize. 1558 /routing-policy/policy-definitions 1560 /routing-policy/policy-definitions/policy-definition 1561 /statements/statement/conditions -- Modification to the conditions 1562 could be used to mount a DoS attack or other attack. An attacker 1563 may change a policy condition and redirect or drop traffic. As 1564 with prefix-sets, neighbor-sets, or tag-sets, traffic redirection 1565 could be used as part of a more elaborate attack. 1567 /routing-policy/policy-definitions/policy-definition 1568 /statements/statement/actions -- Modification to actions could be 1569 used to mount a DoS attack or other attack. Traffic may be 1570 redirected or dropped. As with prefix-sets, neighbor-sets, or 1571 tag-sets, traffic redirection could be used as part of a more 1572 elaborate attack. Additionally, route attributes may be changed 1573 to mount a second-level attack that is more difficult to detect. 1575 Some of the readable data nodes in the YANG module may be considered 1576 sensitive or vulnerable in some network environments. It is thus 1577 important to control read access (e.g., via get, get-config, or 1578 notification) to these data nodes. These are the subtrees and data 1579 nodes and their sensitivity/vulnerability: 1581 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1582 data nodes can be used to ascertain which local prefixes are 1583 suspectable to a Denial-of-Service (DoS) attack. 1585 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1586 data nodes can be used to ascertain local neighbors against whom 1587 to mount a Denial-of-Service (DoS) attack. 1589 /routing-policy/policy-definitions/policy-definition /statements/ 1590 -- Knowledge of these data nodes can be used to attack the local 1591 router with a Denial-of-Service (DoS) attack. Additionally, 1592 policies and their attendant conditions and actions should be 1593 considered proprietary and disclosure could be used to ascertain 1594 partners, customers, and supplies. Furthermore, the policies 1595 themselves could represent intellectual property and disclosure 1596 could diminish their corresponding business advantage. 1598 Routing policy configuration has a significant impact on network 1599 operations, and, as such, any related model carries potential 1600 security risks. Unauthorized access or invalid data could cause 1601 major disruption. 1603 9. IANA Considerations 1605 This document registers a URI in the IETF XML registry [RFC3688]. 1606 Following the format in [RFC3688], the following registration is 1607 requested to be made: 1609 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1610 Registrant Contact: The IESG. 1611 XML: N/A, the requested URI is an XML namespace. 1613 This document registers a YANG module in the YANG Module Names 1614 registry [RFC6020]. 1616 name: ietf-routing-policy 1617 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1618 prefix: rt-pol 1619 reference: RFC XXXX 1621 10. Acknowledgements 1623 The routing policy module defined in this document is based on the 1624 OpenConfig route policy model. The authors would like to thank to 1625 OpenConfig for their contributions, especially Anees Shaikh, Rob 1626 Shakir, Kevin D'Souza, and Chris Chase. 1628 The authors are grateful for valuable contributions to this document 1629 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1630 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1631 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1632 John Heasley. 1634 Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom 1635 Petch for their reviews and comments. 1637 11. References 1639 11.1. Normative references 1641 [INTF-EXT-YANG] 1642 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1643 Sivaraj,, "Common Interface Extension YANG Data Models", 1644 2019, . 1647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1648 Requirement Levels", BCP 14, RFC 2119, 1649 DOI 10.17487/RFC2119, March 1997, 1650 . 1652 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1653 DOI 10.17487/RFC2328, April 1998, 1654 . 1656 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1657 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1658 . 1660 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1661 DOI 10.17487/RFC3688, January 2004, 1662 . 1664 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1665 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1666 DOI 10.17487/RFC4271, January 2006, 1667 . 1669 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1670 Control Mechanism in IS-IS Using Administrative Tags", 1671 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1672 . 1674 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1675 Distribution with Two-Level IS-IS", RFC 5302, 1676 DOI 10.17487/RFC5302, October 2008, 1677 . 1679 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1680 the Network Configuration Protocol (NETCONF)", RFC 6020, 1681 DOI 10.17487/RFC6020, October 2010, 1682 . 1684 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1685 and A. Bierman, Ed., "Network Configuration Protocol 1686 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1687 . 1689 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1690 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1691 . 1693 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1694 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1695 . 1697 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1698 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1699 . 1701 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1702 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1703 . 1705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1707 May 2017, . 1709 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1710 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1711 . 1713 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1714 Access Control Model", STD 91, RFC 8341, 1715 DOI 10.17487/RFC8341, March 2018, 1716 . 1718 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1719 and R. Wilton, "Network Management Datastore Architecture 1720 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1721 . 1723 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1724 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1725 . 1727 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1728 Routing Management (NMDA Version)", RFC 8349, 1729 DOI 10.17487/RFC8349, March 2018, 1730 . 1732 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1733 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1734 . 1736 [SUB-INTF-VLAN-YANG] 1737 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1738 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1739 . 1742 11.2. Informative references 1744 [I-D.ietf-idr-bgp-model] 1745 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1746 YANG Model for Service Provider Networks", draft-ietf-idr- 1747 bgp-model-10 (work in progress), November 2020. 1749 Appendix A. Routing protocol-specific policies 1751 Routing models that require the ability to apply routing policy may 1752 augment the routing policy model with protocol or other specific 1753 policy configuration. The routing policy model assumes that 1754 additional defined sets, conditions, and actions may all be added by 1755 other models. 1757 The example below provides an illustration of how another data model 1758 can augment parts of this routing policy data model. It uses 1759 specific examples from draft-ietf-idr-bgp-model-09 to show in a 1760 concrete manner how the different pieces fit together. This example 1761 is not normative with respect to [I-D.ietf-idr-bgp-model]. The model 1762 similarly augments BGP-specific conditions and actions in the 1763 corresponding sections of the routing policy model. In the example 1764 below, the XPath prefix "bp:" specifies import from the ietf-bgp- 1765 policy sub-module and the XPath prefix "bt:" specifies import from 1766 the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model]. 1768 module: ietf-routing-policy 1769 +--rw routing-policy 1770 +--rw defined-sets 1771 | +--rw prefix-sets 1772 | | +--rw prefix-set* [name] 1773 | | +--rw name string 1774 | | +--rw mode? enumeration 1775 | | +--rw prefixes 1776 | | +--rw prefix-list* [ip-prefix mask-length-lower 1777 | | mask-length-upper] 1778 | | +--rw ip-prefix inet:ip-prefix 1779 | | +--rw mask-length-lower uint8 1780 | | +--rw mask-length-upper uint8 1781 | +--rw neighbor-sets 1782 | | +--rw neighbor-set* [name] 1783 | | +--rw name string 1784 | | +--rw address* inet:ip-address 1785 | +--rw tag-sets 1786 | | +--rw tag-set* [name] 1787 | | +--rw name string 1788 | | +--rw tag-value* tag-type 1789 | +--rw bp:bgp-defined-sets 1790 | +--rw bp:community-sets 1791 | | +--rw bp:community-set* [name] 1792 | | +--rw bp:name string 1793 | | +--rw bp:member* union 1794 | +--rw bp:ext-community-sets 1795 | | +--rw bp:ext-community-set* [name] 1796 | | +--rw bp:name string 1797 | | +--rw bp:member* union 1798 | +--rw bp:as-path-sets 1799 | +--rw bp:as-path-set* [name] 1800 | +--rw bp:name string 1801 | +--rw bp:member* string 1802 +--rw policy-definitions 1803 +--rw policy-definition* [name] 1804 +--rw name string 1805 +--rw statements 1806 +--rw statement* [name] 1807 +--rw name string 1808 +--rw conditions 1809 | +--rw call-policy? 1810 | +--rw source-protocol? identityref 1811 | +--rw match-interface 1812 | | +--rw interface? 1813 | +--rw match-prefix-set 1814 | | +--rw prefix-set? prefix-set/name 1815 | | +--rw match-set-options? match-set-options-type 1816 | +--rw match-neighbor-set 1817 | | +--rw neighbor-set? 1818 | +--rw match-tag-set 1819 | | +--rw tag-set? 1820 | | +--rw match-set-options? match-set-options-type 1821 | +--rw match-route-type* identityref 1822 | +--rw bp:bgp-conditions 1823 | +--rw bp:med-eq? uint32 1824 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 1825 | +--rw bp:next-hop-in* inet:ip-address-no-zone 1826 | +--rw bp:afi-safi-in* identityref 1827 | +--rw bp:local-pref-eq? uint32 1828 | +--rw bp:route-type? enumeration 1829 | +--rw bp:community-count 1830 | +--rw bp:as-path-length 1831 | +--rw bp:match-community-set 1832 | | +--rw bp:community-set? 1833 | | +--rw bp:match-set-options? 1834 | +--rw bp:match-ext-community-set 1835 | | +--rw bp:ext-community-set? 1836 | | +--rw bp:match-set-options? 1837 | +--rw bp:match-as-path-set 1838 | +--rw bp:as-path-set? 1839 | +--rw bp:match-set-options? 1840 +--rw actions 1841 +--rw policy-result? policy-result-type 1842 +--rw set-metric 1843 | +--rw metric-modification? 1844 | +--rw metric? uint32 1845 +--rw set-metric-type 1846 | +--rw metric-type? identityref 1847 +--rw set-route-level 1848 | +--rw route-level? identityref 1849 +--rw set-route-preference? uint16 1850 +--rw set-tag? tag-type 1851 +--rw set-application-tag? tag-type 1852 +--rw bp:bgp-actions 1853 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 1854 +--rw bp:set-local-pref? uint32 1855 +--rw bp:set-next-hop? bgp-next-hop-type 1856 +--rw bp:set-med? bgp-set-med-type 1857 +--rw bp:set-as-path-prepend 1858 | +--rw bp:repeat-n? uint8 1859 +--rw bp:set-community 1860 | +--rw bp:method? enumeration 1861 | +--rw bp:options? 1862 | +--rw bp:inline 1863 | | +--rw bp:communities* union 1864 | +--rw bp:reference 1865 | +--rw bp:community-set-ref? 1866 +--rw bp:set-ext-community 1867 +--rw bp:method? enumeration 1868 +--rw bp:options? 1869 +--rw bp:inline 1870 | +--rw bp:communities* union 1871 +--rw bp:reference 1872 +--rw bp:ext-community-set-ref? 1874 Appendix B. Policy examples 1876 Below we show examples of XML-encoded configuration data using the 1877 routing policy and BGP models to illustrate both how policies are 1878 defined, and how they can be applied. Note that the XML has been 1879 simplified for readability. 1881 The following example shows how prefix-set and tag-set can be 1882 defined. The policy condition is to match a prefix-set and a tag- 1883 set, and the action is to accept routes that match the condition. 1885 1886 1889 1890 1891 1892 prefix-set-A 1893 ipv4 1894 1895 1896 192.0.2.0/24 1897 24 1898 32 1899 1900 1901 198.51.100.0/24 1902 24 1903 32 1904 1905 1906 1907 1908 prefix-set-B 1909 ipv6 1910 1911 1912 2001:DB8::/32 1913 32 1914 64 1915 1916 1917 1918 1919 1920 1921 cust-tag1 1922 10 1923 1924 1925 1927 1928 1929 export-tagged-BGP 1930 1931 1932 term-0 1933 1934 1935 prefix-set-A 1936 1937 1938 cust-tag1 1939 1940 1941 1942 accept-route 1943 1944 1945 1946 1947 1949 1950 1952 In the following example, all routes in the RIB that have been 1953 learned from OSPF advertisements corresponding to OSPF intra-area and 1954 inter-area route types should get advertised into ISIS level-2 1955 advertisements. 1957 1958 1960 1961 1962 export-all-OSPF-prefixes-into-ISIS-level-2 1963 1964 1965 term-0 1966 1967 ospf-internal-type 1968 1969 1970 1971 isis-level-2 1972 1973 accept-route 1974 1975 1976 1977 1978 1979 1980 1982 Authors' Addresses 1984 Yingzhen Qu 1985 Futurewei 1986 2330 Central Expressway 1987 Santa Clara CA 95050 1988 USA 1990 Email: yingzhen.qu@futurewei.com 1992 Jeff Tantsura 1993 Juniper Networks 1995 Email: jefftant.ietf@gmail.com 1996 Acee Lindem 1997 Cisco 1998 301 Midenhall Way 1999 Cary, NC 27513 2000 US 2002 Email: acee@cisco.com 2004 Xufeng Liu 2005 Volta Networks 2007 Email: xufeng.liu.ietf@gmail.com