Internet Engineering Task Force G. Ren Internet-Draft S. Liu Intended status: Standards Track X. Yin Expires: 1 January 2024 Tsinghua University 30 June 2023 Inter-domain Source Address Validation based on AS relationships draft-rly-savnet-inter-domain-as-relationships-00 Abstract This draft introduces an inter-domain source address validation scheme based on relationships between interconnected ASes. This scheme is mainly described from three aspects, namely the research background in fields of source address validation and AS relationships, introduction to the classification and acquisition methods of AS relationships, and the specific architecture of our inter-domain source address validation system based on AS relationships. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Ren, et al. Expires 1 January 2024 [Page 1] Internet-Draft Inter-domain SAV June 2023 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction to AS Relationships . . . . . . . . . . . . . . 4 2.1. Major AS relationships . . . . . . . . . . . . . . . . . 4 2.2. Incidental AS Relationships . . . . . . . . . . . . . . . 6 2.3. AS relationship acquisition methods . . . . . . . . . . . 7 2.3.1. Inference Algorithms . . . . . . . . . . . . . . . . 7 2.3.2. Querying approach . . . . . . . . . . . . . . . . . . 8 3. Architecture of Source Address Validation System . . . . . . 8 3.1. Static Architecture . . . . . . . . . . . . . . . . . . . 8 3.1.1. Validation Rules Generation Server (VRGS) . . . . . . 9 3.1.2. Validation Router (VRR) . . . . . . . . . . . . . . . 11 3.1.3. Address Mapping Server (AMS) . . . . . . . . . . . . 11 3.2. Update Circumstance . . . . . . . . . . . . . . . . . . . 11 3.2.1. Change of the AS relationship . . . . . . . . . . . . 11 3.2.2. Change of the topology of the network . . . . . . . . 14 3.2.3. Change of the routing information . . . . . . . . . . 16 3.2.4. Change of the prefixes of AS . . . . . . . . . . . . 18 4. Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Background Inter-domain Source Address Validation plays a significant role in relieving the source IP address spoofing. Several algorithms with different ideas have been proposed previously, some of which are being applied nowadays. The major idea of the series of uRPF algorithms [RFC2827] [RFC3704] [RFC8704], which have been written in RFCs and become standard methods, is to reverse the existing routing tables for source address validation, and then complement and specify this scheme gradually based on the prototype. The SAVNET working group, which is devoted to improving the inter-domain address validation mechanism now [I-D.wu-savnet-inter-domain-problem-statement], mainly designs a source address validation scheme using detailed inter-domain routing information [I-D.wu-savnet-inter-domain-architecture]. The BAR-SAV algorithm proposed by the SIDRops working group generates the permissible prefix list for SAV with BGP UPDATE messages, ASPA and Ren, et al. Expires 1 January 2024 [Page 2] Internet-Draft Inter-domain SAV June 2023 ROA objects in RPKI [I-D.sriram-sidrops-bar-sav]. Different from all schemes above, this draft primarily introduces an inter-domain source address verification framework based on AS relationships, with the initial idea mentioned in [RFC5210]. The relationship between two ASes determines the export rules between them. The export rules between two ASes , combined with the address prefixes owned by each AS, nearly determine the routing information exchanged between them. (Some BGP attributes affect whether to export some information). This means the relationship between two ASes nearly determines the routing information. Therefore, with the AS relationships, we can design a framework for inter-domain address validation at a more abstract level, to improve the simplicity of the implementation of SAV mechanism. With the continuous advancement of the Internet, many existing research provides feasibility support for the study on inter-domain source address validation based on AS relationships. With the current development of studies on AS relationship, there are many methods to obtain the relationship between two ASes. One is to derive AS relationships from existing data with various algorithms. The other is to query ASPA objects in RPPKI directly for obtaining the P2C/C2P relationships. In this draft, as several ASes volunteer to participate in inter-domain source address validation, we assume that the relationships between every two ASes of them are known to each other. And the existence of RPKI provides a mapping from the AS Number to prefixes owned by the AS. The studies mentioned above make it possible to infer routing information between ASes directly. Analyze the existing source address validation algorithms from four aspects: accuracy, convergence speed, cost and whether to realize the validation at a single point. uRPF algorithm has high convergence speed and low cost, and is performed at a single point, while a multi-point collaborative expansion scheme is proposed. The scheme of SAVNET using multiple information shows high accuracy, while it is fulfilled with multi-point collaboration. BAR-SAV proposed by SIDROPS is an algorithm with medium accuracy with multi-point collaboration. On this basis, this draft hopes to propose a multi- point validation scheme with moderate accuracy, speed of convergence and cost , so we propose the source address validation scheme based on AS relationship. When performing inter-domain source address validation, we have a higher tolerance for false filtering, because several illegal packets with forged source address which are forwarded mistakenly won't cause large-scale attacks. However, we have lower acceptance for false blocking in order to prevent legitimate packets from being discarded, which may cause communication congestion. The inter-domain source address validation scheme based on AS relationship proposed in this Ren, et al. Expires 1 January 2024 [Page 3] Internet-Draft Inter-domain SAV June 2023 draft, compared with algorithms with high accuracy, aims not to increase false blocking rate, not to increase false filtering rate greatly, but to save the deployment cost and validation cost effectively and improve the convergence speed under dynamic circumstances. 2. Introduction to AS Relationships AS relationships are typically congruent with the business relationships between the autonomous systems, so the definitions of AS relationships are basically based on the business relationships. Nowadays, some major relationships occupy the largest proportion of all the AS relationships, while other incidental relationships exist in special situations. In order to describe AS relationships formally, some symbols are defined as follows. As AS represents one autonomous system, Ori(AS), Cus(AS), Pro(AS), Peer(AS), Sib(AS) represents itself, its customer AS, its provider AS, its peer AS, its sibling AS respectively. PartCus(AS) and PartPro(AS) represents the customer AS and the provider AS of AS in partial transit relationship respectively. What's more, RI(AS) represents the routing information of the autonomous system AS while EXRI(AS1, AS2) represents the routing information exported to AS2 from AS1. The symbol U represents union operation. 2.1. Major AS relationships Major AS relationships include three types of relationships, namely P2C relationship, P2P relationship and S2S relationship. The specific definitions and descriptions of them are as follows. I Provider to customer relationship (Transit Relationship, P2C Relationship) A customer pays its provider for connectivity to the rest of the Internet. Therefore, a provider does transit traffic for its customers.[inferring-relationships] The provider and the customer usually do not belong to the same organization. The provider AS exports its all 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 provider to customer relationship is as follows. EXRI(AS,Pro(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Sib(AS)) EXRI(AS,Cus(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Pro(AS)) U RI(Peer(AS)) U RI(Sib(AS)) Ren, et al. Expires 1 January 2024 [Page 4] Internet-Draft Inter-domain SAV June 2023 II Peer to peer relationship (P2P Relationship) A pair of peers agree to exchange traffic between their respective customers free of charge.[inferring-relationships] Two peers usually do not belong to the same organization. Each peer AS exports only the routing information of its customers, its siblings and itself to the other AS. The formal description of peer to peer relationship is as follows. EXRI(AS,Peer(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Sib(AS)) III Sibling to Sibling relationship (S2S Relationship) Two siblings are operated by the same institution. The most common anomalies seem to stem from recent acquisitions and mergers, suggesting that some AS pairs may have a sibling relationship. Each AS exports all of its routes to the other AS. [characterizing-internet] The formal description of sibling to sibling relationship is as follows. EXRI(AS,Sib(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Pro(AS)) U RI(Peer(AS)) U RI(Sib(AS)) Based on the description of the three relationships above, we can summarize the export rule table for major AS relationships (shown in Table 1). +====================+======+==========+==========+=========+======+ | | Peer | Provider | Customer | Sibling | Self | +====================+======+==========+==========+=========+======+ | Export to Peer | | | + | + | + | +--------------------+------+----------+----------+---------+------+ | Export to Provider | | | + | + | + | +--------------------+------+----------+----------+---------+------+ | Export to Customer | + | + | + | + | + | +--------------------+------+----------+----------+---------+------+ | Export to Sibling | + | + | + | + | + | +--------------------+------+----------+----------+---------+------+ Table 1: Major Exporting Rule Table Ren, et al. Expires 1 January 2024 [Page 5] Internet-Draft Inter-domain SAV June 2023 2.2. Incidental AS Relationships The diverse interconnection scenarios in practice cannot be covered completely by the major AS relationships introduced in section 1.1, and other incidental relationships also exist in the AS interconnection network. Currently, we only illustrate hybrid relationship and partial transit relationship which are relatively common in this draft. But in fact, as Internet applications develop further, and the specific applications become more complex, there may be more types of incidental AS relationships. I Hybrid relationship Two ASes have different relationships at different interconnection points (e.g. p2c in one location and p2p elsewhere). [inferring-complex] So from the AS level, the routing information exported from each other between ASes with hybrid relationships, is the union of the routing information which would be exported within each single relationship in the relationship set which hybrid relationships contain. II Partial transit relationship This relationship restricts the scope of a p2c relationship to the provider's peers and customers (but not providers). [inferring-complex] The formal description with export rule table of partial transit relationship is as follows. EXRI(AS,PartCus(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Peer(AS)) U RI(Sib(AS)) +==================+====+==========+==========+=========+======+ | |Peer| Provider | Customer | Sibling | Self | +==================+====+==========+==========+=========+======+ | Export to | + | | + | + | + | | Partial-Customer | | | | | | +------------------+----+----------+----------+---------+------+ Table 2: Exporting Rule of Partial-Customer EXRI(AS,PartPro(AS))=EXRI(AS,Peer(AS))=RI(Ori(AS)) U RI(Cus(AS)) U RI(Sib(AS)) Ren, et al. Expires 1 January 2024 [Page 6] Internet-Draft Inter-domain SAV June 2023 +==================+====+==========+==========+=========+======+ | |Peer| Provider | Customer | Sibling | Self | +==================+====+==========+==========+=========+======+ | Export to | | | + | + | + | | Partial-Provider | | | | | | +------------------+----+----------+----------+---------+------+ Table 3: Exporting Rule of Partial-Provider 2.3. AS relationship acquisition methods There are several methods to obtain AS relationships with different existed data, such as BGP route information, IXP information, IRR database, ASPA information of RPKI and so on. These methods can be divided into two categories. One is to infer relationships between ASes using specific data in the network, and the other is to query data directly to obtain AS relationships. 2.3.1. Inference Algorithms Currently, according to the different strategies used by algorithms, AS relationship inferring algorithms can be mainly divided into three types, namely Network feature ranking Algorithms, Combinatorial optimization Algorithms and Local determination algorithms. The Network feature ranking Algorithms mainly use some characteristics of the Internet to infer the relationships between ASes. These methods first extract features of all the autonomous domains, and ranks them according to the features from the largest to the smallest. Then the methods determine all AS relationships using the rule that high rank are the providers of low-ranking ASes, while ASes with similar rank are peers. Among all these methods, the representative ones are Gao algorithm [inferring-relationships], which utilizes the degree of AS in the network topology as the feature, and Subramanian algorithm [characterizing-internet]. This kind of algorithms are simple to implement with low time complexity and low accuracy. What's more, the extracting of representative features and the setting of empirical parameters are key difficulties. The Combinatorial optimization Algorithms are principally based on the undirected graph abstracted from the Internet topology whose nodes are abstracted from ASes and edges are from connections between ASes. These algorithms usually solve combinatorial optimization problems using mathematical approaches to assign values of relationships between interconnected ASes. However, owing to the high theoretical complexity of the accurate solutions, approximate algorithms or random methods are commonly utilized to obtain the Ren, et al. Expires 1 January 2024 [Page 7] Internet-Draft Inter-domain SAV June 2023 approximate solutions. Erlebach algorithm [classifying-c2p] and Battista algorithm [computing-relationships] are two examples of The Combinatorial optimization Algorithms. This type of algorithms basically have high theoretical complexity, and are complex to implement with high time complexity and low accuracy. The Local determination Algorithms mainly utilize a portion of the determined AS relationships which already exist in the public database or can be monitored by the monitor, combined with the features of AS relationships and AS paths to deduce the rest AS relationships of the Internet. This strategy is adopted by Xia Algorithm [evaluation-inferences], which first filters out invalid paths using Valley-Free principle and then speculates relationships on the AS paths, and Shavitt algorithm [near-deterministic]. This kind of methods are relatively simple to implement with relatively low time complexity and high accuracy, with one premise that accurate and available priori information has been extracted. 2.3.2. Querying approach Apart from above inference algorithms, AS relationships can also be obtained directly by querying the ASPA objects in RPKI. The ASPA object is a cryptographically signed attestation by a Customer AS (CAS) that another AS listed in the ASPA is a Provider. The content of an ASPA identifies the Customer AS (CAS) as well as the Set of Provider ASes (SPAS) that are authorized by the CAS to be its Providers. [I-D.ietf-sidrops-aspa-profile] Therefore, we can get the set of ASes which are in P2C/C2P relationship with one AS straightly from ASPA objects in RPKI. In this draft, as several ASes try to implement SAV together, we suppose that the relationship between every two ASes can be known. But it is apparent that even if the AS relationships are unknown, they can be obtained using algorithms mentioned above. 3. Architecture of Source Address Validation System 3.1. Static Architecture In this section, we will propose the architecture design of the inter-domain source address validation system based on AS relationships. The main validation idea of this system is to deploy the prefix validation rule table on the boundary router of one AS and use the rules to verify the source address of the forwarding packets. And the prefix validation rule table is generated by the server within the AS and then deployed on the boundary router. The validation system designed by this draft mainly consists of three parts with diverse functions, which are Validation Rules Generation Ren, et al. Expires 1 January 2024 [Page 8] Internet-Draft Inter-domain SAV June 2023 Server, Validation Router and Address Mapping Server (AMS). Every AS has its own Validation Rules Generation Server and Validation Router, while the Address Mapping Server is a global infrastructure. 3.1.1. Validation Rules Generation Server (VRGS) The Validation Rules Generation Server (VRGS for short) is responsible for communicating with the VRGS of its connected ASes to exchange their validation rules. VRGS also communicates with the AMS to obtain the IPv6 address prefix corresponding to the AS number, and then generates the prefix validation rule table based on the AS number validation rule table. What's more, VRGS communicates with the Validation Router and sends the prefix validation rule table to it for deployment. The VRGS stores the following data structure so as to generate and record rules. 3.1.1.1. Neighbour AS Table This table stores all the relevant information of the AS connected to this AS. Each record in the table includes the AS number of the neighbour AS, the relationship between it and this AS, and the AS number validation rule set exported to this AS from it. The AS number validation rule set actually records the valid source AS number, that is, the source AS number of the packets which are permitted to be delivered. This storage method of AS number validation rules may cause the data redundance, but is more convenient for VRGS to manage and update the validation rules. This data structure is only stored in VRGS, and will change dynamically. When any change occurs to the complete AS number validation rules of this AS, which are actually the union of all the AS number validation rule sets in this table, it is necessary to update the prefix validation rule table stored in VRGS. The detailed information of a specific example of one neighbour AS table is as follows. +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN1 | P2P | ASN4 | +-----------+-----------------+-----------------------+ | ASN2 | P2C | ASN5 | +-----------+-----------------+-----------------------+ Table 4: An example of Neighbour AS Table Ren, et al. Expires 1 January 2024 [Page 9] Internet-Draft Inter-domain SAV June 2023 3.1.1.2. Static Exporting Rule Table This table stores the export rules of major relationships between different ASes. For this table, VRGS can first select the row based on the relationship between this AS and the interconnected AS, and then select the column based on the source of currently discussed rules, so as to read out the value of the target cell quickly and determine whether to export the discussed rules to the interconnected AS. This data structure is only stored in VRGS, and is static data which will not change with time. The detailed table content is as follows. +=============+======+==========+==========+=========+ | | Peer | Provider | Customer | Sibling | +=============+======+==========+==========+=========+ | to Peer | | | + | + | +-------------+------+----------+----------+---------+ | to Provider | | | + | + | +-------------+------+----------+----------+---------+ | to Customer | + | + | + | + | +-------------+------+----------+----------+---------+ | to Sibling | + | + | + | + | +-------------+------+----------+----------+---------+ Table 5: Static Exporting Rule Table 3.1.1.3. Prefix Validation Rule Table This table stores the set of valid source address prefixes, that is, the set of the source address prefixes of packets which are allowed to be delivered. The VRGS applies to the AMS for the set of prefixes corresponding to some AS numbers, and obtains the prefix validation rule table with the AS number validation rule table. This data structure is stored in both VRGS and VRR, and will change with time dynamically. When the prefix validation rule table stored in VRGS changes, VRGS should communicate with VRR and notify it to update its prefix validation rule table accordingly. The detailed information of a specific example of one neighbour AS table is as follows. +----------------------+---------------+ | Permissible Prefixes | Prefixes Set1 | +----------------------+---------------+ Table 6: An example of Prefix Validation Rule Table Ren, et al. Expires 1 January 2024 [Page 10] Internet-Draft Inter-domain SAV June 2023 3.1.2. Validation Router (VRR) Validation Router (VRR for short) is a boundary router between two interconnected ASes, with prefix validation rule table deployed on it so as to verify the source address of the forwarding packets. VRR needs to communicate with VRGS and update its validation rule table to maintain the accuracy of validation. Prefix rule table is stored in the VRR for validation, and the detailed description of it is made above. 3.1.3. Address Mapping Server (AMS) Address Mapping Server (AMS for short) records the current mapping from AS number to address prefixes owned by the AS. VRGS will communicate with AMS and obtain the address prefixes corresponding to some AS numbers, so as to generate the prefix validation rule table in VRGS. At present, the mapping information of IP address prefixes required by AMS can be obtained from RPKI. 3.2. Update Circumstance In this section, we will discuss the corresponding response and possible problems of the architecture we design when some changes occur to the inter-domain network. Four different change scenarios will be discussed, namely the scenarios when AS relationships change, the scenarios when the network topology changes, the scenarios when the routing information of AS changes and the scenarios when the prefixes one AS owns change. To facilitate a clear explanation on the detailed situation, we will elaborate on it using representative examples. The legends which will be used in the discussion are as follows. +--+ represents the border of one autonomous system, while ++++ represents the border of AMS. The +||+ at the edge of one AS represents a boundary router, that is, a validation router (VRR). The |VRGS| written inside one AS represents a validation rules generate server (VRGS). The line with an arrow which points from AS1 to AS2 means the connection from AS1 to AS2, while the text beside the line shows the relationship from AS1 to AS2. 3.2.1. Change of the AS relationship With occurrence of some business events between ASes, the interconnected relationship between ASes may also change correspondingly, though AS relationships do not change frequently. When changes occur to the relationships between two ASes, VRGSs of the two ASes both need to update the AS number validation rule set recorded in Neighbour AS Table gradually. After updating the AS Ren, et al. Expires 1 January 2024 [Page 11] Internet-Draft Inter-domain SAV June 2023 number rule set, the VRGS regenerates the prefix rule table accordingly. So when we discuss this scenario when AS relationships change, we only focus on the analysis of changes in the AS number validation rule set. In addition to the narrow sense of AS relationship changes, the addition and reduction of connections between ASes can both be considered as the board sense of AS relationship changes and analyzed similarly. +------------------+ | AS1 |VRGS1| | +-+| |+------+| |+-+ /\ /\ / +++++ \ (C2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS2 |VRGS2| | | AS3 |VRGS3| | +-------------+ +-------------+ Figure 1: A specific AS network 1 +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN1 | self | ASN1 | +-----------+-----------------+-----------------------+ | ASN2 | P2C | ASN2 | +-----------+-----------------+-----------------------+ | ASN3 | P2C | ASN3 | +-----------+-----------------+-----------------------+ Table 7: Neighbour AS Table of AS1 +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN2 | self | ASN2 | +-----------+-----------------+-----------------------+ | ASN1 | C2P | ASN1,ASN3 | +-----------+-----------------+-----------------------+ Table 8: Neighbour AS Table of AS2 Ren, et al. Expires 1 January 2024 [Page 12] Internet-Draft Inter-domain SAV June 2023 +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN3 | self | ASN3 | +-----------+-----------------+-----------------------+ | ASN1 | C2P | ASN1,ASN2 | +-----------+-----------------+-----------------------+ Table 9: Neighbour AS Table of AS3 +------------------+ | AS1 |VRGS1| | +-+| |+------+| |+-+ /\ /\ / +++++ \ (P2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS2 |VRGS2| | | AS3 |VRGS3| | +-------------+ +-------------+ Figure 2: AS network 1 after changes of relationships +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN2 | self | ASN2 | +-----------+-----------------+-----------------------+ | ASN1 | P2P | ASN1 | +-----------+-----------------+-----------------------+ Table 10: Neighbour AS Table of AS2 after Updating Then let's assume a scenario, and the detailed connections of all ASes are displayed as Figure 1. Initially, the interconnection relationship between AS1 and AS2 is P2C relationship, while the interconnection relationship between AS1 and AS3 is P2C relationship. After the convergence of validation rules, the Neighbour AS Table stored in the VRGS of AS1, AS2 and AS3 are respectively shown in Table 7, Table 8 and Table 9. After the change of relationship, the interconnection relationship between AS1 and AS2 is transformed to P2P relationship, and the interconnection relationship between AS1 and AS3 remains unchanged. According to the exporting rule table, one AS won't export the validation rules of its customer AS to its provider AS, so the exporting relationship between AS1 and AS2 has changed, and relative validation rule tables need to be updated gradually. After the update and convergence of validation rules, the Ren, et al. Expires 1 January 2024 [Page 13] Internet-Draft Inter-domain SAV June 2023 Neighbour AS Table in VRGS of AS2 is shown in Table 10, while the Neighbour AS Table in VRGS of AS1 and AS3 remains the same in Table 7 and Table 9. 3.2.2. Change of the topology of the network If the change of the topology of the network leads to a change of AS relationships, then this scenario needs to be analyzed like the first case. Therefore, we mainly discuss the scenario when the topology changes but the AS relationships don't change in this section. Under this circumstance, validation rules recorded in relative ASes won't change, which means that the validation architecture ignores the changes caused by changes in network topology granularity. +------------------+ | AS1 |VRGS1| | +-+|1|+------+|2|+-+ /\ /\ / +++++ \ (C2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS2 |VRGS2| | | AS3 |VRGS3| | +-------------+ +-------------+ Figure 3: A specific AS network 2 +------------------+ | AS1 |VRGS1| | +-+|1|+------+|2|+-+ /\ /\ / +++++ \ (C2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS3 |VRGS3| | | AS2 |VRGS2| | +-------------+ +-------------+ Figure 4: AS network 2 after changes of network topology Ren, et al. Expires 1 January 2024 [Page 14] Internet-Draft Inter-domain SAV June 2023 +===========+=================+=======================+ | AS Number | AS Relationship | Permissible AS Number | +===========+=================+=======================+ | ASN1 | self | ASN1 | +-----------+-----------------+-----------------------+ | ASN2 | P2C | ASN2 | +-----------+-----------------+-----------------------+ | ASN3 | P2C | ASN3 | +-----------+-----------------+-----------------------+ Table 11: Neighbour AS Table of AS1 Now we assume such a specific scenario for analysis, whose detailed connections of all ASes are shown in Figure 3. Initially, AS1 is interconnected with AS2 through boundary router VRR1, while AS1 is interconnected with AS3 through boundary router VRR2. At this point, VRR1 should allow the address prefixes owned by AS2 to pass theoretically, and VRR2 should allow the address prefixes of AS3 to pass theoretically. But according to our design, the validation rules deployed on VRR1and VRR2 permit address prefixes of AS2 and AS3 to be delivered. After the change of topology, AS2 is connected to VRR2 and AS3 is connected to VRR1. And after this change, VRR1 should allow the address prefixes of AS3 to pass theoretically, and VRR2 should allow the address prefixes of AS2 to pass theoretically. But because the VRR corresponding to different connections are not recorded, the Neighbour AS Table in VRGS of AS1 remains unchanged (shown in Table 11) and the validation rules deployed on VRR1 and VRR2 do not change. Ren, et al. Expires 1 January 2024 [Page 15] Internet-Draft Inter-domain SAV June 2023 In this scenario when the topology changes but the AS relationships don't change, the AS number validation rules won't change in the architecture designed in this draft. Based on the analysis of this scenario, we find the reason which causes this result is that, one AS may be connected to multiple ASes through multiple different boundary routers, and as the AS topology connected to each VRR is different, validation rules deployed on these VRRs are not the same theoretically. However, in our validation scheme, VRGS won't bind different AS interconnection relationships to its different VRRs, so it won't store the prefix validation rule table corresponding to each VRR. Instead, the VRGS will only record the prefix validation rule table of the entire AS, and deploy the same validation rules on each VRR. So in fact, the VRGS stores the union of all prefix validation rule tables which should be deployed on each VRR respectively. Such processing method makes our validation scheme ignore the changes of network topology which do not cause the changes of AS relationships without blocking legitimate traffic additionally, and allow some forged traffic to pass. At the same time, because the method decreases the frequency of updating validation rules, it also reduces the update cost of our source address validation scheme. 3.2.3. Change of the routing information When the routing information of one AS changes, if the root of this change also causes the change of certain AS relationships, then the ASes whose relationships with neighbour ASes have changed or ASes which are affected indirectly by the change of AS relationships, need to be analyzed like the first case. As for the ASes under the situation when the AS relationships remain unchanged, or ASes which are not affected by such changes in AS relationships, their routing tables may change due to the influence, but their AS number validation rule set don't change. We will mainly discuss the second situations next. Ren, et al. Expires 1 January 2024 [Page 16] Internet-Draft Inter-domain SAV June 2023 +-------------------+ | External Network | +-------+| |+-------+ /\ Routing Table 1 | | | +--+--------------+| |+-+ | AS1 |VRGS1| | +-+| |+-----------+| |+-+ /\ /\ / +++++ \ (C2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS2 |VRGS2| | | AS3 |VRGS3| | +--+----------+ +----------+--+ | | Routing Table 2 Routing Table 3 Figure 5: A specific AS network 3 +-------------------+ | External Network' | +-------+| |+-------+ /\ Routing Table 1' | | | +--+--------------+| |+-+ | AS1 |VRGS1| | +-+| |+-----------+| |+-+ /\ /\ / +++++ \ (C2P) / |AMS| \ (C2P) / +++++ \ +----+| |+----+ +----+| |+----+ | AS2 |VRGS2| | | AS3 |VRGS3| | +--+----------+ +----------+--+ | | Routing Table 2' Routing Table 3' Figure 6: A specific AS network 3 Then we assume such a specific scenario for analysis, and its detailed connections of all ASes are shown in Figure 5. Initially, AS1 is connected to an external network whose routing table is represented as Routing Table1, and the routing tables of AS2 and AS3 are represented as Routing Table2 and Routing Table3 respectively. Ren, et al. Expires 1 January 2024 [Page 17] Internet-Draft Inter-domain SAV June 2023 The change of the external network makes the routing table of AS1 change to Routing Table1'. Because AS1 is connected to AS2 and AS3 respectively, the routing tables of AS2 and AS3 are updated to Routing Table2' and Routing Table3' under the influence of AS1. But in addition, because the change of external network does not cause the changes in validation rules of AS1, the validation rules of AS2 and AS3 won't change owing to the influence. Under the circumstance when the network routing information changes, whether the validation rules of one AS change or not mainly depends on whether it is affected by the change of AS relationships. Therefore, even if one AS needs to update its validation rules, the essence of the update actually comes from the change of AS relationships, and the changes of routing information are only a reflection in one aspect of the impact of the changes in AS relationships. 3.2.4. Change of the prefixes of AS Under the circumstance when the network routing information changes, whether the validation rules of one AS change or not mainly depends on whether it is affected by the change of AS relationships. Therefore, even if one AS needs to update its validation rules, the essence of the update actually comes from the change of AS relationships, and the changes of routing information are only a reflection in one aspect of the impact of the changes in AS relationships. With RPKI, we can obtain the mapping of address prefixes. And in the current RPKI architecture, whenever a holder of IP address space wants to authorize an AS to announce, it first issues an end-entity certificate with its own private key, and then issues a Route Origin Authorization (short for ROA) with the private key of that EE certificate, finishing the binding of the IP address prefixes to this AS.[RFC6480] A ROA records the AS number and its authorized address prefixes.[RFC6482] The ROA objects are stored in the repository of RPKI [RFC6481] to facilitate the data synchronization by the relying parties (short for RP) through rsync [RFC5781] or RRDP protocols [RFC8182]. So the VRGS can combine the third-party software to obtain the certificates, ROA objects and other data regularly from the distributed repository to generate a local cache of RPKI data. Therefore, the ROA objects of one target AS can be queried using the AS number of it, and the set of IP address prefixes owned by this AS can be obtained. In summary, our design of inter-domain source address validation can deal with the four circumstances of changing discussed above. In some cases which can not be handled correctly, such as the scenarios Ren, et al. Expires 1 January 2024 [Page 18] Internet-Draft Inter-domain SAV June 2023 when the network topology changes, our design will only allow some forged traffic to pass through mistakenly, but won't block legitimate traffic additionally. The handle of the design meets our target that the method should not increase false blocking rate or increase false filtering rate greatly. And when changes occur, changes that are more fine-grained than changes of AS relationships won't cause the change of AS number validation rules, which can reduce the frequency of rule changing effectively and improve the efficiency of maintaining validation rules. 4. Next Step In the current discussion and design, there are still some details that have not been covered. We discuss the major and incidental AS relationships in section 1, but there are some more complex and minor AS relationships which haven't been discussed. What's more, with the rapid development of Internet applications, there may be other new incidental AS relationships which are not covered in this draft. In future research, we will further discuss this issue and work to propose solutions that can incrementally handle incidental AS relationships. 5. Security Considerations The security considerations of our inter-domain source address validation scheme based on AS relationships are similar to those of [I-D.wu-savnet-inter-domain-architecture]. 6. IANA Considerations This document has no IANA requirements. 7. References 7.1. Normative References [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . Ren, et al. Expires 1 January 2024 [Page 19] Internet-Draft Inter-domain SAV June 2023 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . 7.2. Informative References [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., Williams, M., and RFC Editor, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", DOI 10.17487/rfc5210, June 2008, . [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [I-D.wu-savnet-inter-domain-problem-statement] Wu, J., Li, D., Liu, L., Huang, M., Sriram, K., Qin, L., and N. Geng, "Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-wu- savnet-inter-domain-problem-statement-09, 27 June 2023, . [I-D.wu-savnet-inter-domain-architecture] Wu, J., Li, D., Huang, M., Chen, L., Geng, N., Liu, L., and L. Qin, "Inter-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, Ren, et al. Expires 1 January 2024 [Page 20] Internet-Draft Inter-domain SAV June 2023 draft-wu-savnet-inter-domain-architecture-02, 1 June 2023, . [I-D.sriram-sidrops-bar-sav] Sriram, K., Lubashev, I., and D. Montgomery, "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR- SAV)", Work in Progress, Internet-Draft, draft-sriram- sidrops-bar-sav-02, 17 December 2022, . [I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-15, 8 June 2023, . [inferring-relationships] Gao, L., "On inferring autonomous system relationships in the Internet", December 2001, . [characterizing-internet] Subramanian, L., Agarwal, S., Rexford, J., and R. H. Katz, "Characterizing the Internet hierarchy from multiple vantage points", June 2002, . [inferring-complex] Giotsas, V., Luckie, M., Huffaker, B., and K. claffy, "Inferring complex AS relationships", November 2014, . [classifying-c2p] Thomas, E., Alexander, H., and S. Thomas, "Classifying customer-provider relationships in the Internet", July 2002, . [computing-relationships] Battista, G. D., Patrignani, M., and M. Pizzonia, "Computing the types of the relationships between autonomous systems", July 2003, . Ren, et al. Expires 1 January 2024 [Page 21] Internet-Draft Inter-domain SAV June 2023 [evaluation-inferences] Xia, J. and L. Gao, "On the evaluation of AS relationship inferences", November 2004, . [near-deterministic] Weinsberg, U., Shavitt, Y., and E. Shir, "Near- deterministic inference of AS relationships", June 2009, . Authors' Addresses Gang Ren Tsinghua University Email: rengang@cernet.edu.cn Shuqi Liu Tsinghua University Email: liu-sq19@mails.tsinghua.edu.cn Xia Yin Tsinghua University Email: yxia@tsinghua.edu.cn Ren, et al. Expires 1 January 2024 [Page 22]