Christopher Morrow <morrowc.lists@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