[proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

Mon Sep 17 16:46:06 UTC 2018

Job,

Thanks for the input, we have a new version of our RPKI monitor that we are in the process of moving from development systems to publicly accessible servers.

The new monitor has significant additions in the areas of diagnostics, and highlights issues of interest such as path / customer cone analysis of prefixes that cover invalid originations.

We break down basic coverage stats – i.e., what is still routable assuming drop invalid policy.
[cid:image001.png at 01D44E84.65DD2B70]

And for the covering valid or not found prefixes we provide path analyses of various sorts.

[cid:image002.png at 01D44E84.65DD2B70]

Other new diagnostics will map changes in origin validation state to specific changes in RPKI data – i.e., answering the question what changed? And why?

I will send a link when we get things moved to a public facing server.

dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST

From: <proj-bgp-bounces at nist.gov> on behalf of Job Snijders <job at ntt.net>
Date: Monday, September 17, 2018 at 12:23 PM
To: nusenu <nusenu-lists at riseup.net>
Cc: rpki-monitor <rpki-monitor at nist.gov>, "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

On Mon, 17 Sep 2018 at 18:38, nusenu <nusenu-lists at riseup.net<mailto:nusenu-lists at riseup.net>> wrote:
Dear NIST RPKI Monitor Team,

thanks for creating and maintaining the RPKI Monitor
https://rpki-monitor.antd.nist.gov/#rpki_adopters
I've seen your graphs in multiple routing security presentations :)

What do you think about adding graphs that show the amount of actually
unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists)

I think such graphs would help us focus on those prefixes that we should have to tackle first.

Agreed. Increased visibility will help all of us. Tracking this data over time would be a beneficial tool.

This page contains examples of INVALID prefixes that would still be reachable in a route origin validating
environment (see the RPKI validator screenshots):
https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40nusenu%2Ftowards-cleaning-up-rpki-invalids-d69b03ab8a8c&data=02%7C01%7Cdougm%40nist.gov%7C15700d56cd4f48295c3008d61cb9f575%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636727982349234348&sdata=kkqQfAKKqNdEOTR7Sh%2BJQIUQTnOonBb8xZleTi7gWUg%3D&reserved=0>

Nusenu thank you for your thorough analysis. This is very useful information.

Kind regards,

Job
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20180917/24f0a138/attachment.html>