[RPKI] Potential for test/dev trust anchor?

[Andrew Gray]

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.

Thanks,
Andrew