



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]
