<div dir="ltr">I agree with you!<br><br>This is the kind of problem that would be more easily resolved with a good dose of automation and APIs than creating a "ROA v2".<br><br>So, if it's to waste energy, let's focus on annoying a bit more the RIRs that don't yet support delegated CA with Krill or direct API... <br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 4 de out. de 2021 às 10:57, Tim Bruijnzeels <<a href="mailto:tim@nlnetlabs.nl">tim@nlnetlabs.nl</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Douglas,<br>
<br>
I think that this kind of question is probably better aimed at sidrops.<br>
<br>
For what it's worth I think that there are many concerns with AS-SETs - not in the least name collisions and loops. If a prefix holder could sign an RPKI ROAv2 (of sorts) that references a set of ASNs (or however it would be called) then how does one verify that this set actually reflects what the *prefix* holder intended? Who signs this object with the actual ASNs? Essentially the prefix holder would have to explicitly outsource this choice somehow and I do not see a clean verifiable signature trail for this.<br>
<br>
My guess is that it's more difficult and error prone to solve this than is justified compared to just maintaining multiple ROAs.<br>
<br>
Don't let me stop you - I think that it's useful to think about future applications of RPKI, and the needs of operators using this day to day is very valuable - just bear in mind *who* signs *what* - and are they authorized to make statements about the resources?<br>
<br>
Tim<br>
<br>
> On 1 Oct 2021, at 14:17, Douglas Fischer via RPKI <<a href="mailto:rpki@lists.nlnetlabs.nl" target="_blank">rpki@lists.nlnetlabs.nl</a>> wrote:<br>
> <br>
> This question made me think about a possibility.<br>
> <br>
> Has it already been discussed whether in the future, when we have a cryptographically signed equivalent of IRR AS-SET, it will be possible to generate an ROA with an AS-SET as Orign?<br>
> <br>
> This would be interesting for sibling scenarios, and CDNs that have IP blocks (usually anycast) being sourced by ASNs that host Bring-Home.<br>
> Much less maintenance and interventions on ROAs.<br>
> <br>
> Em sex., 1 de out. de 2021 às 06:54, Alex Band via RPKI <<a href="mailto:rpki@lists.nlnetlabs.nl" target="_blank">rpki@lists.nlnetlabs.nl</a>> escreveu:<br>
> Hi Jacquie,<br>
> <br>
> A ROA object can contain only one ASN but can have multiple prefixes, so 1 ROA with 5 prefixes will result in 5 VRPs.<br>
> <br>
> The reason why you differences across RIRs is because of their implementations. In case of the RIPE NCC, you don’t actually create ROAs in a direct one-to-one mapping but you authorise announcements seen in BGP. Based on these authorisations, the system will generate ROA objects in the most efficient way possible with the least amount of objects. This is why you see a large difference between the ROA and VRP count. <br>
> <br>
> With other implementations users are guided more towards creating a single ROA per prefix, so there the ROA/VRP counts tend to match.<br>
> <br>
> Cheers,<br>
> <br>
> Alex<br>
> <br>
> > On 1 Oct 2021, at 09:48, Jacquie Zhang via RPKI <<a href="mailto:rpki@lists.nlnetlabs.nl" target="_blank">rpki@lists.nlnetlabs.nl</a>> wrote:<br>
> > <br>
> > Hello,<br>
> > <br>
> > My company is working on implementing RPKI with Routinator so I have some questions I'd like to ask. I'm breaking the questions into multiple emails. <br>
> > <br>
> > My first question is, is ROA to VRP 1-to-1 mapping, ie. there is only one VRP resulted from each ROA?<br>
> > <br>
> > I went through my ASN, AS4804, and compared the ROAs listed in the following public places to the ROAs we signed in APNIC and the VRPs in my Cisco router. They were exactly the same, 364. <br>
> > <br>
> > 1. <a href="https://rpki.cloudflare.com/?view=explorer&asn=4804" rel="noreferrer" target="_blank">https://rpki.cloudflare.com/?view=explorer&asn=4804</a>   showed 364<br>
> > 2. <a href="http://nong.rand.apnic.net:8080/roas" rel="noreferrer" target="_blank">http://nong.rand.apnic.net:8080/roas</a> showed 364<br>
> > 3. My lab Cisco router which is connected to a Routinator. It showed 364.<br>
> > 4. MYAPNIC portal, it showed 364.<br>
> > <br>
> > This lead me to think that the mapping is 1-to-1. Each ROA after processing by a validator software only generates one VRP. <br>
> > <br>
> > But from the following URL, it clearly shows that it is a 1-to-many mapping.<br>
> > <br>
> > Take RIPE as an example, ROA count was 25,704. VRP count was 138,630, which was 5.39 times of the ROA count. All other RIRs have VRP counts must greater than the ROA counts.<br>
> > <br>
> > <a href="https://rpki-validator.ripe.net/ui/metrics" rel="noreferrer" target="_blank">https://rpki-validator.ripe.net/ui/metrics</a><br>
> > <br>
> > <image.png><br>
> > <br>
> > Reading the Routinator document at <a href="https://routinator.docs.nlnetlabs.nl/en/stable/data-processing.html#roas-and-vrps" rel="noreferrer" target="_blank">https://routinator.docs.nlnetlabs.nl/en/stable/data-processing.html#roas-and-vrps</a>, it says "If the ROA passes validation, Routinator will produce one or more plain text validated ROA payloads (VRPs) for each ROA, depending on how many IP prefixes are contained within it."<br>
> > <br>
> > Can someone please help explain which one is correct, 1-to-1 or 1-to-many? Maybe different scenarios produce differently? Which scenario will produce multiple VRPs from a single ROA?<br>
> > <br>
> >  I'm not talking about VRP to prefix mapping. I understand in the case max len is greater than the prefix len in a VRP, multiple IP prefixes will be covered by this VRP.<br>
> >  <br>
> > <br>
> > Thanks,<br>
> > Jacquie from Optus<br>
> > <br>
> > -- <br>
> > RPKI mailing list<br>
> > <a href="mailto:RPKI@lists.nlnetlabs.nl" target="_blank">RPKI@lists.nlnetlabs.nl</a><br>
> > <a href="https://lists.nlnetlabs.nl/mailman/listinfo/rpki" rel="noreferrer" target="_blank">https://lists.nlnetlabs.nl/mailman/listinfo/rpki</a><br>
> <br>
> -- <br>
> RPKI mailing list<br>
> <a href="mailto:RPKI@lists.nlnetlabs.nl" target="_blank">RPKI@lists.nlnetlabs.nl</a><br>
> <a href="https://lists.nlnetlabs.nl/mailman/listinfo/rpki" rel="noreferrer" target="_blank">https://lists.nlnetlabs.nl/mailman/listinfo/rpki</a><br>
> <br>
> <br>
> -- <br>
> Douglas Fernando Fischer<br>
> Engº de Controle e Automação<br>
> -- <br>
> RPKI mailing list<br>
> <a href="mailto:RPKI@lists.nlnetlabs.nl" target="_blank">RPKI@lists.nlnetlabs.nl</a><br>
> <a href="https://lists.nlnetlabs.nl/mailman/listinfo/rpki" rel="noreferrer" target="_blank">https://lists.nlnetlabs.nl/mailman/listinfo/rpki</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>