Subject: [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

From: Linda Dunbar <[email-masked]>
Date: Tue, 17 Jul 2018 03:16:54 +0000

There are two cases proposed by  SDN controlled IPsec Flow Protection:

-        Case 1 is SDN controller only sending down the IPsec configuration attributes to End points, and End Points supports the IKEs and SA maintenance.

-        Case 2 is end points not supporting IKEv2. SDN controller manage all the SA Key computation and distribute to all end nodes. We had an interim meeting discussing this. (see the attached Meeting minutes).

Question to IPsecme WG: How about something in between?

-        Assume that SDN controller maintain TLS (or DTLS) to all end points for distributing the IPsec configuration attributes (same as Case 1 above).

-        Instead of using IKEv2 for two end points (E1 & E2) to establish secure channel first for SA negotiation purpose, E1 can utilize the secure channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and responsible for its own SA computation.

-        E1&E2 still compute SA and maintain SAD. Only utilize the secure channel through the SDN controller to exchange SA.

This method not only doesn’t require the SDN controller to keep all the SAD for all nodes, but also simplify large SD-WAN deployment with large number of IPsec tunnels among many end points.

Any opinion? Issues?

Linda Dunbar

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, July 16, 2018 3:11 PM
To: IPsecME WG <[email-masked]>
Subject: [IPsec] IPsec Flow Protection @I2NSF

Hi.

I’d like to draw you attention to the agenda of the I2NSF working group: https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00

The I2NSF working group will meet on Wednesday after lunch. On the agenda, there is this item which may be of interest to IPsec folks:

13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
In case you haven’t been following, the IPsec flow draft was adopted by I2NSF. The authors are making progress, including open source implementations.

One issue that may come up in the discussion (either at I2NSF or here) is that other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming up. I’m wondering if these are competing, complementary, or what?

We’ll be glad to see you all there.

Yoav
(co-chair of I2NSF)

[1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00
[2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Jul 2018 07:43:49 +0300

[no hats]

I’m not convinced by the necessity of either this or “Case 2”.  

IKEv2 is supported by all operating systems, including every Linux distribution and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. Given that, I’m not convinced we need to take care of nodes that do not support IKEv2. There just aren’t any such nodes in the NSF world. If we were talking about smart objects, then we could find such nodes, but not NSFs.

IKE performs two functions:
Authenticate the peers to one another
Exchange keys.

If I understand your proposal correctly, you would like to keep the peers exchanging keys (although not directly), but not authenticating. This kind of makes sense because the SDN controls identities and credentials. There is no meaningful authentication except to verify the credentials provided to the peer by the controller.

So I think the proposal makes sense, but I don’t see it as necessary.

Yoav
(again, no hats)

> On 17 Jul 2018, at 6:16, Linda Dunbar <[email-masked]> wrote:
> 
>   <>
> From: IPsec [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yoav Nir
> To: IPsecME WG <[email-masked] <mailto:[email-masked]>>
> I’d like to draw you attention to the agenda of the I2NSF working group: https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 <https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00>
>  
> [1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 <https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00>
> [2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 <https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02>
>  
> <Sept 6 Interim minutes v1.pdf>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 17 Jul 2018 10:38:26 +0200

Hi Yoav:

In my opinion, if the E1 and E2 will finally communicate through the controller to run a key management protocol, then I do not see the benefits instead of using case 1, that is IKEv2. 

Regarding case 2. It follows a SDN model: control plane and data plane. Data plane the IPsec stack is the data plane, which deals with flows; control plane is implemented in the SDN controller. NSF are simpler. One of the key points here is that key material is seen by the SDN controller (which, we should not forget, it is a trusted entity). In this sense, for example, draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH public/private keys trying to avoid this. Other options could be also considered.

Regarding the question about smart objects, I do not understand why a constrained device cannot be a flow-based NSF.  

Best Regards. 

> El 17 jul 2018, a las 6:43, Yoav Nir <[email-masked]> escribió:
> 
> [no hats]
> 
>> On 17 Jul 2018, at 6:16, Linda Dunbar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Jul 2018 18:44:03 +0300

Linda Dunbar writes:
> - Case 1 is SDN controller only sending down the IPsec configuration
> attributes to End points, and End Points supports the IKEs and SA
> maintenance.
> 
> - Case 2 is end points not supporting IKEv2. SDN controller manage
> all the SA Key computation and distribute to all end nodes. We had
> an interim meeting discussing this. (see the attached Meeting
> minutes).
> 
> - Assume that SDN controller maintain TLS (or DTLS) to all end
> points for distributing the IPsec configuration attributes (same as
> Case 1 above).
> 
> - Instead of using IKEv2 for two end points (E1 & E2) to establish
> secure channel first for SA negotiation purpose, E1 can utilize the
> secure channel between E1 <-> SDN-Controller <-> E2 to negotiate SA
> with E2 and responsible for its own SA computation.
> 
> - E1&E2 still compute SA and maintain SAD. Only utilize the secure
> channel through the SDN controller to exchange SA.
> 
> This method not only doesn’t require the SDN controller to keep all
> the SAD for all nodes, but also simplify large SD-WAN deployment
> with large number of IPsec tunnels among many end points.

There is lots of TLA who would like that kind of setup, including some
goverments, as this would allow very easy way to keep track of all
traffic keys, as they are always transmitted through the SDN
controller, so there is no need to hack..., I mean install trusted 3rd
party key backup software to every single node.

I think this has exactly same bad properties than case 2 has, i.e., it
will provide traffic keys in one centralized location where they are
convinently available for those who will need them, without any
co-operation from the actual nodes sending or receiving traffic, and
it does not solve the issue of providing the ways to do proper key
management parts that IKEv2 also does. 

If the nodes are doing Diffie-Hellman through the SDN controller, then
I do not see any benefit from the case 1, I mean then you still have
all the calculations to be done, so why not run full IKEv2 instead and
that will also solve all other management issues we have talked before
(rekeying, deleting SAs, negotiation per flow SAs, NAT detection and
NAT-T, etc).
-- 
[email-masked]

---

From: "David Carrel (carrel)" <[email-masked]>
Date: Tue, 17 Jul 2018 18:19:48 +0000

Linda,

Brian and I put together a draft to address the Case #2 with stronger protections for key security.  We will be presenting this in the IPSEME meeting.  The highlights of the draft are that it uses Diffie-Hellman to ensure that all keys are only known to the end nodes and while the controller conveys all messaging to the end nodes, it does NOT ever see the keys.  The devilish details are in how synchronization is achieved when large numbers of end nodes re-key.  Our draft is written as an embeddable method suitable for inclusion in I2NSF drafts and others.

I would be happy to speak to this in I2NSF as well if you like.

Dave

From: I2nsf <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Monday, July 16, 2018 at 11:17 PM
To: Yoav Nir <[email-masked]>, IPsecME WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

Any opinion? Issues?

Linda Dunbar

Hi.

Yoav
(co-chair of I2NSF)

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 17 Jul 2018 18:29:13 +0000

Dave,

That would be great! Any suggestions to provide stronger protections are appreciated.

Thanks, Linda

From: David Carrel (carrel) [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 1:20 PM
To: Linda Dunbar <[email-masked]>; Yoav Nir <[email-masked]>; IPsecME WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

Linda,

Dave

From: I2nsf <[email-masked]<mailto:[email-masked]>> on behalf of Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 16, 2018 at 11:17 PM
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>, IPsecME WG <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

Any opinion? Issues?

Linda Dunbar

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, July 16, 2018 3:11 PM
To: IPsecME WG <[email-masked]<mailto:[email-masked]>>
Subject: [IPsec] IPsec Flow Protection @I2NSF

Hi.

Yoav
(co-chair of I2NSF)

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Tue, 17 Jul 2018 21:11:37 +0000

Hi all,
I don’t have the clear observation of how popular the IKEv2 is supported by most of the OS, my straight thought is something without IKEv2 for simplicity, light weight implementation and cost saving has its feasibility now and in the future.

The other point we should consider is the performance improvement by skipping the IKEv2 negotiation and DH calculation. Take a large scale network as the example, it will take a long time for multiple peers to set up the SAs with one peer by IKEv2 and DH key exchange, since one peer has the cpu/memory up-limit to constrain the maximal number of IKEv2 sessions at the same time. But, by replacing the IKEv2 and DH with the key calculation (by peer itself, or by controller) and key distribution (through the controller), the total time for creating SAs among a large number of peers can be decreased dramatically and keep under certain time.

Of course, the SDN-based IPSec SAs management solution should be based on the basic assumption that the controller and the management plane links are all well protected.

The SA session key can be calculated by the controller and distributed to every peers in a communication group, or can be calculated by the peer itself and distributed to the required peers through the controller, or can be DH exchanged through controller. All the three ways have their respective pros and cons. More study and discussion will be helpful.

Finally, I believe we do need a new way (e.g., the sdn-based way) to deal with the IPSec SAs management, especially for the large number of IPSec SAs. And we already have good progress on the right direction.

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 Yoav Nir
发送时间: 2018年7月17日 12:44
收件人: Linda Dunbar <[email-masked]>
抄送: IPsecME WG <[email-masked]>; [email-masked]
主题: Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

[no hats]

  *   Authenticate the peers to one another
  *   Exchange keys.

Yoav
(again, no hats)

On 17 Jul 2018, at 6:16, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Any opinion? Issues?

Linda Dunbar

Hi.

Yoav
(co-chair of I2NSF)

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jul 2018 01:43:21 +0300

Xialiang (Frank, Network Integration Technology Research Dept) writes:
> The other point we should consider is the performance improvement by
> skipping the IKEv2 negotiation and DH calculation. Take a large
> scale network as the example, it will take a long time for multiple
> peers to set up the SAs with one peer by IKEv2 and DH key exchange,
> since one peer has the cpu/memory up-limit to constrain the maximal
> number of IKEv2 sessions at the same time. But, by replacing the
> IKEv2 and DH with the key calculation (by peer itself, or by
> controller) and key distribution (through the controller), the total
> time for creating SAs among a large number of peers can be decreased
> dramatically and keep under certain time.

How about update your machines so they are using CPUs made in last
decade or something. My home firewall can do 200 Diffie-Hellman
calculations in second (using MODP-2048 which is the current
recommended size), so doing 10000 Diffie-Hellman operations will take
less than minute. My firewall is 3 years old, with CPU that is 5 years
old (came out Q2 of 2013 Intel Xeon E3-1225v3 3.2GHz), and this test
was only using single core out of the 4 it has.

Yes, if you have more than connections than that, then it is even more
important to use IKEv2, as you do not want to create all of them at
startup, but instead create them dynamically when you need them, i.e.
create SA when you are trying to send first packet to it. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Jul 2018 02:42:06 +0300

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez <[email-masked]> wrote:

<snip/>

> Regarding the question about smart objects, I do not understand why a constrained device cannot be a flow-based NSF.  

I don’t think IOT devices are going to be NSFs.  There is no hard definition for what a smart object is, but some common features are:
 - low power
 - intermittent operation
 - (relatively) weak in terms of CPU / memory /  network bandwidth. Often this is measured in tens of kilobytes of memory and 100/250 kbps.
 - interacts with the real world - has sensors and/or actuators

So none of this says NSF to me, especially the bandwidth.

Which is why I believe that any device that is actually used as an NSF implementing IPsec is also likely to have enough power to run IKE.

> Regarding case 2. It follows a SDN model: control plane and data plane. Data plane the IPsec stack is the data plane, which deals with flows; control plane is implemented in the SDN controller. NSF…

It is true that the SDN controller is a trusted entity. We still prefer to limit the attack surface by not giving it access to traffic keys. There is no doubt that a malicious controller can make the NSFs tunnel all traffic through a pervasive monitoring server. We have to trust it not to do that. What we can prevent is having it leak the traffic keys through printing them to logs, crashing and storing them in core files, swapping them from memory to disk and all the other ways that applications leak sensitive information.  That’s just not good key hygiene.

That said, a simpler NSF is an NSF that needs less maintenance, less software updates, less angst over random-number generators that turn out to be not random enough. It’s possible that there is a use case for your case #2 or draft-carrel’s modification.  It would be interesting if someone has market data about whether people would like to deploy such configurations. 

Unfortunately, the slot this work has in I2NSF is not long enough to hash this out.