Hi Paul, all Please find attached some answers to your comments. Let’s go section by section, it will be easier to follow the discussion.
> El 18 nov 2018, a las 7:52, Paul Wouters <[email protected]> escribió: > > > > > > General comments: > I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I > keep losing track of which case is which. > Perhaps call them IKE Case and IKE-less Case ? [Authors] We agree. What about "IKE-full" and "IKE-less" cases? > > > Section 1: > > Typically, traditional IPsec VPN concentrators and, in general, > entities (i.e. hosts or security gateways) supporting IKE/IPsec, must > be configured directly by the administrator. This makes the IPsec > security association (SA) management difficult and generates a lack > of flexibility, specially if the number of security policies and SAs > to handle is high. > > This is not entirely true. We have Opportunistic IPsec that automates > this precisely for the same reasons. We also have packet triggers in > combination with Traffic Selector narrowing to create multiple IPsec > SA's on demand. I know this is all qualified by "typically" but I think > this paragraph is not adding any real information. The idea is that we > have an SDWAN situation with SDN controllers and nodes, and we want to > automate the IKE/IPsec for that specific deployment use case. [Authors] Thanks for the suggestion. Certainly the text is not reflecting the existence of those techniques alleviating the task of establishing IPsec SAs. Nonetheless, we have to clarify that this draft is not only guided by the SDWAN scenario and, in fact, it is intended to be applicable in other foreseeable SDN deployments. With this in mind, we propose the following changes in the text: s/"Typically, traditional IPsec VPN concentrators and, in general, entities (i.e. hosts or security gateways) supporting IKE/IPsec, must be configured directly by the administrator. This makes the IPsec security association (SA) management difficult and generates a lack of flexibility, specially if the number of security policies and SAs to handle is high. With the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant. Thus, the SDN-based service described in this document will autonomously deal with IPsec SAs management." / "With the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant." s/"An example of usage can be the notion of Software Defined WAN (SD- WAN), SDN extension providing a software abstraction to create secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsec as underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services." / "An example of usage can be the notion of Software Defined WAN (SD- WAN), SDN extension providing a software abstraction to create secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsec as underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services. Other examples are host-to-host or full-mesh encryption. Thus, the SDN-based service described in this document will autonomously deal with IPsec SAs management. > > > The analysis of the host-to-gateway (roadwarrior) scenario is TBD. > > Does this sentence mean this is to be done in this document or is it out > of scope for this document (but it does allow it to be added later) ? [Authors] We do not see a clear use case for roadwarrior scenarios based on SDN, the proposal is to remove it from this document. Regards, Gabi. > > ----------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: [email protected]
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
