I agree with you! 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".
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... Em seg., 4 de out. de 2021 às 10:57, Tim Bruijnzeels <[email protected]> escreveu: > Hi Douglas, > > I think that this kind of question is probably better aimed at sidrops. > > 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. > > My guess is that it's more difficult and error prone to solve this than is > justified compared to just maintaining multiple ROAs. > > 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? > > Tim > > > On 1 Oct 2021, at 14:17, Douglas Fischer via RPKI < > [email protected]> wrote: > > > > This question made me think about a possibility. > > > > 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? > > > > This would be interesting for sibling scenarios, and CDNs that have IP > blocks (usually anycast) being sourced by ASNs that host Bring-Home. > > Much less maintenance and interventions on ROAs. > > > > Em sex., 1 de out. de 2021 às 06:54, Alex Band via RPKI < > [email protected]> escreveu: > > Hi Jacquie, > > > > A ROA object can contain only one ASN but can have multiple prefixes, so > 1 ROA with 5 prefixes will result in 5 VRPs. > > > > 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. > > > > With other implementations users are guided more towards creating a > single ROA per prefix, so there the ROA/VRP counts tend to match. > > > > Cheers, > > > > Alex > > > > > On 1 Oct 2021, at 09:48, Jacquie Zhang via RPKI < > [email protected]> wrote: > > > > > > Hello, > > > > > > 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. > > > > > > My first question is, is ROA to VRP 1-to-1 mapping, ie. there is only > one VRP resulted from each ROA? > > > > > > 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. > > > > > > 1. https://rpki.cloudflare.com/?view=explorer&asn=4804 showed 364 > > > 2. http://nong.rand.apnic.net:8080/roas showed 364 > > > 3. My lab Cisco router which is connected to a Routinator. It showed > 364. > > > 4. MYAPNIC portal, it showed 364. > > > > > > This lead me to think that the mapping is 1-to-1. Each ROA after > processing by a validator software only generates one VRP. > > > > > > But from the following URL, it clearly shows that it is a 1-to-many > mapping. > > > > > > 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. > > > > > > https://rpki-validator.ripe.net/ui/metrics > > > > > > <image.png> > > > > > > Reading the Routinator document at > https://routinator.docs.nlnetlabs.nl/en/stable/data-processing.html#roas-and-vrps, > 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." > > > > > > 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? > > > > > > 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. > > > > > > > > > Thanks, > > > Jacquie from Optus > > > > > > -- > > > RPKI mailing list > > > [email protected] > > > https://lists.nlnetlabs.nl/mailman/listinfo/rpki > > > > -- > > RPKI mailing list > > [email protected] > > https://lists.nlnetlabs.nl/mailman/listinfo/rpki > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > -- > > RPKI mailing list > > [email protected] > > https://lists.nlnetlabs.nl/mailman/listinfo/rpki > > -- Douglas Fernando Fischer Engº de Controle e Automação
-- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
