]> 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 propogates traffic flow information with filtering actions. This document specifies a new BGP extended community named Source Address Validation (SAV) Interface-set to disseminate SAV rules through BGP FlowSpec.

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, and redirect. There are many mechanisms that can generate SAV rules on routers (, , , , and ). However, the challenges of accurate validation and operation exist in asymetric routing scenarios or dynamic networks . To facilitate SAV management, additional SAV rule dissemination is needed . BGP FlowSpec is a convenient and flexible tool for traffic filtering/controling (, ). It propogates traffic flow information for different traffic control purposes through the BGP protocol extension. Existing BGP FlowSpec design 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 BGP extended community named SAV Interface-set extended community. SAV rules can be disseminated through BGP FlowSpec by combining the new extended community with source prefix component and filtering actions of existing BGP FlowSpec. 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. AS: Autonomous System

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.

Flow Specifications for SAV

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 invalid source prefixes, the filtering actions, such as block, rate-limit, and redirect, can be taken on the packets . 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 indentified by a group id for easy management.

BGP FlowSpec for SAV SAV can be disseminated to Edge/Border/Aggragation 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., ).

Extended Community for SAV Existing BGP FlowSpec supports the component for matching source prefix and various filtering actions. This document will define a new extended community called SAV Interface-set extended community, whose design follows . SAV rules can be disseminated through BGP FlowSpec by combining the new extended community with source prefix component and filtering actions of existing BGP FlowSpec (, ).

SAV Interface-set Extended Community The newly defined SAV Interface-set extended community is encoded as follows: The meaning of fields:

• Type (1 octect): 0x07 or 0x47. The value of 0x07 is for FlowSpec Transitive Extended Communities, and 0x47 represents FlowSpec Non-Transitive Extended Communities. The two values have been allocated by IANA .
• SubType (1 octect): TBD. SubType field indicates SAV Interface-set extended community.
• AS Number (4 octects): Four-octect AS number. This field indicates the target AS where the SAV rule takes effect.
• Group Identifier (14 bits): A 14-bit number with the value ranging within 0..16383. Group identifier is a local property and identifies a set of interfaces for the source prefix carried in NLRI. The meaning of a group identifier depends on the configuration of network administrator. An interface is usually associated with one group identifiers.
• Flag V (1 bit): 1 means the identified interface set is valid for the source prefix, while 0 means the interface set is invalid for the source prefix.
• Flag U (1 bit): 1 means the rest of interfaces (not included in the interface set) on the local router are unknown for the source prefix. 0 means the rest of interfaces on the local router are invalid (when V=1) or valid (when V=0) for the source prefix.

In a BGP update, there may be more than one instances of SAV Interface-set extended community. The final interface set for the corresponding source prefix MUST be the union of these instances. Multiple source prefixes can be put in multiple BGP FlowSpec NLRIs of one BGP update. In such case, these source prefixes MUST share the same SAV Interface-set extended communities.

Examples Example 1: Configure soucre prefix P1 as valid at AS1's interfaces (Group Identifier=ID1) connecting a multi-homed subnet. Encoding description: NLRI carries source prefix P1 following existing BGP FlowSpec. The SAV Interface-set community with Type=0x07 and subType=TBD carries ID1 with AS number=AS1, flag V=1, and U=1. Example 2: Block soucre prefix P2 at AS2's interfaces (Group Identifier=ID2) connecting to transit providers. Encoding description: NLRI carries source prefix P2 and BGP extended community carries the drop action (e.g., set traffic-rate-bytes to zero). The SAV Interface-set community with Type=0x07 and subType=TBD carries ID2 with AS number=AS2, flag V=0 and U=1.

IANA Considerations This document requests a new subtype (suggested value 0x03) within the FlowSpec Transitive Extended Communities (0x07) and FlowSpec Non-Transitive Extended Communities (0x47). This sub-type shall be named "SAV Interface-set", with a reference to this document.

Security Considerations No new security issues are introduced.

Acknowledgements Many thanks to the comments from Shunwan Zhuang.

References Normative References 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. 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 Huawei This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. 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 capabilitiies 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.