]> China Unicom

Beijing China tongt5@chinaunicom.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Huawei

Beijing China gengnan@huawei.com

China Unicom

Beijing China wangn161@chinaunicom.cn

Huawei

Beijing China zhuangshunwan@huawei.com

China Unicom

Beijing China zhaoj501@chinaunicom.cn

rtg idr Internet-Draft This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rules monitoring and management.

Introduction Source Address Validation (SAV) can efficiently prevent source address spoofing-based attacks. SAV rules, which indicate the valid/invalid incoming interfaces of a specific source IP address or source IP prefix, are installed on routers for checking the source addresses of received packets. SAV rules can be generated by static configuration, management tools, or based on different routing protocols such as OSPFv2, OSPFv3, IS-IS, BGP, or their extensions . Due to the requirements of application scenarios, a router may use more than one tool at the same time to obtain SAV rules. Therefore, the rules on the router will be multi-sourced, which complicates management. What is more challenging is that there may exist conflicts among these multi-sourced rules and the rules can be dynamic. To facilitate SAV rules monitoring and management, this document proposes to extend BGP-LS () for advertising SAV rules on routers to a centralized server. The centralized server can effectively collect multi-sourced SAV rules from routers. For the purpose of advertising SAV rules within BGP-LS advertisements, two new NLRIs called SAV Rule NLRIs are proposed for IPv4 and IPv6, respectively.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

BGP-LS NLRI Advertisement for SAV Rules The "Link-State NLRI" defined in is extended to carry the SAV rule information. The format of "Link-State NLRI" is defined in as follows:

Link-State NLRI

This document defines two new NLRI Types known as SAV Rule NLRIs (values are TBD) for the advertisement of SAV rule Information.

SAV Rule NLRIs This document defines SAV Rule NLRI Types with their common format as shown in the following figure:

BGP-LS SAV Rule NLRI

The fields are defined as follows:

• Protocol-ID: Specifies the source of SAV rules in this NLRI. Protocol-ID values defined in RFC9552 can be reused.
• Identifier: An 8 octet value as defined in .
• Local Node Descriptors TLV: Contains Node Descriptors for the nodes storing SAV rules. This is a mandatory TLV in SAV Rule NLRIs. The Type is 256. The length of this TLV is variable. The value contains one or more Node Descriptor sub-TLVs defined in .
• SAV Rule Descriptors TLVs: There can be one or more SAV Rule Descriptors TLVs for carrying SAV rules.

SAV Rule Descriptors TLVs The SAV Rule Descriptor field is a set of TLV triplets. SAV Rule Descriptors TLVs identify a set of SAV rules having the same set of valid interfaces as defined in . The following TLVs are valid as SAV Rule Descriptors in the SAV Rule NLRI:

SAV Rule Descriptor TLVs

Interface Name TLV An Interface Name TLV is used to identify one valid interface of the source prefixes carried in SAV Prefix TLVs. The format of Interface Name TLV is as follows:

Interface Name TLV

There can be zero, one or more Interface Name TLVs in the SAV Rule Descriptor field.

Interface Group TLV An Interface Group TLV is to identify a group of valid interfaces of the source prefixes carried in SAV Prefix TLVs. The format of Interface Group TLV is as follows:

Interface Group TLV

The Interface Group value can have either a local meaning or a global meaning. On the one hand, it can be a local interface property on the target routers, and the meaning of it depends on the configurations of network administrator . On the other hand, a global meaning Group Identifier field carries an AS number, which represents all the interfaces connected to the neighboring AS with the AS number. Interface Group value can also be an Interface ID for identifying a specific interface. There can be zero, one or more Interface Group TLVs in the SAV Rule Descriptor field. Interface Group TLVs can be used together with Interface Name TLVs. When there is neither an Interface Name TLV nor an Interface Group TLV, the source prefixes carried in SAV Prefix TLVs are considered valid for all the interfaces on the router.

SAV Prefix TLV A SAV Prefix TLV carries one IP address prefix (IPv4 or IPv6). The format of SAV Prefix TLV is as follows:

SAV Prefix TLV

There can be one or more SAV Prefix TLVs in the SAV Rule Descriptor field. The IPv4 SAV Prefix TLVs will only appear in the IPv4 SAV Rule NLRI, and The IPv6 SAV Prefix TLVs are only for the IPv6 SAV Rule NLRI There can be more than one SAV mechanisms based on the same source (identified by Protocol-ID). In order to distinguish the different sources of rules in a more fine-grained manner, the Type field needs to be allocated for multiple values, and each value identifies a specific SAV mechanism based on the same source identified by Protocol-ID.

BGP-LS Attribute for SAV Mode The BGP-LS Attribute, an optional and non-transitive BGP Attribute, is used to carry the validation mode information of SAV rules {I-D.ietf-savnet-general-sav-capabilities}. The following SAV Mode Attribute TLV is defined for the BGP-LS Attribute associated with a SAV Rule NLRI:

SAV Mode TLV

The SAV Mode TLV carries a Mode Flag (M flag is shown in the figure and occupies two bits) describing the validation mode attribute.

• When M flag is set to 00, the mode is Mode 1: interface-based source prefix allowlist. The NLRI carries the source prefixes and interfaces. Only the carried prefixes are valid on the carried interfaces, and any other prefixes are invalid on these interfaces.
• When M flag is set to 01, the mode is Mode 2: interface-based source prefix blocklist. The NLRI carries the source prefixes and interfaces. Only the carried prefixes are invalid on the carried interfaces, and any other prefixes are valid on these interfaces.
• When M flag is set to 10, the mode is Mode 3: prefix-based interface allowlist. The NLRI carries the source prefixes and interfaces. Only the carried interfaces are valid for the carried prefixes, and any other interfaces are invalid for those prefixes. Any other prefixes will not be validated.
• When M flag is set to 11, the mode is Mode 4: prefix-based interface blocklist. The NLRI carries the source prefixes and interfaces. Only the carried interfaces are invalid for the carried prefixes, and any other interfaces are valid for those prefixes. Any other prefixes will not be validated.

BGP-LS Attribute for SAV Actions SAV actions in this document adopt the traffic filtering actions defined in and . Traffic filtering actions defined in [RFC 8955] include traffic-rate-bytes, traffic-rate-packets, traffic-action, rt-redirect, and traffic-marking, which are applicable to IPv4 and IPv6. Rt-redirect-ipv6 is a new traffic filtering action defined in [RFC 8956], which is applicable to IPv6. The encapsulation formats of SAV actions are consistent with the encapsulation formats defined in [RFC 8955] and [RFC 8956]. A SAV rule may match multiple SAV actions, and there may be conflicts among these SAV actions. Section 7.7 of [RFC 8955] describes the conflicts among Traffic filtering actions.

Example of Validation Modes and SAV rule NLRI Configuration In this section, we provide examples of how to configure SAV rule NLRI for the four validation modes. The SAV rule NLRI can carry zero, one, or multiple interfaces/interface groups and one or more prefixes.

Mode 1: Interface-based prefix allowlist In this mode, only the prefixes carried in the SAV rule NLRI are considered valid on the specified interface. All other prefixes arriving at this interface are considered invalid. Example:

• SAV rule NLRI: prefix = 192.168.1.0/24, interfaces = [Interface A]
• Validation: Any packet with a source prefix of 192.168.1.0/24 arriving at Interface A is valid. All other prefixes on Interface A are invalid.

Mode 2: Interface-based prefix blocklist In this mode, the prefixes carried in the SAV rule NLRI are considered invalid on the specified interface. All other prefixes arriving at this interface are considered valid. Example:

• SAV rule NLRI: prefix = 10.0.0.0/8, interfaces = [Interface B]
• Validation: Any packet with a source prefix of 10.0.0.0/8 arriving at Interface B is invalid. All other prefixes on Interface B are valid.

Mode 3: Prefix-based interface allowlist In this mode, for a specific source prefix, only the interfaces carried in the SAV rule NLRI are considered valid. Packets with this source prefix arriving at other interfaces are invalid. Other prefixes are not checked. Example:

• SAV rule NLRI: prefix = 172.16.0.0/16, interfaces = [Interface C, Interface D]
• Validation: Packets with a source prefix of 172.16.0.0/16 are valid only if they arrive at Interface C or Interface D. This prefix arriving at other interfaces is invalid. Other prefixes are not checked.

Mode 4: Prefix-based interface blocklist In this mode, for a specific source prefix, the interfaces carried in the SAV rule NLRI are considered invalid. Packets with this source prefix arriving at other interfaces are valid. Other prefixes are not checked. Example:

• SAV rule NLRI: prefix = 192.168.2.0/24, interfaces = [Interface E]
• Validation: Packets with a source prefix of 192.168.2.0/24 arriving at Interface E are invalid. This prefix arriving at other interfaces is valid. Other prefixes are not checked.

Procedures SAV rules only exist on the routers running SAV mechanisms/protocols and the controller, these routers are usually access routers or boundary routers. This document describes extensions to the BGP-LS NLRI. The Routers running SAV mechanisms/protocols establish BGP-LS sessions with the controller respectively to report multi-sourced SAV rules.

Advertisement of SAV Rules using BGP-LS

Based on Figure 8, the process of reporting SAV rules via BGP-LS is described as follows: Step 1: R1 and R2 run SAV mechanism/protocol, and generate multi-sourced SAV rules. Step 2: R1 and R2 respectively establish BGP-LS sessions with the controller. Step 3: R1 and R2 generate BGP-LS advertisements for the SAV Rule NLRIs. Step 4: R1 and R2 report multi-sourced SAV rules to the controller through the sav rule NLRIs (as defined in Section 2). This enables the controller to monitor and manage multi-sourced SAV rules.

Manageability Considerations The Existing BGP operational and management procedures apply to this document. No new procedures are defined in this document. The considerations as specified in apply to this document.

IANA Considerations This section describes the code point allocation by IANA for this document.

"BGP-LS NLRI-Types" registry This document requests assigning code-points from the registry for SAV Rule NLRIs:

"BGP-LS SAV Rule Descriptors TLVs" registry This document requests assigning code-points from the registry for BGP-LS SAV Rule Descriptors TLVs based on .

"BGP-LS SAV Mode Attribute TLV" registry This document requests assigning a code-point from the registry for the BGP-LS SAV Mode attribute TLV.

Security Considerations Procedures and protocol extensions defined in this document do not affect the base BGP security model. See for details. The security considerations of the base BGP-LS specification as described in also apply.

References Normative References In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Zhongguancun Laboratory China Mobile Tsinghua University Huawei Technologies Zhongguancun Laboratory The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way. Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory Zhongguancun Laboratory This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. Individual Nokia Arrcus, Inc Juniper Networks Huawei The BGP Flow Specification (flowspec) Network Layer Reachability Information (BGP NLRI) extension (draft-ietf-idr-rfc5575bis) is used to distribute traffic flow specifications into BGP. The primary application of this extension is the distribution of traffic filtering policies for the mitigation of distributed denial of service (DDoS) attacks. By default, flow specification filters are applied on all forwarding interfaces that are enabled for use by the BGP flowspec extension. A network operator may wish to apply a given filter selectively to a subset of interfaces based on an internal classification scheme. Examples of this include "all customer interfaces", "all peer interfaces", "all transit interfaces", etc. This document defines BGP Extended Communities (RFC4360) that allow such filters to be selectively applied to sets of forwarding interfaces sharing a common group identifier. The BGP Extended Communities carrying this group identifier are referred to as the BGP Flowspec "interface-set" Extended Communities. Huawei Tsinghua University China Unicom Zhongguancun Laboratory BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules.