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

Sorry for the top-reply:

I think the fundamental problem with AS-SETs in IRR is the unilateral
aspect of "control" of what amounts to assertion of a relationship.

Given the basic mechanisms already in play for RPKI (keys, signing, etc.),
I think this would be easy enough to fix:

   - Any relationship asserted should require both parties to confirm by
   signing
   - Any relationship can be revoked by either party (thus fixing the main
   IRR problem)
   - Anyone else can confirm that relationship via signatures
   - The nature of the relationship would need to be reflected, in order to
   have maximum benefit. E.g. transit-provider, transit-customer, peer,
   mutual-transit, other.
   - This plays well with preventing route-leaks, too.

This would only require the ability to associate things like groups of ASNs
with single entities that speak for them. If that isn't already part of
RPKI, it would need to be added.

Brian

On Wed, May 23, 2018 at 10:07 AM, Job Snijders <job@ntt.net> wrote:

> 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
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>