> On May 23, 2018, at 1:24 PM, Brian Dickson <[email protected]> > wrote: > > 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.
So, this poses some challenges as it won’t actually fit into a well defined set of use-cases. Being able to specify who can announce my route (or routes) and giving them a good way to specify this cone seems helpful. Requiring both parties to sign, countersign, etc.. is not desirable or is problematic operationally. How many e-mails back and forth have you seen go by where getting this updated is a problem? I’ve seen quite a bit. Not everyone is well automated and trying to use this as a sledge to turn that screw is going to be met with a collective yawn and be ignored by many folks. - Jared > • 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
