Skip to content
This repository has been archived by the owner on Jul 15, 2021. It is now read-only.

Feature request: support for RTR over TLS and SSH #119

Open
racompton opened this issue Dec 3, 2019 · 7 comments
Open

Feature request: support for RTR over TLS and SSH #119

racompton opened this issue Dec 3, 2019 · 7 comments

Comments

@racompton
Copy link

I'd like to make a feature request for future versions of the rpki-rtr-server to support encryption using RTR over TLS or over SSH.

@lolepezy
Copy link
Contributor

lolepezy commented Dec 4, 2019

Hi Rich,

We will add it to our roadmap, but I cannot give promises about when it is going to happen. Also, is there's an RFC or any other non-vendor specific documentation about router's implementations of it?

@AlexanderBand
Copy link

AlexanderBand commented Dec 4, 2019

As far as I know nobody has a native implementation for TLS/SSH and support in routers is quite limited. Be that as it may, I think with the help of netcat and OpenSSH this solution could be applied to the RIPE NCC Validator as well: https://rpki.readthedocs.io/en/latest/routinator/daemon.html#secure-transports

@racompton
Copy link
Author

Hi Mikhail, I believe the RFC defining TLS transport of RTR is here: https://tools.ietf.org/html/rfc8210#section-9.2
I know that there are currently no routers that support TLS but I have made a feature request to Cisco, Juniper, and Nokia. It will probably take them a year or two to get this implemented.
Alexander, thanks for the information on how to tunnel the RTR protocol over SSH or over a TLS tunnel. That is an interesting hack but we would prefer TLS/SSH support in the validator solution itself if possible. There is a concern that a man-in-the-middle could modify the data in transit and change a valid to invalid or vice versa.

@AlexanderBand
Copy link

@racompton, the idea is that you run a validator inside your network, close to your router. This is why the transport has always been plain TCP and there haven't been any TCP/SSH implementations for this from the router vendors in the last 8 years. It could happen of course...

Where could the man-in-the-middle occur in your setup?

@racompton
Copy link
Author

@AlexanderBand I agree that there is a small chance of this happening on our own network but we "try" to implement encryption and/or authentication on all of our management/routing protocols. Our network goes across the US and travels through leased circuits/dark fiber/etc. that we are not in control of. There are a lot of nation-state attackers with a lot of resources focusing on large ISPs.

@AlexanderBand
Copy link

@racompton There's two components, 1) fetching and validating ROAs and 2) feeding routers with validated data over RTR. I could imagine you wouldn't want to do the first in every location, but instead transport the validated data securely across sites. There, a small RTR server/proxy could pick up the stream and feed it to your routers.

@racompton
Copy link
Author

@AlexanderBand thank you for the advice. I do plan on having 4 RTR servers spread across the US.

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

No branches or pull requests

3 participants