Dave, That would be great! Any suggestions to provide stronger protections are appreciated.
Thanks, Linda From: David Carrel (carrel) [mailto:[email protected]] Sent: Tuesday, July 17, 2018 1:20 PM To: Linda Dunbar <[email protected]>; Yoav Nir <[email protected]>; IPsecME WG <[email protected]> Cc: [email protected] Subject: Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF 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 protected]<mailto:[email protected]>> on behalf of Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Monday, July 16, 2018 at 11:17 PM To: Yoav Nir <[email protected]<mailto:[email protected]>>, IPsecME WG <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF 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
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
