Skip to content
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

Open
XioNoX opened this issue Apr 11, 2019 · 5 comments
Open

RPKI unreachables #1

XioNoX opened this issue Apr 11, 2019 · 5 comments

Comments

@XioNoX
Copy link

XioNoX commented Apr 11, 2019

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".

@timbru
Copy link
Owner

timbru commented Apr 11, 2019

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?

@timbru
Copy link
Owner

timbru commented Apr 11, 2019

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
10.0.0.0/24 AS65001 valid
10.0.0.1/24 AS65001 invalid

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.

@XioNoX
Copy link
Author

XioNoX commented Apr 11, 2019

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

@timbru
Copy link
Owner

timbru commented Apr 11, 2019

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.

@XioNoX
Copy link
Author

XioNoX commented Apr 11, 2019

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants