A Profile for Source Origin Authorizations(SOAs)

Abstract

This document defines Source Origin Authorization (SOA), a new object in the Resource Public Key Infrastructure (RPKI), designed to extend RPKI's capabilities to securing the data plane. An SOA object is a digitally signed artifact that records information about the possible last-hop ASes traversed by packets before reaching a specific AS. By providing this information, the SOA enables other ASes to collaboratively filter traffic with spoofed source addresses claiming to originate from the IP space of the target AS, thereby enhancing global Internet security through mitigation of source address spoofing and DDoS attacks.¶

1. 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[RFC2827] and uRPF[RFC3704][RFC8704], face deployment challenges due to their "self-deployment, global benefit" nature. Moreover, methods relying solely on local routing information suffer from two key limitations:¶

1. Spoofed traffic may already consume network resources before being filtered.¶
2. 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 [I-D.ren-sidrops-soa-usage].¶

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

3. 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 [RFC6488]).¶

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

5. 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 [RFC6488].¶

6. Operation Considerations

Deployers should regularly check the validity of the SOA and update it promptly when their routing changes. Failure to do so may result in newly added routes being mistakenly blocked.¶

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 the Top N 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.¶

9. References