Hi, Valery Obviously, you need a security controller that scales to the number of SAs it needs to generate. But generating an SA in the IKE-less case is just generating 72 random bytes (for AES-GCM-256) and packaging them. I don’t think with a properly scaled SC this would produce more latency than IKE between the nodes, which has 1/2 round-trips and requires asymmetric operations.
> On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Rafa, > > sure this problem is general for any SDN solution. > My point was that if SC performs a lot of real-time > (or near real-time) tasks as it may happen in IKE-less case, > then this problem may become serious. > > Anyway, I'm happy with the updated text, thank you. > However, in a following document(s), suggested by Yoav, > I'd like to see more concrete advices of how SC should > act in this situation to ensure that the consistence of the > network is preserved despite all the possible delays etc. > > Regards, > Valery. > > > From: Rafa Marin Lopez <r...@um.es> > Sent: Monday, July 22, 2019 6:11 PM > To: Valery Smyslov <smyslov.i...@gmail.com> > Cc: Rafa Marin Lopez <r...@um.es>; Yoav Nir <ynir.i...@gmail.com>; > i2nsf@ietf.org; ip...@ietf.org; Fernando Pereñíguez García > <fernando.perenig...@cud.upct.es>; m...@tail-f.com; Gabriel Lopez > <gab...@um.es> > Subject: Re: [I2nsf] I-D Action: > draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt > > Hi Valery: > > Thank you very much for your comments. Please see ours inside. >> El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.i...@gmail.com >> <mailto:smyslov.i...@gmail.com>> escribió: >> >> Hi, >> >> thank you for updating the document. I still think that some aspect >> of IKE-less use case are not discussed yet (well, probably they are not >> "serious", depending on one's definition of "serious"). >> >> Unlike IKE case. which we can consider as mostly static configuration, >> the IKE-less case is a dynamic one. If IPsec SA are being created >> on demand (via kernel-acquire) and the traffic volume is high, >> then depending on the IPsec policy IKE-less case can become >> a highly dynamic, which implies additional requirement on both >> the network connecting SC and NSF and the performance of the protocol used >> to >> secure their communications. In other words, in IKE case the communication >> between IKE daemon and kernel is seamless, while in IKE-less >> case the communication between NSF ("kernel") and SC adds >> noticeable delay (and can potentially add quite a long delay), >> which can influence total performance of the system. >> >> Generally IKE-less case requires more communications between >> different nodes to establish or rekey IPsec SA, than IKE case >> (I assume that IKE SA is already established), that may have >> an impact on high-speed networks with short-lived IPsec SAs, >> especially if they are created per transport connection >> (say one IPsec SA for one TCP session). > > [Authors] What you have just described is what happens in any SDN-based > network. In fact, your comment would be applicable to practically any > scenario based on the SDN paradigm. In the particular case of the I-D, the > IKE-less case is the most similar to case you can see in, for example, > Openflow networks where latency is also important (just as an example : > https://ieeexplore.ieee.org/document/6573052 > <https://ieeexplore.ieee.org/document/6573052> ) > > >> >> I believe, that SC's task of managing IPsec SAs in IKE-less case >> may become quite complex, especially because due to the >> additional delay, introduced by the network, the picture of the >> state of the SAs the SC has can become inaccurate (well, >> it will always be inaccurate, but with short delays it doesn't matter). >> Just an example. Consider an SC receives a signal from NSF that an SA >> is soft expired and starts rekeying process by first installing a new >> pair of inbound SAs. It successfully installs them on the NSF >> it receives notification from, but then it receives a notification >> that the other NSF has rebooted, so it must clear all the SAs on >> its peers, including the just installed new one (which is only >> half-done). There seems to be a lot of nuances, and the document >> completely ignores them. Not that I think that the task >> is impossible, but the algorithm of managing the SAs can become >> quite complex and possibly unreliable. > > [Authors] We largely thought about this kind of cases, although we do not see > any different that may happen in SDN-based network nowadays. And it seems to > me that SDN is becoming something generally accepted despite the different > nuances that needs to be consider. In any case, what you mention is not > ignored in our document because it is included in the text we have in section > 5.3 (see below) where we highlight the complexity is shifted to the SC > (that’s clear). But as I mentioned, this is not specific to IKE-less case but > for any solution based on the pure SDN paradigm (such as Openflow networks). > In other words, the cases you well mention are applicable to any SDN-based > solution. > > >> >> I didn't find this discussion in the draft (sorry if I missed it). > > Your comments are somehow summarized in the following text section 5.3 > > "On the contrary, the overload of creating fresh IPsec > SAs is shifted to the Security Controller since IKEv2 is not in the > NSF. As a consequence, this may result in a more complex > implementation in the controller side. This overload may create some > scalability issues when the number of NSFs is high. > > In general, literature around SDN-based network management using a > centralized Security Controller is aware about scalability issues and > solutions have been already provided (e.g. hierarchical Security > Controllers; having multiple replicated Security Controllers, etc)." > > I would add that a high-speed dedicated management network between the SC and > the NSFs can be also in place to even limit reduce these delays between the > SC and NSFs (this idea comes again from Openflow networks). Also the SC can > select more “intelligent” lifetime to orchestrate better when the > notifications may appear. > > In any case, we think we can improve that text as follows: > > "On the contrary, the overload of creating and managing IPsec > SAs is shifted to the Security Controller since IKEv2 is not in the > NSF. As a consequence, this may result in a more complex > implementation in the controller side in comparison with > IKE case. For example, the Security Controller have to deal with > the latency existing in the path between the Security Controller > and the NSF in order to solve tasks such as, rekey or creation and > installation of new IPsec SAs. However, this is not specific to our > contribution but a general aspect in any SDN-based network. > In summary, this overload may create some scalability and performance > issues when the number of NSFs is high. > > Nevertheless, literature around SDN-based network management using a > centralized Security Controller is aware about scalability and > performance issues and solutions have been already provided and > discussed (e.g. hierarchical Security Controllers; having multiple > replicated Security Controllers, dedicated high-speed management > networks, etc). In the context of SDN-based IPsec management, one > way to reduce the latency and alleviate some performance issues can > be the installation of the IPsec policies and IPsec SAs at the same time > (proactive mode, as described in Section 7.1) instead of waiting for > notifications (e.g. a notification sadb-acquire when a new IPsec SA > is required) to proceed with the IPsec SA installations (reactive mode). > Another way to reduce the overhead and the potential scalability and > performance issues in the Security Controller is to apply the IKE > case described in this document, since the IPsec SAs are managed > between NSFs without the involvement of the Security Controller at > all, except by the initial IKE configuration provided by the Security > Controller.” > > Please see also our comments to Yoav. > > Best Regards. > > >> >> Regards, >> Valery. >> >> >> >> >> Thanks for getting this done and published. >> >> We will wait with requesting publication until the I2NSF session next week. >> Between now and then, please re-read the draft and send a message to the >> list is something is seriously wrong. >> >> Barring any such shouting, we will request publication right after the >> meeting. >> >> Thanks again, >> >> Linda and Yoav >> >> >> >>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <r...@um.es <mailto:r...@um.es>> >>> wrote: >>> >>> Dear all: >>> >>> We submitted a new version of the I-D (v05) where we have applied several >>> changes. In the following you have a summary of the main changes, which we >>> will expand/explain during our presentation: >>> >>> - We have dealt with YANG doctors’ review (Martin's) >>> >>> - We have dealt with Paul Wouters’ comments and Tero’s comments. >>> >>> - We have added more specific text in the descriptions. >>> >>> - Notifications have a simpler format now since most of the information >>> that contained in the past is already handled by the Security Controller. >>> >>> - State data has been reduced. For example, in IKE case, most of the >>> information is related with IKE and not with the specific details about >>> IPsec SAs that IKE handles (after all, IKE can abstract this information >>> from the Security Controller). >>> >>> - We have included text in the security section to discuss about the >>> default IPsec policies that should be in the NSF when it starts before >>> contacting with the SC such as the IPsec policies required to allow traffic >>> between the SC and the NSF. >>> >>> - We have added a subsection 5.3.4 about NSF discovery by the Security >>> Controller. >>> >>> - In order to specify the crypto-algorithms we have used a simple approach >>> by including an integer and adding a text pointing the IANA in the >>> reference clause. For example: >>> >>> typedef encryption-algorithm-type { >>> type uint32; >>> description >>> "The encryption algorithm is specified with a 32-bit >>> number extracted from IANA Registry. The acceptable >>> values MUST follow the requirement levels for >>> encryption algorithms for ESP and IKEv2."; >>> reference >>> "IANA Registry- Transform Type 1 - Encryption >>> Algorithm Transform IDs. RFC 8221 - Cryptographic >>> Algorithm Implementation Requirements and Usage >>> Guidance for Encapsulating Security Payload (ESP) >>> and Authentication Header (AH) and RFC 8247 - >>> Algorithm Implementation Requirements and Usage >>> Guidance for the Internet Key Exchange Protocol >>> Version 2 (IKEv2)."; >>> } >>> >>> - We have included three additional Annexes with examples in about the >>> usage of the YANG model. >>> >>> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang >>> -f yang --yang-line-length 69 in our model without warnings. >>> >>> Best Regards. >>> >>> >>> >>>> Inicio del mensaje reenviado: >>>> >>>> De: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> >>>> Asunto: [I2nsf] I-D Action: >>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>>> Para: <i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>> >>>> Cc: i2nsf@ietf.org <mailto:i2nsf@ietf.org> >>>> Responder a: i2nsf@ietf.org <mailto:i2nsf@ietf.org> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Interface to Network Security Functions >>>> WG of the IETF. >>>> >>>> Title : Software-Defined Networking (SDN)-based IPsec >>>> Flow Protection >>>> Authors : Rafa Marin-Lopez >>>> Gabriel Lopez-Millan >>>> Fernando Pereniguez-Garcia >>>> Filename : >>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Pages : 81 >>>> Date : 2019-07-07 >>>> >>>> Abstract: >>>> This document describes how providing IPsec-based flow protection by >>>> means of a Software-Defined Network (SDN) controller (aka. Security >>>> Controller) and establishes the requirements to support this service. >>>> It considers two main well-known scenarios in IPsec: (i) gateway-to- >>>> gateway and (ii) host-to-host. The SDN-based service described in >>>> this document allows the distribution and monitoring of IPsec >>>> information from a Security Controller to one or several flow-based >>>> Network Security Function (NSF). The NSFs implement IPsec to protect >>>> data traffic between network resources. >>>> >>>> The document focuses on the NSF Facing Interface by providing models >>>> for configuration and state data required to allow the Security >>>> Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 >>>> to establish Security Associations with a reduced intervention of the >>>> network administrator. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ >>>> >>>> <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/> >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 >>>> <https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 >>>> >>>> <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 >>>> >>>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-05> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org >>>> <http://tools.ietf.org/>. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >>>> >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org <mailto:I2nsf@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/i2nsf >>>> <https://www.ietf.org/mailman/listinfo/i2nsf> >>> >>> ------------------------------------------------------- >>> 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: r...@um.es <mailto:r...@um.es> >>> ------------------------------------------------------- >>> >>> >>> >>> >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org <mailto:I2nsf@ietf.org> >>> https://www.ietf.org/mailman/listinfo/i2nsf >>> <https://www.ietf.org/mailman/listinfo/i2nsf>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
