[RPKI] Potential for test/dev trust anchor?

[Tim Bruijnzeels]

Hi,

This may help:
https://github.com/NLnetLabs/secure-routing-stats <https://github.com/NLnetLabs/secure-routing-stats>

This is a small stand-alone (rust-based) tool that can combine ROAs (Validated ROA Payloads) from a routinator csv output, with RIS style aggregated BGP dumps and NRO stats for:
* global ROA quality stats
* invalids for address space X, Y, Z
* unseen (stale?) ROA VRPs for address space X,Y,Z

Tim

> On 25 Feb 2019, at 12:03, Job Snijders <job at ntt.net> wrote:
> 
> On Sun, Feb 24, 2019 at 07:59:09PM -0700, Andrew Gray wrote:
>> On 2/24/2019 7:19 PM, Jay Borkenhagen wrote:
>>> Andrew Gray writes:
>>>> [...] Could a dev/testing
>>>> trust anchor be set up by the community, and have a couple of the tier 1
>>>> providers provide feedback from that through one of the various looking
>>>> glass systems?
>>>> 
>>>> This would allow people to use that test trust anchor to verify they
>>>> have advertisements correct, things do what they want, etc., before then
>>>> pulling the advertisement over to whichever RIR is appropriate for
>>>> production work.
>>>> 
>>> 
>>> That sounds like a job for your RP software.
>>> 
>>> For example, RIPE's rpki-validator-3 allows its operator to configure
>>> whitelist entries.  After configuring a whitelist entry -- which is in
>>> essence a local ROA -- the RIPE software will show which current
>>> routes known to RIPE RIS would be validated or invalidated by the
>>> whitelist ROA.
>> 
>>> If that kind of 'what if?' analysis is important to you, you should
>>> tell your favorite RP project.  (For my money, it's OK to have this,
>>> but other RP features / capabilities are more important to me.)
>> 
>> This thought was based on some of the comments heard both at the RPKI
>> gathering and at NANOG afterwards - people are very leery of deploying ROA
>> objects at all for fear of what will happen because of those announcements.
>> Telling operators that "If you do nothing, the worst that will happen is
>> you're subject to prefix hijacks.  If you do deploy this and have it wrong,
>> you drop your company/ISP/what-have-you off the internet which is almost
>> certainly a Resume Generating Event" is an extremely hard sell for network
>> engineers to make to their management. Giving them more tools to validate
>> things are correct in a trivial to look at and for management to see format
>> would be valuable.
>> 
>> I guess the root thought is - how can this level of validation made as easy
>> and low-impacting as possible?  The desire is to have a great many people
>> sign their assignments - the fewer barriers/software needs/etc. in the way
>> the better.
> 
> I don't know if it is of any help, but I'm happy to do a one-off
> analysis of your proposed ROAs based on NTT BGP data. Just mail me in
> CSV format the prefix, maxlenght, origin asn(s).
> 
> Kind regards,
> 
> Job
> -- 
> RPKI mailing list
> RPKI at nlnetlabs.nl <mailto:RPKI at nlnetlabs.nl>
> https://www.nlnetlabs.nl/mailman/listinfo/rpki <https://www.nlnetlabs.nl/mailman/listinfo/rpki>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20190227/bac3ace9/attachment.htm>