On Wed, May 23, 2018 at 10:46 AM, Job Snijders <[email protected]> wrote: > On Wed, 23 May 2018 at 19:25, 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. >> > > > I believe the fundamental problem is (1) the same AS-SET name can exist in > multiple databases (duplication), (2) you don’t know which as-set belongs > to which ASN (ownership), and which as-set to use (discovery). > > What you describe is quite low on the wish list from my perspective. Are > you using as-sets for filter generation today? >
So, the question about what I do, is irrelevant (bordering on ad-hominem). The relevant questions, IMHO, are: - Is anyone using as-sets for filter generation? - Are there limitations on the semantics of as-sets, that prevent the generation of filters that can stop all classes of route-leaks? - Are there ways to fix this, if we go down the RPKI path? The answers are "yes", "yes", and IMHO, "yes". While they might not be high on your list, the solution is relatively easy to define and implement, and to do so in a way that won't block the things you propose already. It's an addition, optional but recommended, with slightly stronger controls and semantics. The "cone" draft allows an AS to assert the "customer-of" relationship to its transit provider(s). That's good, and prevents many kinds of route-leaks (presuming registrations are done and filters built, etc.) E.g.: leaf AS leaking full tables upstream would be blocked (if transit providers filter their customers); peer-peer-peer leakage would be blocked (if peers filter); peer-peer-transit would be blocked (if transit providers filter their customers). All of those are where only customer routes should be announced (to upstreams or peers), limiting the announcements to the "cone". (Aside: everyone is also building as-path filters from this data too, right? Because without that, as-path shortening can be done...) There is one category of leaks, or leak-like attacks, that won't be prevented using the transit cone, which is what I'm suggesting adding: the explicit peering sets (for validating the as-paths received from transit providers). There currently is no mechanism to detect (or prevent) anyone from claiming a particular peering (or transit) relationship with any other AS, to their customers. Adding explicit peering declarations would enable that, and facilitate blocking improper announcements by transit providers. I don't want to give particular named examples, but I believe this is a problem in places with authoritarian regimes and mandated transit providers. Anyone peering with such entities, or getting transit from them, may end up sending traffic over a path that would be ill-advised, if they were aware of the as-path manipulation. It is an (extreme) corner case, but I think this is the place to address it with technology. By all means, this should not block the primary stuff (unilateral parent-identification with signatures). Brian P.S. I was wrong about the bilateral signing being needed for the transit path stuff, please forgive that oversight. > > Job > >>
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
