[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