<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3779 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3779.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5652 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">
<!ENTITY RFC6485 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6485.xml">
<!ENTITY RFC6488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6488.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-azimov-sidrops-aspa-profile-00" ipr="trust200902">
    <front>

        <title abbrev="ASPA Profile"> A Profile for Autonomous System Provider Authorization </title>

        <author fullname="Alexander Azimov" initials="A"
            surname="Azimov">
            <organization>Qrator Labs</organization>
            <address>
                <email>aa@qrator.net</email>
            </address>
        </author>

        <author fullname="Eugene Uskov" initials="E"
            surname="Uskov">
            <organization>Qrator Labs</organization>
            <address>
                <email>eu@qrator.net</email>
            </address>
        </author>

        <author fullname="Randy Bush" initials="R"
            surname="Bush">
            <organization>Internet Initiative Japan</organization>
            <address>
                <email>randy@psg.com</email>
            </address>
        </author>

        <author fullname="Keyur Patel" initials="K"
            surname="Patel">
            <organization abbrev="Arrcus">Arrcus, Inc.</organization>
            <address>
                <email>keyur@arrcus.com</email>
            </address>
        </author>

        <author fullname="Job Snijders" initials="J." surname="Snijders">
            <organization abbrev="NTT">NTT Communications</organization>
            <address>
                <postal>
                    <street>Theodorus Majofskistraat 100</street>
                    <code>1065 SZ</code>
                    <city>Amsterdam</city>
                    <country>The Netherlands</country>
                </postal>
                <email>job@ntt.net</email>
            </address>
        </author>

        <author fullname="Russ Housley" initials="R" surname="Housley">
            <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
            <address>
                <postal>
                    <street>918 Spring Knoll Drive</street>
                    <city>Herndon</city>
                    <region>VA</region>
                    <code>20170</code>
                    <country>USA</country>
               </postal>
               <email>housley@vigilsec.com</email>
          </address>
        </author>
    
        <date />

        <keyword>BGP</keyword>
        <keyword>Route leak</keyword>
        <keyword>Hijacks</keyword>

        <abstract>
            <t>
                This document defines a standard profile for Autonomous
                System Provider Authorization in the Resource Public Key
                Infrastructure.  An Autonomous System Provider
                Authorization is a digitally signed object that provides
                a means of verifying that a Customer Autonomous System
                holder has authorized a Provider Autonomous System to be
                its upstream provider and for the Provider to send
                prefixes received from the Customer Autonomous System in
                all directions including providers and peers.
            </t>
        </abstract>

        <note title="Requirements Language">
            <t>
                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
                BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
                only when, they appear in all capitals, as shown here.
            </t>
        </note>
    </front>

    <middle>
        <section title="Introduction" anchor="intro">
            <t>
                The primary purpose of the Resource Public Key
                Infrastructure (RPKI) is to improve routing security.
                (See <xref target="RFC6480" /> for more information.) As
                part of this infrastructure, a mechanism is needed to verify
                that a Provider AS (PAS) has permission from a Customer AS (CAS)
                holder to send routes in all directions.  The digitally signed
                Autonomous System Provider Authorization (ASPA) object provides
                this verification mechanism.
            </t>

            <t>
                The ASPA uses the template for RPKI digitally signed
                objects <xref target="RFC6488" />, which defines a
                Cryptographic Message Syntax (CMS) <xref
                target="RFC5652" /> wrapper for the ASPA content as well
                as a generic validation procedure for RPKI signed
                objects.  As ASPAs need to be validated with RPKI
                certificates issued by the current infrastructure, we
                assume the mandatory-to-implement algorithms in <xref
                target="RFC6485" />, or its successor.</t>

		<t>To complete the specification of the ASPA (see
		Section 4 of <xref target="RFC6488"/>), this document
		defines:
                <list style="numbers">
                    <t>
                        The object identifier (OID) that identifies the ASPA signed object.
                        This OID appears in the eContentType field of the encapContentInfo object as well as the content-type signed attribute within the signerInfo structure).
                    </t>
                    <t>
                        The ASN.1 syntax for the ASPA content, which is the payload signed by the CAS.
                        The ASPA content is encoded using the ASN.1 <xref target="X680"/> Distinguished Encoding Rules (DER) <xref target="X690"/>.
                    </t>
                    <t>
                        The steps required to validate an ASPA beyond the validation steps specified in <xref target="RFC6488" />).
                    </t>
                </list>
            </t>
        </section>

        <section title="The ASPA Content Type" anchor="content-type">
            <t>
                The content-type for an ASPA is defined as id-cct-ASPA, which has the numerical value of 1.2.840.113549.1.9.16.1.TBD.

                This OID MUST appear both within the eContentType in the encapContentInfo structure as well as the content-type signed attribute within the signerInfo structure (see <xref target="RFC6488" />).
            </t>
        </section>

        <section title="The ASPA eContent" anchor="content">
            <t>
                The content of an ASPA identifies the Customer AS (CAS)
                as well as the Provider AS (PAS) that is authorized to
                further propagate announcements received from the
                customer.  If customer has multiple providers, it issues
                multiple ASPAs, one for each provider AS.  An ASPA is
                formally defined as:
            </t>

            <figure>
                <artwork type="asn1">
    ct-ASPA CONTENT-TYPE ::=
        { ASProviderAttestation IDENTIFIED BY id-ct-ASPA }

    id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD }

    ASProviderAttestation ::= SEQUENCE {
        version [0] ASPAVersion DEFAULT v0,
        AFI  AddressFamilyIdentifier,
        customerASID  ASID,
        providerASID  ASID }

    ASPAVersion ::= INTEGER  { v0(0) }

    AddressFamilyIdentifier ::= INTEGER

    ASID ::= INTEGER
                </artwork>
            </figure>

            <t>
                Note that this content appears as the eContent within the encapContentInfo as specified in <xref target="RFC6488" />.
            </t>

            <section title="version">
                <t>
                    The version number of the ASProviderAttestation MUST be v0.
                </t>
            </section>

            <section title="AFI">
                <t>
                    The AFI field contains Address Family Identifier for which the relation between customer and provider ASes is authorized. Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry <xref target="IANA-AF" />.
                </t>
            </section>

            <section title="customerASID">
                <t>
                    The customerASID field contains the AS number of the Autonomous System that authorizes an upstream provider (listed in the providerASId) to propagate prefixes in the specified address family other ASes.
                </t>
            </section>

            <section title="providerASID">
                <t>
                    The providerASID contains the AS number that is authorized to further propagate announcements in the specified address family received from the customer.
                </t>
            </section>
        </section>

        <section title="ASPA Validation" anchor="validation">
            <t>
                Before a relying party can use an ASPA to validate a routing announcement, the relying party MUST first validate the ASPA object itself.
                To validate an ASPA, the relying party MUST perform all the validation checks specified in <xref target="RFC6488" /> as well as the following additional ASPA-specific validation step.
                <list style="symbols">
                    <t>
                        The autonomous system identifier delegation extension <xref target="RFC3779" /> is present in the
                        end-entity (EE) certificate (contained within the ASPA), and the customer AS number in the ASPA is
                        contained within the set of AS numbers specified by the EE certificate's autonomous system identifier
                        delegation extension.
                    </t>
                </list>
            </t>
        </section>

        <section title="ASN.1 Module for the ASPA Content Type" anchor="module">
            <figure>
                <artwork type="asn1">
    RPKI-ASPA-2018
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2018(TBD2) }
    DEFINITIONS IMPLICIT 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) } ;

    ContentSet CONTENT-TYPE ::= { ct-ASPA, ... }

    --
    -- ASPA Content Type
    --

    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

    id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
  
    id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD }
  
    ct-ASPA CONTENT-TYPE ::=
        { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA }

    ASProviderAttestation ::= SEQUENCE {
        version [0] ASPAVersion DEFAULT v0,
        AFI  AddressFamilyIdentifier,
        customerASID  ASID,
        providerASID  ASID }

    ASPAVersion ::= INTEGER  { v0(0) }

    AddressFamilyIdentifier ::= INTEGER

    ASID ::= INTEGER

    END
                </artwork>
            </figure>
        </section>

        <section anchor="IANA" title="IANA Considerations">
            <t>
                Please add the id-mod-rpki-aspa-2018 to the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)
                registry (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-0) as follows:
            </t>        
            <figure>
                <artwork type="text">
    Decimal   | Description                   | Specification
    -----------------------------------------------------------
    TBD2      | id-mod-rpki-aspa-2018         | [ThisRFC]
                   </artwork>
            </figure>

            <t>
                Please add the ASPA to the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry 
                (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-1) as follows:
            </t>        
            <figure>
                <artwork type="text">
    Decimal   | Description                   | Specification
    -----------------------------------------------------------
    TBD       | id-ct-ASPA                    | [ThisRFC]
                   </artwork>
            </figure>

            <t>
                Please add the ASPA to the RPKI Signed Object registry 
                (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects)
                as follows:
            </t>        
            <figure>
                <artwork type="text">
    Name      | OID                           | Specification
    -----------------------------------------------------------
    ASPA      | 1.2.840.113549.1.9.16.1.TBD   | [ThisRFC]
                   </artwork>
            </figure>
        </section>

        <section anchor="Security" title="Security Considerations">
        </section>

        <section anchor="Acknowledgments" title="Acknowledgments">
        </section>

    </middle>

    <back>
        <references title="Normative References">
            &RFC2119;
            &RFC3779;
            &RFC8174;
            &RFC5652;
            &RFC6485;
            &RFC6488;

            <reference anchor="X680" >
                <front>
                    <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
                    <author>
                        <organization>ITU-T</organization>
                    </author>
                    <date year="2015"/>
                </front>
                <seriesInfo name="ITU-T" value="Recommendation X.680"/>
            </reference>

            <reference anchor="X690" >
                <front>
                    <title>Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
                    <author>
                        <organization>ITU-T</organization>
                    </author>
                    <date year="2015"/>
               </front>
               <seriesInfo name="ITU-T" value="Recommendation X.690"/>
            </reference>

            <reference anchor="IANA-AF" target="http://www.iana.org/numbers.html">
                <front>
                    <title>Address Family Numbers</title>
                    <author>
                        <organization>IANA</organization>
                    </author>
                    <date />
                </front>
               <!-- <seriesInfo name="Reachable from" value="http://www.iana.org/numbers.html"/> -->
            </reference>

        </references>

        <references title="Informative References">
            &RFC6480;
        </references>
    </back>
</rfc>
