rfc9067v1.txt   rfc9067.txt 
skipping to change at line 111 skipping to change at line 111
Despite the differences in details of policy expressions and Despite the differences in details of policy expressions and
conventions in various vendor implementations, the model reflects the conventions in various vendor implementations, the model reflects the
observation that a relatively simple condition-action approach can be observation that a relatively simple condition-action approach can be
readily mapped to several existing vendor implementations and also readily mapped to several existing vendor implementations and also
gives operators a familiar and straightforward way to express policy. gives operators a familiar and straightforward way to express policy.
A side effect of this design decision is that other methods for A side effect of this design decision is that other methods for
expressing policies are not considered. expressing policies are not considered.
Consistent with the goal to produce a data model that is vendor Consistent with the goal to produce a data model that is vendor
neutral, only policy expressions that are deemed to be widely neutral, only policy expressions that are deemed to be widely
available in existing major implementations are included in the available in prevalent implementations are included in the model.
model. Those configuration items that are only available from a Those configuration items that are only available from a single
single implementation are omitted from the model with the expectation implementation are omitted from the model with the expectation they
they will be available in separate vendor-provided modules that will be available in separate vendor-provided modules that augment
augment the current model. the current model.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Routing policy: A routing policy defines how routes are imported, Routing policy: A routing policy defines how routes are imported,
skipping to change at line 223 skipping to change at line 223
* A structure that allows routing protocol models to add protocol- * A structure that allows routing protocol models to add protocol-
specific policy conditions and actions through YANG augmentations specific policy conditions and actions through YANG augmentations
is also provided. There is a complete example of this for BGP is also provided. There is a complete example of this for BGP
[RFC4271] policies in the proposed vendor-neutral BGP data model [RFC4271] policies in the proposed vendor-neutral BGP data model
[IDR-BGP-MODEL]. Appendix A provides an example of how an [IDR-BGP-MODEL]. Appendix A provides an example of how an
augmentation for BGP policies might be accomplished. Note that augmentation for BGP policies might be accomplished. Note that
this section is not normative, as the BGP model is still evolving. this section is not normative, as the BGP model is still evolving.
* Finally, a reusable grouping is defined for attaching import and * Finally, a reusable grouping is defined for attaching import and
export rules in the context of routing configuration for different export rules in the context of routing configuration for different
protocols, VRFs, etc. This also enables the creation of policy protocols, Virtual Routing and Forwarding (VRF) instances, etc.
chains and the expression of default policy behavior. In this This also enables the creation of policy chains and the expression
document, policy chains are sequences of policy definitions that of default policy behavior. In this document, policy chains are
are applied in order (described in Section 4). sequences of policy definitions that are applied in order
(described in Section 4).
The module makes use of the standard Internet types, such as IP The module makes use of the standard Internet types, such as IP
addresses, autonomous system numbers, etc., defined in RFC 6991 addresses, autonomous system numbers, etc., defined in RFC 6991
[RFC6991]. [RFC6991].
4. Route Policy Expression 4. Route Policy Expression
Policies are expressed as a sequence of top-level policy definitions, Policies are expressed as a sequence of top-level policy definitions,
each of which consists of a sequence of policy statements. Policy each of which consists of a sequence of policy statements. Policy
statements in turn consist of simple condition-action tuples. statements in turn consist of simple condition-action tuples.
Conditions may include multiple match or comparison operations, and Conditions may include multiple match or comparison operations, and
similarly, actions may include multiple changes to route attributes similarly, actions may include multiple changes to route attributes
or indicate a final disposition of accepting or rejecting the route. or indicate a final disposition of accepting or rejecting the route.
This structure is shown below. This structure is shown below.
+--rw routing-policy +--rw routing-policy
+--ro match-modified-attributes? boolean
+--rw policy-definitions +--rw policy-definitions
+--ro match-modified-attributes? boolean
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw name string +--rw name string
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| ... | ...
+--rw actions +--rw actions
... ...
skipping to change at line 271 skipping to change at line 272
sets. The defined sets include: sets. The defined sets include:
prefix sets: Each prefix set defines a set of IP prefixes, each with prefix sets: Each prefix set defines a set of IP prefixes, each with
an associated IP prefix and netmask range (or exact length). an associated IP prefix and netmask range (or exact length).
neighbor sets: Each neighbor set defines a set of neighboring nodes neighbor sets: Each neighbor set defines a set of neighboring nodes
by their IP addresses. A neighbor set is used for selecting by their IP addresses. A neighbor set is used for selecting
routes based on the neighbors advertising the routes. routes based on the neighbors advertising the routes.
tag sets: Each tag set defines a set of generic tag values that can tag sets: Each tag set defines a set of generic tag values that can
be used in matches for filtering routes. be used in matches for selecting routes.
The model structure for defined sets is shown below. The model structure for defined sets is shown below.
+--rw routing-policy +--rw routing-policy
+--rw defined-sets +--rw defined-sets
| +--rw prefix-sets | +--rw prefix-sets
| | +--rw prefix-set* [name] | | +--rw prefix-set* [name]
| | +--rw name string | | +--rw name string
| | +--rw mode? enumeration | | +--rw mode? enumeration
| | +--rw prefixes | | +--rw prefixes
skipping to change at line 301 skipping to change at line 302
| +--rw tag-sets | +--rw tag-sets
| +--rw tag-set* [name] | +--rw tag-set* [name]
| +--rw name string | +--rw name string
| +--rw tag-value* tag-type | +--rw tag-value* tag-type
4.2. Policy Conditions 4.2. Policy Conditions
Policy statements consist of a set of conditions and actions (either Policy statements consist of a set of conditions and actions (either
of which may be empty). Conditions are used to match route of which may be empty). Conditions are used to match route
attributes against a defined set (e.g., a prefix set) or to compare attributes against a defined set (e.g., a prefix set) or to compare
attributes against a specific value. The default action is reject- attributes against a specific value.
route.
Match conditions may be further modified using the match-set-options Match conditions may be further modified using the match-set-options
configuration, which allows network operators to change the behavior configuration, which allows network operators to change the behavior
of a match. Three options are supported: of a match. Three options are supported:
ALL: Match is true only if the given value matches all members of 'all': Match is true only if the given value matches all members of
the set. the set.
ANY: Match is true if the given value matches any member of the set. 'any': Match is true if the given value matches any member of the
set.
INVERT: Match is true if the given value does not match any member 'invert': Match is true if the given value does not match any member
of the given set. of the given set.
Not all options are appropriate for matching against all defined sets Not all options are appropriate for matching against all defined sets
(e.g., match ALL in a prefix set does not make sense). In the model, (e.g., match 'all' in a prefix set does not make sense). In the
a restricted set of match options is used where applicable. model, a restricted set of match options is used where applicable.
Comparison conditions may similarly use options to change how route Comparison conditions may similarly use options to change how route
attributes should be tested, e.g., for equality or inequality, attributes should be tested, e.g., for equality or inequality,
against a given value. against a given value.
While most policy conditions will be added by individual routing While most policy conditions will be added by individual routing
protocol models via augmentation, this routing policy model includes protocol models via augmentation, this routing policy model includes
several generic match conditions and the ability to test which several generic match conditions and the ability to test which
protocol or mechanism installed a route (e.g., BGP, IGP, static, protocol or mechanism installed a route (e.g., BGP, IGP, static,
etc.). The conditions included in the model are shown below. etc.). The conditions included in the model are shown below.
skipping to change at line 349 skipping to change at line 350
| +--rw match-interface | +--rw match-interface
| | +--rw interface? | | +--rw interface?
| +--rw match-prefix-set | +--rw match-prefix-set
| | +--rw prefix-set? | | +--rw prefix-set?
| | +--rw match-set-options? | | +--rw match-set-options?
| +--rw match-neighbor-set | +--rw match-neighbor-set
| | +--rw neighbor-set? | | +--rw neighbor-set?
| +--rw match-tag-set | +--rw match-tag-set
| | +--rw tag-set? | | +--rw tag-set?
| | +--rw match-set-options? | | +--rw match-set-options?
| +--rw match-route-type* identityref | +--rw match-route-type
| +--rw route-type* | +--rw route-type*
4.3. Policy Actions 4.3. Policy Actions
When policy conditions are satisfied, policy actions are used to set When policy conditions are satisfied, policy actions are used to set
various attributes of the route being processed or to indicate the various attributes of the route being processed or to indicate the
final disposition of the route, i.e., accept or reject. final disposition of the route, i.e., accept or reject.
Similar to policy conditions, the routing policy model includes Similar to policy conditions, the routing policy model includes
generic actions in addition to the basic route disposition actions. generic actions in addition to the basic route disposition actions.
skipping to change at line 392 skipping to change at line 393
Policy 'subroutines' (or nested policies) are supported by allowing Policy 'subroutines' (or nested policies) are supported by allowing
policy statement conditions to reference other policy definitions policy statement conditions to reference other policy definitions
using the call-policy configuration. Called policies apply their using the call-policy configuration. Called policies apply their
conditions and actions before returning to the calling policy conditions and actions before returning to the calling policy
statement and resuming evaluation. The outcome of the called policy statement and resuming evaluation. The outcome of the called policy
affects the evaluation of the calling policy. If the called policy affects the evaluation of the calling policy. If the called policy
results in an accept-route, then the subroutine returns an effective results in an accept-route, then the subroutine returns an effective
Boolean true value to the calling policy. For the calling policy, Boolean true value to the calling policy. For the calling policy,
this is equivalent to a condition statement evaluating to a true this is equivalent to a condition statement evaluating to a true
value and evaluation of the policy continues (see Section 5). Note value, thus the calling party continues in its evaluation of the
that the called policy may also modify attributes of the route in its policy (see Section 5). Note that the called policy may also modify
action statements. Similarly, a reject-route action returns false, attributes of the route in its action statements. Similarly, a
and the calling policy evaluation will be affected accordingly. When reject-route action returns false, and the calling policy evaluation
the end of the subroutine policy statements is reached, the default will be affected accordingly. When the end of the subroutine policy
route disposition action is returned (i.e., Boolean false for reject- statements is reached, the default route disposition action is
route). Consequently, a subroutine cannot explicitly accept or returned (i.e., Boolean false for reject-route). Consequently, a
reject a route. Rather, the called policy returns Boolean true if subroutine cannot explicitly accept or reject a route. Rather, the
its outcome is accept-route or Boolean false if its outcome is called policy returns Boolean true if its outcome is accept-route or
reject-route. Route acceptance or rejection is solely determined by Boolean false if its outcome is reject-route. Route acceptance or
the top-level policy. rejection is solely determined by the top-level policy.
Note that the called policy may itself call other policies (subject Note that the called policy may itself call other policies (subject
to implementation limitations). The model does not prescribe a to implementation limitations). The model does not prescribe a
nesting depth because this varies among implementations. For nesting depth because this varies among implementations. For
example, an implementation may only support a single level of example, an implementation may only support a single level of
subroutine recursion. As with any routing policy construction, care subroutine recursion. As with any routing policy construction, care
must be taken with nested policies to ensure that the effective must be taken with nested policies to ensure that the effective
return value results in the intended behavior. Nested policies are a return value results in the intended behavior. Nested policies are a
convenience in many routing policy constructions, but creating convenience in many routing policy constructions, but creating
policies nested beyond a small number of levels (e.g., two to three) policies nested beyond a small number of levels (e.g., two to three)
is discouraged. Also, implementations MUST validate to ensure that is discouraged. Also, implementations MUST perform validation to
there is no recursion among nested routing policies. ensure that there is no recursion among nested routing policies.
5. Policy Evaluation 5. Policy Evaluation
Evaluation of each policy definition proceeds by evaluating its Evaluation of each policy definition proceeds by evaluating its
individual policy statements in the order that they are defined. individual policy statements in the order that they are defined.
When all the condition statements in a policy statement are When all the condition statements in a policy statement are
satisfied, the corresponding action statements are executed. If the satisfied, the corresponding action statements are executed. If the
actions include either accept-route or reject-route actions, actions include either accept-route or reject-route actions,
evaluation of the current policy definition stops, and no further evaluation of the current policy definition stops, and no further
policy statement is evaluated. If there are multiple policies in the policy statement is evaluated. If there are multiple policies in the
skipping to change at line 512 skipping to change at line 513
+--rw name string +--rw name string
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| +--rw call-policy? -> ../../../../../.. | +--rw call-policy? -> ../../../../../..
| /policy-definitions | /policy-definitions
| /policy-definition/name | /policy-definition/name
| +--rw source-protocol? identityref | +--rw source-protocol? identityref
| +--rw match-interface | +--rw match-interface
| | +--rw interface? -> /if:interfaces/interface | | +--rw interface? if:interface-ref
| | /name
| +--rw match-prefix-set | +--rw match-prefix-set
| | +--rw prefix-set? -> ../../../../../../.. | | +--rw prefix-set? -> ../../../../../../..
| | /defined-sets/prefix-sets | | /defined-sets
| | /prefix-sets
| | /prefix-set/name | | /prefix-set/name
| | +--rw match-set-options? match-set-options-type | | +--rw match-set-options?
| | match-set-options-type
| +--rw match-neighbor-set | +--rw match-neighbor-set
| | +--rw neighbor-set? -> ../../../../../../.. | | +--rw neighbor-set? -> ../../../../../../..
| | /defined-sets/neighbor-sets | | /defined-sets
| | /neighbor-sets
| | /neighbor-set/name | | /neighbor-set/name
| +--rw match-tag-set | +--rw match-tag-set
| | +--rw tag-set? -> ../../../../../../.. | | +--rw tag-set? -> ../../../../../../..
| | /defined-sets/tag-sets | | /defined-sets/tag-sets
| | /tag-set/name | | /tag-set/name
| | +--rw match-set-options? match-set-options-type | | +--rw match-set-options?
| +--rw match-route-type* identityref | | match-set-options-type
| +--rw match-route-type
| +--rw route-type* identityref
+--rw actions +--rw actions
+--rw policy-result? policy-result-type +--rw policy-result? policy-result-type
+--rw set-metric +--rw set-metric
| +--rw metric-modification? metric-modification-type | +--rw metric-modification?
| metric-modification-type
| +--rw metric? uint32 | +--rw metric? uint32
+--rw set-metric-type +--rw set-metric-type
| +--rw metric-type? identityref | +--rw metric-type? identityref
+--rw set-route-level +--rw set-route-level
| +--rw route-level? identityref | +--rw route-level? identityref
+--rw set-route-preference? uint16 +--rw set-route-preference? uint16
+--rw set-tag? tag-type +--rw set-tag? tag-type
+--rw set-application-tag? tag-type +--rw set-application-tag? tag-type
7.2. Routing Policy Model 7.2. Routing Policy Model
skipping to change at line 997 skipping to change at line 1003
} }
description description
"Mask length range lower bound. It MUST NOT be less than "Mask length range lower bound. It MUST NOT be less than
the prefix length defined in ip-prefix."; the prefix length defined in ip-prefix.";
} }
leaf mask-length-upper { leaf mask-length-upper {
type uint8 { type uint8 {
range "1..128"; range "1..128";
} }
must '../mask-length-upper >= ../mask-length-lower' { must '../mask-length-upper >= ../mask-length-lower' {
error-message "The upper bound MUST NOT be less" error-message "The upper bound MUST NOT be less "
+ "than lower bound."; + "than lower bound.";
} }
description description
"Mask length range upper bound. It MUST NOT be less than "Mask length range upper bound. It MUST NOT be less than
lower bound."; lower bound.";
} }
} }
grouping match-set-options-group { grouping match-set-options-group {
description description
skipping to change at line 1037 skipping to change at line 1043
member of the defined set."; member of the defined set.";
} }
enum invert { enum invert {
description description
"Match is true if given value does not match "Match is true if given value does not match
any member of the defined set."; any member of the defined set.";
} }
} }
description description
"Optional parameter that governs the behavior of the "Optional parameter that governs the behavior of the
match operation. This leaf only supports matching on match operation. This leaf only supports
'any' member of the set or 'invert' the match. the 'any' and 'invert' match options.
Matching on 'all' is not supported."; Matching on 'all' is not supported.";
} }
} }
grouping apply-policy-group { grouping apply-policy-group {
description description
"Top-level container for routing policy applications. This "Top-level container for routing policy applications. This
grouping is intended to be used in routing models where grouping is intended to be used in routing models where
needed."; needed.";
container apply-policy { container apply-policy {
skipping to change at line 1134 skipping to change at line 1140
"Prefix set contains IPv4 prefixes only."; "Prefix set contains IPv4 prefixes only.";
} }
enum ipv6 { enum ipv6 {
description description
"Prefix set contains IPv6 prefixes only."; "Prefix set contains IPv6 prefixes only.";
} }
} }
description description
"Indicates the mode of the prefix set in terms of "Indicates the mode of the prefix set in terms of
which address families (IPv4 or IPv6) are present. which address families (IPv4 or IPv6) are present.
The mode provides a hint, all prefixes MUST be of The mode provides a hint; all prefixes MUST be of
the indicated type. The device MUST validate that the indicated type. The device MUST validate
all prefixes and reject the configuration if there all prefixes and reject the configuration if there
is a discrepancy."; is a discrepancy.";
} }
container prefixes { container prefixes {
description description
"Container for the list of prefixes in a policy "Container for the list of prefixes in a policy
prefix list. Since individual prefixes do not have prefix list. Since individual prefixes do not have
unique actions, the order in which the prefix in unique actions, the order in which the prefix in
prefix-list are matched has no impact on the outcome prefix-list are matched has no impact on the outcome
and is left to the implementation. A given prefix-set and is left to the implementation. A given prefix-set
skipping to change at line 1262 skipping to change at line 1268
"Applies the statements from the specified policy "Applies the statements from the specified policy
definition and then returns control to the current definition and then returns control to the current
policy statement. Note that the called policy policy statement. Note that the called policy
may itself call other policies (subject to may itself call other policies (subject to
implementation limitations). This is intended to implementation limitations). This is intended to
provide a policy 'subroutine' capability. The provide a policy 'subroutine' capability. The
called policy SHOULD contain an explicit or a called policy SHOULD contain an explicit or a
default route disposition that returns an default route disposition that returns an
effective true (accept-route) or false effective true (accept-route) or false
(reject-route); otherwise, the behavior may be (reject-route); otherwise, the behavior may be
ambiguous."; ambiguous. The call-policy MUST NOT have been
previously called without returning (i.e.,
recursion is not allowed).";
} }
leaf source-protocol { leaf source-protocol {
type identityref { type identityref {
base rt:control-plane-protocol; base rt:control-plane-protocol;
} }
description description
"Condition to check the protocol / method used to "Condition to check the protocol / method used to
install the route into the local routing table."; install the route into the local routing table.";
} }
container match-interface { container match-interface {
leaf interface { leaf interface {
type leafref { type if:interface-ref;
path "/if:interfaces/if:interface/if:name";
}
description description
"Reference to a base interface."; "Reference to a base interface.";
} }
description description
"Container for interface match conditions"; "Container for interface match conditions";
} }
container match-prefix-set { container match-prefix-set {
leaf prefix-set { leaf prefix-set {
type leafref { type leafref {
path "../../../../../../../defined-sets/" path "../../../../../../../defined-sets/"
skipping to change at line 1348 skipping to change at line 1354
type."; type.";
} }
} }
} }
container actions { container actions {
description description
"Top-level container for policy action "Top-level container for policy action
statements."; statements.";
leaf policy-result { leaf policy-result {
type policy-result-type; type policy-result-type;
default "reject-route";
description description
"Select the final disposition for the route, "Select the final disposition for the route,
either accept or reject."; either accept or reject.";
} }
container set-metric { container set-metric {
leaf metric-modification { leaf metric-modification {
type metric-modification-type; type metric-modification-type;
description description
"Indicates how to modify the metric."; "Indicates how to modify the metric.";
} }
skipping to change at line 1450 skipping to change at line 1455
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/routing-policy/defined-sets/prefix-sets /routing-policy/defined-sets/prefix-sets
Modification to prefix-sets could result in a Denial-of-Service Modification to prefix sets could result in a Denial-of-Service
(DoS) attack. An attacker may try to modify prefix-sets and (DoS) attack. An attacker may try to modify prefix sets and
redirect or drop traffic. Redirection of traffic could be used as redirect or drop traffic. Redirection of traffic could be used as
part of a more elaborate attack to either collect sensitive part of a more elaborate attack to either collect sensitive
information or masquerade a service. Additionally, a control information or masquerade a service. Additionally, a control
plane DoS attack could be accomplished by allowing a large number plane DoS attack could be accomplished by allowing a large number
of routes to be leaked into a routing protocol domain (e.g., BGP). of routes to be leaked into a routing protocol domain (e.g., BGP).
/routing-policy/defined-sets/neighbor-sets /routing-policy/defined-sets/neighbor-sets
Modification to the neighbor-sets could be used to mount a DoS Modification to the neighbor sets could be used to mount a DoS
attack or more elaborate attack as with prefix-sets. For example, attack or more elaborate attack as with prefix sets. For example,
a DoS attack could be mounted by changing the neighbor-set from a DoS attack could be mounted by changing the neighbor set from
which routes are accepted. which routes are accepted.
/routing-policy/defined-sets/tag-sets /routing-policy/defined-sets/tag-sets
Modification to the tag-sets could be used to mount a DoS attack. Modification to the tag sets could be used to mount a DoS attack.
Routes with certain tags might be redirected or dropped. The Routes with certain tags might be redirected or dropped. The
implications are similar to prefix-sets and neighbor-sets. implications are similar to prefix sets and neighbor sets.
However, the attack may be more difficult to detect as the routing However, the attack may be more difficult to detect as the routing
policy usage of route tags and intent must be understood to policy usage of route tags and intent must be understood to
recognize the breach. Conversely, the implications of prefix-set recognize the breach. Conversely, the implications of prefix set
or neighbor-set modification are easier to recognize. or neighbor set modification are easier to recognize.
/routing-policy/policy-definitions/policy- /routing-policy/policy-definitions/policy-
definition/statements/statement/conditions definition/statements/statement/conditions
Modification to the conditions could be used to mount a DoS attack Modification to the conditions could be used to mount a DoS attack
or other attack. An attacker may change a policy condition and or other attack. An attacker may change a policy condition and
redirect or drop traffic. As with prefix-sets, neighbor-sets, or redirect or drop traffic. As with prefix sets, neighbor sets, or
tag-sets, traffic redirection could be used as part of a more tag sets, traffic redirection could be used as part of a more
elaborate attack. elaborate attack.
/routing-policy/policy-definitions/policy- /routing-policy/policy-definitions/policy-
definition/statements/statement/actions definition/statements/statement/actions
Modification to actions could be used to mount a DoS attack or Modification to actions could be used to mount a DoS attack or
other attack. Traffic may be redirected or dropped. As with other attack. Traffic may be redirected or dropped. As with
prefix-sets, neighbor-sets, or tag-sets, traffic redirection could prefix sets, neighbor sets, or tag sets, traffic redirection could
be used as part of a more elaborate attack. Additionally, route be used as part of a more elaborate attack. Additionally, route
attributes may be changed to mount a second-level attack that is attributes may be changed to mount a second-level attack that is
more difficult to detect. more difficult to detect.
Some of the readable data nodes in the YANG module may be considered Some of the readable data nodes in the YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
/routing-policy/defined-sets/prefix-sets /routing-policy/defined-sets/prefix-sets
Knowledge of these data nodes can be used to ascertain which local Knowledge of these data nodes can be used to ascertain which local
prefixes are susceptible to a DoS attack. prefixes are susceptible to a DoS attack.
/routing-policy/defined-sets/prefix-sets /routing-policy/defined-sets/neighbor-sets
Knowledge of these data nodes can be used to ascertain local Knowledge of these data nodes can be used to ascertain local
neighbors against whom to mount a DoS attack. neighbors against whom to mount a DoS attack.
/routing-policy/policy-definitions/policy-definition/statements/ /routing-policy/policy-definitions/policy-definition/statements/
Knowledge of these data nodes can be used to attack the local Knowledge of these data nodes can be used to attack the local
router with a DoS attack. Additionally, policies and their router with a DoS attack. Additionally, policies and their
attendant conditions and actions should be considered proprietary attendant conditions and actions should be considered proprietary
and disclosure could be used to ascertain partners, customers, and and disclosure could be used to ascertain partners, customers, and
supplies. Furthermore, the policies themselves could represent suppliers. Furthermore, the policies themselves could represent
intellectual property and disclosure could diminish their intellectual property and disclosure could diminish their
corresponding business advantage. corresponding business advantage.
Routing policy configuration has a significant impact on network Routing policy configuration has a significant impact on network
operations, and as such, other YANG data models that reference operations, and as such, other YANG data models that reference
routing policies are also susceptible to vulnerabilities relating to routing policies are also susceptible to vulnerabilities relating to
the YANG data nodes specified above. the YANG data nodes specified above.
9. IANA Considerations 9. IANA Considerations
skipping to change at line 1709 skipping to change at line 1714
+--ro match-modified-attributes? boolean +--ro match-modified-attributes? boolean
+--rw policy-definition* [name] +--rw policy-definition* [name]
+--rw name string +--rw name string
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| +--rw call-policy? | +--rw call-policy?
| +--rw source-protocol? identityref | +--rw source-protocol? identityref
| +--rw match-interface | +--rw match-interface
| | +--rw interface? | | +--rw interface? if:interface-ref
| +--rw match-prefix-set | +--rw match-prefix-set
| | +--rw prefix-set? prefix-set/name | | +--rw prefix-set? prefix-set/name
| | +--rw match-set-options? match-set-options-type | | +--rw match-set-options?
| | match-set-options-type
| +--rw match-neighbor-set | +--rw match-neighbor-set
| | +--rw neighbor-set? | | +--rw neighbor-set?
| +--rw match-tag-set | +--rw match-tag-set
| | +--rw tag-set? | | +--rw tag-set?
| | +--rw match-set-options? match-set-options-type | | +--rw match-set-options?
| +--rw match-route-type* identityref | | match-set-options-type
| +--rw match-route-type
| +--rw route-type* identityref
| +--rw bp:bgp-conditions | +--rw bp:bgp-conditions
| +--rw bp:med-eq? uint32 | +--rw bp:med-eq? uint32
| +--rw bp:origin-eq? bt:bgp-origin-attr-type | +--rw bp:origin-eq? bt:bgp-origin-attr-type
| +--rw bp:next-hop-in* inet:ip-address-no-zone | +--rw bp:next-hop-in* inet:ip-address-no-zone
| +--rw bp:afi-safi-in* identityref | +--rw bp:afi-safi-in* identityref
| +--rw bp:local-pref-eq? uint32 | +--rw bp:local-pref-eq? uint32
| +--rw bp:route-type? enumeration | +--rw bp:route-type? enumeration
| +--rw bp:community-count | +--rw bp:community-count
| +--rw bp:as-path-length | +--rw bp:as-path-length
| +--rw bp:match-community-set | +--rw bp:match-community-set
| | +--rw bp:community-set? | | +--rw bp:community-set?
| | +--rw bp:match-set-options? | | +--rw bp:match-set-options?
| +--rw bp:match-ext-community-set | +--rw bp:match-ext-community-set
| | +--rw bp:ext-community-set? | | +--rw bp:ext-community-set?
| | +--rw bp:match-set-options? | | +--rw bp:match-set-options?
skipping to change at line 1750 skipping to change at line 1758
| +--rw metric-modification? | +--rw metric-modification?
| +--rw metric? uint32 | +--rw metric? uint32
+--rw set-metric-type +--rw set-metric-type
| +--rw metric-type? identityref | +--rw metric-type? identityref
+--rw set-route-level +--rw set-route-level
| +--rw route-level? identityref | +--rw route-level? identityref
+--rw set-route-preference? uint16 +--rw set-route-preference? uint16
+--rw set-tag? tag-type +--rw set-tag? tag-type
+--rw set-application-tag? tag-type +--rw set-application-tag? tag-type
+--rw bp:bgp-actions +--rw bp:bgp-actions
+--rw bp:set-route-origin?bt:bgp-origin-attr-type +--rw bp:set-route-origin?
| bt:bgp-origin-attr-type
+--rw bp:set-local-pref? uint32 +--rw bp:set-local-pref? uint32
+--rw bp:set-next-hop? bgp-next-hop-type +--rw bp:set-next-hop? bgp-next-hop-type
+--rw bp:set-med? bgp-set-med-type +--rw bp:set-med? bgp-set-med-type
+--rw bp:set-as-path-prepend +--rw bp:set-as-path-prepend
| +--rw bp:repeat-n? uint8 | +--rw bp:repeat-n? uint8
+--rw bp:set-community +--rw bp:set-community
| +--rw bp:method? enumeration | +--rw bp:method? enumeration
| +--rw bp:options? | +--rw bp:options?
| +--rw bp:inline | +--rw bp:inline
| | +--rw bp:communities* union | | +--rw bp:communities* union
skipping to change at line 1778 skipping to change at line 1787
+--rw bp:reference +--rw bp:reference
+--rw bp:ext-community-set-ref? +--rw bp:ext-community-set-ref?
Appendix B. Policy Examples Appendix B. Policy Examples
Below, we show examples of XML-encoded configuration data using the Below, we show examples of XML-encoded configuration data using the
routing policy and BGP models to illustrate both how policies are routing policy and BGP models to illustrate both how policies are
defined and how they can be applied. Note that the XML defined and how they can be applied. Note that the XML
[W3C.REC-xml11] has been simplified for readability. [W3C.REC-xml11] has been simplified for readability.
The following example shows how prefix-set and tag-set can be The following example shows how prefix set and tag set can be
defined. The policy condition is to match a prefix-set and a tag- defined. The policy condition is to match a prefix set and a tag
set, and the action is to accept routes that match the condition. set, and the action is to accept routes that match the condition.
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy <routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"> xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<defined-sets> <defined-sets>
<prefix-sets> <prefix-sets>
<prefix-set> <prefix-set>
<name>prefix-set-A</name> <name>prefix-set-A</name>
skipping to change at line 1851 skipping to change at line 1860
</statement> </statement>
</statements> </statements>
</policy-definition> </policy-definition>
</policy-definitions> </policy-definitions>
</routing-policy> </routing-policy>
</config> </config>
In the following example, all routes in the RIB that have been In the following example, all routes in the RIB that have been
learned from OSPF advertisements corresponding to OSPF intra-area and learned from OSPF advertisements corresponding to OSPF intra-area and
inter-area route types should get advertised into IS-IS level-2 inter-area route types should get advertised into IS-IS level 2
advertisements. advertisements.
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy <routing-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"> xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
<policy-definitions> <policy-definitions>
<policy-definition> <policy-definition>
<name>export-all-OSPF-prefixes-into-IS-IS-level-2</name> <name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
<statements> <statements>
<statement> <statement>
<name>term-0</name> <name>term-0</name>
<conditions> <conditions>
<match-route-type>ospf-internal-type</match-route-type> <match-route-type>
<route-type>ospf-internal-type</route-type>
</match-route-type>
</conditions> </conditions>
<actions> <actions>
<set-route-level> <set-route-level>
<route-level>isis-level-2</route-level> <route-level>isis-level-2</route-level>
</set-route-level> </set-route-level>
<policy-result>accept-route</policy-result> <policy-result>accept-route</policy-result>
</actions> </actions>
</statement> </statement>
</statements> </statements>
</policy-definition> </policy-definition>
skipping to change at line 1892 skipping to change at line 1903
OpenConfig route policy model. The authors would like to thank OpenConfig route policy model. The authors would like to thank
OpenConfig for their contributions, especially those of Anees Shaikh, OpenConfig for their contributions, especially those of Anees Shaikh,
Rob Shakir, Kevin D'Souza, and Chris Chase. Rob Shakir, Kevin D'Souza, and Chris Chase.
The authors are grateful for valuable contributions to this document The authors are grateful for valuable contributions to this document
and the associated models from Ebben Aires, Luyuan Fang, Josh George, and the associated models from Ebben Aires, Luyuan Fang, Josh George,
Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve
Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and John Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and John
Heasley. Heasley.
Thanks to Mahesh Jethanandani, John Scudder, Chris Bowers, and Tom Thanks to Mahesh Jethanandani, John Scudder, Alvaro Retana, Chris
Petch for their reviews and comments. Bowers, Tom Petch, and Kris Lambrechts for their reviews and
comments.
Authors' Addresses Authors' Addresses
Yingzhen Qu Yingzhen Qu
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
United States of America United States of America
Email: yingzhen.qu@futurewei.com Email: yingzhen.qu@futurewei.com
 End of changes. 43 change blocks. 
79 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/