adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
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. 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 kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On Mon, 17 Sep 2018 at 18:38, nusenu <nusenu-lists@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
Nusenu thank you for your thorough analysis. This is very useful information. Kind regards, Job
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@01D44E84.65DD2B70] And for the covering valid or not found prefixes we provide path analyses of various sorts. [cid:image002.png@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@nist.gov> on behalf of Job Snijders <job@ntt.net> Date: Monday, September 17, 2018 at 12:23 PM To: nusenu <nusenu-lists@riseup.net> Cc: rpki-monitor <rpki-monitor@nist.gov>, "nanog@nanog.org" <nanog@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@riseup.net<mailto:nusenu-lists@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
Doug,
Montgomery, Douglas wrote : 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.
Thanks for all the work. More visibility will help. I have made some private suggestions to how you could enhance the service, and I would add one : provide a BGP feed available to the public with invalid RPKI prefixes with a distinct BGP community describing why the prefix is invalid. We are in an impossible situation where ISPs don't want to discard invalid RPKI prefixes because they can't deal with the customer backshlash of doing it; nothing to gain, money to lose. Money wins. There is another side of this coin, though : you are a government employee. I pay you. As a taxpayer, I think the US governement should provide a better service to US companies with theRPKI collected data. Analysis without action is interesting, but not always federal funding. Best regards, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Michel, First, thanks for your continued support as a taxpayer. Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods and guidance to accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe. Of course what you describe would not be hard to do if some commercial or other organization wished to do so .... with the following caveats: 1. You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker which proposed standardizing an approach to doing what you suggest. Many on this thread think that it is a counterproductive idea to do this. See discussion starting here: https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA 2. There are some legal issues regarding the redistribution of machine readable RPKI data/results to third parties. See below section 5 Prohibited Conduct: https://www.arin.net/resources/rpki/rpa.pdf What we can do is continue to contribute to the development of standards, produce prototypes and test and measurement tools and publish deployment guidance to help foster adoption. For example see the follow draft publication: https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-rout... You mention other suggestions of how we can improve test and measurement services. We welcome all input on that. Maybe contact me off list and we can discuss the other ideas. Thanks, dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST On 9/17/18, 11:04 PM, "Michel Py" <michel.py@tsisemi.com> wrote: Doug, > Montgomery, Douglas wrote : > 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. Thanks for all the work. More visibility will help. I have made some private suggestions to how you could enhance the service, and I would add one : provide a BGP feed available to the public with invalid RPKI prefixes with a distinct BGP community describing why the prefix is invalid. We are in an impossible situation where ISPs don't want to discard invalid RPKI prefixes because they can't deal with the customer backshlash of doing it; nothing to gain, money to lose. Money wins. There is another side of this coin, though : you are a government employee. I pay you. As a taxpayer, I think the US governement should provide a better service to US companies with theRPKI collected data. Analysis without action is interesting, but not always federal funding. Best regards, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Doug,
Douglas Montgomery wrote : You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker which proposed standardizing an approach to doing what you suggest. Many on this thread think that it is a counterproductive idea to do this. See discussion starting here: https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA
I'm looking at adoption numbers, especially in the ARIN region. RPKI is practically inexistant, and some respected members are already saying it's a rathole. At 2% deployment, we are far away from the critical mass it needs. If the deployment strategy does not change, I don't see how that critical mass will happen. Until someone actually starts to discard invalid RPKI prefixes and assesses the actual inconvenience, this is not going anywhere. If you want to promote it, you have to do something not just analyze.
Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods and guidanceto accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe.
You provide critical time services, this would be nothing compared to it.
2. There are some legal issues regarding the redistribution of machine readable RPKI data/results to third parties. See below section 5 Prohibited Conduct: https://www.arin.net/resources/rpki/rpa.pdf
As always (and rightfully so) ARIN is trying to avoid legal liability. Better to remove the possibility of getting sued than having to deal with it. There are ways around that. My $0.02, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Michel, The GoRTR services that cloudflare speaks of below might be an example of an organization positioned to offer the kind of services you suggest. https://blog.cloudflare.com/rpki-details/ dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST On 9/18/18, 4:46 PM, "Michel Py" <michel.py@tsisemi.com> wrote: > Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods > and guidanceto accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe. You provide critical time services, this would be nothing compared to it.
Nusenu, I also found your analysis very interesting and useful. Thanks for that.
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 am also part of the NIST BGP team. Doug has already responded with information that we will soon have a new version of the NIST Monitor which will provide the kind of graphs that you requested. As an additional piece of info, I had given a presentation at IETF 101 in which you may find the data in slides 10-13 interesting: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin... It is a snapshot -- takes update data from Routeviews and validates routes using ROAs (see slides 10-13). Then it drills down on Invalid routes to see how many are covered by Valid (V) or NotFound (NF) less specific routes. Then further drills down to see if the origin AS (OAS) in the V/NF less specific route is the same or different compared to the OAS in the Invalid route. In many cases, the answer is yes - same OAS. We also found that when the answer was 'different OAS', then interestingly, in many instances the OAS in the V/NF less specific route was the transit provider of the OAS in the Invalid route! We (together with Job) have a draft in the IETF SIDROPS WG that specifies the details of DISR (Drop Invalid if Still Routable) policy: https://tools.ietf.org/html/draft-sriram-sidrops-drop-invalid-policy-01 DISR policy is basically what we are discussing here: Drop Invalid if a Valid or NotFound less specific route exists. When one designs implementable policy based on this, some nuances are important to consider. The draft and the slides attempt to do that. Sriram
Sriram, Kotikalapudi (Fed) (2018-09-18):> I also found your analysis very interesting and useful. Thanks for that.
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 am also part of the NIST BGP team. Doug has already responded with information that we will soon have a new version of the NIST Monitor which will provide the kind of graphs that you requested.
Can you share an estimate for when you plan to publish the new version of the NIST Monitor? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
participants (5)
-
Job Snijders -
Michel Py -
Montgomery, Douglas (Fed) -
nusenu -
Sriram, Kotikalapudi (Fed)