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