-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPKI unreachables #1
Comments
First off... we are happy to take on feature requests for this project. It may be a while before we implement - but we are looking into allocating resources. Then to this point. The tool can already produce an output of invalid prefixes. Those announcements would be reject under strict enforcement. What the tool does not do is show whether invalid prefixes have a valid or unknown alternative. Consider an invalid 10.0.0.0/24 for AS65000, if there is a valid alternative 10.0.0.0/24 for AS65001 that prefix would still be reachable there. Or.. consider an invalid 10.0.0.0/24 for AS65000, if there is a valid, or even an unknown, announcement 10.0.0.0/23 for AS the addresses would still be reachable there. Highlighting alternate valid origins for each invalid this way is certainly possible, but is this what you are after? |
Oh and to nitpick your example, and clarify a bit more: If 10.0.0.0/23 is invalid then there has to be a ROA covering 10.0.0.0/23 for some ASN. Then 10.0.0.0/24 can only be valid or invalid - it cannot be unknown because it's covered by a ROA. But let's say you have: 10.0.0.0/23 AS65000 valid Then 10.0.0.1/24 is unreachable at AS65001, but the prefix is reachable as part of 10.0.0.0/23 at 65000. |
Thanks for your quick reply. I should have mentioned this link that does a better job than me at explaining what I'm looking for: https://nusenu.github.io/RPKI-Observatory/unreachable-networks.html |
Right, so I mentioned [“VALID” or “UNKNOWN” less-specifics] but not [multiple “VALID” more-specifics that cover the same IP address space] which is indeed a good addition. Technically we can add this, but we need to see when we can plan this. The link you provided already points at a service where you can see this. I don't mind duplicating some functionality here, and I don't expect that 'nusenu' would mind either, but why do you need it here? So we can understand the priority. |
My idea is to run those unreachable prefixes against our Analytics data, to be able to say "If we reject all RPKI invalids, X% of our users will be unable to reach our websites." track this number, know which AS# we should contact first, etc... |
Would it be possible to use secure_routing_stats to get the list of subnets/IPs that would be unreachable with a strict enforcement of RPKI?
Which means subnets with no more or less specifics prefixes (valid or unknown).
I'm using "subnet" as it can be part of prefixes.
For example if 10.0.0.0/23 is invalid, but 10.0.0.0/24 is unknown/valid.
Enforcing RPKI would make 10.0.1.0/24 unreachable.
This would be useful for us to use with our Analytics platform to estimate the impact of a "reject".
The text was updated successfully, but these errors were encountered: