Source Address Validation Using Source Origin Authorizations (SOAs)
draft-ren-sidrops-soa-usage-02
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 , Shuqi Liu | ||
| Last updated | 2025-12-25 | ||
| 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-usage-02
SIDROPS G. Ren
Internet-Draft M.L. Jia
Intended status: Informational X. Yin
Expires: 28 June 2026 S. Liu
Tsinghua University
25 December 2025
Source Address Validation Using Source Origin Authorizations (SOAs)
draft-ren-sidrops-soa-usage-02
Abstract
Given that an AS collaboration scheme for inter-domain source address
validation requires an information-sharing platform, this document
proposes a new approach by leveraging Resource Public Key
Infrastructure (RPKI) architecture to validate the authenticity of
source address of packets. Source Origin Authorization (SOA) is a
newly defined cryptographically signed object; it provides a means of
recording information about the last Autonomous System (AS) traversed
by packets before reaching a specific AS. When validated, the
eContent of an SOA object confirms that the holder of the listed AS
Number (ASN) has authorized the specified pre-ASes. This enables
other ASes to collaboratively filter spoofed traffic, enhancing
global Internet security by mitigating 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 28 June 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ren, et al. Expires 28 June 2026 [Page 1]
Internet-Draft Source Address Validation Using Source O December 2025
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Source Address Validation Schemes in IETF . . . . . 4
4. Source Address Protection Service & RPKI as the Service
Platform . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Source Origin Authorization (SOA) . . . . . . . . . . . . . . 6
5.1. SOA Content . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. SOA Validation Outcomes for a Packet . . . . . . . . . . 7
5.3. Applying Validation Outcomes to Packet Forwarding . . . . 8
6. SOA as an SAV Information Exchange Framework . . . . . . . . 8
6.1. SOA-Based SAV Architecture . . . . . . . . . . . . . . . 8
6.2. Who Needs to Generate SOA . . . . . . . . . . . . . . . . 9
6.3. Choosing the SAPS Provider . . . . . . . . . . . . . . . 9
6.4. SOA Generation Flexibility . . . . . . . . . . . . . . . 9
7. Analysis of SOA based Source Address Validation . . . . . . . 9
7.1. Analysis of Filtering Effect . . . . . . . . . . . . . . 10
7.2. Analysis of Filtering Overhead . . . . . . . . . . . . . 10
8. SOA Maintenance and Expiration . . . . . . . . . . . . . . . 11
9. Operation Considerations . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11.1. SOA Validation . . . . . . . . . . . . . . . . . . . . . 12
11.2. Architecture Security . . . . . . . . . . . . . . . . . 13
11.3. Rule Applying Security . . . . . . . . . . . . . . . . . 13
11.4. RPKI Security Foundation . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Ren, et al. Expires 28 June 2026 [Page 2]
Internet-Draft Source Address Validation Using Source O December 2025
1. 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
[I-D.ietf-savnet-inter-domain-problem-statement] 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)[RISP]
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[RFC6480] 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.
Ren, et al. Expires 28 June 2026 [Page 3]
Internet-Draft Source Address Validation Using Source O December 2025
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
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.
3. 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[RFC2827] and uRPF[RFC3704] [RFC8704] to derive
validation rules based on a single AS's own routing information.
However, according to the analysis by the SAVNET working group
[I-D.ietf-savnet-inter-domain-problem-statement], these approaches
still face issues in certain scenarios due to incomplete routing
Ren, et al. Expires 28 June 2026 [Page 4]
Internet-Draft Source Address Validation Using Source O December 2025
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
[I-D.ietf-sidrops-bar-sav] 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[I-D.ietf-sidrops-rpki-prefixlist] ,
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
[I-D.wang-sidrops-fcbgp-protocol] 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).[I-D.ietf-sidrops-moa-profile] 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.
4. 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) [RISP] 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
Ren, et al. Expires 28 June 2026 [Page 5]
Internet-Draft Source Address Validation Using Source O December 2025
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[RFC9582] 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[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.
5. 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.
Ren, et al. Expires 28 June 2026 [Page 6]
Internet-Draft Source Address Validation Using Source O December 2025
5.1. 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.
5.2. 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.
Ren, et al. Expires 28 June 2026 [Page 7]
Internet-Draft Source Address Validation Using Source O December 2025
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."
5.3. 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.
6. SOA as an SAV Information Exchange Framework
6.1. SOA-Based SAV Architecture
The architecture of the source validation system based on SOA is as
follows:
Ren, et al. Expires 28 June 2026 [Page 8]
Internet-Draft Source Address Validation Using Source O December 2025
+----------------------+
| |
+----+ 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.
6.2. 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.
6.3. Choosing the SAPS Provider
The SAPS Provider can be freely chosen; however, it is generally
recommended to prioritize ASs with a higher AS Rank.
6.4. 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.
7. Analysis of SOA based Source Address Validation
Ren, et al. Expires 28 June 2026 [Page 9]
Internet-Draft Source Address Validation Using Source O December 2025
7.1. 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.
7.2. 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
Ren, et al. Expires 28 June 2026 [Page 10]
Internet-Draft Source Address Validation Using Source O December 2025
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[I-D.ietf-savnet-general-sav-capabilities], 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[RFC6810] 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.
8. 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.
Ren, et al. Expires 28 June 2026 [Page 11]
Internet-Draft Source Address Validation Using Source O December 2025
9. 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).
10. 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.
11. Security Considerations
11.1. 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.
Ren, et al. Expires 28 June 2026 [Page 12]
Internet-Draft Source Address Validation Using Source O December 2025
11.2. 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.
11.3. 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.
11.4. 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.
12. References
12.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 28 June 2026 [Page 13]
Internet-Draft Source Address Validation Using Source O December 2025
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[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>.
[RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
Kent, "A Profile for Route Origin Authorizations (ROAs)",
RFC 9582, DOI 10.17487/RFC9582, May 2024,
<https://www.rfc-editor.org/info/rfc9582>.
12.2. Informative References
[RISP] Jia, Y., Liu, Y., Ren, G., and L. He, "RISP: An RPKI-based
inter-AS source protection mechanism", 2018,
<https://doi.org/10.26599/TST.2018.9010025>.
[SEC] Yang, X., Cao, J., and M. Xu, "SEC: Secure, Efficient, and
Compatible Source Address Validation with Packet Tags",
2020, <https://doi.org/10.1109/IPCCC50635.2020.9391554>.
[I-D.ietf-sidrops-rpki-prefixlist]
Snijders, J. and G. Huston, "A profile for Signed Prefix
Lists for Use in the Resource Public Key Infrastructure
(RPKI)", Work in Progress, Internet-Draft, draft-ietf-
sidrops-rpki-prefixlist-05, 10 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-prefixlist-05>.
[I-D.ietf-sidrops-moa-profile]
Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A
Profile for Mapping Origin Authorizations (MOAs)", Work in
Progress, Internet-Draft, draft-ietf-sidrops-moa-profile-
02, 19 July 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-sidrops-moa-profile-02>.
Ren, et al. Expires 28 June 2026 [Page 14]
Internet-Draft Source Address Validation Using Source O December 2025
[I-D.wang-sidrops-fcbgp-protocol]
Xu, K., Wang, X., liu, Z., Qi, L., Wu, J., and Y. B. Guo,
"FC-BGP Protocol Specification", Work in Progress,
Internet-Draft, draft-wang-sidrops-fcbgp-protocol-04, 5
October 2025, <https://datatracker.ietf.org/doc/html/
draft-wang-sidrops-fcbgp-protocol-04>.
[I-D.ietf-sidrops-bar-sav]
Sriram, K., Lubashev, I., and D. Montgomery, "Source
Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-
SAV)", Work in Progress, Internet-Draft, draft-ietf-
sidrops-bar-sav-08, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-08>.
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Gap
Analysis, Problem Statement, and Requirements for Inter-
Domain SAV", Work in Progress, Internet-Draft, draft-ietf-
savnet-inter-domain-problem-statement-12, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-12>.
[I-D.ietf-savnet-general-sav-capabilities]
Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen,
"General Source Address Validation Capabilities", Work in
Progress, Internet-Draft, draft-ietf-savnet-general-sav-
capabilities-02, 10 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
general-sav-capabilities-02>.
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
Ren, et al. Expires 28 June 2026 [Page 15]
Internet-Draft Source Address Validation Using Source O December 2025
Xia Yin
Tsinghua University
Beijing
China
Email: yxia@tsinghua.edu.cn
Shuqi Liu
Tsinghua University
Beijing
China
Email: liu-sq23@mails.tsinghua.edu.cn, liushuq2001@gmail.com
Ren, et al. Expires 28 June 2026 [Page 16]