Skip to content
Permalink
root
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

rpki-peering-api-discovery/draft-misell-grow-rpki-peering-api-discovery.xml

Go to file
 
 
Cannot retrieve contributors at this time
345 lines (320 sloc) 15 KB
Raw Blame
Open in GitHub Desktop
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902" submissionType="IETF" category="std" version="3" consensus="true"
docName="draft-misell-grow-rpki-peering-api-discovery-latest">
<front>
<title abbrev="RPKI Peering API Discovery">A Profile for Peering API Discovery via the RPKI</title>
<seriesInfo name="Internet-Draft" status="standard"
value="draft-misell-grow-rpki-peering-api-discovery-latest"/>
<author fullname="Q Misell" initials="Q" surname="Misell">
<organization abbrev="AS207960">AS207960 Cyfyngedig</organization>
<address>
<postal>
<street>13 Pen-y-lan Terrace</street>
<city>Caerdydd</city>
<code>CF23 9EU</code>
<country>United Kingdom</country>
</postal>
<email>q@as207960.net</email>
<email>q@magicalcodewit.ch</email>
<uri>https://magicalcodewit.ch</uri>
</address>
</author>
<area>rtg</area>
<workgroup>grow</workgroup>
<abstract>
<t>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.
</t>
</abstract>
<note removeInRFC="true">
<name>Discussion</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.molgen.mpg.de/q/rpki-peering-api-discovery"/>.
</t>
</note>
</front>
<middle>
<section>
<name>Introduction</name>
<t>An API allowing programmatic configuration of BGP peering sessions is defined in
<xref target="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
<xref target="RFC5652"/>
<xref target="RFC6268"/>
Signed Object
<xref target="RFC6488"/>
for the RPKI
<xref target="RFC6480"/>
to advertise an ASN's Peering API URI base.
</t>
<section>
<name>Requirements Language</name>
<t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>,
<bcp14>SHALL</bcp14>, <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bcp14>,
<bcp14>RECOMMENDED</bcp14>, <bcp14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and
<bcp14>OPTIONAL</bcp14>
in this document are to be interpreted as described in
<xref target="BCP14"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section>
<name>The Peering API Discovery (PAD) Profile</name>
<t>PAD objects follow the Signed Object Template for the RPKI
<xref target="RFC6488"/>
</t>
<t>If multiple PAD objects exist for one ASN then they <bcp14>MUST</bcp14> assert the same
URL base.
</t>
<section>
<name>PAD Content Type</name>
<t>The eContentType for a PAD is defined as id-ct-peeringApiDiscovery,
with the Object Identifier (OID) <tt>1.2.840.113549.1.9.16.1.TDB</tt>.
</t>
<t>This OID <bcp14>MUST</bcp14> appear within both the <tt>eContentType</tt> in the
<tt>encapContentInfo</tt> object and
the ContentType signed attribute in the signerInfo object.
</t>
</section>
</section>
<section>
<name>The PAD eContent</name>
<t>The eContent of an ASPA is an instance of <tt>PeeringAPIDiscovery</tt>, formally defined by the following
ASN.1 <xref target="X.680"/> module:
</t>
<sourcecode type="asn.1">
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
</sourcecode>
<t>The fields are defined as:</t>
<dl>
<dt><tt>version</tt></dt>
<dd>The <tt>version</tt> number of a PeeringAPIDiscovery that complies with this document
<bcp14>MUST</bcp14> be 0.</dd>
<dt><tt>asn</tt></dt>
<dd>The <tt>asn</tt> field contains the ASN field for which the peering API is authoritative.</dd>
<dt><tt>peeringApiUri</tt></dt>
<dd>The <tt>peeringApiUri</tt> contains the URI base of the ASN's peering API
(e.g. <tt>https://example.net/peering</tt>). The URI <bcp14>MUST</bcp14> be a valid absolute
HTTPS URI <xref target="RFC3986"/> and <bcp14>MUST NOT</bcp14> include an authority, query,
fragment, nor a trailing slash.</dd>
</dl>
</section>
<section>
<name>PAD Validation</name>
<t>
Before a relying party can use an PAD to discover a Peering API, the relying party <bcp14>MUST</bcp14>
first validate the PAD object itself.
To validate a PAD, the relying party <bcp14>MUST</bcp14> perform all the validation checks specified in
<xref target="RFC6488"/> as well as the following additional PAD-specific validation steps.</t>
<ul>
<li>The Autonomous System Identifier Delegation Extension <xref target="RFC3779"/> <bcp14>MUST</bcp14>
be present in the end-entity (EE) certificate (contained within the PAD), and the ASN in the PAD
eContent <bcp14>MUST</bcp14> be contained within the set of AS numbers specified by the EE
certificate's Autonomous System Identifier Delegation Extension.</li>
<li>The EE certificate's Autonomous System Identifier Delegation Extension <bcp14>MUST NOT</bcp14>
contain any "inherit" elements.</li>
<li>The IP Address Delegation Extension <xref target="RFC3779"/> MUST be absent.</li>
</ul>
</section>
<section>
<name>IANA Considerations</name>
<section>
<name>SMI Security for S/MIME Module Identifier registry</name>
<t>IANA is requested to add <tt>id-mod-rpkiPeeringApiDiscovery-2024</tt> to the SMI Security for
S/MIME Module Identifier (<tt>1.2.840.113549.1.9.16.0</tt>) registry defined in
<xref target="RFC7107"/></t>
<table>
<name>New entries</name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>TBD</td>
<td><tt>id-mod-rpkiPeeringApiDiscovery-2024</tt></td>
<td>This document</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>SMI Security for S/MIME CMS Content Type registry</name>
<t>IANA is requested to add <tt>id-ct-peeringApiDiscovery</tt> to the S/MIME CMS Content Type
(<tt>1.2.840.113549.1.9.16.1</tt>) registry defined in <xref target="RFC7193"/></t>
<table>
<name>New entries</name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>TBD</td>
<td><tt>id-ct-peeringApiDiscovery</tt></td>
<td>This document</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>RPKI Signed Object registry</name>
<t>IANA is requested to add Peering API Discovery to RPKI Signed Object registry defined in
<xref target="RFC6488"/></t>
<table>
<name>New entries</name>
<thead>
<tr>
<th>Name</th>
<th>OID</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>Peering API Discovery</td>
<td><tt>1.2.840.113549.1.9.16.1.TDB</tt></td>
<td>This document</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>RPKI Repository Name Scheme registry</name>
<t>IANA is requested to add Peering API Discovery to RPKI Repository Name Scheme registry defined in
<xref target="RFC6481"/></t>
<table>
<name>New entries</name>
<thead>
<tr>
<th>Filename Extension</th>
<th>RPKI Object</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td><tt>.pad</tt></td>
<td>Peering API Discovery</td>
<td>This document</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>Media Types Registry</name>
<t>IANA is requested to register the media type <tt>application/rpki-pad</tt> in the "Media Type"
registry as follows:</t>
<artwork>
<![CDATA[
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
]]>
</artwork>
</section>
</section>
<section>
<name>Security Considerations</name>
<t>The security considerations of <xref target="RFC6481"/>, <xref target="RFC6485"/>,
<xref target="RFC6488"/>, and <xref target="RFC3986"/> also apply to PAD objects.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
</referencegroup>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ramseyer-grow-peering-api-05.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3779.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5652.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6268.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6480.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6481.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6485.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6488.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7107.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7193.xml"/>
<reference anchor="X.680">
<front>
<title>
Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic
notation
</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2021"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation X.680"/>
</reference>
</references>
</references>
</back>
</rfc>