A Profile for Source Origin Authorization (SOA) Service Profiles
draft-ren-sidrops-soa-profile-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 | Ren Gang , million , Xia Yin , Shuqi Liu | ||
| Last updated | 2026-06-23 | ||
| 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-ren-sidrops-soa-profile-02
SIDROPS G. Ren
Internet-Draft M.L. Jia
Intended status: Informational X. Yin
Expires: 25 December 2026 S. Liu
Tsinghua University
23 June 2026
A Profile for Source Origin Authorization (SOA) Service Profiles
draft-ren-sidrops-soa-profile-02
Abstract
This document defines Source Origin Authorization (SOA), a new object
in the Resource Public Key Infrastructure (RPKI), for publishing an
AS-level service profile used by inter-AS source address protection
services. An SOA object is a digitally signed artifact that carries
the publisher AS, its service role, a service descriptor, and the
bootstrap information needed to authenticate a private
synchronization channel, such as an endpoint address, an optional
port, an optional protocol identifier, and a public key. An SOA does
not itself create a subscriber-provider service relation, authorize
arbitrary protected prefixes, or carry legitimate predecessor AS
sets. A concrete service relation is established only after
discovery, bilateral request validation, and provider acceptance.
Routing-dependent data and subsequent updates are exchanged over the
authenticated private channel rather than being stored in the RPKI
repository.
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 25 December 2026.
Ren, et al. Expires 25 December 2026 [Page 1]
Internet-Draft SOA Service Profiles June 2026
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SOA Content-Type . . . . . . . . . . . . . . . . . . . . . . 5
4. SOA eContent . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Field Semantics and Encoding . . . . . . . . . . . . . . . . 7
6. SOA Validation . . . . . . . . . . . . . . . . . . . . . . . 8
7. Prefix Authorization Scope . . . . . . . . . . . . . . . . . 8
8. Operation Considerations . . . . . . . . . . . . . . . . . . 9
9. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10.1. RPKI Signed Objects Registry . . . . . . . . . . . . . . 10
10.2. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . 10
10.3. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . 10
10.4. RPKI Repository Name Scheme . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Source Address Validation (SAV) is essential for Internet security,
ensuring that packets carry legitimate and verifiable source
addresses and preventing spoofed traffic.
Ren, et al. Expires 25 December 2026 [Page 2]
Internet-Draft SOA Service Profiles June 2026
Existing SAV solutions, such as IEF[RFC2827] and
uRPF[RFC3704][RFC8704], face deployment challenges due to their
"self-deployment, global benefit" nature. Moreover, methods relying
solely on local routing information suffer from two key limitations:
1. Spoofed traffic may already consume network resources before
being filtered.
2. Reflection attacks can make spoofed packets appear legitimate by
the time they reach the victim, rendering local SAV ineffective.
To address these issues, *inter-AS collaboration* is critical.
Sharing routing-dependent validation information enables upstream
ASes to help with validation and early filtering, reducing spoofed
traffic's impact.
However, building trust and coordination among ASes is difficult,
with key barriers being:
* The challenge of discovering and trusting peer ASes.
* The lack of effective mechanisms to express and enforce unilateral
security needs.
An authenticated, standardized publication substrate is needed to
support trust bootstrap and service discovery. The Resource Public
Key Infrastructure (RPKI), as a global, open system for authenticated
routing-related objects, can serve this stable bootstrap role.
RPKI enables ASes to discover peers and authenticate published
bootstrap information before coordinating source address validation
over a separate channel. This document does not use RPKI as a
repository for routing-dependent predecessor state.
While RPKI primarily supports routing security, it can also help
secure the data plane. A key component of SAV is determining the
valid ingress direction for traffic from a given AS. The SOA
framework addresses this need by using RPKI as a trusted bootstrap
layer and a private channel as the dynamic information layer.
The SOA object leverages RPKI to publish only the minimum information
needed to discover a service relationship and establish an
authenticated private channel. The legitimate predecessor ASes and
their updates are exchanged over that private channel, which also
helps avoid exposing provider-specific path data in public RPKI
repositories.
Ren, et al. Expires 25 December 2026 [Page 3]
Internet-Draft SOA Service Profiles June 2026
An SOA is generated by the AS that publishes a source-address-
protection service profile. A subscriber-role SOA advertises
request-facing identity and channel parameters, while a provider-role
SOA advertises service capability and channel parameters. A concrete
subscriber-provider service relation exists only after bilateral
request validation and provider acceptance. For detailed procedures,
see [I-D.ren-sidrops-soa-usage].
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. 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.
*Service Subscriber*: In the context of the Source Address Protection
Service, this refers to the AS that requests the service and is being
protected.
*Service Provider*: In the context of the Source Address Protection
Service, this refers to the AS that provides the service and protects
other ASes.
*SOA Service Profile*: An AS-level RPKI signed object that advertises
a publisher's service role, service descriptor, endpoint, protocol
hint, and channel public key. It is not a pairwise subscriber-
provider object and does not contain legitimate predecessor AS sets.
Ren, et al. Expires 25 December 2026 [Page 4]
Internet-Draft SOA Service Profiles June 2026
*Accepted Service Relation*: A bilateral relation created after one
party discovers the other party's SOA service profile, validates the
RPKI object and advertised channel identity, checks local policy, and
the provider accepts the service request.
3. SOA Content-Type
The content-type for an SOA is defined as sourceOriginAuthz and has
an IANA-assigned numerical value of TBD. This OID MUST appear both
within the eContentType in the encapContentInfo object as well as the
content-type signed attribute in the signerInfo object (see
[RFC6488]).
4. SOA eContent
The content of an SOA identifies one AS-level service profile
published by one AS. The same profile structure is used for
subscriber-role and provider-role profiles. The object carries the
publisher AS, the publisher's service role, a stable service
descriptor, and the minimum channel bootstrap information needed to
authenticate a private synchronization channel. The SOA does not
carry routing-dependent validation data such as the legitimate
predecessor AS list, and it does not by itself create a subscriber-
provider service relation. If an ASN holder needs to publish
multiple roles, capabilities, endpoints, or key epochs, it 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) |
+--------------------------------------+
And an SOA is formally defined as:
Ren, et al. Expires 25 December 2026 [Page 5]
Internet-Draft SOA Service Profiles June 2026
SourceOriginAttestation ::= SEQUENCE {
publisherAS ASID,
profileRole ProfileRole,
serviceDescriptor ServiceDescriptor,
syncEndpoint IPAddress,
syncPort PortNumber OPTIONAL,
channelProtocol ProtocolID OPTIONAL,
channelPublicKey SubjectPublicKeyInfo,
profileSerial INTEGER OPTIONAL
}
ProfileRole ::= ENUMERATED {
subscriber(0),
provider(1)
}
ASID ::= INTEGER (0..4294967295)
ServiceDescriptor ::= IA5String (SIZE (1..64))
PortNumber ::= INTEGER (1..65535)
ProtocolID ::= IA5String (SIZE (1..32))
SubjectPublicKeyInfo ::= OCTET STRING
IPAddress ::= BIT STRING
The publisherAS field identifies the AS that publishes the service
profile. The profileRole field identifies whether the profile is
published in the subscriber role or the provider role. The
serviceDescriptor field identifies the service family or capability
profile for which the SOA is intended. The syncEndpoint field
identifies the publisher-operated endpoint used during private-
channel establishment. The optional syncPort field identifies the
transport-layer port for that endpoint. The optional channelProtocol
field identifies the private-channel protocol family. If
channelProtocol is absent, the protocol defaults to TLS[RFC8446]. If
syncPort is absent, the default port for the selected protocol is
used, as defined by a future specification or by bilateral deployment
agreement. The channelPublicKey field carries the public key bound
to that endpoint and is used to authenticate the remote peer or
validate key exchange material for the private channel. The optional
profileSerial field provides a profile epoch that can help peers
identify rollover or rollback. The encoding of the routing-dependent
data exchanged over the private channel is out of scope for this
document.
Ren, et al. Expires 25 December 2026 [Page 6]
Internet-Draft SOA Service Profiles June 2026
5. Field Semantics and Encoding
The publisherAS field identifies the AS whose service profile is
being published. The EE certificate used to sign the SOA MUST
contain an AS resource that covers publisherAS. An SOA whose signing
EE certificate does not cover publisherAS is invalid.
The profileRole field MUST be either subscriber or provider. A
relying party that is looking for a subscriber profile MUST reject a
provider-role SOA for that lookup, and vice versa.
The serviceDescriptor field MUST contain a lowercase ASCII service
descriptor. The descriptor identifies the service family and profile
version understood by the peers. Implementations MUST treat an empty
descriptor, a descriptor longer than 64 octets, or a descriptor
containing non-ASCII characters as invalid.
The syncEndpoint field MUST contain either a 32-bit IPv4 address or a
128-bit IPv6 address, encoded in network byte order. Other lengths
are invalid.
If present, the syncPort field MUST contain a transport-layer port
number in the inclusive range 1 to 65535. If absent, the peer MUST
use the default port for the selected protocol, as defined by a
future specification or by bilateral deployment agreement.
If present, the channelProtocol field MUST contain a lowercase ASCII
protocol identifier. The value "tls" identifies a private channel
directly established using TLS[RFC8446]. Other values MAY be used as
long as they preserve the same logical synchronization interface and
security properties described in [I-D.ren-sidrops-soa-usage] or in a
future specification that updates that usage.
The channelPublicKey field MUST contain one and only one DER-encoded
SubjectPublicKeyInfo value. Implementations MUST treat malformed or
algorithm-unknown values as invalid. When channelProtocol is absent
or set to "tls", this public key is used to authenticate the TLS peer
identity by comparing it to the SubjectPublicKeyInfo of the TLS end-
entity certificate presented by the remote peer.
If present, the profileSerial field identifies the publisher's local
profile epoch. Peers MAY use this value to detect key or endpoint
rollover. A lower serial than the locally accepted profile serial is
rollback evidence unless local policy or RPKI repository state proves
otherwise.
Ren, et al. Expires 25 December 2026 [Page 7]
Internet-Draft SOA Service Profiles June 2026
This document intentionally defines only the minimum bootstrap
information required to authenticate the remote peer and locate the
publisher-operated synchronization endpoint. It does not attempt to
encode routing state, evidence tags, message formats, failure-
handling policy, or detailed transport-specific negotiation
parameters in the SOA itself.
6. SOA Validation
Before a relying party can use SOA bootstrap information, the SOA
MUST first be verified. The relying party MUST perform all RPKI
signed-object validation checks specified in [RFC6488], including
certificate path validation, EE certificate validity, revocation
status, manifest and repository consistency, and content-type
matching.
After normal RPKI signed-object validation succeeds, the relying
party MUST parse the SOA eContent and reject the object if any
required field is absent, malformed, duplicated contrary to the ASN.1
structure, or inconsistent with the expected role. The relying party
MUST also verify that the validated EE certificate covers
publisherAS.
A subscriber can use a provider-role SOA for service discovery and
capability screening. A provider can use a subscriber-role SOA to
authenticate the subscriber's advertised identity and channel
parameters after a bilateral service request. Neither SOA alone
creates an accepted service relation or obligates the provider to
install source-validation rules.
Routing-dependent validation data learned over a private channel MUST
NOT be used unless the remote peer has been authenticated against a
currently valid SOA with the expected publisherAS, profileRole,
serviceDescriptor, and channelPublicKey. If the SOA expires, is
withdrawn, is revoked, or is replaced by an SOA with incompatible
bootstrap information, routing-dependent state learned only under the
old bootstrap information becomes unavailable until the channel is
re-authenticated and a fresh snapshot is received.
7. Prefix Authorization Scope
An SOA service profile does not by itself authorize any protected
source prefix. Prefix authorization is a separate step performed
when a concrete subscriber-provider service relation is accepted or
refreshed.
Ren, et al. Expires 25 December 2026 [Page 8]
Internet-Draft SOA Service Profiles June 2026
When Traffic Origin Authorization (TOA)[I-D.qin-savnet-toa] objects
are available, a valid TOA that covers 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 the
current RPKI ecosystem and does not assert that ROA has complete
packet-source authorization semantics.
If neither a valid TOA nor an accepted ROA-match fallback authorizes
a prefix for the subscriber AS, the prefix is outside the effective
protection scope of the accepted service relation, even if the
subscriber's SOA service profile is otherwise valid.
8. Operation Considerations
SOA objects SHOULD remain stable and only be updated when the
publisher's role, service descriptor, endpoint, synchronization port,
selected protocol, channel public key, or profile serial changes.
Routing changes and updates to legitimate predecessor AS information
SHOULD be sent over the authenticated private channel, rather than
causing frequent SOA reissuance in RPKI.
Peers SHOULD implement periodic polling or change-detection
mechanisms to promptly identify changes to SOA bootstrap information.
After discovering a new or updated SOA for an accepted service
relation, the peer SHOULD re-establish or re-authenticate the private
channel before accepting subsequent routing-dependent updates.
When the publisher changes the synchronization endpoint,
synchronization port, selected protocol, or channel public key, it
SHOULD maintain continuity long enough for accepted peers to retrieve
and validate the new SOA and re-establish the private channel. Once
the new channel is authenticated, peers SHOULD discard any routing-
dependent state learned solely from the old bootstrap information.
9. Out of Scope
This document does not define the private-channel message
serialization, detailed TLS profile selection, evidence-tag policy,
router-facing rule model, or the internal algorithm used by the
subscriber to compute legitimate predecessor ASes. Those operational
semantics belong in usage documents or in future private-channel
specifications.
Ren, et al. Expires 25 December 2026 [Page 9]
Internet-Draft SOA Service Profiles June 2026
This document also does not define commercial policy, billing,
service-level objectives, or how a provider decides whether to accept
a subscriber's service request.
10. IANA Considerations
This document requests IANA to make the following assignments.
10.1. RPKI Signed Objects Registry
IANA is requested to register the following entry in the "RPKI Signed
Objects" registry [RFC6488]:
Name: sourceOriginAuthz
OID: TBD
Reference: This document
10.2. 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" registry:
Decimal | Description | Reference
--------+-----------------+----------------
TBD | id-ct-rpkiSOA | This document
10.3. 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" registry:
Decimal | Description | Reference
--------+-------------------+----------------
TBD | id-mod-rpkiSOA | This document
10.4. RPKI Repository Name Scheme
IANA is requested to register the following entry in the "RPKI
Repository Name Schemes" registry:
Filename Extension | RPKI Object | Reference
-------------------+------------------------------+----------------
.soa | Source Origin Authorization | This document
Ren, et al. Expires 25 December 2026 [Page 10]
Internet-Draft SOA Service Profiles June 2026
11. Security Considerations
Data in SOA is not assumed to be confidential; it is anticipated that
SOAs will be stored in repositories accessible to all ISPs and
potentially all Internet users. For this reason, SOA intentionally
contains only role, capability, endpoint, protocol, key, and profile-
epoch information. It does not carry detailed routing-dependent
validation data, legitimate predecessor AS sets, or subscriber-
specific protection policy. Although SOA is a signed application-
layer object, there is no intent to convey non-repudiation through
it.
The purpose of SOA is to authenticate an AS-level service profile and
publish the bootstrap information needed to establish a private
channel. Therefore, the integrity and resource scope of SOA must be
established before any peer uses it. The SOA specification uses the
RPKI signed-object format; thus, all security considerations
discussed in [RFC6488] also apply to SOAs. Additionally, the signed
object profile uses the CMS signed message format for integrity, so
SOAs inherit all security considerations associated with this data
structure.
An SOA does not prove that the publisher is authorized to originate
traffic using a particular IP prefix. Prefix authorization is
checked separately. Valid TOA objects, when available, provide
explicit traffic-origin authorization. A ROA-match rule can be used
as a deployment-compatible fallback before TOA is widely available,
but ROA authorizes route origination for destination-based routing
and does not fully express packet-source authorization.
Implementations that use the ROA-match fallback SHOULD document the
residual false-positive and false-negative cases caused by this
semantic gap.
Accepted service relations remain conditional on both peers' relevant
SOAs staying valid. If a subscriber-role SOA or provider-role SOA is
revoked, withdrawn, expired, or no longer validates for the expected
AS and role, peers MUST stop accepting new routing-dependent state
under that profile and MUST treat state learned solely under the
invalid profile as unavailable until a new SOA is validated and the
private channel is re-authenticated.
The confidentiality, integrity, replay protection, and liveness of
the routing-dependent data exchanged after bootstrap are provided by
the private channel rather than by the SOA object itself.
Implementations SHOULD ensure that the private channel authenticates
the peer against the current channelPublicKey in the SOA and SHOULD
discard stale routing updates when the corresponding SOA is
withdrawn, replaced, or expires.
Ren, et al. Expires 25 December 2026 [Page 11]
Internet-Draft SOA Service Profiles June 2026
Future specifications MAY define how authorization objects other than
TOA or ROA are incorporated into SOA processing. Such extensions are
out of scope for this document.
12. References
12.1. Normative References
[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>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[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>.
12.2. Informative References
Ren, et al. Expires 25 December 2026 [Page 12]
Internet-Draft SOA Service Profiles June 2026
[I-D.ren-sidrops-soa-usage]
Gang, R., Jia, M., Yin, X., and S. Liu, "Source Address
Validation Using Source Origin Authorizations (SOAs)",
Work in Progress, Internet-Draft, draft-ren-sidrops-soa-
usage-02, 25 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ren-sidrops-
soa-usage-02>.
[I-D.qin-savnet-toa]
Qin, L., Maddison, B., Li, D., and I. Lubashev, "A Profile
for Traffic Origin Authorizations (TOAs)", Work in
Progress, Internet-Draft, draft-qin-savnet-toa-01, 29
January 2026, <https://datatracker.ietf.org/doc/html/
draft-qin-savnet-toa-01>.
Authors' Addresses
Gang Ren
Tsinghua University
Beijing
China
Email: rengang@cernet.edu.cn
Minglin Jia
Tsinghua University
Beijing
China
Phone: +86 18800137573
Email: millionvoid@gmail.com, jml20@mails.tsinghua.edu.cn
Xia Yin
Tsinghua University
Beijing
China
Email: yxia@tsinghua.edu.cn
Shuqi Liu
Tsinghua University
Beijing
China
Email: liu-sq23@mails.tsinghua.edu.cn, liushuq2001@gmail.com
Ren, et al. Expires 25 December 2026 [Page 13]