A Profile for Traffic Origin Authorizations (TOAs)

Introduction Source Address Validation (SAV) aims to detect and discard data packets that use a spoofed source IP address. The fundamental concept of the current practice is directionality: for data packets using a given source IP address, only those coming from a specific direction are considered legitimate. BCP84 introduces a more structured direction-based logic, i.e., identifying the incoming directions for traffic of a given source AS and determining the source prefix space that the AS is authorized to use. To support such validation, a mechanism is needed to allow entities to verify that an AS has been authorized to originate traffic using one or more prefixes as the source IP address. One of the main challenges is that the current infrastructure for validating the right to originate traffic with a given source address has so far been built almost entirely on top of mechanisms designed to validate the right to originate routing information for destination-based routing. In most cases, where the two use cases overlap, this approach works reasonably well. However, when the traffic origin diverges from the route origin, ambiguity and misalignment arise between the intended use case and the mechanisms being applied. This distinction is particularly important in scenarios where traffic is unidirectional and there is no need to attract return traffic via route announcements, or where the return traffic is intentionally directed to another location. Examples include:

Content Delivery Networks (CDNs) using Direct Server Return (DSR) (see and ): An ingress AS originates a BGP route for an anycast service prefix and thereby attracts requests sent by users to the corresponding anycast address. The requests are then delivered to a content server located in another AS. Using DSR, the content server sends responses directly to the users with the anycast service address as the source address. Thus, the ingress AS is the route origin, whereas the AS hosting the content server is a traffic origin for the prefix. The latter does not originate a BGP route for the prefix because it is not intended to attract user requests.
DDoS mitigation with Direct Server Return (DSR) : The scrubber AS originates a BGP route for the protected prefix to attract incoming traffic to its scrubbing infrastructure. After traffic has been cleaned, the scrubber AS delivers the legitimate traffic to the customer AS, for example through a tunnel. Return traffic follows a different path: the customer AS sends it directly to the original sender through its regular upstream provider, using an address from the protected prefix as the source address. Therefore, the scrubber AS is the route origin, whereas the customer AS is a traffic origin for the protected prefix without originating the corresponding BGP route.
Unidirectional or asymmetric delivery systems: Some multicast or satellite delivery systems use a data channel that is unidirectional or asymmetric with respect to the return or control channel. When such traffic crosses AS boundaries, the source AS may originate traffic using source addresses from a prefix for which it does not originate a BGP route.

The purpose of a Traffic Origin Authorization (TOA) is to explicitly authorize an AS to originate traffic using a given prefix as a source address, even when that AS is not authorized to originate any BGP routes to that prefix. A conventional ROA for that AS would also authorize the AS to originate routes for the prefix from the ROV perspective. A TOA provides a clear separation between the authorization to originate routing information and the authorization to originate data traffic. The TOA makes use of the template for RPKI digitally signed object , which defines a Cryptographic Message Syntax (CMS) wrapper for a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the TOA (see Section 4 of ), this document defines:

The OID that identifies the signed object as being a TOA. (This OID appears within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object.)
The ASN.1 syntax for the TOA eContent. (This is the payload that specifies the ASes being authorized to originate traffic as well as the prefixes that the ASes may use as the source IP address.) The TOA eContent is ASN.1 encoded using the Distinguished Encoding Rules (DER) .
Additional steps required to validate TOAs (in addition to the validation steps specified in ).

The content of a TOA identifies a list of one or more ASes that have been authorized by the IP address block holder to originate traffic and a list of one or more IP address prefixes within the address block that will be used as the source IP address. The IP address block holder can register one or more TOAs to authorize which ASes can originate traffic using specific prefixes within the block as the source IP address. By registering TOAs, IP address block holders can prevent their source IP addresses from being forged by unauthorized ASes, while allowing legitimate but non-announcing ASes to originate traffic. AS operators can leverage TOAs to improve the accuracy and robustness of SAV, thereby enhancing protection against source address spoofing attacks.

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.

The TOA Content Type The content-type for a TOA is defined as id-ct-trafficOriginAuthz and has the numerical value of 1.2.840.113549.1.9.16.1.TBD. This OID MUST appear within both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object (see ).

The TOA eContent The content of a TOA identifies a list of one or more ASes that have been authorized by the address block holder to originate traffic and a list of one or more IP address prefixes within the address block that will be used as the source IP address. A TOA is formally defined as:

The version Element The version number of the TrafficOriginAttestation entry MUST be 0.

The asSet Element The asSet element contains a set of AS numbers that are authorized to originate traffic using source IP addresses within the given IP address prefixes. The ASIDs in the asSet element MUST be listed in strictly increasing numeric order. The asSet element MUST NOT contain duplicate ASIDs.

The ipAddrBlocks Element The ipAddrBlocks element encodes the set of IP address prefixes that the specified set of ASes is authorized to use as source addresses when originating traffic.

TOAIPAddressFamily Within the TOAIPAddressFamily structure, the addressFamily element contains the Address Family Identifier (AFI) of an IP address family. Each addressFamily MUST be either 0001 or 0002. There MUST be only one instance of TOAIPAddressFamily per unique AFI in the TOA. The addresses field contains IP prefixes as a sequence of type TOAIPAddress.

TOAIPAddress This element is of type BIT STRING and represents a single IP address prefix .

Canonical Form for ipAddrBlocks The ipAddrBlocks element MUST be encoded in canonical form. This canonicalization procedure builds upon the canonicalization procedure specified in Section 2.2.3.6 of and takes inspiration from Section 4.3.3 of . In order to compare, sort, and remove duplicate IP prefixes from the contents of the ipAddrBlocks element, each TOAIPAddress element is mapped to an abstract data element composed of three integer values:

afi:: The AFI value appearing in the addressFamily element of the containing TOAIPAddressFamily, represented as an integer.
addr:: The first IP address of the IP prefix appearing in the TOAIPAddress element, represented as a 32-bit integer for IPv4 or a 128-bit integer for IPv6.
plen:: The length of the IP prefix appearing in the TOAIPAddress element, represented as an integer.

The set of TOAIPAddress elements is totally ordered. The order of two TOAIPAddress elements is determined by the first non-equal comparison in the following list:

Data elements with a lower afi value precede data elements with a higher afi value.
Data elements with a lower addr value precede data elements with a higher addr value.
Data elements with a lower plen value precede data elements with a higher plen value.

Data elements for which all three values compare equal are duplicates of one another. Within each address family, CAs MUST sort the TOAIPAddress elements according to the order defined above. Duplicate IP prefixes MUST NOT appear.

TOA Validation To validate a TOA, the Relying Party (RP) MUST perform all the validation checks specified in as well as the following additional specific validation steps:

The IP address delegation extension is present in the end-entity (EE) certificate (contained within the TOA), and every IP address prefix in the TOA payload is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.
The EE certificate's IP address delegation extension MUST NOT contain "inherit" elements as described in .
The Autonomous System identifier delegation extension described in is not used in TOAs and MUST NOT be present in the EE certificate.
The TOA content fully conforms with all requirements specified in Sections 2 and 3.

If any of the above checks fail, the TOA MUST be considered invalid and an error SHOULD be logged.

Implementation Considerations CAs are RECOMMENDED to generate a new key pair for each new TOA and only sign one TOA with each EE certificate. This type of EE certificate is termed a "one-time-use" EE certificate; see Section 3 of . TOA object filenames use the ".toa" extension. CAs are RECOMMENDED to follow the guidelines for naming TOA objects based on Section 2.2 of , i.e., convert the 160-bit hash of the EE's public key value into a 27-character string using Base 64 Encoding with the URL and Filename Safe Alphabet; see Section 5 of . See Section 7.7 of for more information and considerations.

Security Considerations The security considerations of , , , and also apply to the TOA object.

Operational Considerations

When to Register a TOA Operators should exercise care when deciding to register a Traffic Origin Authorization (TOA). A TOA is primarily useful in scenarios where the traffic origin AS and the route origin AS differ. In such cases, registering a TOA provides the necessary authorization for traffic origination while avoiding ambiguity between routing and traffic authorization. Conversely, when the same AS is both authorized to originate routes (via an existing Route Origin Authorization (ROA) ) and to originate traffic from a given prefix, creating a duplicated TOA would add unnecessary storage and transmission overhead in the RPKI system. Therefore, operators are RECOMMENDED to follow these practices:

Operators SHOULD NOT register a TOA that is identical to or covered by an existing ROA, unless there are valid operational reasons.
TOA registrations SHOULD be periodically reviewed and updated to reflect current operational practices.

For the purpose of determining whether a TOA is identical to or covered by an existing ROA, a TOA is evaluated as a set of (ASID, IP prefix) pairs formed by combining each ASID in the asSet element with each IP prefix in the ipAddrBlocks element. A TOA pair is considered identical to an existing ROA if the ASID is identical and the IP prefix is identical to a prefix in that ROA. A TOA pair is considered covered by an existing ROA if there exists a ROA whose ASID is identical to the ASID in the TOA pair and whose ipAddrBlocks field covers the IP prefix in the TOA pair. A TOA is considered identical to or covered by existing ROAs only if all such pairs are identical to or covered by existing ROAs. Another operational consideration concerns situations where a prefix holder has already signed a ROA for an AS and intends to register a TOA that covers multiple ASNs and prefixes. For example, suppose a prefix holder has an existing ROA {AS1, Prefix1} and wishes to create a TOA {(AS1, AS2, AS3), (Prefix1, Prefix2, Prefix3)}. In this case, the portion {AS1, Prefix1} is already covered by the ROA and is therefore redundant within the TOA. A straightforward way to avoid redundancy would be to split the TOA into smaller objects, such as {(AS1), (Prefix2, Prefix3)} and {(AS2, AS3), (Prefix1, Prefix2, Prefix3)}. However, doing so may unnecessarily increase operational complexity and management overhead. Therefore, it is RECOMMENDED to register a single consolidated TOA covering all relevant ASNs and prefixes. The existence of an overlapping ROA does not invalidate the TOA but should be understood in its respective scope: the ROA authorizes route origin, while the TOA authorizes traffic origin. This approach maintains clear semantics between routing and traffic authorization while minimizing operational burden. Following these recommendations minimizes overhead on the RPKI system while ensuring that TOAs are deployed effectively to enhance Source Address Validation (SAV).

Enhancing SAV with TOAs Without TOAs, current SAV mechanisms (e.g., BAR-SAV ) typically use BGP data, ROAs, or IRR route objects to determine the legitimate source IP address space of a given AS. However, due to the asymmetry between prefixes used as the source IP address and prefixes advertised into the routing system (as mentioned in Section 1), using BGP data, ROAs, and IRR route objects to perform SAV may cause improper blocks (i.e., blocking legitimate data packets). By registering TOAs, IP address block holders can prevent their source addresses from being spoofed by unauthorized ASes, while allowing authorized but non-announcing ASes to originate traffic using these source addresses. AS operators can leverage TOAs to improve the accuracy and robustness of SAV, thereby enhancing protection against source address spoofing attacks.

SAV Processing with TOAs and ROAs When performing SAV, both TOAs and ROAs should be used to determine which prefixes a specific AS is authorized to use as source addresses. For a given AS, the set of prefixes listed in all TOAs and ROAs that include the AS is considered authorized for use as source addresses. Note: The source authorization information provided by TOAs, together with the implicit source authorization derived from ROAs, is intended to be used in conjunction with other path authorization/validation methods to construct a complete inter-domain SAV solution.

Handling Overlapping Prefixes in TOAs In cases where multiple TOAs authorize different ASes for overlapping prefixes, all applicable authorizations apply. For example, if there are two TOAs {AS1, 203.0.113.0/24} and {AS2, 203.0.113.0/28}, both AS1 and AS2 are considered authorized for the more specific prefix. If the intention is to restrict AS1 from the more specific prefix, the first TOA must be modified to explicitly exclude that prefix.

Summary of Discussions This section is to be removed before publishing as an RFC. Discussions on the SAVNET mailing list have considered whether it would be feasible to create a special ROA for an AS that is not authorized to originate a route to a given prefix, as an alternative to implementing TOA. Doing so would require extending ROAs or overloading their semantics to cover this use case, and may require modifications to existing Route Origin Validation (ROV) processing to prevent these special ROAs from being used. The TOA authors consulted ASN.1 experts on this approach, who strongly advised against it. Other participants also recommended against overloading ROA semantics. Accordingly, the current consensus among the TOA authors and some SAVNET participants is that defining a dedicated TOA object represents a more appropriate and robust solution. Some discussions have also proposed creating a conventional ROA for such scenarios, even though the AS is not authorized to originate routes to the given prefix. However, registering such a ROA may introduce an additional risk of forged-origin hijacking. For example, consider a scenario where AS1 is the legitimate route origin for prefix P and has a ROA for P, while AS2 is authorized only to originate traffic using P as a source address. If the prefix holder creates a conventional ROA authorizing AS2 for P, then BGP announcements originated by AS2 for P would be considered RPKI-valid, even though AS2 was not intended to originate routes to P. This risk may remain even when path validation mechanisms are deployed. Suppose AS1 has deployed ASPA, while AS2 has not yet deployed ASPA, which may be common when AS2 is a small edge AS or otherwise outside the prefix holder's operational control. An attacker, ASX, could announce a path such as ASX AS2 for prefix P, claiming to be a provider of AS2. Because the conventional ROA authorizes AS2 as a route origin for P, and because AS2 has no ASPA object that can be used to reject the forged provider relationship, the route may not be rejected by the combination of ROV and ASPA-based path validation. A TOA avoids this ambiguity by authorizing AS2 only as a traffic origin for P, without authorizing AS2 as a route origin for P. Fundamentally, the choice of how to authorize the traffic origin rests with the prefix holder. If the prefix holder wishes ROAs to include only ASes authorized to originate routes to its prefix, there is a clear need to register a TOA to authorize other ASes to only source traffic from the prefix. Conversely, if the prefix holder is unconcerned about forged-origin hijacking or other potential risks, they may instead choose to register a conventional ROA. Overall, this document makes three main contributions:

It analyzes the semantic limitation of the current ROA mechanism: a ROA cannot express that an AS is authorized to originate traffic using a prefix as a source address, while not being authorized to announce routes to that prefix.
It recognizes that existing ROAs can still be used by SAV mechanisms as implicit source-address authorization information, although the original semantics of a ROA are to authorize route origination.
It defines a new RPKI signed object, the Traffic Origin Authorization (TOA), which explicitly authorizes an AS to originate traffic using a prefix as a source address. TOA provides prefix holders with a safer way to express this authorization in scenarios where traffic-origin authorization differs from route-origin authorization, without introducing the additional route-origin security risks associated with registering a conventional ROA for that AS.

IANA Considerations

SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) IANA is requested to allocate the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:

Decimal	Description	Reference
TBD	id-ct-trafficOriginAuthz	draft-qin-savnet-toa

RPKI Signed Objects Registry Please add an item for the TOA file extension to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as follows:

Name	OID	Reference
Traffic Origin Authorization	1.2.840.113549.1.9.16.1.TBD	draft-qin-savnet-toa

File Extension Please add an item for the TOA file extension to the "RPKI Repository Name Scheme" registry created by as follows:

Filename Extension	RPKI Object	Reference
.toa	Traffic Origin Authorization	draft-qin-savnet-toa

SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) IANA is requested to allocate the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:

Decimal	Description	Reference
TBD	id-mod-rpkiTOA-2026	draft-qin-savnet-toa

Media Type Registry The IANA is requested to register the media type application/rpki-toa in the "Media Type" registry as follows: Intended usage: COMMON Restrictions on usage: None Change controller: IETF ]]>

Acknowledgements The authors would like to thank Jeffrey Haas for his valuable contributions in enriching the use cases and clarifying the challenges described in Section 1. Special thanks also go to Job Snijders, who provided expert feedback on the ASN.1 considerations discussed in Section 8.