Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Rafa Marin Lopez <[e-mail]>]

Hi Valery:

Thank you very much for your comments. Please see ours inside.
> El 20 jul 2019, a las 16:38, Valery Smyslov <[e-mail]> 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 )

>  
> 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 <[e-mail] <mailto:[e-mail]>> 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: [e-mail] <mailto:[e-mail]>
>>> 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: <[e-mail] <mailto:[e-mail]>>
>>> Cc: [e-mail] <mailto:[e-mail]>
>>> Responder a: [e-mail] <mailto:[e-mail]>
>>>  
>>> 
>>> 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.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> _______________________________________________
>>> I2nsf mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> 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: [phone] Fax: [phone] e-mail: [e-mail] <mailto:[e-mail]>
>> -------------------------------------------------------
>>  
>>  
>>  
>>  
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>