Cisco’s distinguished Engineers, Dave Carrel and Brian Weis, recently released an IETF draft RFC titled ‘IPsec Key Exchange using a Controller’.
Here’s my attempt at translating the high level contents of this draft into plain English, and explaining how this relates to software defined networking and secure communications.
IPsec VPN reminder
Firstly, for a refresh on how IPsec VPNs are built using the Internet Key Exchange, see my previous blog: Deep Dive – a VPN journey.
Remember, the security of the IKE exchange is provided by Diffie-Hellman (DH), which is a method of negotiating a shared secret between two parties over an insecure medium. Both parties generate a DH public and private value. The public values are exchanged and each party uses the peer’s public value and its own private value to generate the shared secret
Securing large-scale communications
There are a number of ways to achieve this:
- Using NHRP coupled with GRE and IPsec – like FlexVPN or DMVPN. As you will see from my previous blog, DH is used to establish a shared secret between peers, the whole security of the peer-to-peer communications being reliant on the security of DH.
- Protecting data with IKE and IPsec is a very secure method and trusted by UK Government for use at OFFICIAL. A single key is used for encryption between two parties. If one of the parties needs to communicate with another peer, a separate shared secret is generated using DH for that peer-to-peer session.
There is also the concept of a controller based VPN.
Introducing SD-WAN
Firstly, what is SD-WAN? The following summary is taken from Wikipedia:
SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism.
In many examples of SD-WAN, the controller generates one or more secret keys and distributes these to group members for encrypting IPsec traffic. There are some security concerns with a controller generating and distributing key material.
In the case of a single group key, should a single group member be compromised or the key ever recovered, then any other peer-peer communications can be decrypted.
If each device has a key and the controller shares this with other group members that need to encrypt traffic to said device, any device in the group in possession of the key can decrypt such traffic.
For all instances, if the controller is compromised then any captured peer-to-peer communication can be decrypted.
The Great Idea!
The idea that David and Brian have devised overcomes the issue with the controller generating and distributing key material. Their idea uses DH and a controller – but the controller is responsible for distributing DH public values to other members that require communication to said device.
The controller does not generate key material itself. When a device wishes to communicate with another device, it receives the peer’s DH public value plus a random number called a nonce and sends its own DH public value and nonce to the peer via the controller. The peer’s DH public value is then mixed with the local DH private key and nonce and a shared secret is produced. This is exactly how IKE derives a shared secret between peers. The same shared secret is generated on both devices, which is then used to secure and device-device communication.
The following diagram illustrates this method:
The big security benefit of this approach is that the controller does not have the ability to view the DH private value and as such, cannot decrypt traffic between both peers. All peer-peer traffic is protected with pair-wise keys, keys that are local to both devices participating in the communication. Not even the controller has the ability to decrypt peer-peer traffic.
But … ‘what if’
At this stage, you might be thinking: ‘what if the controller inserts its own DH public value for a device, thus allowing itself to man-in-the-middle the session?’
I too thought the same, and that scenario is addressed in the draft. The public key can be cryptographically signed to allow the receiving device to verify the peers identity and DH public value, thus mitigating anyone from inserting their own DH public value.
I hope that you have enjoyed reading this and if you’re excited about securing the future of SD-WAN, visit our dedicated UKI SD-WAN webpage.
And find out more about our security solutions at cisco.co.uk/security
Authors
1 Comments
Interesting read my old Elburton friend. Any views on Identity-based firewalls, or identity based encryption for cloud computing?