]> Tsinghua University

Beijing China rengang@cernet.edu.cn

Tsinghua University

Beijing China liu-sq23@mails.tsinghua.edu.cn

Tsinghua University

Beijing China yxia@tsinghua.edu.cn

Internet Engineering Task Force This draft introduces a distributed inter-domain source address validation scheme based on AS relationships. It mainly describes this method from five aspects: the research background in related fields, introduction to the AS relationship classification and acquisition methods, the SAV system's architecture, typical use cases, and considerations on deployability.

Background Various attacks continue to pose significant security threats to the Internet, and IP spoofing is critical. Attackers frequently employ IP spoofing to launch DDoS attacks and disguise their actual identities. Source address validation (SAV) can greatly relieve IP spoofing and mitigate DDoS attacks. The Source Address Validation Architecture (short for SAVA) proposed by divides its SAV architecture into three levels: the access network, intra-domain, and inter-domain. In SAV at the access network level, many researchers have made considerable progress and established several standards through discussion and collaboration. Researchers also proposed algorithms for inter-domain SAV. , , and proposed uRPF algorithms that reverse routers' forwarding tables as their SAV rules. They further proposed several variants based on this core idea to fit different scenarios. uRPF algorithms exhibit high convergence speed and low cost. The SAVNET working group is devoted to improving the inter-domain SAV mechanism and designing an SAV architecture using various information . Their scheme exhibits high accuracy. The SIDRops working group proposed the BAR-SAV algorithm . It generates a permissible prefix list as SAV rules using BGP UPDATE messages, ASPA, and ROA objects in the RPKI. It has medium accuracy. Though all existing methods have advantages, they have yet to become an effective and deployable standard. Aiming to fix this gap, we propose a scheme with moderate accuracy, convergence speed, and cost. To implement it, we use AS relationships to abstract the inter-domain routing information. At the AS level, each AS owns some address prefixes and advertises them to neighbor ASes. Through its advertisement, neighbor ASes know they can route traffic to these prefixes through it. What's more, neighbor ASes also determine whether to propagate the received routes to their neighbor ASes according to AS relationships. Thus, we can estimate each prefix's propagation, and infer approximate inter-domain routes with AS relationships and address prefixes. This scheme's inaccuracy comes from ignoring fine-grained routing information, such as BGP path attributes. Ignoring them may cause routes to propagate beyond the intended scope, allowing more spoofed packets to pass. Even one dropped legitimate packet may lead to serious Internet interruption, but a few passed forged packets cannot cause large-scale attacks. As our scheme does not block more legitimate packets, it does not violate requirements for inter-domain SAV. This draft introduces a distributed inter-domain SAV scheme based on AS relationships. Considering suggestions from other researchers, our scheme adopts a distributed SAV architecture without a centralized server in each AS or a newly designed protocol. Instead, we extend the current BGP protocol and directly implement our SAV system on existing AS border routers. Compared to the original scheme in , our scheme turns to a distributed system based on BGP extension due to considerations about upgrade costs. We modified it to cover more AS relationships and analyze them in different scenarios. We will explain its details in the following sections.

Introduction to AS Relationships AS relationships are essentially business relationships between autonomous systems. Some major relationships occupy the maximal proportion of all AS relationships, while other incidental relationships exist in particular situations. To formally describe AS relationships, we define some symbols in . Symbol definitions of formal descriptions

Symbol	Symbol Meaning
Cus(ASu)	Customer AS of ASu
Pro(ASu)	Provider AS of ASu
Peer(ASu)	Peer AS of ASu
Sib(ASu)	Sibling AS of ASu
Hybrid(ASu)	AS connected to ASu in hybrid relationship
PartCus(ASu)	Customer AS of ASu in Partial Transit relationship
PartPro(ASu)	Provider AS of ASu in Partial Transit relationship
ASuA	Position A of ASu
RI(ASu)	Routing Information of ASu
EXRI(AS1, AS2)	Routing Information exported from AS1 to AS2

Major AS relationships The major AS relationships include three different types: Provider-to-customer, Peer-to-peer, and Sibling-to-sibling relationships. The definitions and descriptions of them are as follows.

1. Provider-to-customer Relationship (Transit Relationship, P2C Relationship) The provider AS and the customer AS usually do not belong to the same organization, and a customer AS pays its provider AS for connectivity to the rest of the Internet. Therefore, a provider AS does transit traffic for its customer ASes . The provider AS exports all its routing information to its customer because its customer will pay for all the traffic, while the customer AS only exports the routing information of its customers, its siblings, and itself to its provider. The formal description of the P2C relationship is as follows. EXRI(AS, Pro(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS)) EXRI(AS, Cus(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS)) U RI(Peer(AS)) U RI(Pro(AS))
2. Peer-to-peer Relationship (P2P Relationship) A pair of peer ASes usually do not belong to the same organization but agree to exchange traffic between their customers free of charge . Each peer AS only exports the routing information of its customer ASes, its sibling ASes, and itself to the other AS. The formal description of the P2P relationship is as follows. EXRI(AS, Peer(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS))
3. Sibling-to-sibling Relationship (S2S Relationship) Two sibling ASes are operated by the same institution. The most common anomalies stem from recent acquisitions and mergers, suggesting that some AS pairs may have a sibling relationship. Each AS exports all its routes to its sibling ASes . The formal description of the S2S relationship is as follows. EXRI(AS, Sib(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS)) U RI(Peer(AS)) U RI(Pro(AS))

Based on the above descriptions of the three major AS relationships, we can summarize their export rules in Major Export Rule Table

	Peer	Provider	Customer	Sibling	Self
to Peer			+	+	+
to Provider			+	+	+
to Customer	+	+	+	+	+
to Sibling	+	+	+	+	+

Incidental AS Relationships The major AS relationships introduced in cannot cover all practical scenarios, and researchers have discovered other incidental AS relationships. This draft illustrates only two relatively common incidental AS relationships, hybrid and partial transit relationships, as representatives. However, it is significant to note that more incidental AS relationships may appear with the further development of Internet applications.

1. Hybrid Relationship Two ASes with the hybrid relationship have different relationships at different interconnection points (e.g., P2C in one location and P2P elsewhere) . According to the definition, the AS relationship at a pair of interconnection points decides their export rules. To explain it clearly, we take an example of the hybrid of P2C and P2P. We assume that AS 1 and AS 2 are in a hybrid relationship, and AS 1 is a customer of AS 2 at point A while they are peers at point B, as shown in .

   An example of Hybrid Relationships

   The formal descriptions of the hybrid relationship at points A and B are as follows. EXRI(AS_1A, Hybrid(AS_1A)) = RI(AS_1A) U RI(Cus(AS_1A)) U RI(Sib(AS_1A)) U RI(Peer(AS_1A)) U RI(Pro(AS_1A)) EXRI(AS_1B, Hybrid(AS_1B)) = RI(AS_1B) U RI(Cus(AS_1B)) U RI(Sib(AS_1B)) This example describes the route export rules between ASes in a hybrid relationship using the formal description of different AS relationships. The key idea is to discuss and process different interconnection points separately.
2. Partial Transit Relationship The Partial Transit relationship restricts the scope of a typical P2C relationship to the provider AS's peer ASes and customer ASes (but not provider ASes) . The formal description of the AS that provides partial connection services in the partial transit relationship is as follows. EXRI(AS, PartCus(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS)) U RI(Peer(AS)) The export rules of this AS to its customer ASes in the partial transit relationship are described in . Exporting Rule of Partial-Customer

   	Peer	Provider	Customer	Sibling	Self
   to Partial-Customer	+		+	+	+

   According to the definition, the formal description of the AS that uses partial connection services as a customer in the partial transit relationship is as follows. It is consistent with customer ASes' export rules in a typical P2C relationship. EXRI(AS, PartPro(AS)) = RI(AS) U RI(Cus(AS)) U RI(Sib(AS)) The export rules of this ASto its provider ASes in the partial transit relationship are described in . Exporting Rule of Partial-Provider

   	Peer	Provider	Customer	Sibling	Self
   to Partial-Provider			+	+	+

AS relationship acquisition methods Several methods can obtain AS relationships with existing data, such as BGP route information, IXP information, IRR database, and ASPA objects in RPKI et al. Researchers divide these methods into two categories. One is to infer relationships between ASes using specific network data, and the other is to query data directly to obtain AS relationships.

Inference Algorithms Previous researchers have proposed various AS relationship inference algorithms using different strategies. The earliest AS relationship inferring algorithm was proposed by Gao, which speculates on AS relationships based on the Valley Free principle and observation of network phenomena . Gao algorithm believes that the scale of provider AS is usually more immense than that of customer AS. It also supposes that the scale of one AS is generally proportional to its degree in the AS topology graph. Therefore, the Gao algorithm sorts all ASes according to their degrees and assigns each AS connection a relationship based on the sorting results. Overall, the Gao algorithm is easy to implement and has low time complexity, but its accuracy is also low. Threshold parameters used in the algorithm will affect the inference results of AS relationships. Therefore, manual parameter selection requires much experience. Many subsequent AS relationship inferring algorithms are also based on Gao's Valley Free principle. The AS Rank algorithm proposed by Luckie et al. does not rely on Gao's Valley Free principle but proposes three hypotheses as the algorithm foundation: firstly, multiple large provider ASes form peer-to-peer networks to provide global connectivity, building a set of ASes at the top of the hierarchy; Secondly, provider ASes will export its client ASes' routes to its provider ASes, and ASes outside the peer-to-peer network composed of large provider ASes need to connect with provider ASes to obtain global connectivity; Thirdly, the topological connections of AS can be represented using directed acyclic graphs. Based on the three assumptions, the AS Rank algorithm can infer P2C and P2P relationships but cannot handle other complex AS relationships. The AS Rank algorithm exhibits high accuracy and recall and can correctly infer 99.6% of P2C relationships and 98.7% of P2P relationships in validation experiments. The AS relationships inferred with the AS Rank algorithm are still continuously updated on CAIDA. As the AS Rank algorithm has shown excessively high inferring accuracy on public datasets, the probabilistic algorithm Problink proposed by Jin et al. aims to improve the inferring accuracy in some complex situations . The Problink algorithm is based on a naive Bayesian framework and reveals crucial AS connection features derived from stochastically informative signals. Problink exhibits a lower error rate than the AS Rank algorithm on the whole dataset, especially in complex AS relationship inferring situations. With the development and progress of AI technology, some researchers also attempted to apply advanced AI technologies to AS relationship inferring. Varghese et al. use machine learning algorithms to train one AdaBoost model for inferring AS relationships . The BGP2Vec algorithm embeds ASes in a vector space for relationship classification, referring to the NLP word embedding method Word2Vec . However, these methods have relatively low accuracy and interpretability, so they do not receive much attention.

Querying approach Apart from the inference algorithms in , we can also directly obtain AS relationships by querying ASPA objects in RPKI. An ASPA object is a cryptographically verifiable attestation by a Customer AS (CAS) containing a list of its authorized provider ASes . Therefore, we can directly get an AS's provider ASes and customer ASes from ASPA objects. Some researchers proposed the (Autonomous System Relationship Authorization) object based on ASPA. ASRA objects can record more information about more complex AS relationships and may help us directly obtain accurate AS relationships in the future. In this draft, as several ASes implement inter-domain SAV together, we suppose all AS relationships are known. However, it is apparent that even if the AS relationships are unknown, we can attain them using the above algorithms.

Architecture of inter-domain SAV System based on AS relationships In this section, we propose the architecture of the inter-domain SAV system based on AS relationships. In this SAV system, border routers in each AS generate, exchange, and update ASN validation rules until convergence. These routers then generate prefix validation rules using the mapping from ASNs to address prefixes and use these rules to validate forwarding packets' source addresses. The proposed SAV system consists of two main components with different functions: the Validation Router (VR) and the Address Mapping Server (AMS). Border routers in one AS act as its VRs, while AMS is a global infrastructure working for all ASes. An example of our SAV system is shown in .

An example of inter-domain SAV system

Validation Router (VR) The Validation Routers (VR) are actually AS border routers. They are responsible for generating validation rules and then using them to verify forwarding packets. VRs communicate with AMS regularly, translating ASN validation rules into prefix rules. They use the Neighbor Validation Rule Table as their prime data structure to implement these SAV functions. One VR's Neighbor Validation Rule Table stores all its neighbor ASes' helpful information, including their AS numbers, relationships with it, connected interfaces, corresponding ASN validation rules, and prefix rules. The ASN and prefix validation rules record those permitted forwarding packets' source ASNs and IP addresses, respectively. Therefore, VRs can use them to filter forged packets at the AS and prefix level. shows one specific example of the Neighbor Validation Rule Table. An example of Neighbor Validation Rule Table

Interface	ASN	AS Relationship	Permitted ASNs	Permitted Prefixes
Int 1	ASN 1	P2P	ASN 4	P4, P5
Int 2	ASN 2	P2C	ASN 5	P6

Address Mapping Server (AMS) The Address Mapping Server (AMS) records the mapping from ASNs to IP address prefixes owned by ASes. AMS responds to VRs' queries for ASNs' corresponding prefixes, helping them generate their prefix validation rules. The mapping of IP address prefixes that AMS should maintain is now available from the Resource Public Key Infrastructure (RPKI).

Methodology Neighbor VRs complete validation rule exchanges by advertising their rules and receiving others' rules. Like route advertisement, VRs advertise their SAV rules to their neighbors when establishing connections or updating SAV rules. Each VR initially advertises the origin ASNs of all legitimate packets it can send. When receiving ASNs advertised by neighbors, VRs check whether its Neighbor Validation Rule Table needs updating. If VRs update some rules, they advertise new rules to related neighbors according to export rules between different AS relationships. Besides, VRs in the same AS need to communicate validation rules towards different neighbor ASes with each other through intra-domain connections. In these ways, SAV rules in VRs gradually converge and build up filters for spoofing packets.

BGP Extension for Inter-domain SAV mentions that the SAV-specific communication information mechanism can be implemented by a new protocol or an extension to an existing protocol. Following its ideas, we propose an implementation for our SAV scheme by an extension to BGP in this section.

Feasibility of BGP Extension As states, the primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. Each router advertises route paths to networks it can reach. After further propagation, each router establishes a routing table with BGP routes to its reachable networks. Our SAV system uses BGP forwarding routes to approximate the reverse routes. Those VRs can deploy it to calculate networks that can reach them. Routers do not regularly announce their routing tables but incrementally advertise them using BGP UPDATE messages when they are updated. Our scheme calculates and updates SAV rules at the AS level, taking AS relationships as the abstract of inter-domain routing information. After convergence, only when increases, decreases, or changes occur to their AS relationships with neighbor VRs do SAV update rules and advertise the updates to neighbor VRs. At this time, changes also occur to their routing tables, and they should send UPDATE messages to neighbor VRs. Therefore, VRs can advertise SAV updates with BGP UPDATE messages. All these allow us to implement the SAV system with the existing route mechanism and advertise SAV rule updates using BGP UPDATE messages.

Implementation of BGP Extension To achieve the goal, we can slightly modify BGP UPDATE messages, enabling it to complete the advertisement of SAV rules when advertising updated routes. Every BGP UPDATE message contains withdrawn routes, path attributes, and Network Layer Reachability Information. The path attribute part is a sequence of BGP path attributes and can carry many attributes in one message. Each path attribute is recorded as a variable-length triple <Type, Length, Value>, allowing for various information transfers. What's more, new path attributes can be registered after IANA allocates new type codes to them. All these above allow us to design a new BGP path attribute to exchange SAV rules between AS border routers in the form of ASN sets. With this attribute, an AS border router deploying SAV can use BGP UPDATE messages to advertise corresponding SAV rule updates while updating routing information. We name it SAV_INFO for now. SAV_INFO is a triple <attribute type, attribute length, attribute value> referring to the format proposed in . The attribute type is a two-octet field containing some flags and an allocated type code. The value field records SAV rules containing one or more AS numbers, each encoded as a 2-octet length field. The length field is the length of the value field in octets, occupying one or two octets. The later section will use a concrete example to demonstrate the BGP extension for our inter-domain SAV. Our follow-up drafts will discuss the detailed implementation of this design.

An example of BGP Extension shows a simple example network. After the VRs of AS 1 and AS 2 establish a BGP connection, AS 1's VR advertises its route for prefixes P1 with BGP UPDATE messages. If AS 1 deploys our SAV system, its VR will also announce its SAV rules to AS 2's VR in these UPDATE messages. AS 2's VR also advertises its information to AS 1's VR.

The initial example network

shows updates on this network. AS 3 is a new AS connected to AS 1 as a customer AS. Through its connection with AS 1, its VR advertises its routes for P3 to AS 1. AS 1's VR thus learns new routes for P3 through AS 3 and new SAV rules.

The updated example network

Considering BGP and SAV mechanisms, AS 1 should propagate routes and SAV rules from AS 3 further to its neighbors. Since AS 3 is AS 1's customer and AS 1 is AS 2's customer, according to the export rules in Table U, AS 1 should advertise the routes and SAV rules learned from AS 3 to AS 2. AS 1's VR propagates its newly learned routes using BGP UPDATE messages. The message's NLRI field carries the prefix P3, and the Path Attributes field adds our SAV_INFO field. Its AS_PATH attribute records the path to AS 3 through AS 1. Its SAV_INFO attribute carries the AS 3's AS number as AS 1's updated SAV rules. Receiving this BGP UPDATE message, AS 2's VR can learn the routes for AS 3 and updated SAV rules. This example shows that our SAV system can utilize BGP UPDATE messages to complete the SAV rule advertisement while propagating the inter-domain routes.

Multi-homing Scenarios In this section, we utilize some use cases as examples to show that our inter-domain SAV system performs well in multi-homing scenarios. Our SAV scheme performs a lower false positive rate than existing mechanisms, filling the research gap proposed in .

Multipoint Interconnection Scenario In other particular multi-homing scenarios, our scheme can complete inter-domain SAV at the AS level. presents a scenario of multipoint interconnection between ASes. In this example, AS 1 connects with AS 2 through two pairs of VRs. AS 1 and AS 2 are in a hybrid relationship, and AS 2 is the customer of AS 2 at point 1 while they are peers at point 2.

An example of multipoint interconnection

If AS 1 has deployed the inter-domain SAV system based on AS relationships, VRs at points 1 and 2 will add AS 2 to their allowlist at the AS level. Meanwhile, according to AS 2's address prefixes recorded in AMS, they will add all these prefixes to their allowlist at the prefix level. At their interfaces facing AS 2, VRs at points 1 and 2 use the prefix allowlists to filter incoming packets.

Multi-homing Scenario In multi-homing scenarios, the SAV system based on AS relationships improves the validation accuracy in customer interfaces, filling the gap of false positives proposed in . We take as an example to analyze how our scheme solves the limited propagation of prefixes. This figure presents a multi-homing scenario where uRPF mechanisms may lead to the problem. In this scenario, AS 2 and AS 1 are providers of AS 3, and AS 1 is the provider of AS 2. AS 3 adds the NO_EXPORT community attribute to all BGP advertisements to AS 2, preventing AS 2 from further propagating its prefixes.

An example of multi-homing scenario

When deploying uRPF mechanisms, the VR facing AS 2 in AS 1 may improperly block packets originating from AS 3. If it deploys the SAV system based on AS relationships, it will generate validation rules using ASNs transmitted between VRs. The NO_EXPORT attribute can not limit AS 2's propagation of AS 3 rules. Therefore, the VR will allow those packets to pass, avoiding false positives. As for the problem of hidden prefixes, we solve it by specially setting the initial ASN sets advertised by each AS. Under some circumstances, one AS may have particular settings and send packets with source addresses that it does not advertise, like direct server return (DSR). If deploying our scheme, its VRs initially advertise the origin ASNs of all possible legitimate packets it can send. Therefore, these VRs will allow packets that match the specific configurations to pass, effectively avoiding false positives. Besides false positives, also points out false negatives within AS customer cones. Our scheme does not propose a targeted solution for this gap but does propose some ideas. A system on the data plane for traffic monitoring and management may help with limiting attacks within customer cones. What's more, in the SAVA architecture proposed in , access network and intra-domain SAV can prevent source address spoofing within AS and help to reduce attacks within customer cones.

Dynamic Scenario This section utilizes some designed use cases to show how our inter-domain SAV system performs in different dynamic scenarios. This SAV system handles updates at the AS level and ignores more fine-grained route updates. It reduces rule update frequency at the cost of tiny false negatives, cutting down the SAV system's update overhead. We take the network shown in as an example before all changes happen. In this example, AS 1 is AS 2 and AS 3's provider, and all ASes have deployed the inter-domain SAV system based on AS relationships. When diverse changes occur to this network, we show the network after changes and discuss the updates of our inter-domain SAV system.

An example network before changes happen

AS Relationships Change displays the example network after AS relationships change. If the AS relationship between AS 1 and AS 2 changes from C2P to P2P, the VR in AS 1 facing AS 2 and the VR in AS 2 facing AS 1 will modify the AS relationships in their Neighbor Validation Rule Tables and remove previous SAV rules. These VRs will actively advertise their new SAV rules to neighbors. VRs further propagate the rules through VR connections until they come to a new convergence in the changed network.

The example network after AS relationships change

AS Prefixes Change displays the example network after AS prefixes change. If AS 3's IP address prefixes change from P3 to P4, VRs will modify the SAV information about AS 3 in their Neighbor Validation Rule Tables. Under this circumstance, VRs' ASN validation rules remain unchanged, but they will adjust prefix validation rules according to the new mapping recorded in AMS. In our inter-domain SAV system, VRs use ASNs as advertised validation rules. VRs translate ASN rules into prefix rules with the mapping provided by AMS and do not further propagate prefix ones. Therefore, AS prefixes change won't break achieved convergence. In this example, the change of AS 3's prefixes does cause VRs to update their SAV information about AS 3. However, all ASN rules remain unchanged, and VRs only update prefix rules about AS 3.

The example network after AS prefixes change

AS Network Topologies Change displays the example network after the AS network topology changes. If the AS connections change and AS 3 becomes AS 2's peer from AS 1's customer, AS 2 will add one new VR, and AS 3 will adjust its original VR. After reconfigurations, added VR in AS 2 and adjusted VR in AS 3 will fill in their Neighbor Validation Rule Tables according to the latest network situation. These VRs will actively advertise their new SAV rules to neighbors. VRs further propagate the rules through VR connections until they come to a new convergence in the changed network.

The example network after AS network topologies change

BGP Attributes Change displays the example network after BGP attributes change. If the BGP attributes between AS 1 and AS 2 change while other information does not, all VRs in the network needn't update their SAV information. In this example, AS 2 adds the NO_EXPORT community attribute to all BGP advertisements from it to AS 1, preventing AS 1 from further propagating its prefixes. Routing information propagated from AS 1 to AS 3 changes and no longer contains routes to AS 2. However, our SAV system does not restrain the propagation of ASN validation rules from AS 3 to AS 2, so AS 3's ASN and prefix rules remain unchanged, as do other ASes'. The results indicate that our SAV scheme ignores fine-grained routing information changes because it handles AS connections rather than BGP routes. As such processing neglects restrictions on BGP route advertisement, it may allow some forged traffic to pass but will not additionally block legitimate traffic. which meets SAV requirements. Such processing also improves our SAV system's stability and lessens SAV update overhead.

The example network after BGP attributes change

Considerations on Deployability

Utilize existing information as much as possible Using information beyond existing will inevitably incur additional costs due to its need for upgrades. At the same time, it will improve the deployment requirements, which prevent SAV schemes' large-scale promotion. Therefore, an easily deployable SAV scheme in real networks always utilizes existing information as much as possible. Similarly, when existing facilities can provide certain services, deployable solutions always prefer to use them rather than establish new ones. For SAV schemes, existing information includes routing information, business relationships between different ASes, and the mapping from ASNs to IP address prefixes provided. Existing facilities include RPKI and AS border routers. Our scheme establishes the SAV system with these existing information and devices.

Prefer to use and exchange more abstract information Unlike fine-grained concrete information, abstract information lacks details but fundamentally simplifies problems. However, it can reduce computational costs and improve efficiency, which is more conducive to promoting SAV deployment. When multiple SAV nodes collaborate, they can exchange abstract rules and generate fine-grained ones when setting prefix filters. As discussed above, AS relationships determine the routing information between ASes and are more abstract than that. Therefore, our inter-domain SAV scheme uses AS relationships instead of routing information to calculate validation rules at the AS level. It transmits ASNs between ASes instead of IP address prefixes and only generates prefix filtering rules with ASN validation rules at the end.

Balance accuracy, time and cost When the network remains stable, directly generating the most accurate filtering rules during forwarding table establishment is the best idea. However, the Internet often changes at different levels, which triggers validation rule fluctuations until they reconverge. We have discussed some changes and their impacts in . Long convergence time is not conducive to providing validation support in a constantly changing network. Therefore, an easily deployable validation scheme in the dynamic network should balance convergence time and accuracy. When rule calculation and deployment do not bring additional costs, using the most accurate algorithms is the most effective. However, SAV schemes that need more data and calculations often have higher costs in real networks. Trading excessive expenses for a slight accuracy improvement is an inappropriate choice. Therefore, an easily deployable SAV scheme in practical situations should balance computational cost and accuracy. The above analyses of two examples indicate that different evaluation metrics may have hidden contradictions in practical networks, making it difficult to optimize them simultaneously. Our scheme tries to balance accuracy, time, and cost.

Next Step The current discussion and design have not covered some details. We discuss the major and incidental AS relationships in but do not consider other complex and minor ones. With the rapid development of Internet applications, researchers may discover more incidental AS relationships that this draft does not cover. In future research, we will further discuss this issue and work to propose incremental solutions for incidental AS relationships.

Security Considerations The security considerations of our inter-domain source address validation scheme based on AS relationships are similar to those of .

IANA Considerations This draft proposes using a new BGP attribute to carry SAV rules. The new BGP attribute needs an attribute type code assigned by IANA. We will put forward specific IANA considerations in a further draft about the BGP attribute implementation.

References Normative References 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. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] 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. Informative References RFC Editor Tsinghua University Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory 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 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. USA National Institute of Standards and Technology Akamai Technologies USA National Institute of Standards and Technology Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. Yandex JetLend Internet Initiative Japan Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks.

Acknowledgements Thanks to Aijun Wang for his valuable comments and suggestions on this draft.