[Sidrops] request for feedback draft-spaghetti-sidrops-rpki-asgroup-00

[Job Snijders <[e-mail]>]

Dear all,

As recently discussing in RIPE's db-wg [1] and routing-wg [2],
considerable operational heartburn arises from AS-SET objects with
same names/different content existing in multiple IRR databases.
Ultimately this is a namespace/authorization problem, worsened by the
lack of object security.

The lack of an analogy of IRR 'as-set' functionality in the RPKI appears
to be significant barrier for the industry to migrate towards the
ability to run operations in an IRR-free mode. Many ISPs end up having
to use both IRR and RPKI to run their network, this IRR<>RPKI dual
dependency makes for painful complications. All IRR data ultimately is
unverifiable plain text without signatures. 

We put together a proposal to port the IRR 'as-set' class object
functionality to the RPKI framework; leveraging authorization through
validating a chain of AS Identifier extensions; resolve object naming
collisions; and additionally provide an opt-out mechanism. We imagine
the UI for operators could be very similar to IRR AS-SET edit forms.

This proposal might be reminiscent of ASCONES, but there a few
notable differences: the ASGroup ASN.1 formal notations are more
thorough; there is no ambiguity about who signs what; AS Cones had 4
validation modes, ASGroups only has 1 (which simplifies the concept);
AS-CONES attempted to port both IRR 'autnum: + as-set:' functionality in
one go - ASGroup on the other hand only attempts to port IRR 'as-set'
functionality (another simplification); finally - ASCONES's opt-out
mechanism is e-mail based, whereas ASGroups provides an RPKI-native
approach.

Relationship to ASPA: in ASPA the Autonomous System Number resource
holder attests who their upstreams are; and perhaps ASGroups should be
considered as a building block to allow publication of attestations "in
the other direction". This can help increase precision in building
filters. Today many operators signal IRR AS-SET names through
out-of-band means such as PeeringDB or Service Order Forms; we
anticipate that ASGroups can satisify that particular need (in addition
to other future applications).

Your feedback is much appreciated, we'd love to continue work on this as
a working group document.

Kind regards,

Job & Fredrik

[1]: https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html
[2]: https://www.ripe.net/ripe/mail/archives/routing-wg/2022-November/004649.html

----- Forwarded message from [e-mail] -----

Date: Wed, 16 Nov 2022 02:30:22 -0800
From: [e-mail]
To: Fredrik Korsbäck <[e-mail]>, Job Snijders <[e-mail]>
Subject: New Version Notification for draft-spaghetti-sidrops-rpki-asgroup-00.txt

A new version of I-D, draft-spaghetti-sidrops-rpki-asgroup-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:		draft-spaghetti-sidrops-rpki-asgroup
Revision:	00
Title:		A profile for RPKI Signed Groupings of Autonomous System Numbers (ASGroup)
Document date:	2022-11-16
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-asgroup-00.txt
Status:         https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-asgroup/
Html:           https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-asgroup-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-asgroup


Abstract:
   This document defines a Cryptographic Message Syntax (CMS) protected
   content type for use with the Resource Public Key Infrastructure
   (RPKI) to carry a general-purpose listing of Autonomous System
   Numbers (ASNs) and/or pointers to other groupings of ASNs, called an
   ASGroup.  Additionally, the document specifies a mechanism for ASN
   holders to opt-out of being listed in a given ASGroup.  The objective
   is to offer a RPKI-based successor to plain-text RFC 2622 'as-set'
   class objects.  When validated, an ASGroup confirms that the
   respective ASN holder produced the ASGroup object.

The IETF Secretariat

----- End forwarded message -----