grow Q. Misell Internet-Draft AS207960 Intended status: Standards Track 1 August 2024 Expires: 2 February 2025 A Profile for Peering API Discovery via the RPKI draft-misell-grow-rpki-peering-api-discovery-latest Abstract 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 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. 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 2 February 2025. Copyright Notice 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. Table of Contents 1. Introduction 1.1. Requirements Language 2. The Peering API Discovery (PAD) Profile 2.1. PAD Content Type 3. The PAD eContent 4. PAD Validation 5. IANA Considerations 5.1. SMI Security for S/MIME Module Identifier registry 5.2. SMI Security for S/MIME CMS Content Type registry 5.3. RPKI Signed Object registry 5.4. RPKI Repository Name Scheme registry 5.5. Media Types Registry 6. Security Considerations 7. References 7.1. Normative References Author's Address 1. 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. 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 [BCP14] when, and only when, they appear in all capitals, as shown here. 2. 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. 2.1. 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. 3. The PAD eContent The eContent of an ASPA is an instance of PeeringAPIDiscovery, formally defined by the following ASN.1 [X.680] module: RpkiPeeringApiDiscovery-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpkiPeeringApiDiscovery-2024(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) } ; ct-peeringApiDiscovery CONTENT-TYPE ::= { TYPE PeeringAPIDiscovery IDENTIFIED BY id-ct-peeringApiDiscovery } 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) } PeeringAPIDiscovery ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asn ASID, peeringApiUri IA5String } ASID ::= INTEGER (1..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. peeringApiUri The peeringApiUri 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. 4. 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. 5. IANA Considerations 5.1. SMI Security for S/MIME Module Identifier registry IANA is requested to add id-mod-rpkiPeeringApiDiscovery-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-rpkiPeeringApiDiscovery-2024 | This document | +---------+-------------------------------------+---------------+ Table 1: New entries 5.2. 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] +=========+===========================+===============+ | Decimal | Description | Reference | +=========+===========================+===============+ | TBD | id-ct-peeringApiDiscovery | This document | +---------+---------------------------+---------------+ Table 2: New entries 5.3. RPKI Signed Object registry 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 | +-----------------------+-----------------------------+-----------+ Table 3: New entries 5.4. RPKI Repository Name Scheme registry 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 | +--------------------+-----------------------+---------------+ Table 4: New entries 5.5. 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 Intended usage: COMMON Restrictions on usage: None Change controller: IETF 6. Security Considerations The security considerations of [RFC6481], [RFC6485], [RFC6488], and [RFC3986] also apply to PAD objects. 7. References 7.1. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ramseyer-grow-peering-api] Aguado, C., Griswold, M., Ramseyer, J., Servin, A. L., and T. Strickx, "Peering API", Work in Progress, Internet- Draft, draft-ramseyer-grow-peering-api-05, 30 May 2024, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [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, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, DOI 10.17487/RFC6485, February 2012, . [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, . [RFC7107] Housley, R., "Object Identifier Registry for the S/MIME Mail Security Working Group", RFC 7107, DOI 10.17487/RFC7107, January 2014, . [RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/ cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 2014, . [X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2021. Author's Address Q Misell AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom Email: q@as207960.net, q@magicalcodewit.ch URI: https://magicalcodewit.ch