search

RIPE-NCC / rpki-validator-3

RIPE NCC RPKI Validator 3
Other
62 stars 27 forks source link

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

Open racompton opened 4 years ago

racompton commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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