Re: [GROW] draft-ss-grow-rpki-as-cones-00

[Job Snijders <[e-mail]>]

On Wed, May 23, 2018 at 08:03:45AM -0700, Randy Bush wrote:
> >>> me and Job Snijders have recently submitted
> >>> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an
> >>> attempt to bring as-sets into RPKI to facilitate route filtering.
> >> 
> >> in irr, an as-set may reference an as-set.  could you explain the
> >> authority model you have for this when as-sets are signed?
> 
> > My initial thinking for RPKI AS Cones, is that a given Cone in an
> > ASN's namespace can only be defined by the owner of the ASN in who's
> > namespace the Cone is defined.
> 
> namespace?

In the IRR world we have the concept of hierarchical naming of AS-SETs:
an example is "AS15562:AS-SNIJDERS" [1] - under the "AS15562" hierarchy
only the owner (or delegated folks) can add/change/remove AS-SETS. I
call this a namespace, should a different term be used?

> isn't this the irr authorisation model?

The IRR AS-SET feature is working pretty well (since it is better than
nothing), but there are some downsides.

For instance "AS15562:AS-SNIJDERS" can exist in multiple IRR databases,
and we don't know which of those was actually created by the owner of
AS15562. I hope this can be addressed in AS Cones.

Another problem is that there no longer is a way (or perhaps there never
was) to autodetect what AS-SET should be used by which organisation to
generate a filter. RPSL is broken, fundamentally flawed. Perhaps this
can be addressed - not by introducing a new language - but just having a
handy naming convention. Think of it as "AS15562:AS-2914", so AS 2914
knows it should use AS15562:AS-2914 if it exists, and if it doesn't
exist use AS15562:AS-DEFAULT.

> and how did that work out for us?

I consider it a feature that anyone can add anything to an AS-SET they
created, this puts the workload on transit providers and doesn't require
stub networks to do anything. The "member-of:" feature is barely used
and seems to pose too much work.

Clock is ticking... multiple RIRs are struggling with their IRRs (or
lack thereof). If IETF does not pony up a solution that is good enough
for operational purposes, we may end up with RIRs investing in legacy
technology and a continuation of the duplication/discovery/ownership
issue. There is an opportunity here and now, let's work on it?

Kind regards,

Job

[1]: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=AS15562:AS-SNIJDERS#resultsSection