RPKI Validator 2.19; export ROAs as RPSL route: objects
Hello, We've been getting a lot of requests to make processed RPKI data easily available in existing (RPSL based) workflows. This is why we added the ability to export all ROAs as route: objects in the latest release, version 2.19. Practically, this means that running an RPSL export will give you almost 450,000 highly reliable, cryptographically validated route: objects. This functionality should be considered beta for now, because we would like to get your feedback on the notation and the way we de-aggregate ROAs into route: objects based on the specified maximum prefix length. The format looks like this: route: 193.0.12.0/23 origin: AS3333 descr: exported from ripe ncc validator mnt-by: NA created: 2015-05-07T10:01:56Z last-modified: 2015-05-07T10:01:56Z source: ROA-RIPE-NCC-RPKI-ROOT For details on the implementation, please refer to the README: https://github.com/RIPE-NCC/rpki-validator/blob/master/rpki-validator-app/RE... Here's a link to a snapshot I just made: https://alexband.nl/temp/export-20150512.rpsl.zip You can download the RPKI Validator here: https://ripe.net/certification/tools-and-resources We look forward to your feedback. Pull requests are welcome too. :) Cheers, Alex Band Product Manager RIPE NCC
On Tue, May 12, 2015 at 03:58:31PM +0200, Alex Band wrote:
We've been getting a lot of requests to make processed RPKI data easily available in existing (RPSL based) workflows. This is why we added the ability to export all ROAs as route: objects in the latest release, version 2.19. Practically, this means that running an RPSL export will give you almost 450,000 highly reliable, cryptographically validated route: objects.
This functionality should be considered beta for now, because we would like to get your feedback on the notation and the way we de-aggregate ROAs into route: objects based on the specified maximum prefix length.
Interesting! I was considering writing a script to do this, but the NCC beat me to it! :-)
The format looks like this:
route: 193.0.12.0/23 origin: AS3333 descr: exported from ripe ncc validator mnt-by: NA created: 2015-05-07T10:01:56Z last-modified: 2015-05-07T10:01:56Z source: ROA-RIPE-NCC-RPKI-ROOT
Wouldn't it make sense to align the "created:" date with something more specific to the ROA rather then the export date? Another consideration might be to create a "expiry-date:" derived from the ROA's expiry date for easy debugging purposes. Adding a new attribute should not have adverse effects on the generation of prefix-filters in the toolchains I am familiar with. Kind regards, Job
On 13 May 2015, at 11:42, Job Snijders <job@instituut.net> wrote:
On Tue, May 12, 2015 at 03:58:31PM +0200, Alex Band wrote:
We've been getting a lot of requests to make processed RPKI data easily available in existing (RPSL based) workflows. This is why we added the ability to export all ROAs as route: objects in the latest release, version 2.19. Practically, this means that running an RPSL export will give you almost 450,000 highly reliable, cryptographically validated route: objects.
This functionality should be considered beta for now, because we would like to get your feedback on the notation and the way we de-aggregate ROAs into route: objects based on the specified maximum prefix length.
Interesting! I was considering writing a script to do this, but the NCC beat me to it! :-)
The format looks like this:
route: 193.0.12.0/23 origin: AS3333 descr: exported from ripe ncc validator mnt-by: NA created: 2015-05-07T10:01:56Z last-modified: 2015-05-07T10:01:56Z source: ROA-RIPE-NCC-RPKI-ROOT
Wouldn't it make sense to align the "created:" date with something more specific to the ROA rather then the export date?
sure
Another consideration might be to create a "expiry-date:" derived from the ROA's expiry date for easy debugging purposes. Adding a new attribute should not have adverse effects on the generation of prefix-filters in the toolchains I am familiar with.
It would require a bit more work but along that thought we could sure do something like this: created & last-modified: signing time of the ROA embedded certificate (it cannot be modified without re-signing) expiry-date: expiry date of the ROA embedded certificate last-validated: date and time of validation We haven't done anything like this yet, because we wanted to be sure that there is operational value for having this first. So please let us know! Kind regards, Tim
Kind regards,
Job
participants (3)
-
Alex Band -
Job Snijders -
Tim Bruijnzeels