Hi Yoav: Thank you for these comments and pointing out our work. We will have the opportunity to discuss in the meeting.
Nevertheless, since we are not sure if we will have time enough to discuss, let me send some initial comments inline. > El 18 jul 2017, a las 10:29, Yoav Nir <[email protected]> escribió: > > Hi. > > This may be of interest to this working group. > > The I2NSF working group is meeting this afternoon at 13:30 > > On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints > using SDN ([2]). > > I think this draft has two issues: > Their IKE-less case (case #2) has session keys generated on the controller > and forwarded to the IPsec endpoints. IMO this introduces new ways for the > keys to leak. [Rafa] Regarding this, the SDN controller is considered to be a trust party. In fact, the assumption is there is already a security association (think about NETCONF+SSL/SSH) with the NSF. > The information flow in the draft is all from the controller to the > endpoints. The controller is assumed to a-priori know the entire topology of > all endpoints. IMO this is not realistic for VPNs where often the addresses > are allocated by third party ISPs. [Rafa] Basically in a SDN model , the SDN controller needs to have a knowledge of the topology , specifically of those devices it configures. In fact, there is a secure registration process of the NSF with the controller previous to any management process. That is a basic in SDN landscape. > > I think any SDN or SDN-like solution for populating the SPD and PAD would > need to have information flowing from the endpoints to the controller about > the protected domain of that endpoint. Before that you can’t generate the > SPDs. [Rafa] I think you are missing the fact the administrator will send a general flow protection policy to the SDN controller using the northbound interface of the SDN controller. Based on that information the SDN will create the SPD and PAD entries. Thus, I do not see any problem on creating the SPDs based on that information coming from the administrator. > > OTOH this group failed in creating something like that in the AD-VPN work > item. Several companies are now offering their own “SD-WAN” solution that is > partly about automatic configuration of IPsec tunnels. [Rafa] That’s why we should think to standardize this. Best Regards. > > So in case you’re interested, you can come to the I2NSF meeting and hear > their presentation. > > > Yoav > > [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt > <https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt> > [2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 > <https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03> > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] -------------------------------------------------------
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
