Tweet This: Tweet
Share on LinkedIn:
By Kevin Prater, Kovarus, Practice Manager Collaboration / Network Edge
A super useful feature of a lot of SD-WAN solutions out today is what’s being touted as Zero Touch Provisioning (ZTP). Being able to throw an edge device out at a remote location, where you may not have technical resources, just plug it and voilà, it is a wonderful thing. But how does it work? Is it secure? And what’s stopping the mailman from plugging my edge device into the internet and joining my SD-WAN fabric?
Let’s take a look at how Cisco addresses all this and more with Viptela SD-WAN solution and their approach to ZTP.
It’s probably important to take a moment here and define all the pieces and parts of the Cisco solution and what we will be focusing on in getting all of these components happy and talking with each other. First, let’s define the Cisco SD-WAN components in play:
- vBond — The vBond sits in the orchestration plane of the solution. It takes care of the authentication and authorization of a new device into the environment and keeps track of where all of the different components are.
- vManage — At the management plane we have vManage; this is your single pane of glass into what’s going on. This is where you perform all management tasks, access dashboards, take care of policy and template configurations, etc.
- vSmart — vSmarts are the brains of the solution. This is where the routing decisions are made, and where the policies, templates, etc. reside, that you’ve configured via vManage.
- vEdge — The edge devices live at your individual sites and terminate the VPN connections making your SD-WAN fabric. The vEdges get their configurations from the vSmarts and these are the devices we’re adding to the environment with ZTP.
Certificates play a significant role in an SD-WAN environment so with the components defined, we’ll now take a look at the relevant factors we’ll be concerned with when it comes to bringing new devices online, ensuring they’re supposed to be there and doing that as securely as possible.
We’re addressing four key areas:
- Authentication — The process of verifying or testing that the claimed identity is actually valid. This requires some sort of additional information, for instance a password or PIN.
- Integrity — This is the concept of protecting the reliability and correctness of the data; ensuring the contents of the original message are not tampered with between sender and recipient.
- Confidentiality — The goal here is to ensure that we keep the information private, secret, and intended only for the authorized recipient.
- Nonrepudiation — This is ensuring that the subject of an activity or event cannot deny that that activity occurred. For example, an authenticated user, Jethro, sends a message to Mr. Drysdale, nonrepudiation prevents Jethro from denying he sent the message.
Has Anyone Seen My Keys?
Keeping the above in mind, let’s shift gears a little now into how this relates to key exchanges, certificates, digital signatures and all that good stuff. Let’s start off with encryption. There are two different types of key exchanges, symmetric and asymmetric and we’ll be using them both.
Symmetric key encryption works by using the same key at both the ends of the transaction; whether you’re encrypting or decrypting it’s all happening with the same key, so that must be shared between sender and receiver. Some examples of symmetric key algorithms include AES-128, AES-192, and AES-256.
Computationally this is not very intensive, which means it’s got the advantage of being fast, but it does come with a downside: if the key is ever compromised, our wall of security starts to break down. We can’t guarantee integrity, confidentiality and ensure nonrepudiation if we have a compromised encryption key in the mix. So, if we want to leverage the speed of symmetric key encryption but mitigate the risks associated with sharing the key, we need a mechanism to do that sharing securely.
Enter asymmetric key encryption. Also known as public key encryption, this method uses a pair of keys, one public, one private to encrypt and decrypt the payload. These keys are mathematically linked to one another meaning anything encrypted with the public key can only be decrypted with the private key, and vice versa. Examples of asymmetric key algorithms include EIGamal, RSA, DDS, and Diffie-Hellman.
This method requires much more processing power to encrypt and decrypt and is therefore much, much slower than symmetric key encryption which makes it too cumbersome for encrypting large amounts of data. However, it’s perfectly suited to encrypt our symmetric keys so we can securely share those and ensure their integrity. The private keys are well, private, and never shared, right? Right. The public keys however are shared and we do that via a certificate, that’s where the certificates come into play.
So, to quickly recap this bit we’re leveraging both symmetric and asymmetric encryption methods within this solution. Asymmetric keys for the authentication piece and the sharing of the symmetric keys. And we’re using these symmetric keys to address the integrity and confidentiality piece because it is less processor intensive and is much faster in terms of encrypting large amounts of data.
In Part 2, we’ll cover how non-repudiation is addressed with digital signatures, where those come from, Tamper-Proof Modules (TPM) chips, how we ensure rogue edge devices are not allowed to join your SD-WAN fabric, and the ZTP process.
I’d love to chat more! Connect with me on Webex Teams! You can find me at firstname.lastname@example.org
Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.
Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.