[j-nsp] About Secure Transport for RPKI on JUNOS

Jared Mauch jared at puck.nether.net
Wed Dec 26 09:42:00 EST 2018



> On Dec 25, 2018, at 5:22 AM, Job Snijders <job at ntt.net> wrote:
> 
> On Tue, Dec 25, 2018 at 09:08:32AM +0100, Gert Doering wrote:
>> On Tue, Dec 25, 2018 at 02:46:57PM +0800, Pyxis LX wrote:
>>> I think SSHv2 or IPSec with good CLI integration would be nice.
>>> (ex: CLI to manage SSHv2 private keys, OSPFv3-like IPSec
>>> integration...etc.) TLS might be good but as Jared said, certificate
>>> revocation might not be that manageable.  However it's better than
>>> plain TCP anyway.
>> 
>> Careful what you wish for.  Adding heaps of crypto that all of a
>> sudden decides "oh, this certificate is expired" or "bah, this
>> algorithm is so insecure, we do not support this key exchange / mac /
>> cipher anymore!" adds quite a bit of brittleness...
>> 
>> So TCP-MD5 is actually nice because it has none of all that fanciness.
> 
> Already today Junos ships with an OpenSSH client (and server). I'm not
> too worried 'heaps of crypto' will be added if the SSH path is picked.
> 

The problem is with key management systems.  I’ve yet to see a router vendor do this well.  If we had to go the SSL route, I would need to rotate keys, certs and integrate into the corporate CA properly.  SSH transport is great until you have to update known_hosts on a thousand devices based on the nearest validator.

- Jared



More information about the juniper-nsp mailing list