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 protected]> escribió: > > [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] <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 >> <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 >> <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> > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
