Source Address Validation Using Source Address Authorizations (SOAs)

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

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

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

+------------------------------------+
|        SOA Data Structure          |
+----------------+-------------------+
|SAPS Subscriber |   SAPS Provider   |
|      ASN       |        ASN        |
|   (Required)   |     (Required)    |
+----------------+-------------------+
| Destination IP | Legitimate Pre AS |
|   (Optional)   | Length (Required) |
+----------------+-------------------+
|    Legitimate Pre AS (Required)    |
+------------------------------------+

6. Source Address Validation Algorithms Using SOA

             +----------------------+
             |                      |
        +----+ RPKI(SOA Repository) <---+
        |    |                      |   |
        |    +----------------------+   |
        | SOA Object                    | SOA Object
+-------v----------+         +----------+--------+
|                  |         |                   |
| Service Provider |         | Service Subscriber|
|                  |         |                   |
+-------+----------+         +----------^ -------+
        | Validation Rules              |  Routing Info
+-------v----------+         +----------+--------+
|                  |         |                   |
| Service Provider |         | Service Subsctiber|
|      Router      |         |      Router       |
+------------------+         +-------------------+

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.

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.

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.

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

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

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

12. References