SIDROPS                                                           G. RenInternet-Draft                                                  M.L. JiaIntended status: Informational                                    X. YinExpires: 28 June 2026                                             S. Liu                                                     Tsinghua University                                                        25 December 2025  Source Address Validation Using Source Origin Authorizations (SOAs)                     draft-ren-sidrops-soa-usage-02Abstract   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  . . . . . . . . . . . . . . . . . . . . . . .  15Ren, et al.               Expires 28 June 2026                  [Page 2]Internet-Draft  Source Address Validation Using Source O   December 20251.  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 20251.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 routingRen, 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 rulesRen, 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 20255.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 Framework6.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 ValidationRen, et al.               Expires 28 June 2026                  [Page 9]Internet-Draft  Source Address Validation Using Source O   December 20257.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 toRen, 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 20259.  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 Considerations11.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 202511.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.  References12.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.comRen, 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.comRen, et al.               Expires 28 June 2026                 [Page 16]