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 protected]] 代表 Yoav Nir 发送时间: 2018年7月17日 12:44 收件人: Linda Dunbar <[email protected]> 抄送: IPsecME WG <[email protected]>; [email protected] 主题: Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF [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 protected]<mailto:[email protected]>> wrote: 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 protected]] On Behalf Of Yoav Nir Sent: Monday, July 16, 2018 3:11 PM To: IPsecME WG <[email protected]<mailto:[email protected]>> 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 <Sept 6 Interim minutes v1.pdf>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
