SIDROPS G. Ren
Internet-Draft M.L. Jia
Intended status: Informational X. Yin
Expires: 4 September 2025 Tsinghua University
3 March 2025

Source Address Validation Using Source Address Authorizations (SOAs)
draft-ren-sidrops-soa-usage-00

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 Address 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 4 September 2025.

Ren, et al. Expires 4 September 2025 [Page 1]

Internet-Draft Source Address Validation Using Source A March 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. Source Address Validation Algorithms Using SOA . . . . . . . 8
6.1. SOA-Based SAV Architecture . . . . . . . . . . . . . . . 8
6.2. Responsible Party for SOA Generation . . . . . . . . . . 9
6.3. SAPS Provider for SOA Generation . . . . . . . . . . . . 9
6.4. Steps of SOA Generation . . . . . . . . . . . . . . . . . 9
6.5. Using SOA for Traffic Filtering . . . . . . . . . . . . . 10
6.5.1. Building the Neighbor Map . . . . . . . . . . . . . . 10
6.5.2. Extracting Local SOA . . . . . . . . . . . . . . . . 10
6.5.3. Handling Traffic Based on SOA . . . . . . . . . . . . 11
7. SOA based Source Address Validation Analysis . . . . . . . . 11
7.1. Analysis of Filtering Effect . . . . . . . . . . . . . . 11
7.2. Analysis of Filtering Overhead . . . . . . . . . . . . . 12
8. SOA Maintenance and Expiration . . . . . . . . . . . . . . . 12
9. Operation Considerations . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11.1. SOA Validation . . . . . . . . . . . . . . . . . . . . . 13
11.2. Architecture Security . . . . . . . . . . . . . . . . . 14
11.3. Rule Applying Security . . . . . . . . . . . . . . . . . 14
11.4. RPKI Security Foundation . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16

Ren, et al. Expires 4 September 2025 [Page 2]

Internet-Draft Source Address Validation Using Source A March 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 Address
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 Address 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 4 September 2025 [Page 3]

Internet-Draft Source Address Validation Using Source A March 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 4 September 2025 [Page 4]

Internet-Draft Source Address Validation Using Source A March 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 4 September 2025 [Page 5]

Internet-Draft Source Address Validation Using Source A March 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 and retrieval of new objects leveraging RPKI
security, 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 4 September 2025 [Page 6]

Internet-Draft Source Address Validation Using Source A March 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 4 September 2025 [Page 7]

Internet-Draft Source Address Validation Using Source A March 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. Source Address Validation Algorithms Using SOA

6.1. SOA-Based SAV Architecture

The architecture of the source validation system based on SOA is as
follows:

Ren, et al. Expires 4 September 2025 [Page 8]

Internet-Draft Source Address Validation Using Source A March 2025

The Service Subscriber is the AS that generates the SOA request 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. Responsible Party for SOA Generation

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. SAPS Provider for SOA Generation

The SAPS Provider can be freely chosen; however, it is generally
recommended to prioritize ASs with a higher AS Rank.

6.4. Steps of SOA Generation

Let's assume that SOA creators can retrieve the BGP routing tables
from all their border routers.

Ren, et al. Expires 4 September 2025 [Page 9]

Internet-Draft Source Address Validation Using Source A March 2025

1. Initialize an empty set named legal_upstream_as to store legitimate upstream AS numbers.

2. Iterate through each route_entry in the BGP Route Table:
a. Check if the provider_asn exists in the as_path of the route_entry.
b. If provider_asn is present:
i. Identify its position in the as_path.
ii. If there is an AS preceding the provider_asn in the as_path, add it to legal_upstream_as.
c. If provider_asn is not present, proceed to the next route_entry.

3. After processing all route entries, return the legal_upstream_as set containing all legitimate upstream AS numbers for the specified provider ASN.

If there are multiple BGP route tables, each can be calculated
separately and then their union can be taken.

6.5. Using SOA for Traffic Filtering

This section describes the use of Source Origin Authorization (SOA)
in conjunction with BGP routing tables and FIB forwarding tables to
filter traffic based on the source AS.

6.5.1. Building the Neighbor Map

To construct a mapping between neighboring AS and outgoing
interfaces, the following function is utilized:

1. Initialize an empty dictionary named neighbor_map to store the mappings.

2. Iterate through each entry in the FIB table:
a. Retrieve the destination and output interface.
b. For each entry in the BGP table:
i. Check if the BGP destination matches the current FIB destination.
If a match is found:
(1) Obtain the first AS number from the BGP AS path.
(2) Add the first AS number and its corresponding output interface to neighbor_map.

3. After processing all entries, return the neighbor_map containing the mappings.

6.5.2. Extracting Local SOA

To extract all SOAs that point to the local AS, the following
function is employed:

Ren, et al. Expires 4 September 2025 [Page 10]

Internet-Draft Source Address Validation Using Source A March 2025

1. Initialize an empty list named local_soa_list to store local SOA objects.

2. Iterate through each SOA object in the SOA_list:
a. Retrieve the SAPS Provider ASN from the SOA object.
b. Check if the SAPS Provider ASN matches the local AS:
If they are equal:
Append the SOA object to local_soa_list.

3. After processing all SOA objects, return the local_soa_list containing the local SOA objects.

6.5.3. Handling Traffic Based on SOA

Filtering rules are generated and deployed using the following
function:

Iterate through each SOA object in the local SOA list:
a. Retrieve the Legitimate Pre AS list and SAPS Subscriber AS from the SOA object.
b. Initialize an empty list named allowed_interfaces.

c. For each Legitimate Pre AS in the Legitimate Pre AS list:
Retrieve the corresponding interface from the neighbor map.
If the interface is not null, add it to allowed_interfaces.

d. For each interface in all interfaces:
If the interface is not in allowed_interfaces:
Deny packets with a source address belonging to the SAPS Subscriber AS on the interface.

7. SOA based Source Address Validation Analysis

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.

Ren, et al. Expires 4 September 2025 [Page 11]

Internet-Draft Source Address Validation Using Source A March 2025

7.2. Analysis of Filtering Overhead

The main overheads of this solution are divided into three major
parts: the storage overhead of RPKI, the calculation overhead of SOA
objects, and the filtering overhead after the deployment of source
validation rules.

Among them, the storage overhead of RPKI is the most influential
part. However, considering that the current ROA content stored in
RPKI is already in the order of millions, and only some ASes have the
need to subscribe to services, the addition of SOA will not cause an
increase in the volume of RPKI by an order of magnitude. In
addition, if this solution is deployed on a large scale, the SAPS
Subscriber ASN field in the SOA can be expanded into a list form, so
that ASes belonging to the same customer cone (and thus there is a
possibility of having exactly the same arrival direction when
reaching the service provider AS) can collectively subscribe to the
service of one service provider AS. In this way, the SOAs can be
aggregated, greatly reducing their number and the occupied space.

The computation of SOA objects occurs when the SOA is published or
changed. These calculations do not take place with every packet
transmission, so the computational cost does not affect the
throughput of inter-domain devices.

The deployment of source validation rules can be implemented using
ACLs. Since this solution occupies the ACL resources of service
providers, and the more resources are occupied, it proves that the
scale of services provided is larger, and thus more economic benefits
from the services can be obtained. These economic benefits can be
used to upgrade equipment and expand the capacity of ACLs, thereby
accommodating more ACL entries and forming a virtuous cycle.
Therefore, there is also a solution to the occupation of ACLs.

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.

Ren, et al. Expires 4 September 2025 [Page 12]

Internet-Draft Source Address Validation Using Source A March 2025

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.

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 generated SOA objects accurately reflect the
expected packet flow paths. Once the provider ASes are determined,
the subscriber AS calculates the SOA objects 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.

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 4 September 2025 [Page 13]

Internet-Draft Source Address Validation Using Source A March 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 4 September 2025 [Page 14]

Internet-Draft Source Address Validation Using Source A March 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>.

[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-04, 16 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-prefixlist-04>.

[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-
00, 9 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
moa-profile-00>.

Ren, et al. Expires 4 September 2025 [Page 15]

Internet-Draft Source Address Validation Using Source A March 2025

[I-D.wang-sidrops-fcbgp-protocol]
Xu, K., Wang, X., liu, Z., Qi, L., Wu, J., and Y. Guo,
"FC-BGP Protocol Specification", Work in Progress,
Internet-Draft, draft-wang-sidrops-fcbgp-protocol-02, 8
October 2024, <https://datatracker.ietf.org/doc/html/
draft-wang-sidrops-fcbgp-protocol-02>.

[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-05, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-05>.

[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source
Address Validation in Inter-domain Networks Gap Analysis,
Problem Statement, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-savnet-inter-domain-problem-
statement-07, 3 March 2025,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-savnet-inter-domain-problem-statement/>.

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

Xia Yin
Tsinghua University
Beijing
China
Email: yxia@tsinghua.edu.cn

Ren, et al. Expires 4 September 2025 [Page 16]