[RPKI] Potential for test/dev trust anchor?

[Tim Bruijnzeels]

Hi all,

And to be clear... this is in the readme as well

You can of course feed it hypothetical data if you want to simulate and see the outcome - but you will need to stick to the format of the files, and use a value of 5 or higher for the number of peers that 'saw' the announcement. For invalids/unseens you do not need the NRO stats.

Tim


> On 27 Feb 2019, at 16:49, Tim Bruijnzeels <tim at nlnetlabs.nl> wrote:
> 
> 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 <mailto: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>
> -- 
> RPKI mailing list
> RPKI at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/rpki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20190228/81bc2290/attachment.htm>