BGP over TLS

Tue Oct 22 18:48:44 UTC 2019

On Tue, Oct 22, 2019 at 2:21 PM Bjørn Mork <bjorn at mork.no> wrote:
>
> Christopher Morrow <morrowc.lists at gmail.com> writes:
>
> > The x.509 system, to be effective here would require a TrustAnchor /
> > Root-of-Trust that both parties agreed was acceptable...
>
> As in a shared TrustAnchor?  No.  Both ends could use a simple self

as an option, sure. not a great one as you say. (and I agree, today's
'web pki' model just isn't sane for networking)

> signed certificate and be configured to trust the other.  A hash of the
> peers public key would be sufficient for the BGP peer configuration.
>

This is effectively the same as the md5 problem, right? and there'd
have to be a bunch of not-standard machinations in the tls connection
to support this behavior... never mind: "Was that E5S or E5s gosh..
can you send me this over IM please?" :) (passing around the
fingerprints is hard)

> Or you could use more complex PKI models, with a CA hierarchy or
> whatever.  The point is that TLS doesn't force you to do that
>

right, I think I said that in the next paragraph: "Hey, you could use psk..."

> Authenticating the peer by its public key hash is as simple as using an
> TCP-MD5 password.

err... is it though?
  'foobarbaz' is a long simpler than:
   SHA1 Fingerprint=A2:A8:74:E7:3C:20:49:E4:2D:5A:6E:97:EF:B2:65:C7:59:44:1A:6E

> > To get around that you propose we hopscotch over to 'TLS with
> > preshared keys (PSK)'...ok, that smells nice,
>
> Maybe.  Personally I don't see the point.

I think ... if we are working away from a static 'key' and to
something that could be machine managed in a secure fashion (certs,
for instance) we'd be in a better place for:
   bgp session security
   bgp session integrity
   bgp session authentication

> >> My personal major gripe with certificate based systems is that many
> >> routers don't have an RTC and won't know what time it is until they can
> >> NTP, which likely requires protocol adjacencies, and then a dependency loop.
> >
> > this is also a problem, but really ... your igp should get you to an
> > NTP source... or we'd all get to that fairly quickly, right? :)
> >   (some of this is updating 'best practices' in building / maintaining
> > a network, right?)
>
> You may ignore notAfter and notBegin like DANE does. The ntp issue is

I don't know what those fields are but:
notBefore=Oct  3 17:13:51 2019 GMT
notAfter=Dec 26 17:13:51 2019 GMT

maybe you mean these? sure, you CAN ignore those, but that's also
'non-standard, outside openssl-like behavior' so likely to cause
problems :(
and, you really do want certs with expiry that's 'short' so you don't
need to worry about CRL distribution and such. I think anyway.

> another reason.  But IMHO the most important one is that you don't want
> any sort of forced key rotation, where the configuration that was valid
> yesterday suddenly becomes invalid.  That's a policy designed for a
> completely different usecase than running a routing protocol.

there are  many examples of (outside x509/ssl) key management systems
that use date initiated keys though, on network devices.
most vendors support a key table for ISIS and OSPF... and LDP (I believe)

> You'll probably want to trust your configured pinned peer key for as
> long as it is part of your configuration.  And if you are using a CA,

that seems .. bad. What if someone gets the key material that's not your peer?
  https://arstechnica.com/information-technology/2019/10/hackers-steal-secret-crypto-keys-for-nordvpn-heres-what-we-know-so-far/

this doesnt' happen too often... wait, yes it does.
You want the ability to CRL or expire or make a lost cert less useful.
keys/certs/secrets that last forever are not a thing.

> then you'll probably want to use a CRL to withdraw specific certificates
> instead of depending on a timeout.

CRLs imply some external dependency, maybe that's ok depending on your
deployment, but I imagine that if we get to a world with a CA per
peer-as, there are going to be folk very busy getting CRLs and not so
busy getting routes done.

there's a tradeoff for each of these things, I imagine a well reasoned
paper (juilien?) and some standards (possibly) + implementer work
would be necessary to get true forward movement. (and desire to
actually do this work)

> And before someone claims that notAfter and notBegin validation is
> mandated by the RFC 5280 certificate policy - The good authors of RFC
> 5280 anticipated that their "Internet applications" policy wouldn't
> necessarily fit all:
>
>    Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate
>    revocation list (CRL).
>
>
> BTW, using TLS for management protocols is not completely unknown.  We
> already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably
> others I haven't touched yet.  The certificate management problem is
> pretty much the same for all these.  You have a closed group of
> clients/servers/peers using explicitly configured sessions.  You want
> both ends to authenticate each other.  You don't necessarily want an
> umbrella trust anchor in the form of a CA.  Defining trust per session
> is fine, using pinned certificates.

to each his/her own I suspect... on the 'use pinned certs' thing.

I am hoping we can imagine a better world and move there.