Internet-Draft RPKI Peering API Discovery July 2024
Misell Expires 1 February 2025 [Page]
Workgroup:
grow
Internet-Draft:
draft-misell-grow-rpki-peering-api-discovery-00
Published:
Intended Status:
Standards Track
Expires:
Author:
Q. Misell
AS207960

A Profile for Peering API Discovery via the RPKI

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 1 February 2025.

Table of Contents

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:

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.

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.

5. IANA Considerations

5.1. 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]

Table 1: New entries
Decimal Description Reference
TBD id-mod-rpki-peering-api-discovery-2024 This document

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]

Table 2: New entries
Decimal Description Reference
TBD id-ct-peeringApiDiscovery This document

5.3. RPKI Signed Object registry

IANA is requested to add Peering API Discovery to RPKI Signed Object registry defined in [RFC6488]

Table 3: New entries
Name OID Reference
Peering API Discovery 1.2.840.113549.1.9.16.1.TDB This document

5.4. RPKI Repository Name Scheme registry

IANA is requested to add Peering API Discovery to RPKI Repository Name Scheme registry defined in [RFC6481]

Table 4: New entries
Filename Extension RPKI Object Reference
.pad Peering API Discovery This document

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 <q@as207960.net>
   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, <https://www.rfc-editor.org/info/bcp14>.
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, , <https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ramseyer-grow-peering-api-05>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC3779]
Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, , <https://www.rfc-editor.org/info/rfc3779>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/info/rfc5652>.
[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, , <https://www.rfc-editor.org/info/rfc6268>.
[RFC6480]
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <https://www.rfc-editor.org/info/rfc6480>.
[RFC6481]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, , <https://www.rfc-editor.org/info/rfc6481>.
[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, , <https://www.rfc-editor.org/info/rfc6485>.
[RFC6488]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, , <https://www.rfc-editor.org/info/rfc6488>.
[RFC7107]
Housley, R., "Object Identifier Registry for the S/MIME Mail Security Working Group", RFC 7107, DOI 10.17487/RFC7107, , <https://www.rfc-editor.org/info/rfc7107>.
[RFC7193]
Turner, S., Housley, R., and J. Schaad, "The application/cms Media Type", RFC 7193, DOI 10.17487/RFC7193, , <https://www.rfc-editor.org/info/rfc7193>.
[X.680]
ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, .

Author's Address

Q Misell
AS207960 Cyfyngedig
13 Pen-y-lan Terrace
Caerdydd
CF23 9EU
United Kingdom