| Internet-Draft | RPKI Peering API Discovery | July 2024 |
| Misell | Expires 1 February 2025 | [Page] |
The Peering API currently under discussion in the GROW Working Group does not provide a mechanism for discovering the API endpoints that an ASN uses to accept peering requests. This document defines a new RPKI Signed Object to publicise this endpoint and allow discovery.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.molgen.mpg.de/q/rpki-peering-api-discovery.¶
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 1 February 2025.¶
Copyright (c) 2024 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.¶
An API allowing programmatic configuration of BGP peering sessions is defined in [I-D.ramseyer-grow-peering-api]. The API defined in that document does not provide a discovery mechanism for potential peers to know what URL base to use for the ASN's peering API. An ASN could publish on its website information about its Peering API, however this adds an element of human interaction to what could otherwise be an entirely automated process. To this end this document defined a new Cryptographic Message Syntax [RFC5652] [RFC6268] Signed Object [RFC6488] for the RPKI [RFC6480] to advertise an ASN's Peering API URI base.¶
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 [BCP14] when, and only when, they appear in all capitals, as shown here.¶
PAD objects follow the Signed Object Template for the RPKI [RFC6488]¶
If multiple PAD objects exist for one ASN then they MUST assert the same URL base.¶
The eContentType for a PAD is defined as id-ct-peeringApiDiscovery,
with the Object Identifier (OID) 1.2.840.113549.1.9.16.1.TDB.¶
This OID MUST appear within both the eContentType in the
encapContentInfo object and
the ContentType signed attribute in the signerInfo object.¶
The eContent of an ASPA is an instance of PeeringAPIDiscovery, formally defined by the following
ASN.1 [X.680] module:¶
RPKI-PEERING-API-DISCOVERY-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-rpki-peering-api-discovery(TBD) }
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) } ;
id-ct-peeringApiDiscovery OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) peeringApiDiscovery(TBD) }
ct-peeringApiDiscovery CONTENT-TYPE ::=
{ TYPE PeeringAPIDiscovery IDENTIFIED BY
id-ct-peeringApiDiscovery }
PeeringAPIDiscovery ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
asn ASID,
peeringApiUri PrintableString }
ASID ::= INTEGER (0..4294967295)
END
¶
The fields are defined as:¶
versionversion number of a PeeringAPIDiscovery that complies with this document
MUST be 0.¶
asnasn field contains the ASN field for which the peering API is authoritative.¶
peeringApiUrlpeeringApiUrl contains the URI base of the ASN's peering API
(e.g. https://example.net/peering). The URI MUST be a valid absolute
HTTPS URI [RFC3986] and MUST NOT include an authority, query,
fragment, nor a trailing slash.¶
Before a relying party can use an PAD to discover a Peering API, the relying party MUST first validate the PAD object itself. To validate a PAD, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional PAD-specific validation steps.¶
IANA is requested to add id-mod-rpki-peering-api-discovery-2024 to the SMI Security for
S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry defined in
[RFC7107]¶
| Decimal | Description | Reference |
|---|---|---|
| TBD |
id-mod-rpki-peering-api-discovery-2024
|
This document |
IANA is requested to add id-ct-peeringApiDiscovery to the S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) registry defined in [RFC7193]¶
| Decimal | Description | Reference |
|---|---|---|
| TBD |
id-ct-peeringApiDiscovery
|
This document |
IANA is requested to add Peering API Discovery to RPKI Signed Object registry defined in [RFC6488]¶
| Name | OID | Reference |
|---|---|---|
| Peering API Discovery |
1.2.840.113549.1.9.16.1.TDB
|
This document |
IANA is requested to add Peering API Discovery to RPKI Repository Name Scheme registry defined in [RFC6481]¶
| Filename Extension | RPKI Object | Reference |
|---|---|---|
.pad
|
Peering API Discovery | This document |
IANA is requested to register the media type application/rpki-pad in the "Media Type"
registry as follows:¶
Type name: application
Subtype name: rpki-pad
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: Carries an RPKI PAD [RFC-to-be].
This media type contains no active content.
See [RFC-to-be] for further information.
Interoperability considerations: None
Published specification: [RFC-to-be]
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
Peering API URL as defined in [RFC-to-be].
Magic number(s): None
File extension(s): .pad
Macintosh file type code(s):
Person & email address to contact for further information:
Q Misell <[email protected]>
Intended usage: COMMON
Restrictions on usage: None
Change controller: IETF
¶
The security considerations of [RFC6481], [RFC6485], [RFC6488], and [RFC3986] also apply to PAD objects.¶