A Profile for Traffic Origin Authorizations (TOAs)
draft-qin-savnet-toa-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lancheng Qin , Ben Maddison , Dan Li , Igor Lubashev | ||
| Last updated | 2026-08-17 | ||
| Replaces | draft-qin-sidrops-toa | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-qin-savnet-toa-02
SAVNET L. Qin
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track B. Maddison
Expires: 18 February 2027 Workonline
D. Li
Tsinghua University
I. Lubashev
Akamai
17 August 2026
A Profile for Traffic Origin Authorizations (TOAs)
draft-qin-savnet-toa-02
Abstract
This document defines a standard profile for Traffic Origin
Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected
content type for use with the Resource Public Key Infrastructure
(RPKI). A TOA is a digitally signed object that provides a means of
verifying that an IP address block holder has authorized an
Autonomous System (AS) to originate traffic using source IP addresses
within the address block.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Qin, et al. Expires 18 February 2027 [Page 1]
Internet-Draft Traffic Origin Authorization August 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. The TOA Content Type . . . . . . . . . . . . . . . . . . . . 5
3. The TOA eContent . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The version Element . . . . . . . . . . . . . . . . . . . 6
3.2. The asSet Element . . . . . . . . . . . . . . . . . . . . 7
3.3. The ipAddrBlocks Element . . . . . . . . . . . . . . . . 7
3.3.1. TOAIPAddressFamily . . . . . . . . . . . . . . . . . 7
3.3.2. TOAIPAddress . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Canonical Form for ipAddrBlocks . . . . . . . . . . . 7
4. TOA Validation . . . . . . . . . . . . . . . . . . . . . . . 8
5. Implementation Considerations . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Operational Considerations . . . . . . . . . . . . . . . . . 9
7.1. When to Register a TOA . . . . . . . . . . . . . . . . . 9
7.2. Enhancing SAV with TOAs . . . . . . . . . . . . . . . . . 10
7.2.1. SAV Processing with TOAs and ROAs . . . . . . . . . . 11
7.2.2. Handling Overlapping Prefixes in TOAs . . . . . . . . 11
8. Summary of Discussions . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 13
9.2. RPKI Signed Objects Registry . . . . . . . . . . . . . . 13
9.3. File Extension . . . . . . . . . . . . . . . . . . . . . 13
9.4. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 14
9.5. Media Type Registry . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Qin, et al. Expires 18 February 2027 [Page 2]
Internet-Draft Traffic Origin Authorization August 2026
1. 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 [RFC8704] 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 [I-D.ietf-savnet-inter-domain-problem-statement] and
[I-D.ietf-sidrops-bar-sav]): 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) [CLOUDFLARE-MT]:
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
Qin, et al. Expires 18 February 2027 [Page 3]
Internet-Draft Traffic Origin Authorization August 2026
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 [RFC9582] 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
[RFC6488], which defines a Cryptographic Message Syntax (CMS) wrapper
[RFC5652] for a generic validation procedure for RPKI signed objects.
Therefore, to complete the specification of the TOA (see Section 4 of
[RFC6488]), 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) [X.690].
* Additional steps required to validate TOAs (in addition to the
validation steps specified in [RFC6488]).
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
Qin, et al. Expires 18 February 2027 [Page 4]
Internet-Draft Traffic Origin Authorization August 2026
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.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. 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 [RFC6488]).
3. 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:
RPKI-TOA-2026
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0)
id-mod-rpkiTOA-2026(TBD) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
ct-trafficOriginAttestation CONTENT-TYPE ::=
{ TYPE TrafficOriginAttestation
IDENTIFIED BY id-ct-trafficOriginAuthz }
Qin, et al. Expires 18 February 2027 [Page 5]
Internet-Draft Traffic Origin Authorization August 2026
id-ct-trafficOriginAuthz OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) trafficOriginAuthz(TBD) }
TrafficOriginAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
asSet SEQUENCE (SIZE(1..10000)) OF ASID,
ipAddrBlocks SEQUENCE (SIZE(1..2)) OF TOAIPAddressFamily }
ASID ::= INTEGER (0..4294967295)
TOAIPAddressFamily ::= SEQUENCE {
addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),
addresses ADDRESS-FAMILY.&Addresses
({AddressFamilySet}{@addressFamily}) }
ADDRESS-FAMILY ::= CLASS {
&afi OCTET STRING (SIZE(2)) UNIQUE,
&Addresses
} WITH SYNTAX { AFI &afi ADDRESSES &Addresses }
AddressFamilySet ADDRESS-FAMILY ::=
{ addressFamilyIPv4 | addressFamilyIPv6 }
addressFamilyIPv4 ADDRESS-FAMILY ::=
{ AFI afi-IPv4 ADDRESSES TOAAddressesIPv4 }
addressFamilyIPv6 ADDRESS-FAMILY ::=
{ AFI afi-IPv6 ADDRESSES TOAAddressesIPv6 }
afi-IPv4 OCTET STRING ::= '0001'H
afi-IPv6 OCTET STRING ::= '0002'H
TOAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF TOAIPAddress{ub-IPv4}
TOAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF TOAIPAddress{ub-IPv6}
ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 128
TOAIPAddress {INTEGER: ub} ::= BIT STRING (SIZE(0..ub))
END
3.1. The version Element
The version number of the TrafficOriginAttestation entry MUST be 0.
Qin, et al. Expires 18 February 2027 [Page 6]
Internet-Draft Traffic Origin Authorization August 2026
3.2. 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.
3.3. 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.
3.3.1. 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.
3.3.2. TOAIPAddress
This element is of type BIT STRING and represents a single IP address
prefix [RFC3779].
3.3.3. 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 [RFC3779] and takes inspiration from
Section 4.3.3 of [RFC9582].
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:
Qin, et al. Expires 18 February 2027 [Page 7]
Internet-Draft Traffic Origin Authorization August 2026
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:
1. Data elements with a lower afi value precede data elements with a
higher afi value.
2. Data elements with a lower addr value precede data elements with
a higher addr value.
3. 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.
4. TOA Validation
To validate a TOA, the Relying Party (RP) MUST perform all the
validation checks specified in [RFC6488] as well as the following
additional specific validation steps:
* The IP address delegation extension [RFC3779] 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 [RFC3779].
* The Autonomous System identifier delegation extension described in
[RFC3779] is not used in TOAs and MUST NOT be present in the EE
certificate.
Qin, et al. Expires 18 February 2027 [Page 8]
Internet-Draft Traffic Origin Authorization August 2026
* 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.
5. 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 [RFC6487].
TOA object filenames use the ".toa" extension. CAs are RECOMMENDED
to follow the guidelines for naming TOA objects based on Section 2.2
of [RFC6481], 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 [RFC4648]. See
Section 7.7 of [I-D.ietf-sidrops-publication-server-bcp] for more
information and considerations.
6. Security Considerations
The security considerations of [RFC6481], [RFC6485], [RFC6488], and
[RFC9582] also apply to the TOA object.
7. Operational Considerations
7.1. 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) [RFC9582]) 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.
Qin, et al. Expires 18 February 2027 [Page 9]
Internet-Draft Traffic Origin Authorization August 2026
* 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).
7.2. Enhancing SAV with TOAs
Without TOAs, current SAV mechanisms (e.g., BAR-SAV
[I-D.ietf-sidrops-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).
Qin, et al. Expires 18 February 2027 [Page 10]
Internet-Draft Traffic Origin Authorization August 2026
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.
7.2.1. 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.
7.2.2. 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.
8. 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.
Qin, et al. Expires 18 February 2027 [Page 11]
Internet-Draft Traffic Origin Authorization August 2026
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.
Qin, et al. Expires 18 February 2027 [Page 12]
Internet-Draft Traffic Origin Authorization August 2026
* 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.
9. IANA Considerations
9.1. 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 |
+---------+--------------------------+----------------------+
Table 1
9.2. 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 | 1.2.840.113549.1.9.16.1.TBD | draft-qin-savnet-toa |
|Origin | | |
|Authorization | | |
+--------------+-----------------------------+----------------------+
Table 2
9.3. File Extension
Please add an item for the TOA file extension to the "RPKI Repository
Name Scheme" registry created by [RFC6481] as follows:
Qin, et al. Expires 18 February 2027 [Page 13]
Internet-Draft Traffic Origin Authorization August 2026
+====================+================+======================+
| Filename Extension | RPKI Object | Reference |
+====================+================+======================+
| .toa | Traffic Origin | draft-qin-savnet-toa |
| | Authorization | |
+--------------------+----------------+----------------------+
Table 3
9.4. 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 |
+---------+---------------------+----------------------+
Table 4
9.5. Media Type Registry
The IANA is requested to register the media type application/rpki-toa
in the "Media Type" registry as follows:
Type name: application
Subtype name: rpki-toa
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: Carries an RPKI TOA. This media type contains no active content. See Section 5 of draft-qin-savnet-toa for further information.
Interoperability considerations: None
Published specification: draft-qin-savnet-toa
Applications that use this media type: RPKI operators
Additional information:
Content: This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of prefixes and an AS identifier as defined in draft-qin-savnet-toa.
Magic number(s): None
File extension(s): .toa
Macintosh file type code(s): None
Person & email address to contact for further information:
Lancheng Qin <qinlc@mail.zgclab.edu.cn>
Intended usage: COMMON
Restrictions on usage: None
Change controller: IETF
Qin, et al. Expires 18 February 2027 [Page 14]
Internet-Draft Traffic Origin Authorization August 2026
10. 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.
11. References
11.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)",
RFC 6485, DOI 10.17487/RFC6485, February 2012,
<https://www.rfc-editor.org/info/rfc6485>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
Qin, et al. Expires 18 February 2027 [Page 15]
Internet-Draft Traffic Origin Authorization August 2026
[X.690] "Information Technology - ASN.1 encoding rules:
pecification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
[RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
Kent, "A Profile for Route Origin Authorizations (ROAs)",
RFC 9582, DOI 10.17487/RFC9582, May 2024,
<https://www.rfc-editor.org/info/rfc9582>.
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram,
"Problem Statement, Gap Analysis, and Requirements for
Inter-Domain Source Address Validation", Work in Progress,
Internet-Draft, draft-ietf-savnet-inter-domain-problem-
statement-21, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-21>.
[I-D.ietf-sidrops-bar-sav]
Sriram, K., Lubashev, I., and D. Montgomery, "Source
Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-
SAV)", Work in Progress, Internet-Draft, draft-ietf-
sidrops-bar-sav-10, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-10>.
[I-D.ietf-sidrops-publication-server-bcp]
Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and
J. Snijders, "Best Practices for Operating Resource Public
Key Infrastructure (RPKI) Publication Services", Work in
Progress, Internet-Draft, draft-ietf-sidrops-publication-
server-bcp-09, 29 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
publication-server-bcp-09>.
Qin, et al. Expires 18 February 2027 [Page 16]
Internet-Draft Traffic Origin Authorization August 2026
[CLOUDFLARE-MT]
"Magic Transit Reference Architecture", 2026,
<https://developers.cloudflare.com/reference-
architecture/architectures/magic-transit/#default-
configuration-ingress-only-direct-server-return>.
Authors' Addresses
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Ben Maddison
Workonline
Cape Town
South Africa
Email: benm@workonline.africa
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Igor Lubashev
Akamai
Cambridge,
United States of America
Email: ilubashe@akamai.com
Qin, et al. Expires 18 February 2027 [Page 17]