Subject: [GROW] Extending RPKI-Router protocol to do more

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Jul 2019 13:57:56 +0200

[Posted to sidrops, grow and RIPE routing-wg]

Hi all,

A few weeks ago I wrote a draft on extending RPKI to make it possible to validate the full AS path rather than just the origin AS.

Rather than ignore other work in this area such as ASPA and AS Cones, I've decided to focus on the thing that all these efforts will benefit from: extensions to the RPKI-Router protocol so that more types of filtering become possible under the RPKI model than just origin validation as per RFC 6811.

I think the RPKI model is a powerful one: you run the software that uses complex algorithms on a small set of central boxes. This is very flexible software that can be changed quickly (often open source). Then you send filters over to the routers using very well-defined semantics, so you know exactly what the routers are going to do and the risks are minimal, with no need to keep changing the router implementations when there are new validation mechanisms.

My additions are:

- a way to filter entire AS paths (such as created by ASPA or my PathRPKI draft)
- a way to allow prefixes from a given set of ASes, which could be used to implement a system like AS Cones
- a way to deny prefixes from a given set of ASes, which could be used to react to route leaks etc on the fly

These are just examples, I'm sure there are many different things that could be done with these filter extensions.

I wrote a draft about the whole thing, but draft submissions are currently closed so read it here for now:

http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt <http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt>

I'm very interested to hear what you think.

Iljitsch

---

From: Massimiliano Stucchi <[email-masked]>
Date: Thu, 11 Jul 2019 14:43:17 +0200

Hi Iljitsch,

On 11/07/2019 13:57, Iljitsch van Beijnum wrote:

> 
> I wrote a draft about the whole thing, but draft submissions are
> currently closed so read it here for now:
> 
> http://www.muada.com/drafts/draft-van-beijnum-sidrops-rpki-rtr-ext-00.txt
> 

What I don't like (or most likely don't understand the necessity of)
about the draft is the jump up 2 protocol versions.  This is most likely
going to create many issues for implementations and create lots of
unnecessary code in both validators and routers.

I think that the general idea and direction are good, but I also think
we should discuss first about how not to bloat up the protocol, and make
something that can stand long term and can be easily implemented and
maintained.

I would be happy to join the discussion and participate in this, if we
see enough interest.

Ciao!

-- 

Massimiliano Stucchi
MS16801-RIPE

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Jul 2019 14:52:25 +0200

Hi Massimiliano,

> unnecessary code in both validators and routers.

Well, what I was thinking is to allow implementations to select which mechanisms they want to support. You could simply receive the Deny and/or Allow PDUs and ignore those without trouble.

But Path PDUs can't exist at the same time as Prefix PDUs, so the cache server and the router MUST be in agreement on supporting that one.

So version 2 adds Deny and Allow but not Path, and version 3 also adds Path.

What do you think the problems will be with more versions? We already have version 0 and 1, so in any event we'd have three versions.

> something that can stand long term and can be easily implemented and

Right.

> I would be happy to join the discussion and participate in this, if we

Great!

Thanks,

Iljitsch

---

From: Brian Dickson <[email-masked]>
Date: Thu, 11 Jul 2019 10:58:32 -0700

One thing to be cautious about:
AS Cones still allow customer vs customer leaks, while ASPA would prevent
those.
E.g. customers A and B, of provider X. Add C (customer of A and B). If C
leaks A's routes to B, X would allow both B C A and A as valid AS_PATH
values using AS-CONE logic. If B prefixes are localpref'd higher than A,
that would be very bad.

Depending on how PathRPKI works (including the RPKI-RTR piece), it might be
better to only support the ASPA-like functionality (i.e. does performance
of path validation scale independent of how valid paths themselves are
calculated? ).

Brian

On Thu, Jul 11, 2019 at 4:58 AM Iljitsch van Beijnum <iljitsch=
[email-masked]> wrote:

> A few weeks ago I wrote a draft on extending RPKI to make it possible to
> validate the full AS path rather than just the origin AS.
>
> Rather than ignore other work in this area such as ASPA and AS Cones, I've
> decided to focus on the thing that all these efforts will benefit from:
> extensions to the RPKI-Router protocol so that more types of filtering
> become possible under the RPKI model than just origin validation as per RFC
> 6811.
>
> I think the RPKI model is a powerful one: you run the software that uses
> complex algorithms on a small set of central boxes. This is very flexible
> software that can be changed quickly (often open source). Then you send
> filters over to the routers using very well-defined semantics, so you know
> exactly what the routers are going to do and the risks are minimal, with no
> need to keep changing the router implementations when there are new
> validation mechanisms.
>
> My additions are:
>
> These are just examples, I'm sure there are many different things that
> could be done with these filter extensions.
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Jul 2019 11:04:02 +0200

On 11 Jul 2019, at 19:58, Brian Dickson <[email-masked]> wrote:

> AS Cones still allow customer vs customer leaks, while ASPA would prevent those.

Yes, the AS Cones draft mentions "building a prefix list". So even though the validation procedure has access to all the ASes in the AS paths, this information is lost in that final step, presumably because AS Cones wants to build a filter that works on today's routers, and there is no scalable way to make a filter thatonly allows a certain AS path for a certain prefix.

But that is of course the advantage of coming up with something new: then we don't have to be limited in this way. So if AS Cones were to make use of the proposed RPKI-Router extensions, it should probably use the IPvX Path mechanism rather than the Allow IPvX mechanism.

So the Allow IPvX mechanism may be less useful than I thought it would be.

> Depending on how PathRPKI works (including the RPKI-RTR piece), it might be better to only support the ASPA-like functionality (i.e. does performance of path validation scale independent of how valid paths themselves are calculated? ).

Well, basically, if we gloss over some details like the issue above, ASPA, AS Cones and PathRPKI do much the same thing, with the main difference in how they validate the path on the relying party software cache:

- ASPA uses customer-to-provider (C2P) records to recursively build the full path
- AS Cones uses provider-to-customer (P2C) records to recursively build the full path
- PathRPKI uses origin-to-provider (O2P) records for the upstream part of the path and local configuration for the downstream part of the path to build the full path

AS Cones requires the least actions to deploy because only the providers have to register P2C records and there's fewer providers than customers. However, this is less secure because now a provider can incorrectly claim that some AS is its customer and then leak those routes, with the "customer" AS having no way to stop this.

PathRPKI has a deployment advantage over ASPA because only the origin ASes need to register information, and then the path between two ASes that implement PathRPI is immediately protected against leaks, even if the ASes in the middle haven't implemented PathRPKI.

On the other hand, PathRPKI has the downside that if a provider switches providers, now all the customers downstream have to change their O2P registrations, making changes harder and riskier.

Perhaps the right way forward is to integrate the three approaches. If we allow C2P records to contain not just the immediate upstream providers, but optionally, also providers of providers, then basically C2P does everything O2P does so ASPA would gain the advantages of PathRPKI.

We can also support both P2C and C2P records, where C2P records overrule P2C records. (I.e., if AS4 says AS1 is its customer and AS1 has no C2P record, we believe this. But if AS1 says AS2 and AS3 are its providers, then the AS4 claim that AS1 is its customer is ignored.)

This way, we have the best possible deployment scenario, because, apart from the need for the origin to at least have ROAs, for each customer/provider pair, only one side needs to register the relationship to allow us to validate paths, so a single AS in the middle not bothering to participate won't be a showstopper.

Iljitsch