This blog post from Moxie Marlinspike evoked a strong reaction from me because the challenges that he describes for a messaging protocol resonate with respect to moving network technology forward.
I thought about it. We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that’s how far the internet got. It got to the late 90s.
<Nodding my head>
On some level, federation is appealing precisely because it does freeze protocols in time. It’s great when centralized clients and servers roll out features that benefit us, but they could just as easily roll out features that don’t. Federation gives us more collective control over what changes we accept, but that comes with an unacceptable inability to adapt.
Any given data network is a federated system. That is, every device in the network must have the same protoocl and the only way to change or modify the current routing protocols
XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?
BGP has strongly similar problems as the protocol has been extended in dozens of directions (MPLS, VPLS, BGP EVPN, L2VPN just to name a few) and its becoming unlikely that any BGP instance will be able to support all of the possible features. This makes compatibility assertions, vertification/testing and feature deployment more difficult as time goes by.
One potential benefit of federation is the ability to choose what provider gets access to your meta-data.
Today, routing protocols effectively prevent meta-data from being adding to routes. While BGP does have the capability to attach meta-data through the use of extended attributes there is not enough agreement and consensus among the community what the meta-data should be. In the case of the Internet, the service providers like to believe that their routing policies are. For that matter, the IETF group responsible got BGP has refused to modernise the protocol by adding a well-defined API for manaing the BGP.
Even so, attaching meta-data to the BGP messages won’t solve the fundamental security risk of BGP hijacking (here is ChinaNet hijacking the BGP Routes for the DOD NIC on 20160510)
The EtherealMind View
I can’t shake the feeling that networking is stuck in a massive rut of its own making. The result of loosely coupled and federated devices is that change has become effectively impossible. We keep extending existing protocols and tools in quasi-random directions with the best of intentions but never changing anything.
What I realised from Moxie’s post is that the problem is universal. It would seem that the only solution is to build new protocols and get them adopted except that no one will adopt them while the current protocols work. Insecure, unsafe and unreliable BGP may be but no one is going to let it go.