idnits 2.17.1 draft-ietf-rtgwg-policy-model-28.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 493 has weird spacing: '...h-lower uin...' == Line 494 has weird spacing: '...h-upper uin...' == Line 956 has weird spacing: '... enum add-m...' == (3 more instances...) -- The document date (June 7, 2021) is 1053 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 9, 2021 Juniper Networks 6 A. Lindem 7 Cisco 8 X. Liu 9 Volta Networks 10 June 7, 2021 12 A YANG Data Model for Routing Policy 13 draft-ietf-rtgwg-policy-model-28 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 9, 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 . . . . . . . . . . . . . . . . . . . 33 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 76 11.1. Normative references . . . . . . . . . . . . . . . . . . 36 77 11.2. Informative references . . . . . . . . . . . . . . . . . 38 78 Appendix A. Routing protocol-specific policies . . . . . . . . . 38 79 Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 41 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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 subinterface? 350 | +--rw match-prefix-set 351 | | +--rw prefix-set? 352 | | +--rw match-set-options? 353 | +--rw match-neighbor-set 354 | | +--rw neighbor-set? 355 | +--rw match-tag-set 356 | | +--rw tag-set? 357 | | +--rw match-set-options? 358 | +--rw match-route-type* identityref 360 4.3. Policy actions 362 When policy conditions are satisfied, policy actions are used to set 363 various attributes of the route being processed, or to indicate the 364 final disposition of the route, i.e., accept or reject. 366 Similar to policy conditions, the routing policy model includes 367 generic actions in addition to the basic route disposition actions. 368 These are shown below. 370 +--rw routing-policy 371 +--rw policy-definitions 372 +--rw policy-definition* [name] 373 +--rw statements 374 +--rw statement* [name] 375 +--rw actions 376 +--rw policy-result? policy-result-type 377 +--rw set-metric 378 | +--rw metric-modification? 379 | | metric-modification-type 380 | +--rw metric? uint32 381 +--rw set-metric-type 382 | +--rw metric-type? identityref 383 +--rw set-route-level 384 | +--rw route-level? identityref 385 +--rw set-preference? uint16 386 +--rw set-tag? tag-type 387 +--rw set-application-tag? tag-type 389 4.4. Policy subroutines 391 Policy 'subroutines' (or nested policies) are supported by allowing 392 policy statement conditions to reference other policy definitions 393 using the call-policy configuration. Called policies apply their 394 conditions and actions before returning to the calling policy 395 statement and resuming evaluation. The outcome of the called policy 396 affects the evaluation of the calling policy. If the called policy 397 results in an accept-route, then the subroutine returns an effective 398 Boolean true value to the calling policy. For the calling policy, 399 this is equivalent to a condition statement evaluating to a true 400 value and evaluation of the policy continues (see Section 5). Note 401 that the called policy may also modify attributes of the route in its 402 action statements. Similarly, a reject-route action returns false 403 and the calling policy evaluation will be affected accordingly. When 404 the end of the subroutine policy statements is reached, the default 405 route disposition action is returned (i.e., Boolean false for reject- 406 route). Consequently, a subroutine cannot explicitly accept or 407 reject a route. Rather, the called policy returns Boolean true if 408 its outcome is accept-route or Boolean false if its outcome is 409 reject-route. Route acceptance or rejection is solely determined by 410 the top-level policy. 412 Note that the called policy may itself call other policies (subject 413 to implementation limitations). The model does not prescribe a 414 nesting depth because this varies among implementations. For 415 example, an implementation may only support a single level of 416 subroutine recursion. As with any routing policy construction, care 417 must be taken with nested policies to ensure that the effective 418 return value results in the intended behavior. Nested policies are a 419 convenience in many routing policy constructions but creating 420 policies nested beyond a small number of levels (e.g., 2-3) is 421 discouraged. Also, implementations MUST validate to ensure that 422 there is no recursion amongst nested routing policies. 424 5. Policy evaluation 426 Evaluation of each policy definition proceeds by evaluating its 427 individual policy statements in order that they are defined. When 428 all the condition statements in a policy statement are satisfied, the 429 corresponding action statements are executed. If the actions include 430 either accept-route or reject-route actions, evaluation of the 431 current policy definition stops, and no further policy statement is 432 evaluated. If there are multiple policies in the policy chain, 433 subsequent policies are not evaluated. Policy chains are sequences 434 of policy definitions (as described in . (Section 4)). 436 If the conditions are not satisfied, then evaluation proceeds to the 437 next policy statement. If none of the policy statement conditions 438 are satisfied, then evaluation of the current policy definition 439 stops, and the next policy definition in the chain is evaluated. 440 When the end of the policy chain is reached, the default route 441 disposition action is performed (i.e., reject-route unless an 442 alternate default action is specified for the chain). 444 Note that the route's pre-policy attributes are always used for 445 testing policy statement conditions. In other words, if actions 446 modify the policy application-specific attributes, those 447 modifications are not used for policy statement conditions. 449 6. Applying routing policy 451 Routing policy is applied by defining and attaching policy chains in 452 various routing contexts. Policy chains are sequences of policy 453 definitions (described in Section 4). They can be referenced from 454 different contexts. For example, a policy chain could be associated 455 with a routing protocol and used to control its interaction with its 456 protocol peers. Or it could be used to control the interaction 457 between a routing protocol and the local routing information base. A 458 policy chain has an associated direction (import or export), with 459 respect to the context in which it is referenced. 461 The routing policy model defines an apply-policy grouping that can be 462 imported and used by other models. As shown below, it allows 463 definition of import and export policy chains, as well as specifying 464 the default route disposition to be used when no policy definition in 465 the chain results in a final decision. 467 +--rw apply-policy 468 | +--rw import-policy* 469 | +--rw default-import-policy? default-policy-type 470 | +--rw export-policy* 471 | +--rw default-export-policy? default-policy-type 473 The default policy defined by the model is to reject the route for 474 both import and export policies. 476 7. YANG Module and Tree 478 7.1. Routing Policy Model Tree 480 The tree of the routing policy model is shown below. 482 module: ietf-routing-policy 483 rw routing-policy 484 +--rw defined-sets 485 | +--rw prefix-sets 486 | | +--rw prefix-set* [name mode] 487 | | +--rw name string 488 | | +--rw mode enumeration 489 | | +--rw prefixes 490 | | +--rw prefix-list* [ip-prefix mask-length-lower 491 | | mask-length-upper] 492 | | +--rw ip-prefix inet:ip-prefix 493 | | +--rw mask-length-lower uint8 494 | | +--rw mask-length-upper uint8 495 | +--rw neighbor-sets 496 | | +--rw neighbor-set* [name] 497 | | +--rw name string 498 | | +--rw address* inet:ip-address 499 | +--rw tag-sets 500 | +--rw tag-set* [name] 501 | +--rw name string 502 | +--rw tag-value* tag-type 503 +--rw policy-definitions 504 +--rw policy-definition* [name] 505 +--rw name string 506 +--rw statements 507 +--rw statement* [name] 508 +--rw name string 509 +--rw conditions 510 | +--rw call-policy? -> ../../../../../.. 511 | /policy-definitions 512 | /policy-definition/name 513 | +--rw source-protocol? identityref 514 | +--rw match-interface 515 | | +--rw interface? -> /if:interfaces/interface 516 | | /name 517 | | +--rw subinterface? -> /if:interfaces/interface 518 | | /if-ext:encapsulation 519 | | /if-flex:flexible/match 520 | | /dot1q-vlan-tagged 521 | | /outer-tag/vlan-id 522 | +--rw match-prefix-set 523 | | +--rw prefix-set? -> ../../../../../../.. 524 | | /defined-sets/prefix-sets 525 | | /prefix-set/name 526 | | +--rw match-set-options? match-set-options-type 527 | +--rw match-neighbor-set 528 | | +--rw neighbor-set? -> ../../../../../../.. 529 | | /defined-sets/neighbor-sets 530 | | /neighbor-set/name 531 | +--rw match-tag-set 532 | | +--rw tag-set? -> ../../../../../../.. 533 | | /defined-sets/tag-sets 534 | | /tag-set/name 535 | | +--rw match-set-options? match-set-options-type 536 | +--rw match-route-type* identityref 537 +--rw actions 538 +--rw policy-result? policy-result-type 539 +--rw set-metric 540 | +--rw metric-modification? metric-modification-type 541 | +--rw metric? uint32 542 +--rw set-metric-type 543 | +--rw metric-type? identityref 544 +--rw set-route-level 545 | +--rw route-level? identityref 546 +--rw set-preference? uint16 547 +--rw set-tag? tag-type 548 +--rw set-application-tag? tag-type 550 7.2. Routing policy model 552 The following RFCs are not referenced in the document text but are 553 referenced in the ietf-routing-policy.yang module: [RFC2328], 554 [RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343]. 556 file "ietf-routing-policy@2021-06-07.yang" 557 module ietf-routing-policy { 559 yang-version "1.1"; 561 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; 562 prefix rt-pol; 563 import ietf-inet-types { 564 prefix "inet"; 565 reference "RFC 6991: Common YANG Data Types"; 566 } 568 import ietf-yang-types { 569 prefix "yang"; 570 reference "RFC 6991: Common YANG Data Types"; 571 } 573 import ietf-interfaces { 574 prefix "if"; 575 reference "RFC 8343: A YANG Data Model for Interface 576 Management (NMDA Version)"; 577 } 579 import ietf-routing { 580 prefix "rt"; 581 reference "RFC 8349: A YANG Data Model for Routing 582 Management (NMDA Version)"; 583 } 585 import ietf-if-extensions { 586 prefix "if-ext"; 587 reference "RFC YYYY: Common Interface Extension YANG 588 Data Models. Please replace YYYY with 589 published RFC number for 590 draft-ietf-netmod-intf-ext-yang."; 591 } 593 import ietf-if-flexible-encapsulation { 594 prefix "if-flex"; 595 reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models. 596 Please replace ZZZZ with published RFC number 597 for draft-ietf-netmod-sub-intf-vlan-model."; 598 } 600 organization 601 "IETF RTGWG - Routing Area Working Group"; 602 contact 603 "WG Web: 604 WG List: 606 Editor: Yingzhen Qu 607 608 Jeff Tantsura 609 610 Acee Lindem 611 612 Xufeng Liu 613 "; 615 description 616 "This module describes a YANG model for routing policy 617 configuration. It is a limited subset of all of the policy 618 configuration parameters available in the variety of vendor 619 implementations, but supports widely used constructs for 620 managing how routes are imported, exported, modified and 621 advertised across different routing protocol instances or 622 within a single routing protocol instance. This module is 623 intended to be used in conjunction with routing protocol 624 configuration modules (e.g., BGP) defined in other models. 626 This YANG module conforms to the Network Management 627 Datastore Architecture (NMDA), as described in RFC 8342. 629 Copyright (c) 2021 IETF Trust and the persons identified as 630 authors of the code. All rights reserved. 632 Redistribution and use in source and binary forms, with or 633 without modification, is permitted pursuant to, and subject to 634 the license terms contained in, the Simplified BSD License set 635 forth in Section 4.c of the IETF Trust's Legal Provisions 636 Relating to IETF Documents 637 (https://trustee.ietf.org/license-info). 639 This version of this YANG module is part of RFC XXXX; 640 see the RFC itself for full legal notices. 642 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 643 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT 644 RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 645 interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, 646 and only when, they appear in all capitals, as shown here."; 648 reference "RFC XXXX: A YANG Data Model for Routing Policy."; 650 revision "2021-06-07" { 651 description 652 "Initial revision."; 653 reference 654 "RFC XXXX: A YANG Data Model for Routing Policy Management."; 655 } 657 /* Identities */ 658 identity metric-type { 659 description 660 "Base identity for route metric types."; 661 } 663 identity ospf-type-1-metric { 664 base metric-type; 665 description 666 "Identity for the OSPF type 1 external metric types. It 667 is only applicable to OSPF routes."; 668 reference 669 "RFC 2328 - OSPF Version 2"; 670 } 672 identity ospf-type-2-metric { 673 base metric-type; 674 description 675 "Identity for the OSPF type 2 external metric types. It 676 is only applicable to OSPF routes."; 677 reference 678 "RFC 2328 - OSPF Version 2"; 679 } 681 identity isis-internal-metric { 682 base metric-type; 683 description 684 "Identity for the IS-IS internal metric types. It is only 685 applicable to IS-IS routes."; 686 reference 687 "RFC 5302 - Domain-Wide Prefix Distribution with 688 Two-Level IS-IS"; 689 } 691 identity isis-external-metric { 692 base metric-type; 693 description 694 "Identity for the IS-IS external metric types. It is only 695 applicable to IS-IS routes."; 696 reference 697 "RFC 5302 - Domain-Wide Prefix Distribution with 698 Two-Level IS-IS"; 699 } 701 identity route-level { 702 description 703 "Base identity for route import level."; 704 } 705 identity ospf-normal { 706 base route-level; 707 description 708 "Identity for OSPF importation into normal areas 709 It is only applicable to routes imported 710 into the OSPF protocol."; 711 reference 712 "RFC 2328 - OSPF Version 2"; 713 } 715 identity ospf-nssa-only { 716 base route-level; 717 description 718 "Identity for the OSPF Not-So-Stubby Area (NSSA) area 719 importation. It is only applicable to routes imported 720 into the OSPF protocol."; 721 reference 722 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 723 } 725 identity ospf-normal-nssa { 726 base route-level; 727 description 728 "Identity for OSPF importation into both normal and NSSA 729 areas, it is only applicable to routes imported into 730 the OSPF protocol."; 731 reference 732 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 733 } 735 identity isis-level-1 { 736 base route-level; 737 description 738 "Identity for IS-IS Level 1 area importation. It is only 739 applicable to routes imported into the IS-IS protocol."; 740 reference 741 "RFC 5302 - Domain-Wide Prefix Distribution with 742 Two-Level IS-IS"; 743 } 745 identity isis-level-2 { 746 base route-level; 747 description 748 "Identity for IS-IS Level 2 area importation. It is only 749 applicable to routes imported into the IS-IS protocol."; 750 reference 751 "RFC 5302 - Domain-Wide Prefix Distribution with 752 Two-Level IS-IS"; 754 } 756 identity isis-level-1-2 { 757 base route-level; 758 description 759 "Identity for IS-IS Level 1 and Level 2 area importation. It 760 is only applicable to routes imported into the IS-IS 761 protocol."; 762 reference 763 "RFC 5302 - Domain-Wide Prefix Distribution with 764 Two-Level IS-IS"; 765 } 767 identity proto-route-type { 768 description 769 "Base identity for route type within a protocol."; 770 } 772 identity isis-level-1-type { 773 base proto-route-type; 774 description 775 "Identity for IS-IS Level 1 route type. It is only 776 applicable to IS-IS routes."; 777 reference 778 "RFC 5302 - Domain-Wide Prefix Distribution with 779 Two-Level IS-IS"; 780 } 782 identity isis-level-2-type { 783 base proto-route-type; 784 description 785 "Identity for IS-IS Level 2 route type. It is only 786 applicable to IS-IS routes."; 787 reference 788 "RFC 5302 - Domain-Wide Prefix Distribution with 789 Two-Level IS-IS"; 790 } 792 identity ospf-internal-type { 793 base proto-route-type; 794 description 795 "Identity for OSPF intra-area or inter-area route type. 796 It is only applicable to OSPF routes."; 797 reference 798 "RFC 2328 - OSPF Version 2"; 799 } 801 identity ospf-external-type { 802 base proto-route-type; 803 description 804 "Identity for OSPF external type 1/2 route type. 805 It is only applicable to OSPF routes."; 806 reference 807 "RFC 2328 - OSPF Version 2"; 808 } 810 identity ospf-external-t1-type { 811 base ospf-external-type; 812 description 813 "Identity for OSPF external type 1 route type. 814 It is only applicable to OSPF routes."; 815 reference 816 "RFC 2328 - OSPF Version 2"; 817 } 819 identity ospf-external-t2-type { 820 base ospf-external-type; 821 description 822 "Identity for OSPF external type 2 route type. 823 It is only applicable to OSPF routes."; 824 reference 825 "RFC 2328 - OSPF Version 2"; 826 } 828 identity ospf-nssa-type { 829 base proto-route-type; 830 description 831 "Identity for OSPF NSSA type 1/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 ospf-nssa-t1-type { 838 base ospf-nssa-type; 839 description 840 "Identity for OSPF NSSA type 1 route type. 841 It is only applicable to OSPF routes."; 842 reference 843 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 844 } 846 identity ospf-nssa-t2-type { 847 base ospf-nssa-type; 848 description 849 "Identity for OSPF NSSA type 2 route type. 851 It is only applicable to OSPF routes."; 852 reference 853 "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; 854 } 856 identity bgp-internal { 857 base proto-route-type; 858 description 859 "Identity for routes learned from internal BGP (IBGP). 860 It is only applicable to BGP routes."; 861 reference 862 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 863 } 865 identity bgp-external { 866 base proto-route-type; 867 description 868 "Identity for routes learned from external BGP (EBGP). 869 It is only applicable to BGP routes."; 870 reference 871 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 872 } 874 /* Type Definitions */ 876 typedef default-policy-type { 877 type enumeration { 878 enum accept-route { 879 description 880 "Default policy to accept the route."; 881 } 882 enum reject-route { 883 description 884 "Default policy to reject the route."; 885 } 886 } 887 description 888 "Type used to specify route disposition in 889 a policy chain. This typedef is used in 890 the default import and export policy."; 891 } 893 typedef policy-result-type { 894 type enumeration { 895 enum accept-route { 896 description 897 "Policy accepts the route."; 898 } 899 enum reject-route { 900 description 901 "Policy rejects the route."; 902 } 903 } 904 description 905 "Type used to specify route disposition in 906 a policy chain."; 907 } 909 typedef tag-type { 910 type union { 911 type uint32; 912 type yang:hex-string; 913 } 914 description 915 "Type for expressing route tags on a local system, 916 including IS-IS and OSPF; may be expressed as either decimal 917 or hexadecimal integer."; 918 reference 919 "RFC 2328 - OSPF Version 2 920 RFC 5130 - A Policy Control Mechanism in IS-IS Using 921 Administrative Tags"; 922 } 924 typedef match-set-options-type { 925 type enumeration { 926 enum any { 927 description 928 "Match is true if given value matches any member 929 of the defined set."; 930 } 931 enum all { 932 description 933 "Match is true if given value matches all 934 members of the defined set."; 935 } 936 enum invert { 937 description 938 "Match is true if given value does not match any 939 member of the defined set."; 940 } 941 } 942 default any; 943 description 944 "Options that govern the behavior of a match statement. The 945 default behavior is any, i.e., the given value matches any 946 of the members of the defined set."; 948 } 950 typedef metric-modification-type { 951 type enumeration { 952 enum set-metric { 953 description 954 "Set the metric to the specified value."; 955 } 956 enum add-metric { 957 description 958 "Add the specified value to the existing metric. 959 If the result would overflow the maximum metric 960 (0xffffffff), set the metric to the maximum."; 961 } 962 enum subtract-metric { 963 description 964 "Subtract the specified value from the existing metric. If 965 the result would be less than 0, set the metric to 0."; 966 } 967 } 968 description 969 "Type used to specify how to set the metric given the 970 specified value."; 971 } 973 /* Groupings */ 975 grouping prefix { 976 description 977 "Configuration data for a prefix definition. 979 The combination of mask-length-lower and mask-length-upper 980 define a range for the mask length, or single 'exact' 981 length if mask-length-lower and mask-length-upper are 982 equal. 984 Example: 192.0.2.0/24 through 192.0.2.0/26 would be 985 expressed as prefix: 192.0.2.0/24, 986 mask-length-lower=24, 987 mask-length-upper=26 989 Example: 192.0.2.0/24 (an exact match) would be 990 expressed as prefix: 192.0.2.0/24, 991 mask-length-lower=24, 992 mask-length-upper=24 994 Example: 2001:DB8::/32 through 2001:DB8::/64 would be 995 expressed as prefix: 2001:DB8::/32, 996 mask-length-lower=32, 997 mask-length-upper=64"; 999 leaf ip-prefix { 1000 type inet:ip-prefix; 1001 mandatory true; 1002 description 1003 "The IP prefix represented as an IPv6 or IPv4 network 1004 number followed by a prefix length with an intervening 1005 slash character as a delimiter. All members of the 1006 prefix-set MUST be of the same address family as the 1007 prefix-set mode."; 1008 } 1010 leaf mask-length-lower { 1011 type uint8 { 1012 range "0..128"; 1013 } 1014 description 1015 "Mask length range lower bound. It MUST NOT be less than 1016 the prefix length defined in ip-prefix."; 1017 } 1018 leaf mask-length-upper { 1019 type uint8 { 1020 range "1..128"; 1021 } 1022 must "../mask-length-upper >= ../mask-length-lower" { 1023 error-message "The upper bound MUST NOT be less" 1024 + "than lower bound."; 1025 } 1026 description 1027 "Mask length range upper bound. It MUST NOT be less than 1028 lower bound."; 1029 } 1030 } 1032 grouping match-set-options-group { 1033 description 1034 "Grouping containing options relating to how a particular set 1035 will be matched."; 1037 leaf match-set-options { 1038 type match-set-options-type; 1039 description 1040 "Optional parameter that governs the behavior of the 1041 match operation."; 1042 } 1043 } 1044 grouping match-set-options-restricted-group { 1045 description 1046 "Grouping for a restricted set of match operation 1047 modifiers."; 1049 leaf match-set-options { 1050 type match-set-options-type { 1051 enum any { 1052 description 1053 "Match is true if given value matches any 1054 member of the defined set."; 1055 } 1056 enum invert { 1057 description 1058 "Match is true if given value does not match 1059 any member of the defined set."; 1060 } 1061 } 1062 description 1063 "Optional parameter that governs the behavior of the 1064 match operation. This leaf only supports matching on 1065 'any' member of the set or 'invert' the match. 1066 Matching on 'all' is not supported."; 1067 } 1068 } 1070 grouping match-interface-condition { 1071 description 1072 "This grouping provides interface match condition."; 1074 container match-interface { 1075 leaf interface { 1076 type leafref { 1077 path "/if:interfaces/if:interface/if:name"; 1078 } 1079 description 1080 "Reference to a base interface. If a reference to a 1081 subinterface is required, this leaf MUST be specified 1082 to indicate the base interface."; 1083 } 1084 leaf subinterface { 1085 type leafref { 1086 path "/if:interfaces/if:interface/if-ext:encapsulation" 1087 + "/if-flex:flexible/if-flex:match" 1088 + "/if-flex:dot1q-vlan-tagged" 1089 + "/if-flex:outer-tag/if-flex:vlan-id"; 1090 } 1091 description 1092 "Reference to a subinterface -- this requires the base 1093 interface to be specified using the interface leaf in 1094 this container. If only a reference to a base interface 1095 is required, this leaf MUST NOT be set."; 1096 } 1098 description 1099 "Container for interface match conditions"; 1100 } 1101 } 1103 grouping match-route-type-condition { 1104 description 1105 "This grouping provides route-type match condition"; 1107 leaf-list match-route-type { 1108 type identityref { 1109 base proto-route-type; 1110 } 1111 description 1112 "Condition to check the protocol-specific type 1113 of route. This is normally used during route 1114 importation to select routes or to set protocol 1115 specific attributes based on the route type."; 1116 } 1117 } 1119 grouping prefix-set-condition { 1120 description 1121 "This grouping provides prefix-set conditions."; 1123 container match-prefix-set { 1124 leaf prefix-set { 1125 type leafref { 1126 path "../../../../../../../defined-sets/" + 1127 "prefix-sets/prefix-set/name"; 1128 } 1129 description 1130 "References a defined prefix set."; 1131 } 1132 uses match-set-options-restricted-group; 1134 description 1135 "Match a referenced prefix-set according to the logic 1136 defined in the match-set-options leaf."; 1137 } 1138 } 1139 grouping neighbor-set-condition { 1140 description 1141 "This grouping provides neighbor-set conditions."; 1143 container match-neighbor-set { 1144 leaf neighbor-set { 1145 type leafref { 1146 path "../../../../../../../defined-sets/neighbor-sets/" + 1147 "neighbor-set/name"; 1148 require-instance true; 1149 } 1150 description 1151 "References a defined neighbor set."; 1152 } 1154 description 1155 "Match a referenced neighbor set according to the logic 1156 defined in the match-set-options-leaf."; 1157 } 1158 } 1160 grouping tag-set-condition { 1161 description 1162 "This grouping provides tag-set conditions."; 1164 container match-tag-set { 1165 leaf tag-set { 1166 type leafref { 1167 path "../../../../../../../defined-sets/tag-sets" + 1168 "/tag-set/name"; 1169 require-instance true; 1170 } 1171 description 1172 "References a defined tag set."; 1173 } 1174 uses match-set-options-group; 1176 description 1177 "Match a referenced tag set according to the logic defined 1178 in the match-options-set leaf."; 1179 } 1180 } 1182 grouping apply-policy-import { 1183 description 1184 "Grouping for applying import policies."; 1186 leaf-list import-policy { 1187 type leafref { 1188 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1189 "rt-pol:policy-definition/rt-pol:name"; 1190 require-instance true; 1191 } 1192 ordered-by user; 1193 description 1194 "List of policy names in sequence to be applied on 1195 receiving redistributed routes from another routing protocol 1196 or receiving a routing update in the current context, e.g., 1197 for the current peer group, neighbor, address family, 1198 etc."; 1199 } 1201 leaf default-import-policy { 1202 type default-policy-type; 1203 default reject-route; 1204 description 1205 "Explicitly set a default policy if no policy definition 1206 in the import policy chain is satisfied."; 1207 } 1209 } 1211 grouping apply-policy-export { 1212 description 1213 "Grouping for applying export policies."; 1215 leaf-list export-policy { 1216 type leafref { 1217 path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + 1218 "rt-pol:policy-definition/rt-pol:name"; 1219 require-instance true; 1220 } 1221 ordered-by user; 1222 description 1223 "List of policy names in sequence to be applied on 1224 redistributing routes from one routing protocol to another 1225 or sending a routing update in the current context, e.g., 1226 for the current peer group, neighbor, address family, 1227 etc."; 1228 } 1230 leaf default-export-policy { 1231 type default-policy-type; 1232 default reject-route; 1233 description 1234 "Explicitly set a default policy if no policy definition 1235 in the export policy chain is satisfied."; 1236 } 1237 } 1239 grouping apply-policy-group { 1240 description 1241 "Top level container for routing policy applications. This 1242 grouping is intended to be used in routing models where 1243 needed."; 1245 container apply-policy { 1246 description 1247 "Anchor point for routing policies in the model. 1248 Import and export policies are with respect to the local 1249 routing table, i.e., export (send) and import (receive), 1250 depending on the context."; 1252 uses apply-policy-import; 1253 uses apply-policy-export; 1255 } 1256 } 1258 container routing-policy { 1259 description 1260 "Top-level container for all routing policy."; 1262 container defined-sets { 1263 description 1264 "Predefined sets of attributes used in policy match 1265 statements."; 1267 container prefix-sets { 1268 description 1269 "Data definitions for a list of IPv4 or IPv6 1270 prefixes which are matched as part of a policy."; 1271 list prefix-set { 1272 key "name mode"; 1273 description 1274 "List of the defined prefix sets"; 1276 leaf name { 1277 type string; 1278 description 1279 "Name of the prefix set -- this is used as a label to 1280 reference the set in match conditions."; 1281 } 1282 leaf mode { 1283 type enumeration { 1284 enum ipv4 { 1285 description 1286 "Prefix set contains IPv4 prefixes only."; 1287 } 1288 enum ipv6 { 1289 description 1290 "Prefix set contains IPv6 prefixes only."; 1291 } 1292 } 1293 description 1294 "Indicates the mode of the prefix set, in terms of 1295 which address families (IPv4, IPv6, or both) are 1296 present. The mode provides a hint, all prefixes MUST 1297 be of the indicated type. The device MUST validate 1298 that all prefixes and reject the configuration if 1299 there is a discrepancy."; 1300 } 1302 container prefixes { 1303 description 1304 "Container for the list of prefixes in a policy 1305 prefix list. Since individual prefixes do not have 1306 unique actions, the order in which the prefix in 1307 prefix-list are matched has no impact on the outcome 1308 and is left to the implementation. A given prefix-set 1309 condition is satisfied if the input prefix matches 1310 any of the prefixes in the prefix-set."; 1312 list prefix-list { 1313 key "ip-prefix mask-length-lower mask-length-upper"; 1314 description 1315 "List of prefixes in the prefix set."; 1317 uses prefix; 1318 } 1319 } 1320 } 1321 } 1323 container neighbor-sets { 1324 description 1325 "Data definition for a list of IPv4 or IPv6 1326 neighbors which can be matched in a routing policy."; 1328 list neighbor-set { 1329 key "name"; 1330 description 1331 "List of defined neighbor sets for use in policies."; 1333 leaf name { 1334 type string; 1335 description 1336 "Name of the neighbor set -- this is used as a label 1337 to reference the set in match conditions."; 1338 } 1340 leaf-list address { 1341 type inet:ip-address; 1342 description 1343 "List of IP addresses in the neighbor set."; 1344 } 1345 } 1346 } 1348 container tag-sets { 1349 description 1350 "Data definitions for a list of tags which can 1351 be matched in policies."; 1353 list tag-set { 1354 key "name"; 1355 description 1356 "List of tag set definitions."; 1358 leaf name { 1359 type string; 1360 description 1361 "Name of the tag set -- this is used as a label to 1362 reference the set in match conditions."; 1363 } 1365 leaf-list tag-value { 1366 type tag-type; 1367 description 1368 "Value of the tag set member."; 1369 } 1370 } 1371 } 1372 } 1374 container policy-definitions { 1375 description 1376 "Enclosing container for the list of top-level policy 1377 definitions."; 1379 list policy-definition { 1380 key "name"; 1381 description 1382 "List of top-level policy definitions, keyed by unique 1383 name. These policy definitions are expected to be 1384 referenced (by name) in policy chains specified in 1385 import or export configuration statements."; 1387 leaf name { 1388 type string; 1389 description 1390 "Name of the top-level policy definition -- this name 1391 is used in references to the current policy."; 1392 } 1394 container statements { 1395 description 1396 "Enclosing container for policy statements."; 1398 list statement { 1399 key "name"; 1400 ordered-by user; 1401 description 1402 "Policy statements group conditions and actions 1403 within a policy definition. They are evaluated in 1404 the order specified (see the description of policy 1405 evaluation at the top of this module."; 1407 leaf name { 1408 type string; 1409 description 1410 "Name of the policy statement."; 1411 } 1413 container conditions { 1414 description 1415 "Condition statements for the current policy 1416 statement."; 1418 leaf call-policy { 1419 type leafref { 1420 path "../../../../../../" + 1421 "rt-pol:policy-definitions/" + 1422 "rt-pol:policy-definition/rt-pol:name"; 1423 require-instance true; 1424 } 1425 description 1426 "Applies the statements from the specified policy 1427 definition and then returns control to the current 1428 policy statement. Note that the called policy 1429 may itself call other policies (subject to 1430 implementation limitations). This is intended to 1431 provide a policy 'subroutine' capability. The 1432 called policy SHOULD contain an explicit or a 1433 default route disposition that returns an 1434 effective true (accept-route) or false 1435 (reject-route), otherwise the behavior may be 1436 ambiguous."; 1437 } 1439 leaf source-protocol { 1440 type identityref { 1441 base rt:control-plane-protocol; 1442 } 1443 description 1444 "Condition to check the protocol / method used to 1445 install the route into the local routing table."; 1446 } 1448 uses match-interface-condition; 1449 uses prefix-set-condition; 1450 uses neighbor-set-condition; 1451 uses tag-set-condition; 1452 uses match-route-type-condition; 1453 } 1455 container actions { 1456 description 1457 "Top-level container for policy action 1458 statements."; 1459 leaf policy-result { 1460 type policy-result-type; 1461 default reject-route; 1462 description 1463 "Select the final disposition for the route, 1464 either accept or reject."; 1465 } 1466 container set-metric { 1467 leaf metric-modification { 1468 type metric-modification-type; 1469 description 1470 "Indicates how to modify the metric."; 1471 } 1472 leaf metric { 1473 type uint32; 1474 description 1475 "Metric value to set, add, or subtract."; 1476 } 1477 description 1478 "Set the metric for the route."; 1479 } 1480 container set-metric-type { 1481 leaf metric-type { 1482 type identityref { 1483 base metric-type; 1484 } 1485 description 1486 "Route metric type."; 1487 } 1488 description 1489 "Set the metric type for the route."; 1490 } 1491 container set-route-level { 1492 leaf route-level { 1493 type identityref { 1494 base route-level; 1495 } 1496 description 1497 "Route import level."; 1498 } 1499 description 1500 "Set the level for importation or 1501 exportation of routes."; 1502 } 1503 leaf set-preference { 1504 type uint16; 1505 description 1506 "Set the preference for the route. It is also 1507 known as 'administrative distance', allows for 1508 selecting the preferred route among routes with 1509 the same destination prefix. A smaller value is 1510 more preferred."; 1511 } 1512 leaf set-tag { 1513 type tag-type; 1514 description 1515 "Set the tag for the route."; 1516 } 1517 leaf set-application-tag { 1518 type tag-type; 1519 description 1520 "Set the application tag for the route. 1521 The application-specific tag is an additional tag 1522 that can be used by applications that require 1523 semantics and/or policy different from that of the 1524 tag. For example, the tag is usually automatically 1525 advertised in OSPF AS-External Link State 1526 Advertisements (LSAs) while this application-specific 1527 tag is not advertised implicitly."; 1528 } 1529 } 1530 } 1531 } 1532 } 1533 } 1534 } 1535 } 1536 1538 8. Security Considerations 1540 The YANG module specified in this document defines a schema for data 1541 that is designed to be accessed via network management protocols such 1542 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1543 is the secure transport layer, and the mandatory-to-implement secure 1544 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1545 is HTTPS, and the mandatory-to-implement secure transport is TLS 1546 [RFC8446]. 1548 The NETCONF Access Control Model (NACM) [RFC8341] provides the means 1549 to restrict access for particular NETCONF or RESTCONF users to a pre- 1550 configured subset of all available NETCONF or RESTCONF protocol 1551 operations and content. 1553 There are a number of data nodes defined in this YANG module that are 1554 writable/creatable/deletable (i.e., config true, which is the 1555 default). These data nodes may be considered sensitive or vulnerable 1556 in some network environments. Write operations (e.g., edit-config) 1557 to these data nodes without proper protection can have a negative 1558 effect on network operations. These are the subtrees and data nodes 1559 and their sensitivity/vulnerability: 1561 /routing-policy 1563 /routing-policy/defined-sets/prefix-sets -- Modification to 1564 prefix-sets could result in a Denial-of-Service (DoS) attack. An 1565 attacker may try to modify prefix-sets and redirect or drop 1566 traffic. Redirection of traffic could be used as part of a more 1567 elaborate attack to either collect sensitive information or 1568 masquerade a service. Additionally, a control-plane DoS attack 1569 could be accomplished by allowing a large number of routes to be 1570 leaked into a routing protocol domian (e.g., BGP). 1572 /routing-policy/defined-sets/neighbor-sets -- Modification to the 1573 neighbor-sets could be used to mount a DoS attack or more 1574 elaborate attack as with prefix-sets. For example, a DoS attack 1575 could be mounted by changing the neighbor-set from which routes 1576 are accepted. 1578 /routing-policy/defined-sets/tag-sets -- Modification to the tag- 1579 sets could be used to mount a DoS attack. Routes with certain 1580 tags might be redirected or dropped. The implications are similar 1581 to prefix-sets and neighbor-sets. However, the attack may be more 1582 difficult to detect as the routing policy usage of route tags and 1583 intent must be understood to recognize the breach. Conversely, 1584 the implications of prefix-set or neighbor set modification are 1585 easier to recognize. 1587 /routing-policy/policy-definitions 1589 /routing-policy/policy-definitions/policy-definition 1590 /statements/statement/conditions -- Modification to the conditions 1591 could be used to mount a DoS attack or other attack. An attacker 1592 may change a policy condition and redirect or drop traffic. As 1593 with prefix-sets, neighbor-sets, or tag-sets, traffic redirection 1594 could be used as part of a more elaborate attack. 1596 /routing-policy/policy-definitions/policy-definition 1597 /statements/statement/actions -- Modification to actions could be 1598 used to mount a DoS attack or other attack. Traffic may be 1599 redirected or dropped. As with prefix-sets, neighbor-sets, or 1600 tag-sets, traffic redirection could be used as part of a more 1601 elaborate attack. Additionally, route attributes may be changed 1602 to mount a second-level attack that is more difficult to detect. 1604 Some of the readable data nodes in the YANG module may be considered 1605 sensitive or vulnerable in some network environments. It is thus 1606 important to control read access (e.g., via get, get-config, or 1607 notification) to these data nodes. These are the subtrees and data 1608 nodes and their sensitivity/vulnerability: 1610 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1611 data nodes can be used to ascertain which local prefixes are 1612 suspectable to a Denial-of-Service (DoS) attack. 1614 /routing-policy/defined-sets/prefix-sets -- Knowledge of these 1615 data nodes can be used to ascertain local neighbors against whom 1616 to mount a Denial-of-Service (DoS) attack. 1618 /routing-policy/policy-definitions/policy-definition /statements/ 1619 -- Knowledge of these data nodes can be used to attack the local 1620 router with a Denial-of-Service (DoS) attack. Additionally, 1621 policies and their attendant conditions and actions should be 1622 considered proprietary and disclosure could be used to ascertain 1623 partners, customers, and supplies. Furthermore, the policies 1624 themselves could represent intellectual property and disclosure 1625 could diminish their corresponding business advantage. 1627 Routing policy configuration has a significant impact on network 1628 operations, and, as such, any related model carries potential 1629 security risks. Unauthorized access or invalid data could cause 1630 major disruption. 1632 9. IANA Considerations 1634 This document registers a URI in the IETF XML registry [RFC3688]. 1635 Following the format in [RFC3688], the following registration is 1636 requested to be made: 1638 URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1639 Registrant Contact: The IESG. 1640 XML: N/A, the requested URI is an XML namespace. 1642 This document registers a YANG module in the YANG Module Names 1643 registry [RFC6020]. 1645 name: ietf-routing-policy 1646 namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy 1647 prefix: rt-pol 1648 reference: RFC XXXX 1650 10. Acknowledgements 1652 The routing policy module defined in this document is based on the 1653 OpenConfig route policy model. The authors would like to thank to 1654 OpenConfig for their contributions, especially Anees Shaikh, Rob 1655 Shakir, Kevin D'Souza, and Chris Chase. 1657 The authors are grateful for valuable contributions to this document 1658 and the associated models from: Ebben Aires, Luyuan Fang, Josh 1659 George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, 1660 Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and 1661 John Heasley. 1663 Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom 1664 Petch for their reviews and comments. 1666 11. References 1668 11.1. Normative references 1670 [INTF-EXT-YANG] 1671 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1672 Sivaraj,, "Common Interface Extension YANG Data Models", 1673 2019, . 1676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1677 Requirement Levels", BCP 14, RFC 2119, 1678 DOI 10.17487/RFC2119, March 1997, 1679 . 1681 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1682 DOI 10.17487/RFC2328, April 1998, 1683 . 1685 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1686 RFC 3101, DOI 10.17487/RFC3101, January 2003, 1687 . 1689 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1690 DOI 10.17487/RFC3688, January 2004, 1691 . 1693 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1694 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1695 DOI 10.17487/RFC4271, January 2006, 1696 . 1698 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1699 Control Mechanism in IS-IS Using Administrative Tags", 1700 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1701 . 1703 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1704 Distribution with Two-Level IS-IS", RFC 5302, 1705 DOI 10.17487/RFC5302, October 2008, 1706 . 1708 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1709 the Network Configuration Protocol (NETCONF)", RFC 6020, 1710 DOI 10.17487/RFC6020, October 2010, 1711 . 1713 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1714 and A. Bierman, Ed., "Network Configuration Protocol 1715 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1716 . 1718 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1719 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1720 . 1722 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1723 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1724 . 1726 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1727 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1728 . 1730 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1731 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1732 . 1734 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1735 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1736 May 2017, . 1738 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1739 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1740 . 1742 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1743 Access Control Model", STD 91, RFC 8341, 1744 DOI 10.17487/RFC8341, March 2018, 1745 . 1747 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1748 and R. Wilton, "Network Management Datastore Architecture 1749 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1750 . 1752 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1753 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1754 . 1756 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1757 Routing Management (NMDA Version)", RFC 8349, 1758 DOI 10.17487/RFC8349, March 2018, 1759 . 1761 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1762 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1763 . 1765 [SUB-INTF-VLAN-YANG] 1766 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1767 Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, 1768 . 1771 11.2. Informative references 1773 [I-D.ietf-idr-bgp-model] 1774 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1775 YANG Model for Service Provider Networks", draft-ietf-idr- 1776 bgp-model-10 (work in progress), November 2020. 1778 Appendix A. Routing protocol-specific policies 1780 Routing models that require the ability to apply routing policy may 1781 augment the routing policy model with protocol or other specific 1782 policy configuration. The routing policy model assumes that 1783 additional defined sets, conditions, and actions may all be added by 1784 other models. 1786 The example below provides an illustration of how another data model 1787 can augment parts of this routing policy data model. It uses 1788 specific examples from draft-ietf-idr-bgp-model-09 to show in a 1789 concrete manner how the different pieces fit together. This example 1790 is not normative with respect to [I-D.ietf-idr-bgp-model]. The model 1791 similarly augments BGP-specific conditions and actions in the 1792 corresponding sections of the routing policy model. In the example 1793 below, the XPath prefix "bp:" specifies import from the ietf-bgp- 1794 policy sub-module and the XPath prefix "bt:" specifies import from 1795 the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model]. 1797 module: ietf-routing-policy 1798 +--rw routing-policy 1799 +--rw defined-sets 1800 | +--rw prefix-sets 1801 | | +--rw prefix-set* [name] 1802 | | +--rw name string 1803 | | +--rw mode? enumeration 1804 | | +--rw prefixes 1805 | | +--rw prefix-list* [ip-prefix mask-length-lower 1806 | | mask-length-upper] 1807 | | +--rw ip-prefix inet:ip-prefix 1808 | | +--rw mask-length-lower uint8 1809 | | +--rw mask-length-upper uint8 1810 | +--rw neighbor-sets 1811 | | +--rw neighbor-set* [name] 1812 | | +--rw name string 1813 | | +--rw address* inet:ip-address 1814 | +--rw tag-sets 1815 | | +--rw tag-set* [name] 1816 | | +--rw name string 1817 | | +--rw tag-value* tag-type 1818 | +--rw bp:bgp-defined-sets 1819 | +--rw bp:community-sets 1820 | | +--rw bp:community-set* [name] 1821 | | +--rw bp:name string 1822 | | +--rw bp:member* union 1823 | +--rw bp:ext-community-sets 1824 | | +--rw bp:ext-community-set* [name] 1825 | | +--rw bp:name string 1826 | | +--rw bp:member* union 1827 | +--rw bp:as-path-sets 1828 | +--rw bp:as-path-set* [name] 1829 | +--rw bp:name string 1830 | +--rw bp:member* string 1831 +--rw policy-definitions 1832 +--rw policy-definition* [name] 1833 +--rw name string 1834 +--rw statements 1835 +--rw statement* [name] 1836 +--rw name string 1837 +--rw conditions 1838 | +--rw call-policy? 1839 | +--rw source-protocol? identityref 1840 | +--rw match-interface 1841 | | +--rw interface? 1842 | | +--rw subinterface? 1843 | +--rw match-prefix-set 1844 | | +--rw prefix-set? prefix-set/name 1845 | | +--rw match-set-options? match-set-options-type 1846 | +--rw match-neighbor-set 1847 | | +--rw neighbor-set? 1848 | +--rw match-tag-set 1849 | | +--rw tag-set? 1850 | | +--rw match-set-options? match-set-options-type 1851 | +--rw match-route-type* identityref 1852 | +--rw bp:bgp-conditions 1853 | +--rw bp:med-eq? uint32 1854 | +--rw bp:origin-eq? bt:bgp-origin-attr-type 1855 | +--rw bp:next-hop-in* inet:ip-address-no-zone 1856 | +--rw bp:afi-safi-in* identityref 1857 | +--rw bp:local-pref-eq? uint32 1858 | +--rw bp:route-type? enumeration 1859 | +--rw bp:community-count 1860 | +--rw bp:as-path-length 1861 | +--rw bp:match-community-set 1862 | | +--rw bp:community-set? 1863 | | +--rw bp:match-set-options? 1864 | +--rw bp:match-ext-community-set 1865 | | +--rw bp:ext-community-set? 1866 | | +--rw bp:match-set-options? 1867 | +--rw bp:match-as-path-set 1868 | +--rw bp:as-path-set? 1869 | +--rw bp:match-set-options? 1870 +--rw actions 1871 +--rw policy-result? policy-result-type 1872 +--rw set-metric 1873 | +--rw metric-modification? 1874 | +--rw metric? uint32 1875 +--rw set-metric-type 1876 | +--rw metric-type? identityref 1877 +--rw set-route-level 1878 | +--rw route-level? identityref 1879 +--rw set-preference? uint16 1880 +--rw set-tag? tag-type 1881 +--rw set-application-tag? tag-type 1882 +--rw bp:bgp-actions 1883 +--rw bp:set-route-origin?bt:bgp-origin-attr-type 1884 +--rw bp:set-local-pref? uint32 1885 +--rw bp:set-next-hop? bgp-next-hop-type 1886 +--rw bp:set-med? bgp-set-med-type 1887 +--rw bp:set-as-path-prepend 1888 | +--rw bp:repeat-n? uint8 1889 +--rw bp:set-community 1890 | +--rw bp:method? enumeration 1891 | +--rw bp:options? 1892 | +--rw bp:inline 1893 | | +--rw bp:communities* union 1894 | +--rw bp:reference 1895 | +--rw bp:community-set-ref? 1896 +--rw bp:set-ext-community 1897 +--rw bp:method? enumeration 1898 +--rw bp:options? 1899 +--rw bp:inline 1900 | +--rw bp:communities* union 1901 +--rw bp:reference 1902 +--rw bp:ext-community-set-ref? 1904 Appendix B. Policy examples 1906 Below we show examples of XML-encoded configuration data using the 1907 routing policy and BGP models to illustrate both how policies are 1908 defined, and how they can be applied. Note that the XML has been 1909 simplified for readability. 1911 The following example shows how prefix-set and tag-set can be 1912 defined. The policy condition is to match a prefix-set and a tag- 1913 set, and the action is to accept routes that match the condition. 1915 1916 1919 1920 1921 1922 prefix-set-A 1923 ipv4 1924 1925 1926 192.0.2.0/24 1927 24 1928 32 1929 1930 1931 198.51.100.0/24 1932 24 1933 32 1934 1935 1936 1937 1938 prefix-set-B 1939 ipv6 1940 1941 1942 2001:DB8::/32 1943 32 1944 64 1945 1946 1947 1948 1949 1950 1951 cust-tag1 1952 10 1953 1954 1955 1957 1958 1959 export-tagged-BGP 1960 1961 1962 term-0 1963 1964 1965 prefix-set-A 1966 1967 1968 cust-tag1 1969 1970 1971 1972 accept-route 1973 1974 1975 1976 1977 1979 1980 1982 In the following example, all routes in the RIB that have been 1983 learned from OSPF advertisements corresponding to OSPF intra-area and 1984 inter-area route types should get advertised into ISIS level-2 1985 advertisements. 1987 1988 1990 1991 1992 export-all-OSPF-prefixes-into-ISIS-level-2 1993 1994 1995 term-0 1996 1997 ospf-internal-type 1998 1999 2000 2001 isis-level-2 2002 2003 accept-route 2004 2005 2006 2007 2008 2009 2010 2012 Authors' Addresses 2014 Yingzhen Qu 2015 Futurewei 2016 2330 Central Expressway 2017 Santa Clara CA 95050 2018 USA 2020 Email: yingzhen.qu@futurewei.com 2022 Jeff Tantsura 2023 Juniper Networks 2025 Email: jefftant.ietf@gmail.com 2026 Acee Lindem 2027 Cisco 2028 301 Midenhall Way 2029 Cary, NC 27513 2030 US 2032 Email: acee@cisco.com 2034 Xufeng Liu 2035 Volta Networks 2037 Email: xufeng.liu.ietf@gmail.com