]> New H3C Technologies

China linchangwang.04414@h3c.com

China Telecom

Beiqijia Town, Changping District Beijing Beijing 102209 China wangaj3@chinatelecom.cn

rtg IDR Working Group YANG, BGP, Flowspec This document defines a YANG data model for the BGP Flow Specification (Flowspec) address families (RFC8955 and RFC8956). The model augments the BGP YANG model to add the IPv4 Flow Specification (AFI, SAFI = 1, 133) and IPv6 Flow Specification (AFI, SAFI = 2, 133) address families, including Flowspec-specific configuration, the Flow Specification RIB, and per-neighbor Adj-RIBs.

Introduction defines BGP Flow Specification (Flowspec) for IPv4 (AFI, SAFI = 1, 133), which allows the dissemination of traffic filtering rules as BGP NLRI. extends Flowspec to IPv6 (AFI, SAFI = 2, 133). The revised validation procedure for Flowspec routes is defined in . The BGP YANG model defines a vendor-neutral YANG model for BGP protocol configuration, policy, and operational state, including a Routing Information Base (RIB). It defines an extension pattern for adding new address families: a new identity derived from 'afi-safi-type' in the IANA-maintained 'iana-bgp-afi-safi-types' module, together with augmentations of the AFI/SAFI lists in the global configuration tree and in the RIB tree (Appendix B of ). This document applies this address family extension pattern to Flowspec, whose NLRI is carried as MP_REACH_NLRI/MP_UNREACH_NLRI per . It defines a YANG module, "ietf-bgp-flowspec", that registers the Flowspec address family identities, adds Flowspec-specific configuration and RIB augmentation, and defines reusable type definitions and groupings for Flow Specification match components and traffic filtering actions.

Terminology and Notation Conventions

Terminology The following terms are used in this document:

• Flowspec: BGP Flow Specification, the dissemination of traffic filtering rules via BGP NLRI .
• AFI/SAFI: Address Family Identifier / Subsequent Address Family Identifier .
• Loc-RIB: The local RIB containing the routes selected by the local BGP speaker.
• Adj-RIB-In / Adj-RIB-Out: Per-neighbor routing information bases for received and advertised routes, respectively.

Tree Diagrams Tree diagrams used in this document follow the notation defined in .

Data Model Overview This document defines one YANG module: "ietf-bgp-flowspec". The "ietf-bgp-flowspec" YANG module extends the BGP YANG model with the Flowspec address families. It lives under the BGP protocol instance, reusing the base model's AFI/SAFI configuration structure, RIB structure, and route annotations. It includes:

• Flowspec address family identities: 'ipv4-flowspec' (AFI, SAFI = 1, 133) and 'ipv6-flowspec' (AFI, SAFI = 2, 133) .
• Flowspec-specific configuration for the global AFI/SAFI, such as the prefix limit and the route-origin validation control.
• The Flowspec RIB: a Loc-RIB of Flow Specifications selected for local enforcement and per-neighbor Adj-RIB-In/Out tables (pre- and post-policy).
• Reusable type definitions and groupings for Flow Specification match components (Section 4 of ) and traffic filtering actions (Section 7 of ).

Network management applications enable Flowspec on a BGP instance by creating an entry in the global 'afi-safi' list with one of the Flowspec identities as the 'name', following the same procedure as for any other address family in the base model.

BGP Flow Specification YANG Module

Tree View The full tree of the "ietf-bgp-flowspec" YANG module is provided in . The following subsections list the subtree structures.

Overall Structure The overall tree structure of the "ietf-bgp-flowspec" YANG module is shown in . The "ietf-bgp-flowspec" YANG module augments the BGP YANG module "ietf-bgp" at two points. The first augmentation adds Flowspec-specific configuration to the global AFI/SAFI list; the second augmentation adds the Flowspec RIB to the RIB AFI/SAFI tree. Both augmentations are active only when the AFI/SAFI name is derived from the 'ipv4-flowspec' or 'ipv6-flowspec' identities.

Overall BGP Flow Specification Tree Structure

The first augmentation has a container 'flowspec', which provides the Flowspec-specific configuration for a Flowspec AFI/SAFI instance. The second augmentation has a container 'flowspec', which holds the Flowspec RIB: the Loc-RIB of Flow Specifications selected for local enforcement, and the per-neighbor Adj-RIB tables.

Flowspec Configuration The Flowspec configuration structure is shown in .

Flowspec Configuration Subtree Structure

The configuration data nodes of the container 'flowspec' are described as follows: 'prefix-limit': The prefix limit imported from the base model's 'mp-all-afi-safi-common' grouping , which limits the number of Flowspec routes accepted from a peer. 'validate-route-origin': Enables the Flowspec route validation procedure of Section 6 of , or the revised validation procedure of when the implementation supports it. The default is 'true', consistent with the recommendation that Flowspec routes be validated before they are used for traffic filtering.

Flowspec RIB The Flowspec RIB structure is shown in .

Flowspec RIB Subtree Structure

The 'loc-rib' contains the set of Flow Specifications selected for local enforcement. The route entry is keyed by the encoded Flow Specification NLRI ('flow-spec-components'); because the NLRI encoding is canonical (components in strictly increasing type order per Section 4.2 of [RFC8955]), the encoded NLRI uniquely identifies the route across implementations. The 'active' leaf indicates whether the Flow Specification is valid and enforced locally. The 'neighbors' container lists the Flowspec neighbors. For each neighbor, the model provides four tables: Adj-RIB-In pre-policy and post-policy, and Adj-RIB-Out pre-policy and post-policy. Each table contains a list of routes keyed by 'flow-spec-components' and 'path-id'. The structure of an Adj-RIB route entry is shown in .

Flowspec Adj-RIB Route Entry Subtree Structure

Route entries reuse the base model's route-annotation groupings ('bgp-common-route-annotations-state', 'bgp-adj-rib-attr-state', attribute and community index references, 'bgp-unknown-attr-top', and 'rib-ext-route-annotations') , so that operators see the same operational state attributes for Flowspec routes as for any other address family. The Adj-RIB-In post-policy table additionally uses the 'bgp-adj-rib-in-post-route-annotations-state' grouping, which provides the 'best-path' flag.

Match Components and Actions The module defines the 'flowspec-match' grouping, which models the Flow Specification match components of Section 4 of as a YANG choice with one case per component type, and the 'flowspec-actions' grouping, which models the traffic filtering actions of Section 7 of (traffic-rate, traffic-action sample/log bits, redirect, and traffic-marking). These groupings are defined in this revision as reusable building blocks for policy models and for future revisions of this document that attach decoded match and action trees to the configuration and operational state. This initial version provides the Flowspec address family infrastructure as a basic subset: the full numeric-operator and set-operation semantics of , as well as the relation between the match and action groupings and the routing policy framework of , are left to future revisions of this document.

YANG Module This YANG module has normative references to , , , , , and (the 'ysv:version' extension used to tag the module revision with a semantic version). WG List: IDR Author: Changwang Lin "; description "This module contains YANG definitions for the BGP Flow Specification address families. It extends the BGP YANG model defined in RFC XXXX with the IPv4 Flow Specification (AFI, SAFI = 1, 133) and IPv6 Flow Specification (AFI, SAFI = 2, 133) address families, per RFC 8955 and RFC 8956, and adds the corresponding RIB contents. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC YYYY; see the RFC itself for full legal notices. All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters)."; revision 2026-10-29 { description "Initial Version"; ysv:version 0.0.1; reference "RFC YYYY: YANG Model for BGP Flow Specification"; } /* * Features. */ feature flowspec-redirect-ip { description "The implementation supports the Redirect-to-IP extended community as a Flow Specification action."; reference "RFC AAAA: BGP Flow-Spec Redirect-to-IP Action"; } /* * Identities. */ identity ipv4-flowspec { base bast:afi-safi-type; description "IPv4 Flow Specification (AFI, SAFI = 1, 133)."; reference "RFC 8955: Dissemination of Flow Specification Rules"; } identity ipv6-flowspec { base bast:afi-safi-type; description "IPv6 Flow Specification (AFI, SAFI = 2, 133)."; reference "RFC 8956: Dissemination of Flow Specification Rules for IPv6"; } /* * Typedefs. */ typedef component-type { type enumeration { enum destination-prefix { value 1; description "Destination prefix component (Type 1)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.1"; } enum source-prefix { value 2; description "Source prefix component (Type 2)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.2"; } enum ip-protocol { value 3; description "IP protocol component (Type 3)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.3"; } enum port { value 4; description "Port component (Type 4)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.4"; } enum destination-port { value 5; description "Destination port component (Type 5)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.5"; } enum source-port { value 6; description "Source port component (Type 6)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.6"; } enum icmp-type { value 7; description "ICMP type component (Type 7)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.7"; } enum icmp-code { value 8; description "ICMP code component (Type 8)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.8"; } enum tcp-flags { value 9; description "TCP flags component (Type 9)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.9"; } enum packet-length { value 10; description "Packet length component (Type 10)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.10"; } enum dscp { value 11; description "DSCP component (Type 11)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.11"; } enum fragment { value 12; description "Fragment component (Type 12)."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.12"; } enum flow-label { value 13; description "Flow label component (Type 13); IPv6 only."; reference "RFC 8956: Dissemination of Flow Specification Rules for IPv6, Section 3.7"; } } description "Type of a Flow Specification component. The value of the enumeration corresponds to the Flow Specification component type code defined in RFC 8955 and RFC 8956."; } typedef tcp-flags-bits { type bits { bit fin { position 0; description "FIN flag (bit position 0 in the wire-format octet, counted from the least significant bit)."; } bit syn { position 1; description "SYN flag (bit position 1)."; } bit rst { position 2; description "RST flag (bit position 2)."; } bit psh { position 3; description "PSH flag (bit position 3)."; } bit ack { position 4; description "ACK flag (bit position 4)."; } bit urg { position 5; description "URG flag (bit position 5)."; } bit ece { position 6; description "ECE flag (bit position 6)."; } bit cwr { position 7; description "CWR flag (bit position 7)."; } bit ns { position 8; description "Nonce Sum flag (bit position 8)."; } } description "TCP flags as defined in RFC 8955, Section 4.2.2.9. Bit positions follow the bit-numbering convention of RFC 8955, where bit 0 is the least significant bit of the TCP flags octet."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.9"; } typedef fragment-bits { type bits { bit dont-fragment { position 0; description "Match if the Don't Fragment (DF) bit is set."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.12"; } bit is-fragment { position 1; description "Match if the packet is a fragment other than the first fragment."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.12"; } bit first-fragment { position 2; description "Match if the packet is a first fragment."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.12"; } bit last-fragment { position 3; description "Match if the packet is a last fragment (IF bit defined in RFC 8956 for IPv6)."; reference "RFC 8956: Dissemination of Flow Specification Rules for IPv6, Section 3.6"; } } description "Fragment flags used by the fragment component (Type 12). For IPv4, the four bits map to the FF (fragment) bit-field of RFC 8955; for IPv6, the last-fragment bit corresponds to the IF (last fragment) bit introduced by RFC 8956."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 4.2.2.12 RFC 8956: Dissemination of Flow Specification Rules for IPv6, Section 3.6"; } typedef flow-spec-value-op { type bits { bit less-than { position 0; description "op bit 1: less-than."; } bit greater-than { position 1; description "op bit 2: greater-than."; } bit equal { position 2; description "op bit 3: equal."; } bit and { position 3; description "op bit 4: logical AND of the previous operand."; } bit not { position 4; description "op bit 5: negate this operand."; } } description "Numeric operator bits as encoded in the least significant 5 bits of the 'op' byte defined in Section 4.2.1 of RFC 8955."; } /* * Groupings. */ grouping numeric-operand { description "A single numeric operand as defined in Section 4.2.1 of RFC 8955, together with its operator bits."; leaf op { type flow-spec-value-op; description "Operator flags for this operand."; } leaf value { type uint16; description "Numeric operand value."; } } grouping flowspec-match { description "Flow Specification match components, keyed by the component type as defined in Section 4.2.2 of RFC 8955. A packet matches the Flow Specification when it matches all components present. The YANG tree models each component type as a distinct choice case; NLRI encoding follows the component type ordering rules of Section 4 of RFC 8955."; choice component { description "One of the Flow Specification component types. Only a single component of a given type code may be present in a Flow Specification rule, per Section 4.2 of RFC 8955."; case destination-prefix { leaf destination-prefix { type inet:ip-prefix; description "Destination prefix component (Type 1 for IPv4; Type 1 in the IPv6 Flow Specification NLRI per RFC 8956 with an expanded encoding when the prefix length exceeds 64 bits)."; } } case source-prefix { leaf source-prefix { type inet:ip-prefix; description "Source prefix component (Type 2 for IPv4; Type 2 in the IPv6 Flow Specification NLRI per RFC 8956 with an expanded encoding when the offset is non-zero)."; } } case ip-protocol { leaf-list ip-protocol { type uint8; description "IP protocol values (Type 3). Multiple values and negation are encoded per the numeric operator rules of RFC 8955, Section 4.2."; } } case port { leaf-list port { type inet:port-number; description "Source or destination port component (Type 4). Matches either the source or the destination TCP or UDP port of a packet."; } } case destination-port { leaf-list destination-port { type inet:port-number; description "Destination port component (Type 5)."; } } case source-port { leaf-list source-port { type inet:port-number; description "Source port component (Type 6)."; } } case icmp-type { leaf-list icmp-type { type uint8 { range "0..255"; } description "ICMP type component (Type 7)."; } } case icmp-code { leaf-list icmp-code { type uint8 { range "0..255"; } description "ICMP code component (Type 8)."; } } case tcp-flags { leaf tcp-flags { type tcp-flags-bits; description "TCP flags component (Type 9). The value is the byte used in the operand; the match/mask operator bits of RFC 8955 Section 4.2.1.2 apply."; } } case packet-length { leaf-list packet-length { type uint16; description "Packet length component (Type 10): the total IP packet length, excluding the Layer 2 framing but including the IP header."; } } case dscp { leaf-list dscp { type inet:dscp; description "DSCP component (Type 11)."; } } case fragment { leaf fragment { type fragment-bits; description "Fragment component (Type 12)."; } } case flow-label { leaf-list flow-label { type uint32 { range "0..1048575"; } description "IPv6 flow label component (Type 13), per RFC 8956. Applicable only to the IPv6 Flow Specification address family."; } } } } grouping flowspec-actions { description "Traffic filtering actions for a Flow Specification rule, encoded in Extended Communities as defined in Section 7 of RFC 8955."; container traffic-rate { description "Traffic rate action (transitive extended community, subtype 0x8006). The rate is expressed in bytes per second as IEEE 754 single-precision floating point."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 7.1"; leaf rate { type decimal64 { fraction-digits 12; } units "bytes per second"; description "Traffic rate in bytes per second. A rate of 0 will discard all traffic matched by the Flow Specification."; } leaf sample { type boolean; default "false"; description "When true, packets matching the Flow Specification must be sampled, per Section 7.3 of RFC 8955."; } leaf log { type boolean; default "false"; description "When true, matching packets must be logged, per Section 7.3 of RFC 8955."; } } container redirect { description "Redirect action. The Flow Specification rule redirects matching traffic to a VRF, to an IP address, or to another Next-Hop."; leaf route-target { type string { pattern '(0|([1-9][0-9]*)):[0-9]+|' + '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|' + '25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|' + '2[0-4][0-9]|25[0-5]):([0-9]+)|' + '([0-9a-fA-F]{1,4}:){1,2}[0-9a-fA-F]{1,4}:[0-9]+'; } description "Route Target extended community of the VRF to which the traffic is redirected, per Section 7.4 of RFC 8955."; } leaf ip-address { if-feature "flowspec-redirect-ip"; type inet:ip-address; description "IPv4 or IPv6 address to which matching traffic is redirected, per the Redirect-to-IP action of RFC AAAA."; } } container traffic-marking { description "Traffic marking action (transitive extended community, subtype 0x8009), per Section 7.5 of RFC 8955."; leaf dscp { type inet:dscp; description "The DSCP value to set in transit IP packets. The value 0xffffffff (reserved) has no meaning in this model and is not used."; } } } /* * Data nodes. */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bgp:bgp/bgp:global/" + "bgp:afi-safis/bgp:afi-safi" { when "derived-from-or-self(bgp:name, 'bfs:ipv4-flowspec') or " + "derived-from-or-self(bgp:name, 'bfs:ipv6-flowspec')" { description "This augmentation is valid for a Flow Specification AFI/SAFI instance."; } description "BGP Flow Specification specific configuration that applies to the global AFI/SAFI."; container flowspec { description "Flow Specification specific configuration for the AFI/SAFI."; uses bgp:mp-all-afi-safi-common; leaf validate-route-origin { type boolean; default "true"; description "When true, the local system applies the validation procedure of Section 6 of RFC 8955 (or the revised validation procedure of RFC 9117 when configured) to Flow Specification routes received from BGP peers."; reference "RFC 8955: Dissemination of Flow Specification Rules, Section 6 RFC 9117: Revised Validation Procedure for BGP Flow Specifications"; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bgp:bgp/bgp:rib/" + "bgp:afi-safis/bgp:afi-safi" { when "derived-from-or-self(bgp:name, 'bfs:ipv4-flowspec') or " + "derived-from-or-self(bgp:name, 'bfs:ipv6-flowspec')" { description "This augmentation is valid for a Flow Specification AFI/SAFI instance."; } description "BGP Flow Specification RIB augmentation."; container flowspec { config false; description "Container for the BGP Flow Specification RIB."; container loc-rib { description "The Flow Specification Loc-RIB: the set of Flow Specifications selected for local enforcement."; container routes { config false; description "Enclosing container for the list of Flow Specification routes."; list route { key "flow-spec-components"; description "List of Flow Specification routes in the Loc-RIB, keyed by the encoded Flow Specification NLRI."; leaf flow-spec-components { type binary; description "The Flow Specification NLRI encoded per Section 4 of RFC 8955 (or Section 3 of RFC 8956 for IPv6), including the component type codes and operator/operand bytes. The encoding of a Flow Specification is canonical (components in strictly increasing type order per Section 4.2 of RFC 8955), so the encoded NLRI uniquely identifies the route across implementations."; } leaf active { type boolean; description "Indicates whether the Flow Specification is valid and enforced locally."; } uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-loc-rib-common-attr-refs; uses bgp:rib-ext-route-annotations; } } } container neighbors { description "Enclosing container for the neighbor list."; list neighbor { key "neighbor-address"; description "List of Flow Specification neighbors of the local BGP speaker."; leaf neighbor-address { type inet:ip-address; description "IP address of the BGP neighbor or peer."; } container adj-rib-in-pre { description "Per-neighbor table containing the Flow Specification NLRI updates received from the neighbor before any local input policy rules have been applied."; uses flowspec-adj-rib; } container adj-rib-in-post { description "Per-neighbor table containing the Flow Specification paths received from the neighbor that are eligible for best-path selection after local input policy rules have been applied."; uses flowspec-adj-rib-in-post; } container adj-rib-out-pre { description "Per-neighbor table containing Flow Specification paths eligible for sending to the neighbor before output policy rules have been applied."; uses flowspec-adj-rib; } container adj-rib-out-post { description "Per-neighbor table containing Flow Specification paths eligible for sending to the neighbor after output policy rules have been applied."; uses flowspec-adj-rib; } } } } } grouping flowspec-adj-rib { description "Common structural grouping for each Flow Specification Adj-RIB table."; container routes { config false; description "Enclosing container for the list of Flow Specification routes in the routing table."; list route { key "flow-spec-components path-id"; description "List of Flow Specification routes in the table, keyed by the Flow Specification NLRI and path-id to distinguish multiple routes for the same NLRI (e.g., when BGP add-paths is enabled)."; leaf flow-spec-components { type binary; description "The Flow Specification NLRI encoded per Section 4 of RFC 8955 (or Section 3 of RFC 8956 for IPv6), including the component type codes and operator/operand bytes. The encoding of a Flow Specification is canonical (components in strictly increasing type order per Section 4.2 of RFC 8955), so the encoded NLRI uniquely identifies the route across implementations."; } uses bgp:bgp-adj-rib-attr-state; uses bgp:bgp-adj-rib-common-attr-refs; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } } grouping flowspec-adj-rib-in-post { description "Common structural grouping for the Flow Specification Adj-RIB-In post-policy table."; container routes { config false; description "Enclosing container for the list of Flow Specification routes in the routing table."; list route { key "flow-spec-components path-id"; description "List of Flow Specification routes in the table, keyed by the Flow Specification NLRI and path-id to distinguish multiple routes for the same NLRI (e.g., when BGP add-paths is enabled)."; leaf flow-spec-components { type binary; description "The Flow Specification NLRI encoded per Section 4 of RFC 8955 (or Section 3 of RFC 8956 for IPv6), including the component type codes and operator/operand bytes. The encoding of a Flow Specification is canonical (components in strictly increasing type order per Section 4.2 of RFC 8955), so the encoded NLRI uniquely identifies the route across implementations."; } uses bgp:bgp-adj-rib-attr-state; uses bgp:bgp-adj-rib-common-attr-refs; uses bgp:bgp-common-route-annotations-state; uses bgp:bgp-adj-rib-in-post-route-annotations-state; uses bgp:bgp-unknown-attr-top; uses bgp:rib-ext-route-annotations; } } } }]]>

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-bgp-flowspec" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. In particular, the ability to enable or disable a Flowspec address family, to change the 'validate-route-origin' setting, or to modify prefix limits may lead to traffic being filtered, redirected, or dropped. The following subtrees and data nodes have particular sensitivities/vulnerabilities: Disabling 'validate-route-origin' weakens the validation procedure of Section 6 of , allowing unvalidated Flowspec routes to affect traffic handling. Changing prefix limits may cause BGP sessions to be torn down or allow an excessive number of Flowspec routes to be installed, exhausting device resources. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The Flowspec RIB contents (the 'flow-spec-components' NLRI, the per-neighbor Adj-RIB tables, and the route annotations) reveal traffic filtering policy information about the network, which may be considered sensitive. The following subtrees and data nodes have particular sensitivities/vulnerabilities: There are no particularly sensitive RPC or action operations. The Flowspec mechanism itself allows traffic to be filtered or redirected on the basis of rules disseminated via BGP; the security considerations of , , and apply to any deployment that uses the data model defined in this document.

IANA Considerations

BGP Flow Specification YANG Module Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group (): IANA is requested to register the following YANG module in the "YANG Module Names" registry () within the "YANG Parameters" registry group.

References Normative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can still interoperate with a router that doesn't support the extensions. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. This document defines a new BGP Network Layer Reachability Information (NLRI) encoding format that can be used to distribute traffic Flow Specification rules. The encoding format is generic and can be applied to any address family. This document additionally defines the required procedures to enable the dissemination of Flow Specification rules over a BGP session for IPv4 and VPNv4. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the dissemination of traffic Flow Specification rules for IPv4. This document provides an extension for the dissemination of the rules for IPv6. RFC 5575 defines a validation procedure for the BGP Flow Specification routes that are used to ensure that a BGP speaker that receives a Flow Specification route is authorized to action it. This document revises the validation procedure defined in RFC 5575. RFC 9911, DOI 10.17487/RFC9911 Kloud Services Arrcus Huawei HPE This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. HPE Nokia Nokia Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard, RFC 8955, defines a redirect-to-VRF (Virtual Routing and Forwarding) action for policy-based forwarding. This mechanism can be difficult to use, particularly in networks without Layer 3 VPN infrastructure. This document specifies a new Redirect-to-IP flow-spec action to redirect or copy matching traffic toward a specific IP address. Cisco Systems, Inc. Cisco Systems, Inc. Equinix Ericsson Nokia Everything OPS This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 9907, and 8525. Informative References This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this purpose from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. This document obsoletes RFC 1771. This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic policy framework that can be augmented with protocol-specific policy defined in protocol-specific YANG models. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.

Full Tree of BGP Flow Specification YANG Module