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 of new objects to share information, 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.

SOA as an SAV Information Exchange Framework

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 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.

SOA Generation Flexibility This document does not prescribe specific methods for generating SOA objects. Service Subscribers can generate SOAs using any appropriate method that accurately reflects the legitimate pre-ASes through which their traffic reaches the Service Provider. The flexibility in SOA generation allows ASes to adapt to their specific network environments and operational requirements.

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 two major parts: the storage overhead of RPKI and the filtering overhead after the deployment of source validation rules. Regarding RPKI storage overhead, since this solution is fundamentally driven by service provision and economic incentives, a portion of the service fees can be allocated to RPKI maintenance teams. This funding can support the development of high-performance architectures suitable for large-scale deployment. Additionally, since SOA objects are primarily relevant only to the service provider and subscriber ASNs, RPKI relying party software can be enhanced to only retrieve SOA objects that are directly relevant to the local AS, further reducing storage and bandwidth requirements. As SOA serves as an information exchange framework rather than specifying calculation methods, the computational overhead associated with SOA generation and processing is determined by the specific implementation chosen by each AS. This flexibility allows ASes to optimize their own SOA processing based on their individual network capabilities and requirements. Regarding ACL consumption, this remains a significant challenge. In the worst-case scenario, the inter-domain ACL consumption for SAV solutions can be approximated as the number of IP prefixes of an AS multiplied by either the number of legitimate predecessor ASes for a target or the total number of neighbors minus legitimate predecessors (depending on whether permit or deny ACLs are used), further multiplied by the number of subscribers a service provider has. To address ACL consumption challenges, two improvement approaches are proposed: 1. Service subscribers pay based on the number of IP prefixes they deploy. This would incentivize subscribers to consolidate their internal IP prefixes for better aggregation, although this approach requires significant changes to current network practices and may not be practical. 2. Adopt the general SAV capability draft from SAVNET, utilizing prefix-based interface allowlist SAV. Additionally, considering the AS-level source validation characteristics of this proposal, we strongly recommend extending the SAVNET draft to include AS-based interface allowlist SAV, which restrict incoming interfaces based on the AS of the packet's source address. Specifically, this would integrate IP-to-AS mappings obtained via RPKI-to-Router protocol into ACL tables, first mapping the source IP to its ASN, then validating the ASN against the incoming interface. If hardware-implemented, this would significantly reduce the number of ACL entries and improve validation speed. Furthermore, it would insulate ACL rules from changes in the IP address space allocation of ASNs. Additionally, service providers can reduce ACL utilization by aggregating consecutive ROA IP prefixes that belong to the same service subscriber. This aggregation is optional and depends on the service provider's own resource optimization needs, as it directly benefits the provider by reducing ACL entry requirements.

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 SOA objects accurately reflect the expected packet flow paths. Once the provider ASes are determined, the subscriber AS generates the SOA objects using its preferred method 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. Service providers should implement real-time alerting mechanisms for ACLs that trigger a significant number of filtering events in a short period. If the filtered traffic originates from a single IP address that belongs to one of their service subscribers, the provider should directly alert that subscriber, requesting an immediate SOA update. During such situations, the provider should also increase the polling frequency of the RPKI repository to detect any SOA updates more quickly. The subscriber should verify whether the filtering-triggering interface is a new legitimate interface (and update their SOA accordingly) or if they are experiencing an attack (in which case no SOA update is needed).

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.