A Profile for Source Prefix Authorizations (SPAs)
draft-braet-sidrops-spa-profile-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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Kamiel Braet | ||
| Last updated | 2026-06-18 | ||
| 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-braet-sidrops-spa-profile-00
sidrops K. Braet
Internet-Draft Liberty Global Ltd.
Intended status: Standards Track 16 June 2026
Expires: 18 December 2026
A Profile for Source Prefix Authorizations (SPAs)
draft-braet-sidrops-spa-profile-00
Abstract
This document defines a standard profile for Source Prefix
Authorizations (SPAs), a Cryptographic Message Syntax (CMS) protected
content type for use with the Resource Public Key Infrastructure
(RPKI). A SPA is a digitally signed object that allows the holder of
an IP address prefix assigned by a Regional Internet Registry (RIR)
to publish a list of source IP address prefixes authorized to send IP
packets to that destination prefix or its subprefixes.
To enforce these policies, a BGP speaker may include a
SOURCE_SELECTIVE Path Attribute referencing the SPAs. This
distributes policy references, enabling routing systems to
incorporate source-based constraints into local forwarding policies
and trigger control plane enforcement
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 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Braet Expires 18 December 2026 [Page 1]
Internet-Draft RPKI-SPA June 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The SPA Content Type . . . . . . . . . . . . . . . . . . . . 4
3. The SPA eContent . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The SourcePrefixAttestation address family . . . . . . . 7
3.2. The version Element . . . . . . . . . . . . . . . . . . . 7
3.3. The protectedIpAddrBlock Element . . . . . . . . . . . . 7
3.3.1. ProtectedSPAIPAddressFamily . . . . . . . . . . . . . 7
3.4. The srcIpAddrBlocks Element . . . . . . . . . . . . . . . 7
3.4.1. SPAIPAddressFamily . . . . . . . . . . . . . . . . . 7
3.4.2. SPAIPAddress . . . . . . . . . . . . . . . . . . . . 7
3.5. The policyType Element . . . . . . . . . . . . . . . . . 8
3.6. SPA Filename convention . . . . . . . . . . . . . . . . . 8
3.6.1. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 8
3.6.2. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 8
4. SPA Publication and Validation . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 10
6.2. RPKI Signed Objects Registry . . . . . . . . . . . . . . 10
6.3. File Extension . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . 11
6.3.2. Media Type Registry . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Braet Expires 18 December 2026 [Page 2]
Internet-Draft RPKI-SPA June 2026
1. Introduction
The Resource Public Key Infrastructure (RPKI) enables
cryptographically verifiable assertions about routing authorization
using a distributed trust model rooted in the Internet number
resource allocation hierarchy, as described in [RFC6480].
Operational experience with RPKI-based origin validation, as
specified in [RFC6811], has demonstrated that cryptographically
verifiable routing intent can be incrementally deployed without
disrupting BGP routing semantics.
While RPKI enables assertions about routing authorization, it does
not currently allow prefix holders assigned by a Regional Internet
Registry (RIR) to publish a signed list for authorized source
prefixes.
This document defines a standard profile for Source Prefix
Authorization (SPA), which enables a prefix holder to publish a
cryptographically signed list of authorized source prefixes via RPKI.
The Source Prefix Authorization (SPA) 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 SPA (see Section 4 of [RFC6488]), this section
defines:
* The OID that identifies the signed object as being a SPA. (This
OID appears within the eContentType in the encapContentInfo object
as well as the content-type signed attribute in the signerInfo
object.)
* The SPA eContent is ASN.1 syntax, encoded using the Distinguished
Encoding Rules (DER) [X.690].
* Additional steps required to validate SPAs (in addition to the
validation steps specified in [RFC6488]).
This document is part of the Source-Selective BGP mechanism
[I-D.braet-idr-source-selective-bgp-framework], which consists of
RPKI Source Authorization objects and a BGP Path Attribute used to
reference them.
Braet Expires 18 December 2026 [Page 3]
Internet-Draft RPKI-SPA June 2026
1.1. Terminology
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
[RFC2119].
* Source Prefix Authorization (SPA) CMS: A set of Source IP address
prefixes authorized to send packets to a destination prefix
published in RPKI as specified in this document.
* Source Authorization (SA) CMS: An RPKI Source Authorization object
type category. This category includes the Source Prefix
Authorization (SPA) object defined in this document.
* SOURCE_SELECTIVE: The BGP Path Attribute that references one or
more RPKI Source Authorization (SA) objects, including the SPA
object type, as specified in
[I-D.braet-idr-bgp-source-selective-attr]
* Relying Party (RP): An entity that validates RPKI objects.
* Source Address Validation (SAV): Techniques that prevent packets
with spoofed source addresses from entering or traversing a
network.
* Cryptographic Message Syntax (CMS): The format defined in
[RFC5652] used to encapsulate ASN.1 DER-encoded RPKI payloads
along with their digital signatures and the certificates required
for validation.
* Abstract Syntax Notation One (ASN.1): A standard notation for
defining platform-independent data structures, as specified in the
ITU-T [X.680] series.
* Distinguished Encoding Rules (DER): A set of encoding rules
defined in ITU-T [X.690] that produces a unique, deterministic
binary representation of ASN.1 structures, essential for
cryptographic consistency.
2. The SPA Content Type
The content-type for a SPA is defined as id-ct-SPA and has the
numerical value of 1.2.840.113549.1.9.16.1.TBD1.
This OID MUST appear within both the eContentType in the
encapContentInfo object and the content-type signed attribute in the
signerInfo object (see [RFC6488]).
Braet Expires 18 December 2026 [Page 4]
Internet-Draft RPKI-SPA June 2026
3. The SPA eContent
The content of a SPA binds a destination IP prefix or a designated
subprefix of that prefix to a set of authorized source IP prefixes
with a policy type. Only the legitimate holder of the destination
prefix may publish the object. A single SPA object instance MUST
only contain prefixes from a single address family. A SPA is
formally defined as:
RPKI-SPA-2026
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) id-mod-spa-2026(TBD2) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
ct-sourcePrefixAttestation CONTENT-TYPE ::=
{ TYPE SourcePrefixAttestation
IDENTIFIED BY id-ct-SPA }
id-ct-SPA OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) spa(TBD1) }
SourcePrefixAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
protectedIpAddrBlock ProtectedSPAIPAddressFamily,
srcIpAddrBlocks SEQUENCE (SIZE(0..100)) OF SPAIPAddressFamily,
policyType PolicyType
}
ProtectedSPAIPAddressFamily ::= SEQUENCE {
addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),
address ADDRESS-FAMILY.&Address
({AddressFamilySet}{@addressFamily})}
SPAIPAddressFamily ::= SEQUENCE {
addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),
addresses ADDRESS-FAMILY.&Addresses
({AddressFamilySet}{@addressFamily}),
savSource ADDRESS-FAMILY.&savSource
({AddressFamilySet}{@addressFamily})
Braet Expires 18 December 2026 [Page 5]
Internet-Draft RPKI-SPA June 2026
}
ADDRESS-FAMILY ::= CLASS {
&afi OCTET STRING (SIZE(2)) UNIQUE,
&Address,
&Addresses,
&savSource
} WITH SYNTAX {
AFI &afi
ADDRESS &Address
ADDRESSES &Addresses
SAV-SOURCE-TYPE &savSource
}
AddressFamilySet ADDRESS-FAMILY ::=
{ addressFamilyIPv4 | addressFamilyIPv6 }
addressFamilyIPv4 ADDRESS-FAMILY ::= {
AFI afi-IPv4
ADDRESS SPAAddressIPv4
ADDRESSES SEQUENCE (SIZE(0..MAX)) OF SPAAddressIPv4
SAV-SOURCE-TYPE ENUMERATED { no(0), yes(1) }
}
addressFamilyIPv6 ADDRESS-FAMILY ::= {
AFI afi-IPv6
ADDRESS SPAAddressIPv6
ADDRESSES SEQUENCE (SIZE(0..MAX)) OF SPAAddressIPv6
SAV-SOURCE-TYPE ENUMERATED { no(0), yes(1) }
}
SPAIPAddress {INTEGER:ub} ::= BIT STRING (SIZE(0..ub))
SPAAddressIPv4 ::= SPAIPAddress{ub-IPv4}
SPAAddressIPv6 ::= SPAIPAddress{ub-IPv6}
PolicyType ::= ENUMERATED {
allow (0),
deny (1),
future (2)
}
afi-IPv4 OCTET STRING ::= '0001'H
afi-IPv6 OCTET STRING ::= '0002'H
ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 64
Braet Expires 18 December 2026 [Page 6]
Internet-Draft RPKI-SPA June 2026
END
3.1. The SourcePrefixAttestation address family
The IP address family MUST be of the same type for all IP address
prefixes in a single RPKI Signed Object.
3.2. The version Element
The version number of the SourcePrefixAttestation entry MUST be 0.
3.3. The protectedIpAddrBlock Element
The protectedIpAddrBlock element contains the Holder's IP address
prefix or a designated subprefix of that prefix.
3.3.1. ProtectedSPAIPAddressFamily
Within the ProtectedSPAIPAddressFamily structure, the addressFamily
element contains the Address Family Identifier (AFI) of an IP address
family. Each addressFamily MUST be either '0001'H or '0002'H.
The address element contains a single IP prefix of type SPAIPAddress.
3.4. The srcIpAddrBlocks Element
The srcIpAddrBlocks element encodes the set of IP address prefixes
that are authorized to send IP packets to the IP Prefix encoded in
protectedIpAddrBlock element.
3.4.1. SPAIPAddressFamily
Within the SPAIPAddressFamily structure, the addressFamily element
contains the Address Family Identifier (AFI) of an IP address family.
Each addressFamily MUST be either '0001'H or '0002'H.
The addresses element contains IP prefixes as a sequence of type
SPAIPAddress.
The savSource element is an ENUMERATED type that indicates if Source
Address Validation (SAV) controls should be applied to traffic
originating from the specified source IP prefixes. It MUST be set to
either no(0) or yes(1).
3.4.2. SPAIPAddress
This element is of type BIT STRING and represents a single IP address
prefix [RFC3779].
Braet Expires 18 December 2026 [Page 7]
Internet-Draft RPKI-SPA June 2026
For IPv4, the maximum prefix length (ub-IPv4) MUST be 32 bits. For
IPv6, the maximum prefix length (ub-IPv6) MUST be limited to 64 bits
to mitigate hardware resource exhaustion.
3.5. The policyType Element
The policyType element is an ENUMERATED type specifying the
operational rule governing the associated source prefixes. It MUST
be set to allow(0) for allowlist-based policies, deny(1) for
denylist-based policies, or future(2) for prospective policy
expansions.
3.6. SPA Filename convention
3.6.1. IPv4 Prefixes
For SPAs associated with IPv4 prefixes, the filename MUST be derived
from the authorized destination IPv4 prefix and MUST consist of a
prefix-specific label followed by a hyphen ("-"), the decimal
representation of the prefix length in bits, and the ".spa" file
extension.
The prefix-specific label MUST be encoded using dotted-decimal
notation and MUST include only those octets that are fully or
partially covered by the prefix. Any octets entirely untouched by
the prefix length MUST be omitted. Any bits beyond the prefix length
within a partially covered octet MUST NOT be represented. For octets
that are only partially covered by the prefix, all bits not covered
by the prefix MUST be set to zero. The prefix length component MUST
correspond exactly to the length in bits of the authorized prefix.
For example, an authorization for the prefix 192.0.2.0/24 would be
encoded as 192.0.2-24.spa, and an authorization for the prefix
203.0.113.0/25 would be encoded as 203.0.113.0-25.spa.
3.6.2. IPv6 Prefixes
For SPAs associated with IPv6 prefixes, the filename MUST be derived
from the authorized destination IPv6 prefix and MUST consist of a
prefix-specific label followed by a hyphen ("-"), the decimal
representation of the prefix length in bits, and the ".spa" file
extension.
The prefix-specific label MUST be encoded using the canonical
hexadecimal representation defined in [RFC5952] and MUST include only
those 16-bit segments that are fully or partially covered by the
prefix. Any octets entirely untouched by the prefix length MUST be
omitted. Any bits beyond the prefix length within a partially
Braet Expires 18 December 2026 [Page 8]
Internet-Draft RPKI-SPA June 2026
covered octet MUST NOT be represented. For segments that are only
partially covered by the prefix, all bits not covered by the prefix
MUST be set to zero. Hexadecimal digits MUST be represented in
lowercase. The colon (":") separator defined in RFC5952 MUST be
replaced by a period (".") in the filename to ensure compatibility
with common operating system file systems. Zero compression ("::")
MUST NOT be used. The prefix length component MUST correspond
exactly to the length in bits of the authorized prefix.
For example, an authorization for the IPv6 prefix 2001:0db8:abcd::/48
would be encoded as 2001.db8.abcd-48.spa, and an authorization for
the IPv6 prefix 2001:0db8:abcd:ef00::/56 would be encoded as
2001.db8.abcd.ef00-56.spa.
4. SPA Publication and Validation
* SPA objects MUST be published in the RPKI repository of the
destination prefix holder.
* Entities holding Provider Aggregatable (PA) space assigned by a
Local Internet Registry (LIR) do not hold the necessary Resource
Certificates to sign these objects directly; consequently, they
must request their LIR to create and sign SPA objects on their
behalf.
Before a Relying Party can use a SPA, the Relying Party MUST first
validate the SPA. To validate a SPA, the Relying Party MUST perform
all the validation checks specified in [RFC6488] as well as the
following additional SPA-specific validation steps:
* The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the SPA), and the
protectedIpAddrBlock IP address prefix in the SPA 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 SPA content fully conforms with all requirements specified in
Sections 2 and 3.
If any of the above checks fail, the SPA in its entirety MUST be
considered invalid and an error SHOULD be logged.
Braet Expires 18 December 2026 [Page 9]
Internet-Draft RPKI-SPA June 2026
5. Security Considerations
The security considerations of [RFC6481], [RFC7935], [RFC6488], and
[RFC9582] also apply to the Source Prefix Authorization (SPA) RPKI
object.
Failure to validate Source Prefix Authorization (SPA) objects
correctly, or to apply consistent policy across enforcement points,
may result in unintended traffic drops or acceptance of unauthorized
traffic.
6. IANA Considerations
Note: Allocation of the SOURCE_SELECTIVE BGP Path Attribute
referenced in this document is handled exclusively within
[I-D.braet-idr-bgp-source-selective-attr].
6.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 |
+=========+=============+=================================+
| TBD1 | id-ct-SPA | draft-braet-sidrops-spa-profile |
+---------+-------------+---------------------------------+
Table 1
6.2. RPKI Signed Objects Registry
IANA is requested add an item for the SPA file extension to the RPKI
Signed Object registry (https://www.iana.org/assignments/rpki/
rpki.xhtml#signed-objects) as follows:
+===============+==============================+==============+
| Name | OID | Reference |
+===============+==============================+==============+
| Source Prefix | 1.2.840.113549.1.9.16.1.TBD1 | draft-braet- |
| Authorization | | sidrops-spa- |
| | | profile |
+---------------+------------------------------+--------------+
Table 2
Braet Expires 18 December 2026 [Page 10]
Internet-Draft RPKI-SPA June 2026
6.3. File Extension
IANA is requested add an item for the SPA file extension to the "RPKI
Repository Name Scheme" registry created by [RFC6481] as follows:
+===========+===============+=================================+
| Filename | RPKI Object | Reference |
| extension | | |
+===========+===============+=================================+
| .spa | Source Prefix | draft-braet-sidrops-spa-profile |
| | Authorization | |
+-----------+---------------+---------------------------------+
Table 3
6.3.1. 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 |
+=========+=================+=================================+
| TBD2 | id-mod-spa-2026 | draft-braet-sidrops-spa-profile |
+---------+-----------------+---------------------------------+
Table 4
6.3.2. Media Type Registry
The IANA is requested to register the media type application/rpki-spa
in the "Media Type" registry as follows:
Type name: application
Subtype name: rpki-spa
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: Carries an RPKI SPA. This media type
contains no active content. See Section 5 of draft-braet-sidrops-
spa-profile for further information.
Braet Expires 18 December 2026 [Page 11]
Internet-Draft RPKI-SPA June 2026
Interoperability considerations: None
Published specification: draft-braet-sidrops-spa-profile
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 Source Prefixes
and an associated IP Prefix assigned to the publisher of the
object as defined in draft-braet-sidrops-spa-profile.
Magic number(s): None
File extension(s): .spa
Macintosh file type code(s): None
Person & email address to contact for further information:
Kamiel Braet kabraet@libertyglobal.com
(mailto:kabraet@libertyglobal.com)
Intended usage: COMMON
Restrictions on usage: None
Change controller: IETF
7. Acknowledgments
The author would like to thank the individual reviewers from the IETF
community for their valuable feedback and contributions during the
development of this document.
The design of Source Prefix Authorization (SPA) builds on decades of
work in BGP, RPKI, and secure routing. The author gratefully
acknowledges the contributions of the IETF IDR, SIDROPS, and GROW
working groups.
8. References
8.1. Normative References
[I-D.braet-idr-bgp-source-selective-attr]
Braet, K., "BGP Source-Selective Attribute", Work in
Progress, Internet-Draft, draft-braet-idr-bgp-source-
selective-attr, 2026,
<https://datatracker.ietf.org/doc/html/draft-braet-idr-
bgp-source-selective-attr>.
Braet Expires 18 December 2026 [Page 12]
Internet-Draft RPKI-SPA June 2026
[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/rfc/rfc2119>.
[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/rfc/rfc3779>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[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/rfc/rfc6481>.
[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/rfc/rfc6488>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/rfc/rfc7935>.
[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/rfc/rfc9582>.
[X.680] "Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation", ITU-T , 2021.
[X.690] "Information Technology - ASN.1 encoding rules:
pecification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T , 2021.
8.2. Informative References
Braet Expires 18 December 2026 [Page 13]
Internet-Draft RPKI-SPA June 2026
[I-D.braet-idr-source-selective-bgp-framework]
Braet, K., "Source-Selective BGP Framework", Work in
Progress, Internet-Draft, draft-braet-idr-source-
selective-bgp-framework, 2026,
<https://datatracker.ietf.org/doc/html/draft-braet-idr-
source-selective-bgp-framework>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/rfc/rfc6811>.
Author's Address
Kamiel Braet
Liberty Global Ltd.
Netherlands
Email: kabraet@libertyglobal.com
Braet Expires 18 December 2026 [Page 14]