]> Huawei

Beijing China gengnan@huawei.com

Huawei

Beijing China huangmingqing@huawei.com

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

CAICT

Beijing China gaowei@caict.ac.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 spoofed-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 soly used to configure SAV rules on remote routers. It can also help existing SAV mechanisms generate accurate SAV rules (i.e., as a supplement of SAV mechanisms).

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>. source prefix is for matching specific packets. Interface set represents a set of physical interfaces from which the packets arrive. Validity indicates whether the packets matching the source prefix and arrival interface are valid or invalid, so validity 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, which is similar to . 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 may be associated with one or more 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 TBD.

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 Huawei Zhongguancun Laboratory Huawei Tsinghua University Zhongguancun Laboratory This document proposes an intra-domain SAVNET architecture. Devices in the intra-domain network can communicate with each other and advertise SAV-specific information. SAV-specific information explicitly or implicitly indicates the accurate incoming directions of source addresses. With the advertised information, devices can generate accurate SAV rules automatically. Under the incremental/ partial deployment of the architecture, routing information can be used as a supplement of SAV-specific information for SAV rule generation. The architecture primarily introduces the SAV-specific information, architectural components, and the collaborations between them. Future intra-domain SAV mechanisms/protocols can be developed based on the architecture. Concrete protocol extensions or implementations are not the focus of this document. Tsinghua University Tsinghua University Huawei Zhongguancun Laboratory Huawei Zhongguancun Laboratory Tsinghua University This document introduces an inter-domain SAVNET architecture, providing a comprehensive framework for guiding the design of inter- domain SAV mechanisms. The proposed architecture empowers ASes to establish SAV rules by sharing SAV-specific Information between themselves. During the incremental or partial deployment of SAV- specific Information, it can rely on general information, such as routing information from the RIB, to construct the SAV table when SAV-specific Information for an AS's prefixes 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 China Mobile Tsinghua University Huawei Huawei Zhongguancun Laboratory Source address validation (SAV) table consists of SAV rules that are manually configured or automatically generated. The table will take effect in data plane for checking the validity of source addresses. SAV mechanisms may enable SAV tables in data plane using different methods (e.g., ACL or FIB), and these tables are suitable for different application scenarios. This document aims to provide a systematic view of existing SAV tables, which makes it convenient for engineers or operators to improve existing SAV mechanisms or properly apply SAV on routers. The document first examines existing forms of SAV tables and provides a unified abstraction. Then, three validation modes are concluded as well as suggestions for application scenarios. Finally, diversified actions for each validity state are introduced for compliance of different operation requirements. 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.