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, . [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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 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, . [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, . 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]