Network Working Group T. Bruijnzeels
Internet-Draft RIPE NCC
Intended status: Informational O. Borchert
Expires: 4 September 2025 NIST
D. Ma
ZDNS
T. de Kock
RIPE NCC
3 March 2025
Human Readable ASPA Notation
draft-ietf-sidrops-aspa-notation-03
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 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bruijnzeels, et al. Expires 4 September 2025 [Page 1]
Internet-Draft ASPA Notation March 2025
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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. ASPA Notation Definition . . . . . . . . . . . . . . . . . . 3
3.1. customer-asid . . . . . . . . . . . . . . . . . . . . . . 3
3.2. providers . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. provider-as . . . . . . . . . . . . . . . . . . . . . 4
3.3. asn . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example Notations . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 (generators), making it easier for operators to
compare results.
* This can be used by RPKI Certificate Authorities (CA) command line
interfaces and/or configuration, where an automated process parses
this syntax. 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.
Bruijnzeels, et al. Expires 4 September 2025 [Page 2]
Internet-Draft ASPA Notation March 2025
The chosen notation style can be read from left to right to mean that
the holder of the customer ASN on the left authorizes one or more
provider ASNs on the right.
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].
notation = customer-asid separator providers
customer-asid = asn
separator = " => "
providers = providers-one-line / providers-multiline
providers-one-line = asn *(*wsp "," *wsp asn)
providers-multiline = "[" *wspml asn *(*wspml "," *wspml asn) *wspml "]"
asn = "AS" uint32
uint32 = %d0-4294967295
wsp = space / tab
wspml = space / tab / cr / lf
cr = %d13
lf = %d10
space = %d32
tab = %d9
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 constraints
apply to the content of ASPA objects:
1. There must be at least one provider-as.
2. The customer-asid "asn" value must not appear in any provider-as.
Bruijnzeels, et al. Expires 4 September 2025 [Page 3]
Internet-Draft ASPA Notation March 2025
3. The elements of providers must be ordered in ascending numerical
order by the "asn" value of the provider-as field.
4. Each "asn" value for used for a provider-as must be unique.
A generator MUST ensure that the output matches all these normative
constraints. However, to be more resilient to input written by
humans, a parser MUST accept a list of providers that is not
correctly sorted (3) but otherwise valid.
3.2.1. provider-as
This field represents a Provider AS as defined in section 3.3 of
[I-D.ietf-sidrops-aspa-profile].
3.3. asn
This field consists of 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 represent a 32 bit
value, and therefore MUST be part of the range 0-4294967295.
4. Example Notations
Some example notations are listed below. The last example is not
advised for readability but is technically allowed by this
specification.
AS65000 => AS65001
AS65000 => AS65001
AS65000 => AS65002
AS65000 => AS65001, AS65002,AS65003
AS65000 => [ AS65001, AS65002, AS65003 ]
AS65000 => [
AS65001,
AS65002,
AS65003
]
AS65000 => [AS65001,
AS65002
,AS65003
]
The following example is valid for input only (i.e. while it is
sorted in string order, it is not sorted in numerical order):
Bruijnzeels, et al. Expires 4 September 2025 [Page 4]
Internet-Draft ASPA Notation March 2025
AS65000 => [ AS4200000000, AS64496 ]
note: private use AS number used because all documentation AS numbers
have the same textual prefix.
5. IANA Considerations
This document has no IANA actions.
6. Security Considerations
TBD
7. Acknowledgements
Thanks to Randy Bush for suggesting to allow only one possible
notation for AS numbers.
8. Normative References
[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-19, 6 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-19>.
[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>.
Bruijnzeels, et al. Expires 4 September 2025 [Page 5]
Internet-Draft ASPA Notation March 2025
Authors' Addresses
Tim Bruijnzeels
RIPE NCC
Email: tbruijnzeels@ripe.net
Oliver Borchert
NIST
Email: oliver.borchert@nist.gov
Di Ma
ZDNS
Email: madi@zdns.cn
Ties de Kock
RIPE NCC
Email: tdekock@ripe.net
Bruijnzeels, et al. Expires 4 September 2025 [Page 6]