A Profile for Source Origin Authorizations(SOAs)

Introduction Source Address Validation (SAV) is essential for Internet security, ensuring that packets carry legitimate and verifiable source addresses and preventing spoofed traffic. Existing SAV solutions, such as IEF and uRPF, face deployment challenges due to their "self-deployment, global benefit" nature. Moreover, methods relying solely on local routing information suffer from two key limitations:

Spoofed traffic may already consume network resources before being filtered.
Reflection attacks can make spoofed packets appear legitimate by the time they reach the victim, rendering local SAV ineffective.

To address these issues, inter-AS collaboration is critical. Sharing routing information enables upstream ASes to help with validation and early filtering, reducing spoofed traffic's impact. However, building trust and coordination among ASes is difficult, with key barriers being:

The challenge of discovering and trusting peer ASes.
The lack of effective mechanisms to express and enforce unilateral security needs.

A centralized, standardized platform is needed to support trust management and service discovery. The Resource Public Key Infrastructure (RPKI), as a global, open system, is well-suited to this role. RPKI enables ASes to exchange verified routing data and coordinate source address validation, improving protection against spoofed and reflection-based attacks, reducing DoS risk, and enhancing network resilience. While RPKI primarily supports routing security, it can also secure the data plane. A key component of SAV is determining the valid ingress direction for traffic from a given AS. The SOA (Source Origin Authorization) framework addresses this need. The SOA object leverages RPKI to record the last-hop AS before reaching a destination AS, facilitating source address filtering and validation. An SOA is generated by the source AS seeking protection and used by the AS responsible for enforcing SAV. For detailed procedures, see .

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. Service Subscriber: In the context of the Source Address Protection Service, this refers to the AS that requests the service and is being protected. Service Provider: In the context of the Source Address Protection Service, this refers to the AS that provides the service and protects other ASes.

SOA Content-Type The content-type for an SOA is defined as sourceOriginAuthz and has the numerical value of xxxxx. This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see ).

SOA eContent The content of an SOA identifies a single AS that has been authorized by the ASN holder to originate packets with IP address of this ASN as their source addresses. 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 | +----------------+-------------------+ | Source AS | Destination AS | | (Required) | (Required) | +----------------+-------------------+ | Destination IP | Legitimate Pre AS | | (Optional) | Length (Required) | +----------------+-------------------+ | Legitimate Pre AS (Required) | +------------------------------------+ And an SOA is formally defined as: SourceOriginAttestation ::= SEQUENCE { srcAS ASID, dstAS ASID, dstIP IPPrefix OPTIONAL, legitimatePreASLength INTEGER, legitimatePreASList SEQUENCE (SIZE (1..MAX)) OF ASID } ASID ::= INTEGER IPPrefix ::= SEQUENCE { address IPAddress, netmask INTEGER} IPAddress ::= BIT STRING

SOA Validation Before a service provider can use SOA to validate the authenticity of source addresses, the SOA must first be verified. To verify an SOA, a trusted party must perform all validation checks specified in .

Operation Considerations Both service providers and service subscribers should make efforts to minimize the synchronization delay between their router configurations and SOA objects to ensure the effectiveness of source address validation. For service subscribers, they should implement both periodic and event-triggered update strategies: SOA objects should be updated after a defined period of time and whenever there are changes to their routing policies. For service providers, they should implement either periodic polling or change-detection mechanisms to promptly identify SOA updates and update their filtering rules accordingly. According to our study, the effectiveness of deploying SOA is positively correlated with the AS Rank of the deployment location, even without any prior assumption about the target of the attack traffic. Therefore, if there is no specific defensive objective, the scheme should be deployed on top-ranked ASes. In addition, if, during actual network operation, a large amount of attack traffic is observed originating from a specific reflection point, it may indicate a reflection amplification attack using that node. In this case, SOA should be deployed in the AS where the reflection point resides.

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 Data in SOA is not assumed to be confidential; it is anticipated that SOAs will be stored in repositories accessible to all ISPs and potentially all Internet users. SOA does not have explicit authentication associated with it, as the PKI (Public Key Infrastructure) used for SOA validation provides authorization but not authentication. Although SOA is a signed application-layer object, there is no intent to convey non-repudiation through it. The purpose of SOA is to convey authorization for an ASto originate traffic with source addresses from the prefixes specified in the SOA. Therefore, the integrity of SOA must be established. The SOA specification uses the RPKI (Resource Public Key Infrastructure) signed object format; thus, all security considerations discussed in also apply to SOAs. Additionally, the signed object profile uses the CMS (Cryptographic Message Syntax) signed message format for integrity, so SOAs inherit all security considerations associated with this data structure. The right of the SOA signer to authorize the target AS to originate traffic from IP addresses associated with the ASN in the SOA is established through the use of ROA objects within RPKI. In other words, SOA does not directly store the mapping between ASN and IP prefixes; this relationship is derived from ROAs. When using SOA, one must verify the validity of both the SOA and all ROAs associated with the AS, and integrate the information from both to generate and deploy filtering rules. It is worth noting that the comprehensiveness of ROA coverage for an AS's IP addresses does not critically affect SOA's functionality. Specifically, IP addresses not covered by ROAs will not be filtered when traffic originates from them; instead, these addresses retain the same vulnerability as they would have without SOA deployment, meaning they could potentially be spoofed by other ASes. For this reason, we strongly recommend that ASes deploying SOA fully cover their own IP addresses with ROAs. This ensures that these addresses can be properly protected under the SOA framework. Looking to the future, if Traffic Origin Authorization (TOA) is standardized and deployed, it should be used directly as a supplement to or replacement for ROAs when implementing SOA. TOA is expected to provide higher accuracy in verifying traffic origins compared to ROAs, which would further enhance the effectiveness of source address validation under the SOA framework.