BGP over TLS

[bjorn at mork.no (Bjørn Mork)]

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
signed certificate and be configured to trust the other.  A hash of the
peers public key would be sufficient for the BGP peer configuration.

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

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

> 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.

>> 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
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.

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,
then you'll probably want to use a CRL to withdraw specific certificates
instead of depending on a timeout.

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.


Bjørn