Skip to main content

Human Readable ASPA Notation
draft-timbru-sidrops-aspa-notation-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Tim Bruijnzeels , Oliver Borchert , Di Ma
Last updated 2023-05-11
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-timbru-sidrops-aspa-notation-00
Network Working Group                                     T. Bruijnzeels
Internet-Draft                                                NLnet Labs
Intended status: Informational                               O. Borchert
Expires: 12 November 2023                                           NIST
                                                                   D. Ma
                                                                    ZDNS
                                                             11 May 2023

                      Human Readable ASPA Notation
                 draft-timbru-sidrops-aspa-notation-00

Abstract

   This document defines a human readable notation for Validated ASPA
   Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based
   on ABNF (RFC 5234).

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 12 November 2023.

Copyright Notice

   Copyright (c) 2023 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.

Bruijnzeels, et al.     Expires 12 November 2023                [Page 1]
Internet-Draft                ASPA Notation                     May 2023

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  ASPA Notation Definition  . . . . . . . . . . . . . . . . . .   2
     3.1.  customer-asid . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  providers . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.1.  provider-as . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  asn . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  asn-v4  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.5.  asn-v6  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Example Notations . . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Requirements notation

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   This informational document defines a human readable ASPA notation
   for Validated ASPA Payloads (VAPs) [I-D.ietf-sidrops-aspa-profile].

   The main motivations for providing this notations style are: * This
   can help to create consistency between RPKI Relying Party software
   output, making it easier for operators to compare results. * This can
   be used by RPKI Certificate Authorities (CA) command line interfaces
   and/or configuration.  E.g. allowing a CA to provide a listing of
   intended VAPs which can be easily compared to RP output. * This can
   be used for documentation.

   That said, this definition is informational.  Implementations can
   choose to use their own notation styles instead of, or in addition to
   this.

3.  ASPA Notation Definition

   This specification uses ABNF syntax specified in [RFC5234].

Bruijnzeels, et al.     Expires 12 November 2023                [Page 2]
Internet-Draft                ASPA Notation                     May 2023

   notation           = customer-asid separator providers
   customer-asid      = asn
   separator          = " => "
   providers          = provider-as *(provider-separator provider-as)
   provider-as        = asn / asn-limit-v4 / asn-limit-v6
   provider-separator = ", "
   uint32             = %d0-4294967295
   asn                = ["AS"] uint32
   asn-limit-v4       = asn "(v4)"
   asn-limit-v6       = asn "(v6)"

3.1.  customer-asid

   This field represents the customerASID defined in section 3.2 of
   [I-D.ietf-sidrops-aspa-profile]

3.2.  providers

   This field represents the providers defined in section 3.3 of
   [I-D.ietf-sidrops-aspa-profile].  Note that the normative constraints
   which are defined in that section mean that following :

   *  There must be at least one provider-as.

   *  The customer-asid "asn" value must not appear in any provider-as.

   *  The elements of providers must be ordered in ascending numerical
      order by the "asn" value of the provider-as field.

   *  Each "asn" value for used for a provider-as must be unique.
      Assertions for the same "asn" with different afiLimit values must
      be merged.

3.2.1.  provider-as

   This field represents a ProviderAS as defined in section 3.3.1 of
   [I-D.ietf-sidrops-aspa-profile].

   A ProviderAS in ASPA consists of a providerASID (section 3.3.1.1) and
   an optional afiLimit (section 3.3.1.2).  In the notation defined here
   we use a simple "asn" to represent a ProviderAS that has no afiLimit,
   we use "asn-limit-v4" to represent a ProviderAS with an afiLimit for
   IPv4, and we use "asn-limit-v4" to represent a ProviderAS with an
   afiLimit for IPv6.

   As mentioned earlier: the same "asn" MUST NOT appear more than once
   in the providers.  There is no point in listing the same "asn" with
   and without an afiLimit, as the entry without an afiLimit already

Bruijnzeels, et al.     Expires 12 November 2023                [Page 3]
Internet-Draft                ASPA Notation                     May 2023

   encompassed the other.  Similarly, there is no point in listing the
   same "asn" with an IPv4 and an IPv6 limit, as this can and must be
   more concisely expressed as a single entry without an afiLimit.

3.3.  asn

   This field can optionally be prepended with the string "AS" followed
   by a decimal value of a 32 bit Autonomous System Number using the
   asplain presentation as specified in [RFC5396].  Decimal values MUST
   be used, and values MUST be part of the range 0-4294967295.

3.4.  asn-v4

   This represents a providerAS that uses an afiLimit for IPv4.

3.5.  asn-v6

   This represents a providerAS that uses an afiLimit for IPv6.

4.  Example Notations

   AS65000 => AS65001
   AS65000 => AS65002(v4)
   AS65000 => AS65001, AS65002(v4), AS65003(v6)

   65000 => 65001
   65000 => AS65002(v4)
   65000 => 65001, 65002(v4), 65003(v6)

5.  IANA Considerations

   This document has no IANA actions.

6.  Security Considerations

   TBD

7.  Acknowledgements

   TBD

8.  Normative References

Bruijnzeels, et al.     Expires 12 November 2023                [Page 4]
Internet-Draft                ASPA Notation                     May 2023

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-13, 25 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-13>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5396]  Huston, G. and G. Michaelson, "Textual Representation of
              Autonomous System (AS) Numbers", RFC 5396,
              DOI 10.17487/RFC5396, December 2008,
              <https://www.rfc-editor.org/info/rfc5396>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Tim Bruijnzeels
   NLnet Labs
   Email: tim@nlnetlabs.nl

   Oliver Borchert
   NIST
   Email: oliver.borchert@nist.gov

   Di Ma
   ZDNS
   Email: madi@zdns.cn

Bruijnzeels, et al.     Expires 12 November 2023                [Page 5]