Source-Selective BGP Framework

3.1. Limitations of Destination-Only Routing

BGP's destination-only forwarding model treats all traffic equally, regardless of its source. Once a route to a destination prefix is selected, the router forwards all packets destined to that prefix along the chosen path.¶

This creates several challenges:¶

• Networks cannot differentiate between legitimate traffic from trusted sources and malicious traffic from attackers.¶

• Service providers cannot offer connectivity that is selectively available only to specific customer populations.¶

• Enterprises cannot advertise internal services that should be reachable only from business partners or branch offices.¶

Existing workarounds, such as access control lists (ACLs), firewall rules, and VPN overlays, operate above the IP routing layer or on the receiving end only and cannot influence Internet forwarding. These mechanisms:¶

• Require traffic to traverse the network before being filtered, consuming bandwidth and resources.¶

• Cannot prevent upstream networks from forwarding unwanted traffic.¶

• Lack cryptographic verifiability and rely on manual configuration.¶

• Do not integrate with the Internet's global routing system.¶

3.2. DDoS and Security Challenges

Distributed Denial of Service (DDoS) attacks exploit the destination-only routing model by sending large volumes of malicious traffic that cannot be distinguished from legitimate traffic at the routing layer.¶

Current DDoS mitigation strategies include:¶

• Remotely Triggered Black Hole (RTBH) filtering [RFC5635], which discards all traffic to a destination, including legitimate traffic.¶

• BGP FlowSpec [RFC8955], which requires per-flow filter distribution, does not provide cryptographic authorization by the holder of the IP addresses on the receiving end.¶

• Scrubbing centers, which introduce latency, cost, and potential privacy concerns.¶

• DDoS Open Threat Signaling (DOTS) [RFC8782], which provides a bilateral framework to reactively signal mitigation requests upstream, but depends on pre-existing provider relationships and lacks a mechanism for global, multi-hop cryptographic source authorization.¶

None of these approaches enable a network at the receiving end to cryptographically signal "accept traffic to this destination only from these authorized sources" in a way that upstream networks can validate and enforce.¶

3.3. Business Connectivity Requirements

Enterprises and service providers require selective reachability for business connectivity:¶

• B2B Extranet Services: A manufacturer may want its ordering system reachable only from authorized supplier networks, not from the full Internet.¶

• SD-WAN Underlay Protection: An SD-WAN device should be reachable only from the enterprise's own branch locations, not from arbitrary Internet sources.¶

• Cloud Service Interconnection: A cloud customer may want specific workloads reachable only from their on-premises networks or approved partners.¶

Current solutions rely on overlay technologies (IPsec VPNs, MPLS L3VPNs, SD-WAN) or manual ACL configuration. These approaches:¶

• Require bilateral coordination and manual configuration.¶

• Do not leverage the global BGP routing system.¶

• Cannot be cryptographically verified by intermediate networks.¶

• Increase operational complexity and reduce agility.¶

3.4. Source-Constrained Reachability Model

Some operational models require that reachability to specific destination prefixes be constrained based on the set of permitted source networks. Examples include controlled interconnection between organizations, protection of infrastructure endpoints, and reduction of unwanted traffic from unknown sources.¶

Existing Internet routing mechanisms do not provide a standardized way for prefix holders to signal such source-specific reachability constraints to other networks. As a result, operators rely on locally configured filtering, overlay mechanisms, or application-layer controls.¶

Source Selective BGP (SSB) enables prefix holders to publish authorization information indicating which source prefixes are permitted to use their advertised reachability, and to signal the applicability of this information using BGP.¶

This approach allows routing systems to incorporate source-based policy inputs into local decision-making processes, where supported. The mechanism is compatible with existing destination-based routing and does not require changes to endpoint behavior.¶

The use of source-constrained reachability policies is intended to support operational use cases where tighter control over permitted traffic sources is desirable. The interpretation and enforcement of these policies remain a matter of local operator configuration.¶

4.1. Core Concept

Source-Selective BGP enables a prefix holder to cryptographically declare: "Traffic to my destination prefix D should be accepted only if it originates from source prefixes S1, S2, ..., Sn."¶

This authorization is expressed as a Source Prefix Authorization (SPA) object, signed using the RPKI and published in the global RPKI repository system. The SPA is then referenced in BGP route advertisements using a new SOURCE_SELECTIVE path attribute.¶

Routers that support SSB may:¶

1. Fetch and validate SPA objects from the RPKI repository using the Relying Party Validator.¶

2. Process BGP UPDATE messages containing SOURCE_SELECTIVE attributes.¶

3. Install data plane filters that permit only authorized source prefixes to reach the advertised destination.¶

Routers that do not support SSB can ignore the SOURCE_SELECTIVE attribute and continue to forward traffic using destination-only routing, enabling incremental deployment.¶

4.2. How SSB Works

The SSB workflow involves four main steps:¶

Step 1: SPA Creation and Publication¶

The prefix holder (e.g., an enterprise) uses their RPKI resource certificate to sign an SPA object that specifies:¶

• The destination prefix or sub-prefix being protected (e.g., 2001:db8:2016:1f00::/56)¶

• A list of authorized source prefixes (e.g., 3fff:10::/32, 3fff:20::/32)¶

• A unique SPA object name derived from the destination prefix or destination sub-prefix being protected¶

The SPA (e.g. 2001.db8.2016.1f00-56.spa) is published in the global RPKI repository, where it can be fetched and validated by any network operator.¶

Step 2: BGP Route Advertisement with SOURCE_SELECTIVE Attribute¶

When advertising the destination prefix in BGP, the origin AS (or an upstream AS) includes a SOURCE_SELECTIVE path attribute in the UPDATE message. This attribute contains one or more SA-IDs that reference the published SPA objects using the destination prefix or destination sub-prefix.¶

Example:¶

UPDATE message for 2001:db8::/32
Path Attributes:
  ORIGIN: IGP
  AS_PATH: 64496 64497
  SOURCE_SELECTIVE:
    SA-ID: 2001:db8:2016:1f00::/56

Step 3: SPA Retrieval and Validation¶

Routers that receive the UPDATE message extract the SA-ID from the SOURCE_SELECTIVE attribute and retrieve the corresponding SPA object content from the RPKI Validator typically via the RPKI-to-Router protocol.¶

The RPKI Validator validates:¶

• The cryptographic signature on the SPA using the RPKI trust anchor.¶

• That the signing certificate covers the destination prefix.¶

• That the SPA has not expired.¶

Following successful validation, the RTR server delivers the VSP (Validated SPA Payload) contents to SSB routers.¶

Step 4: Data Plane Filter Installation¶

Once the SPA policy is validated and retrieved from the VSP cache, the router installs a data plane filter (SPA filter) that permits traffic to the destination prefix only from the authorized source prefixes listed in the SPA.¶

Traffic from unauthorized sources is dropped at ingress, before being forwarded into the network. Example filter logic:¶

IF destination == 2001:db8:2016:1f00::/56 THEN
  IF source IN {3fff:10::/32, 3fff:20::/32} THEN
    FORWARD
  ELSE
    DROP
  END IF
END IF

5.1. RPKI Source Prefix Authorization (SPA)

An SPA is a digitally signed object, like a Route Origin Authorization (ROA) [RFC6482], that binds a destination prefix to a set of authorized source prefixes.¶

SPA structure (defined in [I-D.braet-sidrops-spa-profile]) conceptually compasses:¶

• Version: SPA format version¶

• Protected Prefix: The destination prefix for which sources are being authorized¶

• Source Prefix List: One or more authorized source prefixes¶

• Validity Period: Not Before / Not After timestamps¶

• Signature: Cryptographic signature using the prefix holder's RPKI certificate¶

SPAs are encoded as CMS-signed objects [RFC5652] and published in the RPKI repository system using the same distribution mechanisms as ROAs, certificates, and manifests.¶

Key properties:¶

• Cryptographically verifiable: Any party can validate the signature using the RPKI trust hierarchy.¶

• Destination prefix authorization: The signing certificate must cover the destination prefix.¶

• Global discoverability: SPAs are published in the global RPKI repository and can be fetched by any network.¶

• Revocable: SPAs can be expired or revoked by publishing updated manifests.¶

5.2. BGP SOURCE_SELECTIVE Path Attribute

The SOURCE_SELECTIVE path attribute is an optional transitive BGP path attribute that carries references (SA-IDs) to one or more SPA objects.¶

Attribute structure (defined in [I-D.braet-idr-bgp-source-selective-attr]):¶

• Attribute Type Code: TBD (to be assigned by IANA)¶

• Attribute Flags: Optional, Transitive¶

• Attribute Length: Variable¶

• SA-ID List: One or more SA-IDs (References to SPAs)¶

The attribute is optional transitive, meaning:¶

• Routers that understand SSB process the attribute and may install SPA filters.¶

• Routers that do not understand SSB propagate the attribute unchanged, enabling incremental deployment.¶

Multiple SA-IDs can be included to reference multiple SPAs, enabling multiple source authorization policies for a single aggregate prefix advertisement (e.g., authorizing different source sets for different Destination prefixes or different Source Authorization types).¶

5.3. RPKI-to-Router Protocol Extensions

The RPKI-to-Router (RTR) protocol [RFC8210] is extended to deliver Validated SPA Payloads (VSPs) from validators to routers. This avoids requiring routers to parse complex cryptography directly.¶

These extensions support the addition and withdrawal of both IPv4 and IPv6 permitted source prefix filters. The informative wire format and lookup models are detailed in Appendix A of [I-D.braet-idr-bgp-source-selective-attr]. A formal protocol specification will be introduced at a later stage.¶

5.4. Data Flow

The complete SSB data flow:¶

1. Prefix Holder: Creates and signs SPA, publishes to RPKI repository.¶

2. RPKI Validator (e.g., Routinator, FORT): Fetches SPA from repository, validates signature and certificate chain.¶

3. Origin AS: Advertises destination prefix in BGP UPDATE with SOURCE_SELECTIVE attribute containing SA-ID.¶

4. Transit/Peer AS Routers:¶

   1. The router receives BGP UPDATE with SOURCE_SELECTIVE attribute.¶

   2. The router extracts Destination Prefix from attribute. Limiting this check to local and customer BGP routes reduces router resource utilization.¶

   3. The router queries local RPKI cache (retrieved via RTR protocol) for SPA matching Destination Prefix.¶

   4. The router retrieves SPA data (destination prefix, source prefix list).¶

   5. The router validates that destination prefix in SPA matches or is a subset of NLRI in UPDATE.¶

   6. The router installs data plane SPA filter: permit traffic to destination only from authorized sources.¶

5. Data Plane: Ingress router applies SPA filter; drops traffic from unauthorized sources.¶

6.1. Reliable Cloud Connectivity

Problem: An enterprise connects to a cloud provider (e.g., AWS, Azure, GCP) and wants to ensure that certain cloud-hosted services are reachable only from the enterprise's own networks and vice versa, not from the public Internet.¶

Traditional approach: Configure cloud firewall rules or security groups to permit traffic only between the enterprise's source IP ranges and the Cloud-hosted service IP ranges. However, this filtering occurs at the cloud perimeter and enterprise firewall. Unauthorized traffic has already traversed the Internet to the enterprise network and services potentially overloading network resources.¶

SSB solution:¶

• The cloud provider publishes an SPA authorizing only the enterprise's source prefixes.¶

• The enterprise publishes an SPA authorizing only the cloud source prefixes.¶

• The cloud provider and enterprise advertise their prefixes in BGP with a SOURCE_SELECTIVE attribute referencing the SPAs.¶

• Upstream ISPs that support SSB install SPA filters, dropping unauthorized traffic before it reaches the cloud provider's and enterprise's networks.¶

• DDoS attacks and unauthorized access attempts are filtered at Internet edge routers, reducing load on the cloud and enterprise infrastructure.¶

Benefits:¶

• Reduced attack surface: Unwanted traffic is dropped at the network edge.¶

• Operational Cost Savings: Minimizes ingress bandwidth fees and prevents DDoS attacks from triggering expensive cloud auto-scaling mechanisms.¶

• Improved security posture: Cryptographically validate access control at the routing layer.¶

• Increased availability of Cloud services: Connectivity protected against DDoS attacks.¶

6.2. SD-WAN Underlay Protection

Problem: An SD-WAN deployment uses the public Internet as an underlay. SD-WAN infrastructure endpoints are Internet-reachable and vulnerable to reconnaissance, vulnerability scanning, and DDoS attacks.¶

Traditional approach: Deploy the SD-WAN infrastructure behind firewalls or VPN concentrators or use cloud-based DDoS scrubbing services. These add cost, latency, and complexity.¶

SSB solution:¶

• The enterprise publishes SPAs authorizing only its own branch office prefixes to reach the SD-WAN controller and SW-WAN edge devices.¶

• The prefixes for SD-WAN infrastructure are advertised in BGP with SOURCE_SELECTIVE attributes.¶

• ISPs supporting SSB install SPA filters, ensuring only authorized branch locations can send traffic to SD-WAN endpoints.¶

Benefits:¶

• Protection against Internet-wide attacks: Unauthorized sources cannot reach SD-WAN infrastructure.¶

• Simplified security architecture: No need for complex firewall rules or scrubbing services.¶

• Concealed infrastructure footprint: Prevents public Internet reconnaissance, port scanning, and vulnerability discovery against underlay endpoints.¶

• Increased availability underlay network: Unauthorized sources cannot overload underlay transport.¶

6.3. Business-to-Business Extranet Connectivity

Problem: A manufacturer operates an ordering system that should be reachable only from authorized supplier networks. Exposing this system on the public Internet creates security risks; using MPLS VPNs with Network-to-Network Interfaces (NNIs) for each supplier adds operational overhead.¶

Traditional approach: Deploy VPNs or MPLS L3VPNs for each supplier or use application-layer authentication and firewall rules.¶

SSB solution:¶

• The manufacturer publishes an SPA authorizing source prefixes belonging to approved suppliers.¶

• The manufacturer advertises the ordering system prefix in BGP with a SOURCE_SELECTIVE attribute.¶

• Transit ISPs install SPA filters, allowing only authorized suppliers to reach the ordering system.¶

• New suppliers can be onboarded by issuing an updated SPA profile without requiring extending a MPLS VPN service with NNIs.¶

Benefits:¶

• Dynamic, cryptographically authorized access control: No bilateral VPN setup required.¶

• Reduced operational complexity: Centralized authorization via RPKI.¶

• Scalable Partner Onboarding: Enables rapid supplier integration via simple routing policy updates.¶

6.4. DDoS Mitigation and Traffic Engineering

Problem: Distributed Denial of Service (DDoS) attacks overwhelm destination networks with volumetric traffic. Existing control-plane mitigation techniques, such as Remotely Triggered Black Hole (RTBH) routing or third-party traffic redirection, require reactive implementation after an attack is detected. This introduces a propagation delay during which the attack traffic reaches the destination network. Furthermore, third-party redirection services operate without intrinsic knowledge of the destination's specific connectivity requirements, while RTBH indiscriminately discards all traffic destined to the target IP, resulting in complete service disruption for legitimate users.¶

SSB solution:¶

• The prefix holder publishes an SPA specifying authorized source prefixes (e.g., CDN edges or trusted partners) based on its network requirements.¶

• The destination network advertises the destination prefix in BGP with the SOURCE_SELECTIVE attribute.¶

• The destination network can apply this attribute exclusively to a more-specific sub-prefix if only a part of the prefix needs protection.¶

• Supporting upstream networks match traffic against the SPA filter at ingress, dropping traffic from unlisted sources.¶

Benefits:¶

• Pre-enforced Filtering: Eliminates the propagation delay associated with reactive mitigation by maintaining an active ingress filter profile.¶

• Autonomous Traffic Control: Relies on data provided directly by the prefix holder, removing dependence on external traffic classification policies.¶

• Granular Preservation: Limits traffic drops to unauthorized sources, preventing the total service disruption caused by destination-based black-holing.¶

• Cryptographically Authorized Intent: Verifies the source-filter policy through the RPKI trust anchor before installation.¶

7.1. Incremental Deployment

• The SOURCE_SELECTIVE attribute is optional transitive, routers that do not understand SSB will propagate it unchanged.¶

• Networks that support SSB gain the ability to enforce source-based filtering; networks that do not support it continue to operate with destination-only routing.¶

• Prefix holders can begin publishing SPAs and advertising routes with SOURCE_SELECTIVE attributes immediately, even if only some ASes support enforcement.¶

• As more networks deploy SSB, the security and filtering benefits increase, creating a positive deployment incentive.¶

Early adopters will likely include:¶

• ISPs offering differentiated security services to customers¶

• Cloud and content providers seeking to reduce DDoS exposure¶

• Large enterprises with strong security requirements¶

7.2. Provider-Aggregatable (PA) Address Space

Challenge: Many enterprises use Provider-Aggregatable (PA) address space allocated by their ISP. These enterprises do not hold RPKI certificates for PA space and cannot sign SPAs.¶

Solutions:¶

• ISP delegation: The ISP can delegate a resource certificate to the enterprise customer, allowing them to sign SPAs for their PA prefixes.¶

• ISP as SPA publisher: The ISP publishes SPAs on behalf of customers as a managed service.¶

• Migration to Provider Independent (PI) space: Enterprises that require SSB may choose to obtain PI address space, giving them direct control over RPKI certificates and SPA publication.¶

7.3. Route Aggregation

Challenge: BGP route aggregation may cause a more-specific route with a SOURCE_SELECTIVE attribute to be aggregated into a less-specific route without the attribute, breaking SSB enforcement.¶

Solutions:¶

• Aggregate routes can carry a SOURCE_SELECTIVE attribute with a list of Source Authorization Identifiers covering for more-specific prefixes.¶

• Routers may include Source Authorization Identifiers of contributing routes in the aggregate route advertisement.¶

7.4. Brownfield Deployment

SSB is designed to work in existing ("brownfield") networks without requiring forklift upgrades:¶

• No changes to existing BGP speakers: Routers that do not support SSB simply ignore the SOURCE_SELECTIVE attribute.¶

• Router software upgrades. SSB requires software support for:¶

  • Processing the SOURCE_SELECTIVE path attribute¶

  • Fetching SPA objects via RTR protocol¶

  • Installing data plane SPA filters¶

• SPA publication tools: Prefix holders need tools to create, sign, and publish SPA objects, similar to existing ROA management tools.¶

• RPKI infrastructure:¶

  • Risk: Standard specifications lack clear forward compatibility rules, legacy validators encountering unrecognized file formats may reject the entire parent Certificate Authority repository.¶

  • Mitigation: To prevent these cascading routing dropouts, the new object type must be tested in isolated testbeds and phased into production only after ensuring the global network has upgraded to fault-tolerant validator versions.¶

  • Precedent: Operational rollouts for objects like Autonomous System Provider Authorizations (ASPA) have successfully conditioned the modern validation ecosystem to safely isolate and ignore un-implemented profile types by default.¶

8.1. Scaling SPA Filters

Question: How many SPA filters can a router support?¶

Considerations:¶

• Data plane capacity: Modern routers support hundreds of thousands of ACL entries; SPA filters are conceptually similar.¶

• Control plane overhead: Routers must fetch and validate SPAs via RTR protocol; this is comparable to ROA processing.¶

• Memory: SPA filters consume memory for source prefix lists and destination prefix state.¶

Mitigation strategies:¶

• Selective SPA enforcement: Routers can choose to enforce SPAs only for prefixes that are ASN local or advertised by customers.¶

• Hardware offload: Data plane filtering can be implemented in ASICs or FPGAs for line-rate performance.¶

• Hierarchical filtering: Edge routers enforce SPAs; core routers may rely on edge enforcement and avoid installing SPA filters.¶

SSB is not intended for universal enforcement across the default-free zone; operators can and are expected to scope enforcement to prefixes of interest.¶

8.2. SPA Lifecycle Management

SPA objects have a lifecycle like ROAs:¶

• Creation: Prefix holder generates and signs SPA using RPKI tooling.¶

• Publication: SPA is published to RPKI repository and propagated via RPKI sync protocol.¶

• Validation: RPKI validators fetch, validate, and distribute SPA via RTR protocol.¶

• Expiration: SPAs include a validity period (Not Before / Not After timestamps). Expired SPAs are automatically invalidated.¶

• Revocation: SPAs can be revoked by removing them from the manifest or by publishing updated manifests with incremented serial numbers.¶

• Updates: To add or remove authorized source prefixes, the prefix holder publishes a new SPA with an updated source prefix list.¶

Best practices:¶

• Set reasonable validity periods (e.g., 30-90 days) to limit the impact of compromise while minimizing management overhead.¶

• Automate SPA renewal to avoid accidental expiration.¶

• Monitor SPA validation status and alert on failures.¶

8.3. Monitoring and Troubleshooting

Operators deploying SSB should monitor:¶

• SPA publication status: Are SPAs successfully published to the RPKI repository?¶

• SPA validation status: Are routers successfully fetching and validating SPAs?¶

• SPA filter installation: Are data plane filters correctly installed for advertised prefixes?¶

• Traffic drops: Are legitimate traffic flows being inadvertently dropped due to misconfigured SPAs?¶

Troubleshooting tools:¶

• RPKI validation reports: Show which SPAs are valid, invalid, or missing.¶

• BGP route monitoring: Verify that SOURCE_SELECTIVE attributes are correctly propagated.¶

• SPA Destination Prefix match monitoring: Verify that BGP advertised Source Authorization policies are successfully matched in Validated SPA Payload (VSP) cache.¶

• SPA filter table: Table off all implemented SPA policies and associated BGP route.¶

• SPA filter logs: Log traffic drops due to SPA enforcement to identify misconfigurations or attacks.¶

• Test traffic: Send test packets from authorized and unauthorized sources to verify SPA enforcement.¶

9.1. Role of the BGP SOURCE_SELECTIVE Path Attribute

While SPAs carry the cryptographically signed Source Authorization policy, explicit signaling in the BGP control plane is required for scalable and operable deployment.¶

10.1. BGP FlowSpec

BGP FlowSpec [RFC8955] allows networks to distribute traffic flow specifications (filters) via BGP. FlowSpec can match on source prefix, destination prefix, ports, protocols, and other fields, and can apply actions such as rate-limiting or dropping.¶

Differences from SSB:¶

• Scope: FlowSpec distributes arbitrary filters that can be generated by any entity; SSB specifically binds authorized sources to destinations by the holder of the destination IP addresses.¶

• Cryptographic authorization: SSB uses RPKI-signed SPAs created by the holder of the destination IP addresses.¶

• Deployment model: FlowSpec is typically used within a single AS or between trusted ASes; SSB is designed for global Internet deployment.¶

• Semantics: FlowSpec filters are often reactive (e.g., installed during an attack); SSB authorizations are proactive and policy-driven.¶

SSB and FlowSpec can be complementary: FlowSpec can provide fine-grained filtering, while SSB provides cryptographically verifiable source authorization.¶

10.2. RPKI Route Origin Authorization (ROA)

A Route Origin Authorization (ROA) [RFC6482] authorizes an AS to originate a destination prefix. ROAs enable destination prefix validation but do not address source prefixes.¶

Relationship to SSB:¶

• SPAs and ROAs use the same RPKI infrastructure (certificates, repositories, validators).¶

• A prefix holder can publish both ROAs (to authorize origin ASes) and SPAs (to authorize source prefixes).¶

• ROAs validate "who can announce this prefix"; SPAs validate "who can send traffic to this prefix."¶

Both mechanisms are complementary and can be deployed together.¶

10.3. Remotely Triggered Black Hole (RTBH) Filtering

RTBH [RFC5635] allows a network to remotely trigger upstream routers to drop all traffic destined to a specific prefix, typically used for DDoS mitigation.¶

Differences from SSB:¶

• Granularity: RTBH drops all traffic; SSB allows selective filtering based on source.¶

• Use case: RTBH is a last-resort defence; SSB is a proactive access control mechanism.¶

• Authorization: RTBH relies on trust between ASes; SSB uses cryptographic authorization.¶

SSB provides a more flexible alternative to RTBH by allowing networks to block attack traffic while continuing to accept legitimate traffic from authorized sources.¶

10.4. Internet Routing Registry (IRR) and RPSL

The Internet Routing Registry (IRR) and Routing Policy Specification Language (RPSL) [RFC2622] allow network operators to publish routing policies, including source-based policies for BGP advertisements.¶

Differences from SSB:¶

• Routing Paradigm: IRR/RPSL focus entirely on destination routing; they lack data structures to map allowed source prefixes to destination space.¶

• Cryptographic security: IRR/RPSL lack strong authentication; SSB uses RPKI signatures.¶

• Data plane enforcement: IRR/RPSL are informational and revolve around control plane; SSB enables automated data plane filter installation.¶

• Adoption: IRR data quality and authentication are inconsistent; SSB builds on the more rigorous RPKI framework.¶

11.1. RPKI Security Model

SSB inherits the security properties of RPKI:¶

• Trust anchor: The five Regional Internet Registries (RIRs) operate RPKI trust anchors.¶

• Certificate hierarchy: Resource certificates bind IP prefixes and AS numbers to public keys.¶

• Signed objects: SPAs are signed using the prefix holder's certificate, ensuring authenticity and integrity.¶

Threats and mitigations:¶

• Compromise of RPKI trust anchor: Would allow forging SPAs for any prefix. Mitigation: RIRs follow rigorous operational security practices; multiple trust anchors provide some redundancy.¶

• Compromise of resource certificate: Would allow an attacker to forge SPAs for the covered prefixes. Mitigation: Certificate holders should protect private keys using Hardware Security Modules (HSMs) and follow key management best practices.¶

• Replay attacks: An attacker could replay an old, expired SPA. Mitigation: SPAs include validity periods and are checked against the current time; RPKI validators distribute only currently valid SPAs.¶

SSB assumes the integrity of the RPKI trust hierarchy for authorization, while making no assumptions about the trustworthiness of the global BGP control plane beyond reachability propagation.¶

11.2. Source Address Validation

SSB enforces source-based filtering but does not, by itself, validate that packets are actually originated from the claimed source prefix (i.e., it does not prevent source address spoofing).¶

Complementary mechanisms:¶

• Source Address Validation (SAV): Techniques such as BCP 38 [RFC2827] (ingress filtering) and uRPF (Unicast Reverse Path Forwarding) [RFC3704] prevent spoofing by verifying that packets arrive on interfaces consistent with the source address.¶

• RPKI-based SAV: Proposals exist to use RPKI to enhance SAV (e.g., by distributing prefix-to-AS mappings).¶

Operators deploying SSB are strongly encouraged to also deploy SAV mechanisms to ensure that source addresses cannot be spoofed.¶

11.3. Denial of Service Vectors

Potential DoS attacks against SSB infrastructure:¶

• SPA repository flooding: An attacker could publish large numbers of SPAs to overwhelm validators and routers. Mitigation: RPKI repositories have size limits and rate-limiting; routers can selectively fetch SPAs for prefixes of interest.¶

• SPA validation overhead: An attacker could advertise many prefixes with SOURCE_SELECTIVE attributes to force RPKI Validators to process many SPAs. Mitigation: RPKI Validators can cache validated SPAs and rate-limit validation requests.¶

• Data plane filter exhaustion: An attacker could attempt to exhaust router memory by advertising many prefixes with large source prefix lists. Mitigation: Routers can limit the number of SPA filters installed and prioritize enforcement for critical prefixes.¶

11.4. Operational Security

Best practices for operators deploying SSB:¶

• Protect RPKI private keys: Use HSMs and restrict access to key material.¶

• Validate SPA signatures: Ensure RPKI Validators verify cryptographic signatures before sending the SPA payload to routers.¶

• Monitor SPA publication: Detect unauthorized or unexpected SPAs for your prefixes.¶

• Test SPA configurations: Verify that SPAs correctly authorize intended sources and do not inadvertently block legitimate traffic.¶

• Coordinate with partners: When deploying SSB for B2B connectivity, coordinate with partners to ensure their source prefixes are correctly authorized.¶

11.5. BGP Control Plane Manipulation

Like standard path attributes, SOURCE_SELECTIVE signaling is susceptible to manipulation, such as removal or SA-ID inflation, by transit routers along the path. Because this vulnerability is inherent to BGP, mitigation relies on established internet peering reputations, reinforced by public ISP looking glass portals that allow external operators to openly audit and detect Path Attribute modifications.¶

14.1. Normative References

[I-D.braet-idr-bgp-source-selective-attr]

Braet, K., "BGP Source-Selective Attribute", Work in Progress, Internet-Draft, draft-braet-idr-bgp-source-selective-attr, 2026, <https://datatracker.ietf.org/doc/html/draft-braet-idr-bgp-source-selective-attr>.

[I-D.braet-sidrops-spa-profile]

Braet, K., "A Profile for Source Prefix Authorizations (SPAs)", Work in Progress, Internet-Draft, draft-braet-sidrops-spa-profile, 2026, <https://datatracker.ietf.org/doc/html/draft-braet-sidrops-spa-profile>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[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/rfc/rfc6480>.

14.2. Informative References

[RFC2622]

Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/rfc/rfc2622>.

[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/rfc/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/rfc/rfc3704>.

[RFC5635]

Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, <https://www.rfc-editor.org/rfc/rfc5635>.

[RFC5652]

Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/rfc/rfc5652>.

[RFC6482]

Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/rfc/rfc6482>.

[RFC8210]

Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/rfc/rfc8210>.

[RFC8782]

Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, <https://www.rfc-editor.org/rfc/rfc8782>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/rfc/rfc8955>.