Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

[Gabriel Lopez <[e-mail]>]

Hi Paul,

> El 27 nov 2018, a las 14:34, Paul Wouters <[e-mail]> escribió:
> 
> On Tue, 27 Nov 2018, Gabriel Lopez wrote:
> 
>> 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 <[e-mail]> 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?
> 
> Hmm, I find "IKE-full" a bit odd (also because in English you would
> probably say "full-IKE" and not "IKE-full". Maybe another word could
> be "IKE-managed" or "IKE-controled" or "IKE-delegated” ?


Let’s use then IKE and IKE-less cases. Is that ok?

> 
>> [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.
> 
> works for me.
> 
>>        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. 
> 
> The case I can think of is if this is a "site to site" connection but
> one site is on dynamic IP (eg cable modem or 4g/5g connection) ?
> 
> The only difference in yang would be to instead of a static ip or
> hostname, to also allow a value of "any IP". In libreswan we use
> the string "%any" (and %any4 or %any6) but one could also use 0.0.0.0
> to mean that. I don't think it needs any other special handling (other
> then making sure an endpoint 0.0.0.0 should not use an IP based
> identity.

ok, that can be supported by the model without the necessity to include the specific road warrior scenario.


BTW, Fernando Pereñiguez is helping with the review. Our plan is to add him as author in the next version.

> 
> Paul

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: [phone]
Fax: [phone]
email: [e-mail]