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

[Gert Doering]

Hi,

On Wed, Dec 26, 2018 at 09:40:57PM +0800, Pyxis LX wrote:
> I'm not sure I agree with your opinion about SSH.
> IMHO if a KEX/MAC/Cipher algorithm that is generally considered insecure by
> the security community, it might not be a good idea to keep using it:)

This very much depends on what your focus is.  Mine is more "operational
stability" - and if unattended machine-to-machine communication breaks,
causing operational outage, because one side decides to upgrade their
SSH implementation and existing algorithms stop working, then I know what
my answer will be.

Like, when Fortinet upgraded their SSH backend in one of the minor releases,
not even mentioning it in the release notes and all of a sudden SSH-DSA
keys stopped working.  While the CLI still happily let us enter DSA keys,
they just did not work anymore, with no hint whatsoever anywhere.  Broke
quite a bit of our automatization system which was still using DSA keys
because *other* vendors couldn't be bothered to implement RSA keys in a
timely fashion...


> And please don't get me wrong, TCP-AO is totally fine with rpki-rtr since
> it provides integrity.
> Integrity provided by either SSHv2 tunnel or TLS, TCP-AO, ...etc. is
> mandatory when using external rpki-rtr servers or renting a pseudo leased
> line from other carriers that you might not have 100% trust.

Sure.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at greenie.muc.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20181226/9606e7c5/attachment.sig>