]> Huawei

Beijing China gengnan@huawei.com

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Routing IDR SAV BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document specifies a new flow specification called Incoming-Interface-Set. Incoming-Interface-Set can be used together with the Source Prefix component to disseminate 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 a minor extension, BGP FlowSpec can be used for SAV rule dissemination. This document specifies 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. Traffic filtering actions of existing BGP FlowSpec can also be carried to specify the actions for the packets failing source address validation. The new extension can be used to configure SAV rules on remote routers. It can also act 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.

SAV Rules SAV rules can be used for checking the validity of source addresses of incoming packets. A rule usually 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 . In real networks, the interface set in SAV rules usually 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. Group Identifier is a local interface property on the target routers, and the meaning of it depends on the configurations of network administrator. Any interface may be associated with one or more Group Identifiers.

BGP FlowSpec for SAV SAV 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. Note that, SAV rules disseminated by BGP FlowSpec can take effect alone or acts as a management tool of other SAV mechanisms (e.g., ). Existing BGP FlowSpec has supported source prefix matching and various traffic filtering actions. To disseminate SAV rules (<source prefix, interface set, validity indicator>), a new flow specification component is needed to carry the information of interface set and validity indicator.

Flow Specification Encoding for SAV The new flow specification component is encoded in the BGP Flowspec NLRI. It SHOULD appear together with Source Prefix 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 set, the identified interface set is valid for the source prefix. If unset, it means the interface set is invalid for the source prefix.
• Flag R (1 bit): The second most significant bit in the value field. This bit is reserved for future use and MUST be set to zero.

Group Identifier indicates a specific set of interfaces that are configured by network administrator. 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 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.

Examples Example 1: Configure source prefix P1 as valid at AS1's interfaces (Group Identifier=ID1) connecting a multi-homed subnet. Encoding description: NLRI carries a P1 in a Source Prefix component and a Incoming-Interface-set component with (V=1, R=0, Group Identifier=ID1). Example 2: Configure source prefix P2 as invalid at AS2's interfaces (Group Identifier=ID2) connecting to transit providers and as valid for any other interfaces. Encoding description: NLRI carries a P2 in a Source Prefix component and a Incoming-Interface-set component with (V=0, R=0, Group Identifier=ID2) and (V=1, R=0, Group Identifier=0).

Other 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 This document requests a new entry in "Flow Spec component types registry" with the following values:

Security Considerations TBD.

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

References Normative References 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 Huawei Zhongguancun Laboratory Huawei Zhongguancun Laboratory Tsinghua University 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 rely on 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. It also defines the architectural components and their relations. Huawei Technologies 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.