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

[Chris Morrow]

At Thu, 27 Dec 2018 11:57:54 +0100,
Bjørn Mork <bjorn at mork.no> wrote:
> 
> Chris Morrow <morrowc at ops-netman.net> writes:
> 
> > tls brings with it cert issues.
> 
> Well.  How bad does it have to be?  Yes, you have to manage private
> keys. That's the same for TCP-AO, SSH and TLS. Or any other transport
> security protocol. No real difference.

you have to at least manage private keys, plus you need to
monitor/manage certificates on the devices, and rotate them over time.
you probably do NOT want to just place a ~forever certificate on your
device(s) and you probably want some unique identification per
device/certificate. you probably want CRL checking as well... and you
need to operate a CA in a semi-secure fashion.

you must be able to revoke certs, check client/server certificate
details upon connection(s) and log out appropriate details so
debugging connection problems is a reasonably quick effort.

the devices must have a reasonable method to manage the actual
cert/key content, with a reasonable method to refresh the
certificate/key in use by the services on the device(s). There is some
work in this area happening on most vendor gear I follow due to the
push(ing) to use gRPC for streaming telemetry (instead of snmp) and
gRPC for config management. (grpc is the new netmod is the new xml is
the new .....) The certificate management MAY only work for the 'gRPC'
part of the device/os though :( Looking at one particular vendor (not
juniper) the 'which certificate/key to use' is very 'service' specific
:( without any real mapping (except an uploaded bash script??? wtf?)
of which cert/key to which service(s). it's pretty depressing to watch
the myopic vendor process on this :(

you must keep time sync'd reasonably closely as well.

> I assume the perceived issue with TLS is that private keys have short
> life spans?  But they don't have to in a RPKI setup.  You will want to

no, you want short lifespans, think of a typical lifespan on the order
of 'days'... like less than 7 days in some cases, and perhaps shorter
depending upon which jurisdiction the device lands in.

> manage the CA(s) yourself, and can implement the policies you need. If
> you want keys with "infinite" life spans, then that's possible. The

infinite is.. infinitely naive. please do not do infinite certificate
lifetimes.

> servers validating router certificates can easily check revoked keys,
> using a simple CRL or whatever. So you can issue a certificate to your
> router and just forget about ever updating it, just like you do with all
> your other passwords ;-)

uhm, no. this is perhaps the worst advice evar. Are you also just
injecting your igp into your egp? :)

> The only difference is that there is a way to actually withdraw that
> password.
> 
> TLS is nice. Don't be fooled by all the lousy infrastructure
> implementations.  Certificate management does not have to suck.

agreed, it doesn't... except that basically all implementations for
network gear are sucky (today) and bespoke. hurray, job security? :(

> And there is no reason to believe that TCP-AO key management will suck
> less - until we've seen it implemented.

oh I agree about this... wait there's karp! (https://tools.ietf.org/wg/karp/)
ha, just kidding that ended up as a pile of fail :(

There are key management schemes to be cribbed from in other network
device management things, particularly I think the ISIS/ospf in
particular. I think both juniper/cisco offer 'key tables' as options
there with timed swap from key to key. That's not an unreasonable
option, except managing AO (in the case of BGP) means potentially
managing quite the matrix of neigh/keys/times... and coordinating with
your peers could get entertaining :( It would be better than 'I set my
md5 key to "chocolate" (no quotes) in 1996.. we're still good with
that, right?' :)

For rpki-rtr you should have a smaller matrix of things you actually
control though (2-3 cache's per device with 2-3 keys 'last, current,
next')

-chris