[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]> 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
