A Profile for Traffic Origin Authorizations (TOAs)
draft-qin-savnet-toa-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Lancheng Qin , Ben Maddison , Dan Li , Igor Lubashev | ||
| Last updated | 2025-11-03 | ||
| RFC stream | (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-00
Network Working Group L. Qin
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track B. Maddison
Expires: 7 May 2026 Workonline
D. Li
Tsinghua University
I. Lubashev
Akamai
3 November 2025
A Profile for Traffic Origin Authorizations (TOAs)
draft-qin-savnet-toa-00
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 8174 [RFC8174].
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 7 May 2026.
Qin, et al. Expires 7 May 2026 [Page 1]
Internet-Draft Traffic Origin Authorization November 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
2. The TOA Content Type . . . . . . . . . . . . . . . . . . . . 4
3. The TOA eContent . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The version Element . . . . . . . . . . . . . . . . . . . 6
3.2. The asSet Element . . . . . . . . . . . . . . . . . . . . 6
3.3. The ipaddrBlocks Element . . . . . . . . . . . . . . . . 6
3.3.1. TOAIPAddressFamily . . . . . . . . . . . . . . . . . 6
3.3.2. TOAIPAddress . . . . . . . . . . . . . . . . . . . . 6
4. TOA Validation . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Operational Recommendations . . . . . . . . . . . . . . . . . 7
7. Enhancing SAV with TOAs . . . . . . . . . . . . . . . . . . . 8
8. Summary of Discussions . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 9
9.2. RPKI Signed Objects Registry . . . . . . . . . . . . . . 9
9.3. File Extension . . . . . . . . . . . . . . . . . . . . . 10
9.4. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 10
9.5. Media Type Registry . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Qin, et al. Expires 7 May 2026 [Page 2]
Internet-Draft Traffic Origin Authorization November 2025
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.
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 TOA provides a clear separation between the
authorization to originate routing information and the authorization
to originate data traffic.
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]), IP multicast, and
traffic sourced with internal-use prefixes.
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.)
Qin, et al. Expires 7 May 2026 [Page 3]
Internet-Draft Traffic Origin Authorization November 2025
* 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
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.
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-2025
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0)
id-mod-rpkiTOA-2025(TBD) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Qin, et al. Expires 7 May 2026 [Page 4]
Internet-Draft Traffic Origin Authorization November 2025
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 }
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 ASSet,
ipaddrBlocks SEQUENCE (SIZE(1..2)) OF TOAIPAddressFamily }
ASSet ::= SEQUENCE (SIZE(1..10000)) OF ASID
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
Qin, et al. Expires 7 May 2026 [Page 5]
Internet-Draft Traffic Origin Authorization November 2025
TOAIPAddress {INTEGER: ub} ::= BIT STRING (SIZE(0..ub))
END
3.1. The version Element
The version number of the TrafficOriginAttestation entry MUST be 0.
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.
3.3. The ipaddrBlocks Element
The ipaddrBlocks element encodes the set of IP address prefixes that
the specified set of AS numbers 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].
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.
Qin, et al. Expires 7 May 2026 [Page 6]
Internet-Draft Traffic Origin Authorization November 2025
* 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.
* 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. Security Considerations
The security considerations of [RFC6481], [RFC6485], [RFC6488], and
[RFC9582] also apply to the TOA object.
6. Operational Recommendations
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 ROA) and to originate traffic from a given prefix,
creating an 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.
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 ASes 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
Qin, et al. Expires 7 May 2026 [Page 7]
Internet-Draft Traffic Origin Authorization November 2025
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 ASes 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. 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 will cause improper blocks (i.e., blocking
legitimate data packets).
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.
Discussion: When different ASes are authorized for overlapping
prefixes (e.g., there are two TOAs { AS1, 1.2.0.0/20 } and { AS2,
1.2.0.0/24 }), does SAV consider both AS1 and AS2 authorized to
source traffic from the more specific prefix (1.2.0.0/24), or only
AS2? In the current context, both AS1 and AS2 could be interpreted
as authorized for the more specific prefix. If the intent is to
restrict AS1 from the more specific prefix, the first TOA could be
modified to explicitly exclude the more specific prefix.
8. Summary of Discussions
This section is to be removed before publishing as an RFC.
Qin, et al. Expires 7 May 2026 [Page 8]
Internet-Draft Traffic Origin Authorization November 2025
Recent 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. 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 several 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, our analysis indicates that
registering such a ROA introduces additional risks of forged-origin
hijacking: an attacker could impersonate the AS listed in the ROA and
announce a BGP route that would be considered RPKI-valid.
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 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.
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:
Qin, et al. Expires 7 May 2026 [Page 9]
Internet-Draft Traffic Origin Authorization November 2025
+==============+=============================+======================+
|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:
+====================+================+======================+
| 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--rpkiTOA-2025 | 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:
Qin, et al. Expires 7 May 2026 [Page 10]
Internet-Draft Traffic Origin Authorization November 2025
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
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
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[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>.
Qin, et al. Expires 7 May 2026 [Page 11]
Internet-Draft Traffic Origin Authorization November 2025
[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>.
[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>.
[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>.
[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>.
[X.690] ITU-T, ""Information Technology - ASN.1 encoding rules:
pecification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)"", 2021.
11.2. Informative References
[I-D.ietf-savnet-inter-domain-problem-statement]
Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Gap
Analysis, Problem Statement, and Requirements for Inter-
Domain SAV", Work in Progress, Internet-Draft, draft-ietf-
savnet-inter-domain-problem-statement-12, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-12>.
[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-08, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-08>.
[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>.
Qin, et al. Expires 7 May 2026 [Page 12]
Internet-Draft Traffic Origin Authorization November 2025
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 7 May 2026 [Page 13]