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

[Brian Dickson <[e-mail]>]

On Wed, May 23, 2018 at 10:46 AM, Job Snijders <[e-mail]> wrote:

> On Wed, 23 May 2018 at 19:25, Brian Dickson <[e-mail]>
> 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
>
>>