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.
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.
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.
And for the covering valid or not found prefixes we provide path analyses of various sorts.
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.
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:
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:
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.
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!...
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:
2. There are some legal issues regarding the redistribution of machine readable RPKI data/results to third parties. See below section 5 Prohibited Conduct:
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.
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!...
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?
