[Sidrops] Extending RPKI-Router protocol to do more

[Iljitsch van Beijnum <[e-mail]>]

[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