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 protected]> wrote: > [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 > > I'm very interested to hear what you think. > > Iljitsch > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
