Source Address Validation Using Source Origin Authorizations (SOAs)

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 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-dependent information and validation rules, thereby enabling proactive filtering and mitigating the impact of spoofed traffic. Source Address Protection Service (SAPS) 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 can facilitate SAPS's service discovery and trust bootstrap while ensuring the trustworthiness of shared bootstrap information. By leveraging RPKI, ASes can discover peers, authenticate their published bootstrap data, and then establish private channels for routing-dependent exchanges, strengthening defenses against spoofed traffic. A new RPKI object introduced in this document, Source Origin Authorization (SOA), provides an AS-level service profile for this system. SOA enables a service subscriber or service provider AS to publish the minimum identity, role, capability, endpoint, and key material required to establish an authenticated private channel after bilateral acceptance. This object improves the deployability of SAV by keeping RPKI stable while moving routing-driven updates to the private channel. This document explores the semantics of Source Origin Authorization (SOA) in the context of the Resource Public Key Infrastructure (RPKI), focusing on how it bootstraps trusted inter-AS cooperation for Source Address Validation (SAV). The document further explains how legitimate predecessor AS information is synchronized over a private channel after the SOA-based trust relationship is established.

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 when, and only when, they appear in all capitals, as shown here.

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 or path consistency of a packet's source address based on factors such as the source IP address, incoming interface, synchronized predecessor state, and local policy. 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. Private Channel: An authenticated communication channel established using the bootstrap information in a validated SOA. It is used to exchange routing-dependent state, including legitimate predecessor AS sets and their updates. TLS carrying CBOR-encoded logical messages is the default channel profile, although other transports or encodings MAY be used if they expose an equivalent synchronization interface and security properties. SOA Service Profile: An AS-level RPKI signed object that advertises a publisher's SAPS role, service descriptor, endpoint, protocol hint, and channel public key. It is not a subscriber-provider pair object and does not contain legitimate predecessor AS sets. Accepted Service Relation: A bilateral relation created after a candidate peer's SOA service profile is discovered, the RPKI object and advertised channel identity are validated, local policy and profile compatibility are checked, and the provider accepts the service request.

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 and uRPF to derive validation rules based on a single AS's own routing information. However, according to the analysis by the SAVNET working group , 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 stable cross-AS service discovery and trust bootstrap, RPKI provides an authenticated publication substrate, and several SAV-related solutions build upon it. The SAVNET working group's BAR-SAV mechanism 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 , 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 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). 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.

Source Address Protection Service & RPKI as the Service Platform To address the above issues, collaboration between ASes is crucial. By sharing routing-dependent information, ASes can filter spoofed traffic across different locations on the Internet. Source Address Protection Service (SAPS) allows an AS to provide routing-dependent information to another AS, helping it deploy validation rules and filter spoofed packets. The AS providing routing-dependent information and receiving protection is called the service subscriber, while the AS obtaining routing-dependent 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 objects bind IP address blocks to AS numbers, providing cryptographic proof of resource ownership. By leveraging RPKI, ASes can publish bootstrap information for source validation, enabling discovery, trust establishment, and authenticated channel setup, 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 ; (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.

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 Source Origin Authorization (SOA). In the two-tier architecture considered in this document, SOA is used only as the Tier-1 bootstrap artifact: it publishes an AS-level service profile containing the publisher's role, service descriptor, endpoint, and channel key. A concrete subscriber-provider relation is created later through bilateral request validation and provider acceptance. After the private channel is established, the legitimate predecessor ASes and their updates are exchanged through the Tier-2 private channel and are used by the provider to calculate filtering rules. The following introduces the content and usage method of the SOA.

SOA Content The content of the SOA identifies one AS-level service profile. The same structure is used by subscriber-role and provider-role profiles. The SOA carries the publisher AS, the publisher's SAPS role, a stable service descriptor, and the minimum information required to establish the private channel that will carry routing-dependent SAV data. The SOA itself does not identify a concrete peer AS and does not include the Legitimate Predecessor AS list. If the ASN holder needs to publish multiple roles, capabilities, endpoints, or key epochs, the holder can issue multiple SOAs. An SOA has the following data structure: +--------------------------------------+ | SOA Data Structure | +------------------+-------------------+ | Publisher AS | Profile Role | | (Required) | (Required) | +------------------+-------------------+ | Service | Sync Endpoint | | Descriptor | Address | | (Required) | (Required) | +------------------+-------------------+ | Sync Port | Channel | | (Optional) | Protocol | | | (Optional) | +------------------+-------------------+ | Channel Public Key (Required) | +------------------+-------------------+ | Profile Serial (Optional) | +--------------------------------------+ The Publisher AS identifies the AS that publishes the profile. The Profile Role identifies whether the object is a subscriber-role profile or a provider-role profile. The Service Descriptor identifies the service family or capability profile. The Sync Endpoint Address identifies the publisher-operated endpoint used to bootstrap the private channel. The optional Sync Port identifies the port for that endpoint. The optional Channel Protocol identifies the transport used by the private channel and defaults to TLS when omitted. The Channel Public Key is used to authenticate that endpoint or validate the key exchange material used by the private channel. The optional Profile Serial identifies the publisher's local profile epoch for rollover or rollback detection.

Protection Scope and Prefix Authorization A validated SOA service profile does not by itself authorize any protected source prefix. Prefix authorization is checked after a concrete subscriber-provider service relation is accepted or refreshed. When Traffic Origin Authorization (TOA) objects are available, a valid TOA covering the subscriber AS and the protected prefix is the preferred source of explicit traffic-origin authorization. Until TOA or an equivalent traffic-origin authorization object is deployable, implementations MAY use a conservative ROA-match fallback: a prefix is accepted only if the subscriber AS is the authorized origin AS in a currently valid ROA for that prefix. This fallback is a compatibility mechanism for today's RPKI deployment and does not claim that ROA has complete packet-source authorization semantics. If neither a valid TOA nor an accepted ROA-match fallback authorizes the prefix for the subscriber AS, then the prefix is outside the protection scope of the accepted service relation and MUST NOT be treated as protected based solely on the existence of an SOA.

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," "path-consistent," "not found," or "state unavailable," but it cannot guarantee an "unspoofed" validation. For an accepted service relation, the provider first checks whether the packet's source prefix is within the subscriber's authorized protection scope. The provider then uses the Legitimate Predecessor AS set learned over the authenticated private channel to verify whether the packet arrived from a currently legitimate predecessor direction for that subscriber. If so, the validation result will be "path-consistent." 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 has no accepted service relation for the subscriber, no acceptable prefix authorization for the source prefix, or no applicable synchronized predecessor state, the result will be classified as "not found." If an accepted service relation exists but the corresponding routing-dependent state is unavailable because the private channel is down, the synchronized state is stale, a full resynchronization is pending, or continuity of the synchronized state cannot be confirmed, the result will be classified as "state unavailable."

Channel and Synchronization State For operational clarity, implementations SHOULD distinguish at least the following states for a subscriber-provider relationship: Fresh, meaning the relevant SOA profiles are valid and current routing-dependent state is available; BootstrapOnly, meaning the relevant SOA profiles are valid but no usable synchronized state has yet been installed; ResyncPending, meaning the provider is waiting for a new full snapshot after channel restart or rollover; Stale, meaning synchronized state exists but its freshness can no longer be confirmed; and WithdrawnOrExpired, meaning the SOA or the synchronized state can no longer be used. Packets MUST NOT be classified as "path-consistent" unless the relationship is in the Fresh state.

Applying Validation Outcomes to Packet Forwarding This document does not prescribe one mandatory forwarding action for each validation outcome. Autonomous Systems (ASes) MAY decide on appropriate actions based on a combination of factors, such as traffic load, defense strategies, local policy, and business relationships. For Autonomous Systems that use SOA for source address validation, packets that are validated as "spoofed" SHOULD be handled according to the accepted service profile and local policy. These packets can be dropped, rate-limited, marked, counted, or handed to additional DDoS mitigation systems. Packets classified as "state unavailable" SHOULD be handled differently from packets classified as "not found". The former indicates that an accepted service relation exists but the synchronized validation state cannot currently be trusted, while the latter indicates the absence of an applicable accepted service relation. Unless a local operator explicitly configures a stricter policy, packets classified as "state unavailable" SHOULD follow a fail-open forwarding policy. In such a policy, unavailable or untrusted synchronized state does not by itself cause a packet to be dropped; instead, the provider may log, rate-limit, mark, or request resynchronization while preserving reachability.

SOA as an SAV Information Exchange Framework

SOA-Based SAV Architecture The architecture of the source validation system based on SOA is as follows: +------------------------------------+ | Tier 1: RPKI (SOA Repository) | | Service discovery, authentication, | | server address, public key | +----------------+-------------------+ ^ | Validated SOA | +-------------------------+------------------+ | Authenticated Private Channel | | Tier 2: Legitimate predecessor ASes and | | triggered routing updates | +-------------------------+------------------+ | v +------------------+ +------------------+ | Service Provider | |Service Subscriber| +--------+---------+ +---------+--------+ | Validation Rules | Routing Info +--------v---------+ +---------+--------+ | Service Provider | | Service Subscriber| | Router | | Router | +------------------+ +------------------+ The Service Subscriber is the AS that requests protection for its source prefixes, while the Service Provider refers to the AS that uses synchronized state to enforce source address validation. Both roles can publish SOA service profiles. The subscriber uses provider-role SOAs to discover candidate providers, and the provider uses subscriber-role SOAs to authenticate request-facing identity and channel parameters. Since this validation mainly benefits the subscriber, it is considered a service. In this two-tier architecture, RPKI provides only discovery and trust bootstrap, while the private channel carries routing-dependent information after provider acceptance.

Who Needs to Generate SOA Any AS that wants to participate in SAPS can publish an SOA service profile. A subscriber-role profile exposes the identity and channel parameters a provider needs to validate a service request. A provider-role profile exposes service capability and bootstrap parameters for candidate subscribers. An AS MAY publish both roles if it both requests and provides protection services.

Choosing the SAPS Provider The SAPS Provider can be freely chosen. Selection criteria are deployment-specific and may include topology, operational capacity, business relationship, and defensive objective. However, being selected by a subscriber does not obligate the provider to process the request, establish a private channel, or install filtering rules. A service relation exists only after the provider validates the subscriber's SOA, checks local policy and profile compatibility, and explicitly accepts the request.

SOA Generation Flexibility This document does not prescribe specific methods for generating SOA objects. ASes can generate SOAs using any appropriate method that correctly identifies the publisher AS, selected profile role, service descriptor, endpoint, and channel public key. The flexibility in SOA generation allows ASes to adapt to their specific network environments and operational requirements while preserving the object-level validation rules in .

Private Channel Synchronization After the service provider validates the subscriber-role SOA, checks its own local acceptance policy, and accepts the service request, it uses the bootstrap information in the SOA to establish an authenticated private channel with the service subscriber. The initial legitimate predecessor AS set and subsequent routing-driven updates are then transmitted over that channel. Implementations MUST support TLS as the baseline private-channel transport and CBOR as the baseline message encoding. If the SOA does not explicitly specify a channel protocol, the protocol is TLS. If the SOA does not explicitly specify a synchronization port, the default port for the selected protocol is used, as defined by future specification or bilateral configuration. Other transports or encodings MAY be used if they are explicitly identified and if they provide peer authentication bound to the current SOA, integrity protection, replay resistance, ordered delivery or replay detection for state-changing messages, and a mechanism to quickly deliver triggered updates. When the selected protocol is TLS, the provider MUST compare the SubjectPublicKeyInfo of the TLS end-entity certificate presented by the remote peer with the channelPublicKey carried in the validated SOA. The provider MUST NOT accept synchronized state over that channel unless the comparison succeeds. For interoperability, the synchronization behavior over the private channel MUST support at least the following logical operations: an initial full snapshot that replaces all previously learned state for the subscriber-provider relationship, an incremental update that adds or removes legitimate predecessor ASes, a withdrawal that revokes all currently synchronized state for that relationship, and a re-authentication event following SOA rollover or channel restart. Each full snapshot or incremental update MUST be associated with monotonically increasing freshness information, such as a sequence number, version number, or timestamp from a strictly ordered local source. The provider MUST ignore stale or replayed synchronization messages and MUST apply updates in freshness order. When a private channel is re-established, the provider SHOULD request or wait for a new full snapshot before relying on subsequent incremental updates. If the provider cannot confirm continuity of synchronization state across a restart, it SHOULD discard the previously learned routing-dependent state for that subscriber-provider relationship. A subscriber MAY synchronize different legitimate predecessor AS sets to different providers. This is expected because each provider may enforce source validation at a different topological location. Carrying this information over private channels, rather than in globally visible RPKI objects, also helps limit disclosure of provider-specific routing relationships and subscriber protection policies.

Logical Synchronization Message Model The baseline private-channel wire profile serializes each logical message as a CBOR map carried over the authenticated TLS channel. The map MUST contain a msg_type text string and the common state fields described below. Implementations that use another serialization or RPC framework SHOULD preserve the following logical message semantics.

HELLO: advertises the local implementation, supported synchronization behavior, current bootstrap epoch, and nonce.
COOKIE: optionally proves return reachability and binds the peer to a fresh nonce before expensive state transfer begins.
INIT: starts a synchronization session for an accepted subscriber-provider relationship and identifies the protected relation authenticated by the validated SOA profiles.
SNAPSHOT: replaces all previously installed routing-dependent state for that relationship with a complete current authorization view.
DELTA: adds, removes, or updates a bounded portion of the authorization view after a previously acknowledged snapshot.
ACK: acknowledges the highest continuous snapshot or delta sequence number that has been accepted.
REKEY: indicates that the peer is moving to bootstrap information from a newly validated SOA or to new channel keying material.
RESYNC: requests a fresh snapshot after sequence discontinuity, channel restart, state loss, or policy downgrade.
WITHDRAW: revokes all currently synchronized routing-dependent state for the relationship.
ERROR: reports an authentication, syntax, sequence, policy, or resource error.

Each state-changing logical message MUST carry the subscriber-provider relationship identifier, bootstrap epoch, channel instance identifier, monotonically increasing sequence number, message creation time, and expiration time. In the CBOR baseline profile, these fields are encoded as map entries named relation_id, bootstrap_epoch, channel_id, seq, created_at, and expires_at. A provider MUST NOT apply a DELTA unless it can associate that delta with an accepted SNAPSHOT and a continuous sequence. A provider SHOULD treat sequence gaps, expired messages, bootstrap epoch rollback, or a lower sequence number than the accepted high-water mark as replay or rollback evidence and enter ResyncPending or Stale state.

Evidence Tags and Minimal Disclosure The private channel SHOULD carry only the authorization state needed by the provider to decide whether a protected source prefix is path-consistent at that provider. It SHOULD NOT carry raw AS paths, raw traceroute results, complete customer-policy data, or observations that are not needed for provider-side filtering. Each synchronized predecessor entry SHOULD be associated with an evidence tag. Implementations SHOULD support at least the following logical tags: bgp-only, data-plane-confirmed, bgp-and-data-plane, operator-confirmed, and temporary-exception. Additional tags MAY be defined by bilateral policy if both peers understand their semantics. A conservative default policy is to accept operator-confirmed, data-plane-confirmed, and bgp-and-data-plane entries as default path-consistent directions. A provider MAY also accept bgp-only entries when they are fresh and corroborated by provider-local BGP, multiple collectors, or historical stability. A temporary-exception entry SHOULD have a short lifetime, a reason code, and audit logging, and MUST expire automatically unless refreshed by policy.

Failure Handling Failure handling is local to the subscriber-provider relationship. A failure in one relationship MUST NOT cause a provider to discard unrelated synchronized state learned from other relationships.

If a relevant subscriber-role or provider-role SOA expires, is withdrawn, or is replaced by incompatible bootstrap information, the provider MUST stop classifying packets as "path-consistent" based solely on state bound to the old profile.
If the private channel is unavailable, the provider SHOULD retain the last accepted state only until its freshness lifetime expires. After that, the relationship enters "state unavailable" and the default forwarding behavior is fail-open unless local policy says otherwise.
If a sequence gap, rollback, duplicate bootstrap epoch, or replayed message is detected, the provider SHOULD request RESYNC and avoid applying further deltas until a fresh snapshot is accepted.
If rule installation fails on a router, the provider SHOULD treat the affected protected prefixes or interfaces as not enforced, log the failure, and avoid claiming that packets are filtered by rules that were not installed.
If routing anomalies such as route leaks or sudden path churn make predecessor state unstable, implementations MAY shorten lifetimes, require stronger evidence tags, or temporarily classify the affected entries as "state unavailable".
If a subscriber withdraws protection or reports a full withdrawal, the provider MUST remove or invalidate synchronized state for that relationship according to local configuration and router safety constraints.

Key Rollover and Channel Re-establishment When either peer changes the synchronization endpoint or rotates the public key referenced by its SOA, including a change of synchronization port or selected protocol, it MUST publish a new SOA in RPKI before requiring the other peer to trust the new bootstrap information. The peer receiving the update MUST validate the new SOA and re-authenticate the private channel against it before accepting subsequent routing-dependent updates. To reduce synchronization gaps, the publishing peer SHOULD maintain the old endpoint or key material long enough for the peer to retrieve the new SOA and re-establish the private channel. Once the new channel is authenticated and a new full snapshot is received, the provider SHOULD discard state associated only with the prior channel instance. If old and new private channels temporarily coexist, synchronized state learned from the channel bound to the most recently validated SOA profiles takes precedence. A provider MUST treat routing-dependent state associated only with an expired, withdrawn, or superseded SOA profile as "state unavailable" and MUST NOT continue classifying packets as "path-consistent" solely on the basis of that state.

Out of Scope This document defines a baseline TLS-plus-CBOR logical message profile, but it does not define transport port allocation, detailed TLS cipher-suite policy, alternate RPC mappings, or how the subscriber computes the legitimate predecessor AS set from its internal routing information. This document also does not define business policy, payment settlement, or service-level objectives between a SAPS Subscriber and a SAPS Provider.

Analysis of SOA based Source Address Validation

Analysis of Filtering Effect The filtering effect of the SAPS solution based on SOA is directly related to the number and topological location of accepted service providers. A spoofed packet can be filtered only after it reaches a deployed provider that has an accepted service relation, an authorized protected-prefix scope, and current synchronized predecessor state for the subscriber. Providers at highly connected transit positions may offer broader path encounter opportunities than edge-only providers, but the exact effect depends on traffic distribution, deployment scope, prefix authorization coverage, and the predecessor-state acquisition method. Quantitative deployment claims therefore need to be supported by a reproducible evaluation rather than by the SOA object profile itself.

Analysis of Filtering Overhead The main overheads of this solution are divided into two major parts: the storage overhead of RPKI and private-channel state, and the filtering overhead after the deployment of source validation rules. Regarding RPKI storage overhead, the two-tier architecture keeps SOA objects small because they only contain the minimum bootstrap information for service discovery and channel establishment. 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. The cost of dynamic information exchange is shifted from RPKI synchronization to the authenticated private channel. This allows routing-driven updates to be delivered much faster, at the cost of maintaining per-relationship channel state. The computational overhead associated with channel maintenance and rule generation is determined by the specific implementation chosen by each AS. Regarding ACL consumption, this remains a significant challenge. In the worst-case scenario, the inter-domain ACL consumption for SAV solutions can be approximated as the number of IP prefixes of an AS multiplied by either the number of legitimate predecessor ASes for a target or the total number of neighbors minus legitimate predecessors (depending on whether permit or deny ACLs are used), further multiplied by the number of subscribers a service provider has. To address ACL consumption challenges, two improvement approaches are proposed: 1. Service subscribers pay based on the number of IP prefixes they deploy. This would incentivize subscribers to 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, 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 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.

SOA Maintenance and Expiration The validity of an SOA service profile is bounded by normal RPKI object validation, including the EE certificate validity interval, revocation status, manifest state, and local stale-object policy. SOA profile validity is separate from the freshness lifetime of synchronized predecessor state carried over the private channel. Accepted service relations remain conditional on the relevant subscriber-role and provider-role SOAs staying valid for the expected ASes and roles. A provider SHOULD periodically revalidate the subscriber SOA used to authenticate the private channel, and a subscriber SHOULD periodically revalidate the provider SOA used for service discovery and capability screening. The revalidation interval is an operator policy, but it SHOULD be no longer than the local RPKI relying-party refresh and stale-object policy used for routing-security decisions. Routing changes do not, by themselves, require SOA reissuance. Instead, they SHOULD be sent as ordered snapshot or delta updates over the authenticated private channel. Endpoint changes, protocol changes, key rollover, role changes, or service-descriptor changes require a new SOA profile. If an SOA is revoked, withdrawn, expired, or replaced by incompatible bootstrap information, peers MUST stop accepting new routing-dependent state under the old profile and MUST treat state learned solely under that profile as unavailable until the new SOA is validated, the channel is re-authenticated, and a fresh snapshot is received.

Operation Considerations When deploying the SOA framework, the service subscriber AS can discover candidate provider ASes from provider-role SOA profiles and can select candidate providers based on parameters such as topology, operational capacity, business relationship, and defensive objective. The subscriber's choice is a service request, not a unilateral command. The provider decides whether to accept the request according to local policy, profile compatibility, resource budget, and prefix-authorization checks. To maintain the accuracy and effectiveness of the filtering mechanism, the subscriber AS SHOULD promptly send the current legitimate predecessor AS set to the provider AS after the accepted private channel is established, and MUST send triggered updates over that channel whenever routing changes affect the accepted predecessor state. Concurrently, the provider AS MUST authenticate the private channel against the current subscriber-role SOA, check that the requested protected prefixes are authorized for the subscriber, receive the latest routing-dependent data, and update its filtering rules according to local fail-safe and resource-budget policy. 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 private-channel update. The subscriber SHOULD verify whether the filtering-triggering interface is a new legitimate interface and, if so, send an updated legitimate predecessor AS set over the private channel. If the bootstrap server address, port, selected protocol, or public key has changed, the subscriber MUST additionally update the SOA in RPKI.

IANA Considerations This document does not define any new IANA registries. All IANA actions are specified in .

Security Considerations

SOA Validation SOA users MUST ensure that the SOA service profile they use has been properly validated for the expected publisher AS and role. Otherwise, they may inadvertently authenticate the wrong peer or use maliciously generated illegitimate SOAs, resulting in the incorrect filtering of legitimate traffic.

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. Implementers MUST also ensure that the private channel is authenticated against the bootstrap information in the current SOA and that a concrete service relation is accepted by the provider before synchronized predecessor state is used. Any compromise in either the bootstrap, the bilateral acceptance process, or the private-channel synchronization process could undermine the validation mechanism for the affected service relation.

Rule Applying Security When applying SOA-based filtering rules, ASes SHOULD bind each installed rule group to the accepted service relation, protected-prefix authorization state, subscriber SOA profile, provider SOA profile, and synchronized predecessor-state epoch from which the rule group was derived. 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, counters, rollback support, and testing of filtering rules are RECOMMENDED to maintain the accuracy and effectiveness of the SOA framework. Routing-dependent data learned over a private channel MUST be discarded or marked unavailable when the corresponding SOA becomes invalid, expires, or is replaced by an SOA with incompatible bootstrap information.

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.

Private Channel Security Because the legitimate predecessor AS data and triggered updates are no longer carried in RPKI, the private channel becomes the primary vehicle for dynamic synchronization. Implementations MUST provide integrity protection, replay resistance, and peer authentication bound to the current public key published in the validated SOA. The TLS baseline profile authenticates the peer by comparing the SubjectPublicKeyInfo of the TLS end-entity certificate with the channelPublicKey in the current SOA. CBOR messages carrying state changes MUST be rejected if they are stale, replayed, out of order, expired, or associated with a superseded bootstrap epoch.

Source-Authorization Boundary SOA does not prove that a packet was genuinely originated by the subscriber AS. It only authenticates the service profile and, after bilateral acceptance, enables synchronization of predecessor directions for protected prefixes. A packet classified as "path-consistent" can still be spoofed by an entity that sends traffic through a currently legitimate predecessor direction. Deployments that use ROA-match as a prefix-authorization fallback before TOA is available MUST treat that rule as a compatibility heuristic, not as complete packet-source authorization.

Privacy Considerations One motivation for the two-tier design is to avoid publishing provider-specific legitimate predecessor AS sets, subscriber protection policies, and other business-sensitive routing details in globally accessible RPKI repositories. By limiting SOA to bootstrap information and carrying routing-dependent state only over private channels, the framework reduces unnecessary disclosure of subscriber-provider relationships and synchronized path information.

Deployment Observations Operational observations suggest that the effectiveness of deploying SOA is correlated with the topological position of the chosen providers. In some scenarios, providers located at highly connected transit positions may offer broader filtering coverage than providers at the edge. Similarly, if a large amount of attack traffic is observed to involve a particular reflection point, operators may find it useful to deploy protection mechanisms near the AS where that reflection point resides. These observations are informative only and are not normative requirements of this specification.