A Profile for Peering API Discovery via the RPKI
Internet-Draft draft-misell-grow-rpki-peering-api-discovery-00
Q Misell
AS207960 Cyfyngedig
13 Pen-y-lan Terrace
Caerdydd
CF23 9EU
United Kingdom
q@as207960.net
q@magicalcodewit.ch
https://magicalcodewit.ch
rtg
grow
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.
Discussion
Source for this draft and an issue tracker can be found at https://github.molgen.mpg.de/q/rpki-peering-api-discovery.
Introduction
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.
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 [BCP14] when, and only when, they appear in all capitals, as shown here.
The Peering API Discovery (PAD) Profile
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.
PAD Content Type
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 PAD eContent
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:
version
The version number of a PeeringAPIDiscovery that complies with this document MUST be 0.
asn
The asn field contains the ASN field for which the peering API is authoritative.
peeringApiUrl
The peeringApiUrl 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.
PAD Validation
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.
- The Autonomous System Identifier Delegation Extension [RFC3779] MUST be present in the end-entity (EE) certificate (contained within the PAD), and the ASN in the PAD eContent MUST be contained within the set of AS numbers specified by the EE certificate's Autonomous System Identifier Delegation Extension.
- The EE certificate's Autonomous System Identifier Delegation Extension MUST NOT contain any "inherit" elements.
- The IP Address Delegation Extension [RFC3779] MUST be absent.
IANA Considerations
SMI Security for S/MIME Module Identifier registry
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]
New entries
Decimal | Description | Reference
TBD | id-mod-rpki-peering-api-discovery-2024 | This document
SMI Security for S/MIME CMS Content Type registry
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]
New entries
Decimal | Description | Reference
TBD | id-ct-peeringApiDiscovery | This document
RPKI Signed Object registry
IANA is requested to add Peering API Discovery to RPKI Signed Object registry defined in [RFC6488]
New entries
Name | OID | Reference
Peering API Discovery | 1.2.840.113549.1.9.16.1.TDB | This document
RPKI Repository Name Scheme registry
IANA is requested to add Peering API Discovery to RPKI Repository Name Scheme registry defined in [RFC6481]
New entries
Filename Extension | RPKI Object | Reference
.pad | Peering API Discovery | This document
Media Types Registry
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 <q@as207960.net>
   Intended usage: COMMON
   Restrictions on usage: None
   Change controller: IETF

Security Considerations
The security considerations of [RFC6481], [RFC6485], [RFC6488], and [RFC3986] also apply to PAD objects.
References
Normative References
[X.680]

Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITU-T
2021
ITU-T Recommendation X.680
[I-D.ramseyer-grow-peering-api]
[RFC5652]
[RFC6268]
[RFC6488]
[RFC6480]
[RFC3986]
[RFC3779]
[RFC7107]
[RFC7193]
[RFC6481]
[RFC6485]