]> Huawei

Beijing China gengnan@huawei.com

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

China Unicom

Beijing China tongt5@chinaunicom.cn

Zhongguancun Laboratory

Beijing China huangmq@mail.zgclab.edu.cn

Routing IDR SAV 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.

Introduction Source Address Validation (SAV) is an efficient method for preventing source address spoofing-based attacks. SAV rules indicate the valid/invalid incoming interfaces of a specific source IP address or source IP prefix. The rules can be deployed on edge routers, border routers, or aggregation routers for checking the validity of intra-domain and inter-domain packets. For invalid packets, filtering actions can be taken such as block, rate-limit, redirect, and sampling . There are many mechanisms that can distributedly generate SAV rules on routers (, , , , and ). To facilitate flexible SAV management and improve validation accuracy, centralized SAV rule dissemination is also needed , which can be a complementary to existing distributed SAV mechanisms. BGP FlowSpec is a convenient and flexible tool for traffic filtering/controlling (, ). It propagates traffic flow information for different traffic control purposes through the BGP protocol extension. Existing BGP FlowSpec has supported source prefix matching and various traffic filtering actions but does not support binding valid/invalid incoming interfaces to source prefixes. With some extensions, BGP FlowSpec can be used for SAV rule dissemination. This document defines a new flow specification component named Incoming-Interface-Set. SAV rules can be disseminated through BGP FlowSpec by carrying the new flow specification component together with Source Prefix component (or Source Prefix Group component). Traffic filtering actions of existing BGP FlowSpec can also be carried to specify the actions for the packets failing source address validation. This document also defines a new action which indicates where to install the SAV rules in the data-plane. BGP FlowSpec with the new extensions can be used to disseminate SAV rules to remote routers, which acts as a supplement of existing SAV mechanisms and help improve SAV accuracy.

Terminology SAV: Source address validation SAV Rule: The rule that indicates the valid/invalid incoming interfaces of a specific source IP address or source IP prefix. Group Identifier: An ID value that identifies a set of interfaces on the target routers (e.g., all the interfaces connected to customer ASes).

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 FlowSpec for SAV A SAV rule typically has a format of <source prefix, interface set, validity indicator>. Source prefix is for matching specific packets. Interface set represents a set of physical interfaces from which the packets arrive. Validity indicator indicates whether the packets matching the source prefix and arrival interface are valid or invalid. So, validity indicator has a value of either valid or invalid. For example, the rule <P1, [intf1, intf2], valid> means the source prefix P1 must arrive the router at interface Intf1 or Intf2, otherwise, P1 is invalid. For the packets with invalid source addresses/prefixes, the filtering actions, such as block, rate-limit, and redirect, can be taken . SAV rules can be disseminated to Edge/Border/Aggregation routers (i.e., target routers) through BGP FlowSpec, as shown in the figure below. The controller is used to set up BGP connection with the routers in a SAV-deployed AS or domain. Existing BGP FlowSpec has supported source prefix matching and various traffic filtering actions. There are also some proposals that group source prefixes by AS numbers () or community values for good scalability and efficiency. An AS number or a community value can represent a set of source prefixes. For simplicity, the term of Source Prefix Group component will be used to represent such source prefix groups in BGP FlowSpec. However, existing BGP FlowSpec does not support binding valid/invalid incoming interfaces to source prefixes. Besides, BGP FlowSpec rules are mostly installed in ACL table/firewall table. In contrast, SAV rules may be installed in differect positions of data-plane, such as ACL/firewall, FIB, or independent SAV table. Some extensions are needed by BGP FlowSpec for efficient SAV rule dissemination.

Extensions to BGP FlowSpec

Incoming-Interface-Set Component

Interface Set To facilitate scalability, the interface set in SAV rules can be grouped. For example, the interfaces can be grouped as:

• Subnet interface set that contains the interfaces connecting a target subnet.
• All customer AS interfaces set or the customer AS interfaces set of a customer AS.
• All lateral peer AS interfaces set or the lateral peer AS interfaces set of a lateral peer AS.
• All transit provider AS interfaces set or the transit provider AS interfaces set of a transit provider AS.

These interface set can be identified by a Group Identifier for easy management. A Group Identifier can have either local meaning or 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 AS number, which represents all the interfaces connected to the neighboring AS with the AS number. Any interface may be associated with one or more Group Identifiers.

Incoming-Interface-Set Encoding The new flow specification component is encoded in the BGP Flowspec NLRI. It appears together with Source Prefix component or Source Prefix Group component. The following new component type is defined:

• Type TBD1: Incoming-Interface-Set
• Encoding: <type (1 octet), [numeric_op, value]+>

The new component contains a set of {numeric_op, value} pairs that are used to match the Incoming-Interface-Set (i.e., the valid or invalid interfaces of a specific source prefix). The numeric operator (numeric_op) is encoded as (see RFC8955 sec. 4.2.1.1): The value field is encoded as: The length of the value field can be 1, 2, 4, or 8 octets, which depends on the len in numeric_op. Particularly, the most two significant bits in the value field are two flags:

• Flag V (1 bit): The most significant bit in the value field. If unset, it means the interface set is invalid for the source prefix. If set, the identified interface set is valid for the source prefix.
• Flag G (1 bit): The second most significant bit in the value field. If unset, the Group Identifier has a local meaning. If set, the Group Identifier has a global meaning, i.e., the Group Identifier field stores an AS number.

Zero Group Identifier (i.e., Group Identifier equaling 0) is a reserved value and does not need to be configured. A NLRI may carry one zero Group Identifier and several non-zero Group Identifiers. The zero Group Identifier means any other interfaces on the target router except the interfaces indicated by non-zero Group Identifiers in the same NLRI. If a NLRI only contains a zero Group Identifier and has no non-zero Group Identifiers, the zero Group Identifier will represent all interfaces on the target router. A NLRI MUST not contain more than one zero Group Identifiers, otherwise, the whole NLRI will be ignored. The bits lt, gt, and eq can be combined to match a specific Group Identifier or a range of Group Identifiers (e.g., greater than Group ID1 and less than Group ID2). For a range of Group Identifiers, their corresponding flags (i.e., V and R) MUST be the same. Otherwise, the whole NLRI will be ignored. If a receiving BGP speaker cannot support this new flow specification component type, it MUST discard the NLRI value field that contains such unknown components (section 10 of ). A NLRI value field MUST only contain a Source Prefix component (or Source Prefix Group component) and an Incoming-Interface-Set component. If the NLRI value does not satisfy this principle, the receiving BGP speaker SHOULD discard the NLRI value field (see Section ). Since the NLRI field encoding (Section 4 of ) is defined in the form of a 2-tuple <length, NLRI value>, message decoding can skip over the unknown NLRI value and continue with subsequent remaining NLRIs.

Example Example: A Flow Specification NLRI encoding for "incoming interfaces {Group ID range [1, 20]} are valid for the packets from 203.0.113.0/24, and other local interfaces are invalid for the source prefix". Decoded: = | +-------+------------+------------------------------------+ | 0x81 | value | V=1, R=0, ID=1 | +-------+------------+------------------------------------+ | 0x45 | numeric_op | "AND", value size=1, <= | +-------+------------+------------------------------------+ | 0x94 | value | V=1, R=0, ID=20 | +-------+------------+------------------------------------+ | 0x81 | numeric_op | end-of-list, value size=1, == | +-------+------------+------------------------------------+ | 0x00 | value | V=0, R=0, ID=0 | +-------+------------+------------------------------------+ ]]> This constitutes an NLRI with an NLRI length of 12 octets.

Rule-Position Extended Community This document proposes a new BGP Route Target extended community called the "rule-position". This document expands the definition of the Route Target extended community to allow a new value of high order octet (Type field) to be 0x07 for the transitive flowspec interface-set extended community, or 0x47 for the non-transitive flowspec interface-set extended community. These are in addition to the values specified in [RFC4360]. The Rule-Position extended community is encoded as follows: The Position field indicates that where to install the SAV rule. Some values can be:

• 0: ACL
• 1: FIB
• 2: Independent SAV table
• Other values: reserved

Since FIB and Independent SAV table can only match address prefix and interface, the Rule-Position extended community with the Position field equaling 1 or 2 means the NLRI is specific for SAV rule dissemination, and the unrelated components (not Source Prefix (Group) or Incoming-Interface-Set) SHOULD NOT appear in the NLRI.

General Usages The Incoming-Interface-Set component can be used as a general flow specification instead of SAV-specific component. Other components can be combined with the new component for matching specific traffic.

Error Handling TBD

IANA Considerations

Incoming-Interface-Set Component This document requests a new entry in "Flow Spec component types registry" with the following values:

Rule-Position Extended Community This document requests a new subtype TBD2 within Transitive and Non-Transitive Extended Communities. This sub-type shall be named "rule-position", with a reference to this document.

Security Considerations TBD.

Acknowledgements Many thanks to the comments from Shunwan Zhuang, Susan Hares, Jeffrey Haas, Mingxing Liu, etc.

References Normative References Huawei China Telecom Huawei BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. 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. 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 Tsinghua University Tsinghua University Tsinghua University Huawei 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 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 rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. Tsinghua University Tsinghua University Zhongguancun Laboratory 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. Zhongguancun Laboratory China Mobile Tsinghua University Huawei Technologies Huawei Technologies Zhongguancun Laboratory New H3C Technologies 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. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.