Source Address Validation Using Source Origin Authorizations (SOAs)

Introduction Source Address Validation (SAV) is crucial in internet security, as it helps filter traffic with spoofed source addresses, reducing network attacks based on source address spoofing. However, after several years of development, the SAVNET working group still points out that we need more accurate solutions that support partial deployment and automatic updates. To more accurately obtain data plane transmission paths and improve source address validation, cooperation between Autonomous Systems is crucial. It allows ASes to share routing information and validation rules, thereby enabling proactive filtering and mitigating the impact of spoofed traffic. Source Address Protection Service (SAPS) provides flexibility by allowing collaboration between non-peering ASes, making it more adaptable to diverse needs. However, due to challenges in information exchange and service discovery, this approach requires a centralized management platform. The Resource Public Key Infrastructure (RPKI) framework can facilitate SAPS's information transmission while ensuring the trustworthiness of shared routing information. By leveraging RPKI, ASes can share validated routing information and use it as a basis for source address validation, strengthening defenses against spoofed traffic. A new RPKI object introduced in this document, Source Origin Authorization (SOA), plays a significant role in this system. SOA enables an AS to authorize other ASes to use its IP addresses as source addresses for sending packets, adding an additional layer of validation. This object improves the accuracy of SAV, provides a more robust solution for protecting source addresses, and ensures effective collaboration in a dynamic and scalable manner. This document explores the semantics of Source Origin Authorization (SOA) in the context of the Resource Public Key Infrastructure (RPKI), focusing on how it enhances Source Address Validation (SAV) to validate the authenticity of source addresses declared in packets. The document provides an in-depth analysis of the semantic interpretation of SOA, emphasizing its role in securing inter-domain routing and enabling authoritative packet transmission.

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.

Terminology This section defines the key terms used in this document. Source Address Protection Service (SAPS): Refers to a service in which one AS (service provider) deploys source validation rules on its border routers to protect the IP addresses belonging to another AS (service subscriber) from being spoofed. To further explain, the service provider filters those packets whose source addresses are spoofed to be the IP addresses belonging to the service subscriber. IP Spoofing: A malicious attacker forges the source IP address, setting it to the target IP to conduct network attacks. Such packets may generate DDoS attack traffic against the target IP via reflection nodes or result in the target IP being incorrectly attributed as the source of malicious activity. Thus, IP spoofing serves as a precursor to network attacks or misattribution. Source Validation Rules: Refers to rules used to determine the authenticity of a packet's source address based on factors such as the source IP address, destination IP address, incoming interface, and packet content. SAPS Subscriber: In the context of the Source Address Protection Service, this refers to the AS that requests the service and is being protected. SAPS Provider: In the context of the Source Address Protection Service, this refers to the AS that provides the service and protects other ASes.

Proposed Source Address Validation Schemes in IETF Due to the importance of SAV, it has been a focus of network professionals for a long time. Previously, the OPSEC working group proposed IEF and uRPF to derive validation rules based on a single AS's own routing information. However, according to the analysis by the SAVNET working group , these approaches still face issues in certain scenarios due to incomplete routing information. Therefore, to accurately obtain data plane transmission paths, it is necessary to consider the sharing of routing information across ASes. For cross-AS information sharing, RPKI serves as an excellent platform, and many SAV solutions are built upon it. The SAVNET working group's BAR-SAV mechanism generates source validation rules based on routing propagation rules using BGP Update messages, ASPA, and ROA objects from RPKI. This allows source validation rules to be generated using only the information already present in the Internet. Additionally, the SAVNET working group introduced the Signed SAVNET Peer Information (SiSPI) object , which stores a list of ASes that support SAVNET, to facilitate source address validation within the SAVNET framework. The SIDROPS working group has proposed the FC-BGP solution. This solution binds the upstream and downstream neighbors for the transmission of BGP routing information through encrypted signatures, called Forwarding Commitments, and stores them in the BGP Update message to prevent path tampering. Among them, router certificates used for validating the authenticity of Forwarding Commitments need to be stored in the RPKI. Another work of SIDROPS working group is the Mapping Origin Authorizations (MOA). It mainly operates in the context of IPv4 service delivery in IPv6-only networks, aiming to prevent malicious attacks during the IPv4-to-IPv6 address conversion that could lead to conversion errors and cause traffic to be directed to incorrect addresses. Its approach is to add MOA to the Resource Public Key Infrastructure (RPKI) to store the mapping relationships between IPv4 and IPv6 address prefixes, which requires authorization by the Autonomous System (AS) that owns the IPv4 address prefix block.

Source Address Protection Service & RPKI as the Service Platform To address the above issues, collaboration between ASes is crucial. By sharing routing information, ASes can filter spoofed traffic across different locations on the Internet. Source Address Protection Service (SAPS) allows an AS to provide routing information to another AS, helping it deploy validation rules and filter spoofed packets. The AS providing routing information and receiving protection is called the service subscriber, while the AS obtaining routing information and computing source validation rules to provide protection is called the service provider. SAPS also offers clear security and economic benefits, promoting deployment. However, cross-AS collaboration still faces challenges such as service discovery and trust establishment. Existing solutions mainly fall into two categories: first, distributed models similar to BGP, where each AS independently sends and receives information, validates it, but this requires new protocols and hardware, making deployment difficult; second, establishing a unified platform where ASes register and publish information, build trust, and form service relationships, though creating a global unified platform is challenging. Thus, we turn to RPKI, which has been widely deployed. RPKI is based on X.509 certificates, and ROA objects bind IP address blocks to AS numbers, providing cryptographic proof of resource ownership. By leveraging RPKI, ASes can publish source validation information, enabling discovery, trust establishment, and sharing validated routing data, facilitating SAPS deployment and strengthening defenses against spoofed traffic. Current RPKI-based source address validation schemes primarily utilize RPKI in three ways: (1) identity authentication via CA certificates to prevent man-in-the-middle attacks, as seen in SEC ; (2) information retrieval from existing RPKI objects such as ROAs to obtain AS-IP mappings, exemplified by BAR-SAV and RISP; and (3) storage and retrieval of new objects leveraging RPKI security, as in SiSPI and the forthcoming SOA scheme.

Source Origin Authorization (SOA) Although the Resource Public Key Infrastructure (RPKI) is mainly used to protect the control plane, it can also enhance the security of the data plane. We propose a new RPKI object, the Service Origin Authorization (SOA). It contains the interface directions through which the packets sent by the service subscriber AS may arrive when passing through the service provider AS, so as to perform Source Address Validation (SAV) based on this information. In this way, the service subscriber AS generates and publishes the SOA object to the RPKI, enabling the service provider AS to retrieve the related SOAs and calculate the filtering rules, which are then applied on its border routers. The two parties establish a trust relationship and an information exchange channel through the RPKI to achieve the establishment of a secure and trustworthy protection relationship. The following introduces the content and usage method of the SOA.

SOA Content The content of the SOA identifies an Autonomous System (AS) authorized by the Autonomous System Number (ASN) holder. This AS is allowed to send data packets using the IP addresses of that ASN as the source address. In addition, the SOA also includes a list of possible previous-hop ASes, here called the Legitimate Pre AS, when the data packets sent from this AS reach the specified AS. If the ASN holder needs to authorize multiple ASes to originate packets from the same AS, the holder issues multiple SOAs, one per AS number. An SOA has the following data structure: +------------------------------------+ | SOA Data Structure | +----------------+-------------------+ |SAPS Subscriber | SAPS Provider | | ASN | ASN | | (Required) | (Required) | +----------------+-------------------+ | Destination IP | Legitimate Pre AS | | (Optional) | Length (Required) | +----------------+-------------------+ | Legitimate Pre AS (Required) | +------------------------------------+ Among them, SAPS Subscriber and SAPS Provider have been explained in Section 2. The Destination IP is an optional part, indicating that only the data packets destined for the specified IP will be filtered. This is to reduce the filtering scope, lower the risk of false filtering, and improve the filtering efficiency when the destinations of the attack traffic are relatively concentrated. The Legitimate Pre AS and its Length refer to all possible previous-hop ASes when the data packets reach the SAPS Provider.

SOA Validation Outcomes for a Packet Due to the inherent limitations of path-based validation, we cannot confirm whether a packet arriving at the correct interface was genuinely sent by the claimed AS or by another AS along the valid path. As a result, the outcome of path validation can only be classified as "spoofed," "validation passed," or "not found," but it cannot guarantee an "unspoofed" validation. Based on the content of an SOA, which includes the SAPS Subscriber AS, the SAPS Provider AS, and the Legitimate Predecessor AS, if the SAPS Provider AS specified in an SOA receives a packet from an IP address belonging to the SAPS Subscriber AS, it can verify whether the packet arrived from the corresponding legitimate predecessor AS. If so, the validation result will be "validation passed." However, it is important to note that this does not necessarily mean the packet is unspoofed, due to the limitations of path validation. If the packet did not arrive from one of the legitimate predecessors, the result is classified as "spoofed." If the AS receiving the packet does not find any SOA in which it is listed as the SAPS Provider AS, and the SAPS Subscriber AS corresponds to the AS to which the source address of the packet belongs, the result will be classified as "not found."

Applying Validation Outcomes to Packet Forwarding This document does not prescribe specific actions for handling packets where the validation result falls under a particular category. Autonomous Systems (ASes) may decide on appropriate actions based on a combination of factors, such as traffic load, defense strategies, and business relationships. For Autonomous Systems that use SOA for source address validation, packets that are validated as "spoofed" should be addressed accordingly. These packets may either be dropped immediately, or handled by referring to methods such as SAVNET-based DDoS Defense for further mitigation.

Source Address Validation Algorithms Using SOA

SOA-Based SAV Architecture The architecture of the source validation system based on SOA is as follows: +----------------------+ | | +----+ RPKI(SOA Repository) <---+ | | | | | +----------------------+ | | SOA Object | SOA Object +-------v----------+ +----------+--------+ | | | | | Service Provider | | Service Subscriber| | | | | +-------+----------+ +----------^ -------+ | Validation Rules | Routing Info +-------v----------+ +----------+--------+ | | | | | Service Provider | | Service Subscriber| | Router | | Router | +------------------+ +-------------------+ The Service Subscriber is the AS that generates the SOA request for source validation, while the Service Provider refers to the AS that uses the SOA for source address validation. Since this validation mainly benefits the AS that generates the SOA, it is considered a service.

Who Needs to Generate SOA Based on the intended use of the Source Address Origin Authorization (SOA), its generation is conducted by the Autonomous System (AS) that requires protection. Any AS that seeks to safeguard its source address can generate an SOA.

Choosing the SAPS Provider The SAPS Provider can be freely chosen; however, it is generally recommended to prioritize ASs with a higher AS Rank.

Steps of SOA Generation Let's assume that SOA creators can retrieve the BGP routing tables from all their border routers. Considering that this scheme is designed for inter-AS deployment, the deployer is typically the administrator of a single AS. Therefore, the administrator can collect routing table information from border routers by deploying mechanisms such as BMP, making this assumption reasonable. 1. Initialize an empty set named legal_upstream_as to store legitimate upstream AS numbers. 2. Iterate through each route_entry in the BGP Route Table: a. Check if the provider_asn exists in the as_path of the route_entry. b. If provider_asn is present: i. Identify its position in the as_path. ii. If there is an AS preceding the provider_asn in the as_path, add it to legal_upstream_as. c. If provider_asn is not present, proceed to the next route_entry. 3. Perform traceroute measurements: a. Select IP prefixes originated by provider_asn and several IP addresses from different regions of the Internet. b. For each traceroute result that reaches provider_asn, identify the AS immediately preceding provider_asn. c. Add such preceding ASes to legal_upstream_as. 4. After processing both BGP route entries and traceroute results, return the legal_upstream_as set containing all legitimate upstream AS numbers for the specified provider ASN. For multiple BGP routing tables, the union of the calculated legitimate upstream AS sets should be taken.

Using SOA for Traffic Filtering This section describes the use of Source Origin Authorization (SOA) in conjunction with BGP routing tables and FIB forwarding tables to filter traffic based on the source AS.

Building the Neighbor Map To construct a mapping between neighboring AS and outgoing interfaces, the following function is utilized: 1. Initialize an empty dictionary named neighbor_map to store the mappings. 2. Iterate through each entry in the FIB table: a. Retrieve the destination and output interface. b. For each entry in the BGP table: i. Check if the BGP destination matches the current FIB destination. If a match is found: (1) Obtain the first AS number from the BGP AS path. (2) Add the first AS number and its corresponding output interface to neighbor_map. 3. After processing all entries, return the neighbor_map containing the mappings.

Extracting Local SOA To extract all SOAs that point to the local AS, the following function is employed: 1. Initialize an empty list named local_soa_list to store local SOA objects. 2. Iterate through each SOA object in the SOA_list: a. Retrieve the SAPS Provider ASN from the SOA object. b. Check if the SAPS Provider ASN matches the local AS: If they are equal: Append the SOA object to local_soa_list. 3. After processing all SOA objects, return the local_soa_list containing the local SOA objects.

Handling Traffic Based on SOA Filtering rules are generated and deployed using the following function. This mechanism allows the system to dynamically adapt to path changes, such as route detours or temporary failures, so that traffic is not dropped simply because the SOA is temporarily outdated. Iterate through each SOA object in the local SOA list: a. Retrieve the Legitimate Pre AS list and SAPS Subscriber AS from the SOA object. b. Initialize an empty list named allowed_interfaces. c. For each Legitimate Pre AS in the Legitimate Pre AS list: Retrieve the corresponding interface from the neighbor map. If the interface is not null, add it to allowed_interfaces. d. For each interface in all interfaces: If the interface is not in allowed_interfaces: i. Apply rate limiting to packets with a source address belonging to the SAPS Subscriber AS on this interface. ii. Perform packet sampling and record the source and destination addresses of sampled traffic. iii. Notify the Service Subscriber AS of the new incoming traffic, including sampled source and destination addresses. e. Upon receiving such notification, the Service Subscriber AS performs traceroute towards the reported destination addresses. If a new legitimate predecessor AS is discovered, the Service Subscriber AS updates its SOA accordingly. f. After the SOA is updated, during the next rule update at the Service Provider, the validation rules will be adaptively adjusted to reflect the new legitimate upstream AS information.

Analysis of SOA based Source Address Validation

Analysis of Filtering Effect Obviously, the filtering effect of the SAPS solution based on SOA is directly related to the number and location of service providers. The more service providers that source address spoofing packets pass through, the more likely they are to be filtered. However, in practice, deploying in a small number of ASes (around 100) with a high AS Rank can already achieve a rather good filtering effect. For example, the expected number of service providers that can correctly filter an attack packet with a random Internet path is expected to reach 1. In practical applications, service subscriber ASes can flexibly choose service providers for service subscription according to their own needs.

Analysis of Filtering Overhead The main overheads of this solution are divided into three major parts: the storage overhead of RPKI, the calculation overhead of SOA objects, and the filtering overhead after the deployment of source validation rules. Among them, the storage overhead of RPKI is the most influential part. However, considering that the current ROA content stored in RPKI is already in the order of millions, and only some ASes have the need to subscribe to services, the addition of SOA will not cause an increase in the volume of RPKI by an order of magnitude. In addition, if this solution is deployed on a large scale, the SAPS Subscriber ASN field in the SOA can be expanded into a list form, so that ASes belonging to the same customer cone (and thus there is a possibility of having exactly the same arrival direction when reaching the service provider AS) can collectively subscribe to the service of one service provider AS. In this way, the SOAs can be aggregated, greatly reducing their number and the occupied space. The computation of SOA objects occurs when the SOA is published or changed. These calculations do not take place with every packet transmission, so the computational cost does not affect the throughput of inter-domain devices. The deployment of source validation rules can be implemented using ACLs. Since this solution occupies the ACL resources of service providers, and the more resources are occupied, it proves that the scale of services provided is larger, and thus more economic benefits from the services can be obtained. These economic benefits can be used to upgrade equipment and expand the capacity of ACLs, thereby accommodating more ACL entries and forming a virtuous cycle. Therefore, there is also a solution to the occupation of ACLs.

SOA Maintenance and Expiration When generating the SOA, it is essential to incorporate a validity period mechanism, which is determined based on the stability of the routing and commercial relationships. The validity can be chosen: 1 hour, 1 day, 1 week, 1 month, 1 year, and 3 years. The generator SHOULD update the validity period of the SOA at least 10% prior to its expiration, unless they no longer wish to continue subscribing to the service. When deploying an ACL, the corresponding validity period should also be established. The entity SHOULD fetch a new SOA and update the validity period within the last 10% of the current validity period. If no new SOA is found, the ACL should be revoked upon reaching the end of its validity period.

Operation Considerations When deploying the SOA framework, the service subscriber AS must carefully select appropriate provider ASes based on parameters such as AS rank, routing policies, and network topology. This selection process ensures that the generated SOA objects accurately reflect the expected packet flow paths. Once the provider ASes are determined, the subscriber AS calculates the SOA objects and publishes them to the RPKI repository. To maintain the accuracy and effectiveness of the filtering mechanism, the subscriber AS must promptly update its SOA objects in RPKI whenever routing changes occur. Concurrently, the provider AS must actively retrieve the latest SOA objects from RPKI and update its filtering rules accordingly. This proactive approach minimizes the duration of potential filtering errors caused by outdated routing information, ensuring robust and reliable source address validation.

IANA Considerations With this document, IANA is requested to allocate the code for SOA in the registry of "RPKI Signed Objects". In addition, two OIDs need to be assigned by IANA, one for the module identifier, and another one for the content type. The codes will use this document as the reference.

Security Considerations

SOA Validation SOA users MUST ensure that the SOA they use has been properly validated. Otherwise, they may inadvertently use maliciously generated illegitimate SOAs, resulting in the incorrect filtering of legitimate traffic.

Architecture Security The security of the SOA framework relies heavily on the integrity of its architecture. Implementers MUST ensure that the SOA objects are securely generated, signed, and published in the RPKI repository. Any compromise in the generation or distribution process could lead to the injection of malicious SOA objects, undermining the entire validation mechanism.

Rule Applying Security When applying SOA-based filtering rules, ASes MUST ensure that the rules are correctly implemented and consistently enforced at their border routers. Misconfigurations or inconsistencies in rule application could result in either the failure to block spoofed traffic or the accidental filtering of legitimate traffic. Regular audits and testing of filtering rules are RECOMMENDED to maintain the accuracy and effectiveness of the SOA framework.

RPKI Security Foundation The security of SOA is built upon the RPKI infrastructure, which provides cryptographic proof of resource ownership. To ensure the integrity of SOA, RPKI repositories and certificate authorities (CAs) MUST be protected against unauthorized access and tampering. Additionally, RPKI users MUST validate the entire certificate chain, including the revocation status of certificates, to prevent the use of compromised or revoked credentials.