Subject: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio

From: Linda Dunbar <[email-masked]>
Date: Thu, 20 Apr 2017 21:40:26 +0000

Yoav, 

You said that it is a bad idea to have "sharing key among multiple points" as introduced by draft-abad-i2nsf-sdn-ipsec-flow-protection. 

Isn't the "Group Encryption Key" of having a "Key Server" distributing the key to multiple members doing the same? http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf

Linda

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 

>> - I2NSF has a proposal on using Controller to manager all the IPSec
>> tunnels:
>> https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection.
>> What kind of issues do you see with the proposed approach?
> 
> I didn't read it.

I did. They have two cases. In case #1 the controller provisions credentials for IKE and entries in PAD and SPD. In case #2 you forego IKE and have the controller provision the SAs (including keys).

I especially didn’t like case #2. Sharing a secret key among three entities is a bad idea. A shared authentication credential can also be misused, but that’s a hard attack to mount. A shared traffic key makes the controller a very attractive target.

More in general, SDN was born in the data center. In a data center an all-knowing controller makes sense. This is true for routing as it is for NSFs such as firewalls, IDPs and IDSs. VPN extends the reach of the private network to all corners of the Internet. Think of a store chain with a CPE in every one of thousands of branches. Or a bank. The problem there is that there is no central administrative function. Local branches may switch ISP and renumber their network without bothering to tell the IT people. So the model where the controller knows everything is tough to deploy in practice.

It is probably necessary to have two-way communications, where the CPE tells the controller about its topology (how it partitions the Internet to “in” vs “out”) so that the controller can set up the appropriate SPDs.

There have been several attempts at this. RFC 7018 describes requirements, but the WG ultimately failed to publish a solution document.  There are also more recent commercial solutions sold today under the marketing name of “SD-WAN”, which is sort of like SDN if you squint hard enough. All of these have some interaction between CPE and controllers (or hubs) which draft-abad does not.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Fri, 21 Apr 2017 01:18:34 +0300

Hi, Linda

> On 21 Apr 2017, at 0:40, Linda Dunbar <[email-masked]> wrote:
> 
> Yoav,
> 
> Isn't the "Group Encryption Key" of having a "Key Server" distributing the key to multiple members doing the same? http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf <http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf>

Just because Cisco do it doesn’t mean that it’s not a bad idea.  :-)

GETVPN is based on GDOI (RFC 6407). GDOI is about extending IPsec to multicast communications, where in a group of nodes a node encrypts a multicast IPsec packet and sends it to all group members who in turn decrypt it.  For group communications sharing a key is inevitable.

GETVPN extends the key server back to regular unicast IPsec. It trades the security and robustness of pair-wise key exchange for the operational convenience of using a single traffic key for the entire configuration.In return for everyone using the same key, they eliminate the need for each node to be configured with the IP address and protected domain of every other node.

Any SDN or SDN-like solution does not need to eliminate configuration as that can be done dynamically by the controller. I don’t think the trade-off that was necessary for GDOI and convenient for GETVPN has many advantages for VPN with SDN.

Yoav

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Apr 2017 19:49:23 +0000

Yoav,

Thank you very much for the detailed explanation.

Just out of curiosity, what kind of “security and robustness of pair-wise key exchange” are lost by using a single traffic key for multiple end points?

Even with SDN approach, as being proposed by the draft-abad-i2nsf-sdn-ipsec-flow-protection-01, some end points (i.e. branch CPEs) may not have enough resource to manage large number of security associations with many other end points (as in many SD-WAN branch to branch direct tunnels use case).

Linda

From: Yoav Nir [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 5:19 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio

Hi, Linda

On 21 Apr 2017, at 0:40, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Yoav,

Yoav