A Profile for Source Origin Authorizations(SOAs)
draft-ren-sidrops-soa-profile-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ren Gang , Minglin Jia , Xia Yin | ||
| Last updated | 2025-09-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ren-sidrops-soa-profile-00
SIDROPS G. Ren
Internet-Draft M.L. Jia
Intended status: Informational X. Yin
Expires: 5 March 2026 Tsinghua University
1 September 2025
A Profile for Source Origin Authorizations(SOAs)
draft-ren-sidrops-soa-profile-00
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.
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 5 March 2026.
Copyright Notice
Copyright (c) 2025 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.
Ren, et al. Expires 5 March 2026 [Page 1]
Internet-Draft Abbreviated Title September 2025
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SOA Content-Type . . . . . . . . . . . . . . . . . . . . . . 4
4. SOA eContent . . . . . . . . . . . . . . . . . . . . . . . . 4
5. SOA Validation . . . . . . . . . . . . . . . . . . . . . . . 5
6. Operation Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Ren, et al. Expires 5 March 2026 [Page 2]
Internet-Draft Abbreviated Title September 2025
* 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].
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
Ren, et al. Expires 5 March 2026 [Page 3]
Internet-Draft Abbreviated Title September 2025
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:
Ren, et al. Expires 5 March 2026 [Page 4]
Internet-Draft Abbreviated Title September 2025
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.
7. 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.
Ren, et al. Expires 5 March 2026 [Page 5]
Internet-Draft Abbreviated Title September 2025
8. 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
[RFC6488] 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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
Ren, et al. Expires 5 March 2026 [Page 6]
Internet-Draft Abbreviated Title September 2025
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8704>.
9.2. Informative References
[I-D.ren-sidrops-soa-usage]
Ren, G., Jia, M., and X. Yin, "Source Address Validation
Using Source Origin Authorizations (SOAs)", Work in
Progress, Internet-Draft, draft-ren-sidrops-soa-usage-01,
1 September 2025, <https://datatracker.ietf.org/doc/html/
draft-ren-sidrops-soa-usage-01>.
Authors' Addresses
Gang Ren
Tsinghua University
Beijing
China
Email: rengang@cernet.edu.cn
Minglin Jia
Tsinghua University
Beijing
China
Phone: +86 18800137573
Email: jml20@mails.tsinghua.edu.cn, millionvoid@gmail.com
Xia Yin
Tsinghua University
Beijing
China
Email: yxia@tsinghua.edu.cn
Ren, et al. Expires 5 March 2026 [Page 7]