Ensuring RPKI ROAs match your routing intent
Hi everyone, Over the last two years NLnet Labs has been working on free, open source RPKI software and research for the community, supported by the RIPE NCC Community Projects Fund, Brazilian NIR NIC.br and Asia Pacific RIR APNIC. I have an update that we’d like to share. When creating a ROA in RPKI, it can have an effect on one or more BGP announcements, making them either Valid, Invalid or NotFound. Understanding what exactly determines these three states is not immediately obvious, especially in the beginning. At times, this can make creating ROAs a bit of a shot in the dark. I’ve seen several examples in the past where an operator created a ROA in their RIR Portal, waited for it to be published and then checked in services like BGPMon or the HE BGP Toolkit to see if everything turned out as expected. This is why, during my time at the RIPE NCC, we put a lot of work into making it immediately obvious what the effect of a ROA is going to be on the BGP announcements with your address space. Several RIRs have followed in these footsteps since. I presented on this journey at NANOG 63 in 2015: https://archive.nanog.org/meetings/abstract?id=2500 Now, in my new adventure at NLnet Labs, we’ve gotten the same team together to make simple, intuitive ROA management for Delegated RPKI available for everyone, seamlessly across RIR regions. With Krill 0.7.1 ‘Sobremesa’ you can easily create and maintain ROAs in a user interface that incorporates all of the best practices and lessons learned over the last 10 years and monitor them in ways never before possible, such as through Prometheus. Blog post with details: http://link.medium.com/1SsTJSAvB7 All the best, Alex
alex, you point out a serious concern, when creating a ROA will i do damage? the way the DRL CA gooey has handled this for a decade+ is to have a full bgp dump and to compare the prospective new ROA to that dump. krill seems to be following this path. cool. what does the NCC's CA do in this space (i only use delegated, so do not see it)? randy
Hi, On Thu, Jun 25, 2020 at 07:57:54AM -0700, Randy Bush wrote:
you point out a serious concern, when creating a ROA will i do damage?
I see a few obvious mistakes - fatfinger the origin AS, turn all my announcements from "unknown" to "invalid" - overlook length restrictions, turn all my more-specifics from "unknown" to "invalid" - overlook valid more-specifics originated from a different origin AS ("multihomed customer using part of my space")
the way the DRL CA gooey has handled this for a decade+ is to have a full bgp dump and to compare the prospective new ROA to that dump.
This sounds like a good plan to avoid both types of mistakes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
the way the DRL CA gooey has handled this for a decade+ is to have a full bgp dump and to compare the prospective new ROA to that dump. This sounds like a good plan to avoid both types of mistakes.
yep. seemed obvious. props to michael elkins (of mutt fame), who hacked that part of the gooey. it has been working well for a long while. and, of course, we never make mistakes :) randy
Hi Randy,
On 25 Jun 2020, at 16:57, Randy Bush <randy@psg.com> wrote:
alex,
you point out a serious concern, when creating a ROA will i do damage? the way the DRL CA gooey has handled this for a decade+ is to have a full bgp dump and to compare the prospective new ROA to that dump. krill seems to be following this path. cool. what does the NCC's CA do in this space (i only use delegated, so do not see it)?
The ROA management in the RIPE NCC Portal uses these RIS dumps: http://www.ris.ripe.net/dumps/ As far as I know APNIC and LACNIC offer something similar, with the former also creating matching route objects in the same UI. Krill uses these RIS dumps too for this initial release, but we intend to evolve it over the next releases with something more real-time, as well as letting you plug in a local router feed, add tagging, staging of ROAs, warning of liberal maxLength, etc. Combined with the Prometheus monitoring we already have, it should provide a quick alerting system if problematic announcements appear. Props to DRLs pioneering work. -Alex
Krill uses these RIS dumps too for this initial release, but we intend to evolve it over the next releases with something more real-time, as well as letting you plug in a local router feed
drl considered this but i voted against it. my local router is already too heavily influenced by my local rpki collection and policies. when i contemplate a new roa, i want to see how it might impact anything floating around in the global table as seen from as many vantage points as possible; hence route views and ris. of course, that thought was a decade plus ago, and ymmv. randy
Hi Randy, all,
On 26 Jun 2020, at 16:04, Randy Bush <randy@psg.com> wrote:
Krill uses these RIS dumps too for this initial release, but we intend to evolve it over the next releases with something more real-time, as well as letting you plug in a local router feed
drl considered this but i voted against it. my local router is already too heavily influenced by my local rpki collection and policies. when i contemplate a new roa, i want to see how it might impact anything floating around in the global table as seen from as many vantage points as possible; hence route views and ris. of course, that thought was a decade plus ago, and ymmv.
I think that for a start RIS and RouteViews are great. However, as ROV becomes more deployed and your upstreams may start dropping your unintended invalids, those may not show up any more in those views. So, I think that in future local feeds will become more important. This could be based on automated router config set ups (like IPAM solutions) which can use an API to create the ROAs as needed. Or it could be 'just-in-time' or well.. 'just-too-late' authorisations based on a real local BGP feed even. Indeed YMMV and we are still exploring this. Note that even then monitoring your own prefixes in the global BGP in relation to your ROAs from other vantage points will still be important. I expect that something like BGP Alerter (or similar) rather than your own RPKI CA will be more suitable for this purpose. Tim
randy
However, as ROV becomes more deployed and your upstreams may start dropping your unintended invalids, those may not show up any more in those views.
remember, this when contemplating *creating* a roa. ain't no new invalids yet, intended or unintended. when contemplating creating a roa, i want to know how i will be affecting the global routing of that prefix, not just my local router.
Note that even then monitoring your own prefixes in the global BGP in relation to your ROAs from other vantage points will still be important. I expect that something like BGP Alerter (or similar) rather than your own RPKI CA will be more suitable for this purpose.
i love bgp alerter. butt tha is ex post facto. the CA check of the effect of contemplated roa creation is *before* i break things. but, while i see a comparison to 42 more local views as uninteresting, they would not seem to cause harm. but i would keep the global comparison as the prominent user-facing feature. but if you want to be creative, when i contemplate adding a roa for a prefix, it would be nice to check that i am not invalidating longer sub-prefixes, e.g. those possibly routed by customers. and again, in the global table. randy
participants (4)
-
Alex Band -
Gert Doering -
Randy Bush -
Tim Bruijnzeels