Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Rafa, thank you for adding this text. I think these are the very minimum recommendations that are needed to help implementers to handle various error cases correctly. Regards, Valery. From: Rafa Marin Lopez Sent: Thursday, July 25, 2019 5:54 PM To: Valery Smyslov Cc: Rafa Marin Lopez ; Fernando Pereñíguez García ; Martin Björklund ; i2nsf@ietf.org; Gabriel Lopez ; Yoav Nir ; ip...@ietf.org WG Subject: Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Hi Valery: Great!. Thanks for these comments. Very valuable. Following your suggestion we would like to add similar text to part of the I-D describing the process of IPsec SA installation. This is inline with the previous text about rekeying we sent: "Figure 4 describes the IKE-less case, when a data packet needs to be protected in the path between the NSF A and NSF B: 1. The administrator establishes the flow-based security policies, and the Security Controller looks for the involved NSFs. 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. 3. The Security Controller inserts these entries in both NSF A and NSF B IPsec databases (SPD and SAD). The following text describes how this happens between two NSFs A and B: * The Security Controller chooses two random values as SPIs: for example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers MUST not be in conflict with any IPsec SA in NSF A or NSF B. It also generates fresh cryptographic material for the new inbound/outbound IPsec SAs and their parameters and send simultaneously the new inbound IPsec SA with SPIa1 and new outbound IPsec SAs with SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to B, together with the corresponding IPsec policies. * Once the Security Controller receives confirmation from NSF A and NSF B, the controller knows that the IPsec SAs are correctly installed and ready. If some of the operations described above fails (e.g. the NSF A reports an error when the Security Controller is trying to install the SPD entry, the new inbound and outbound IPsec SAs) the Security Controller must perform rollback operations by deleting any new inbound or outbound SA and SPD entry that had been successfully installed in any of the NSFs (e.g NSF B) and stop the process (NOTE: the Security Controller may retry several times before giving up). Other alternative to this operation is: the Security Controller sends first the IPsec policies and new inbound IPsec SAs to A and B and once it obtains a successful confirmation of these operations from NSF A and NSF B, it proceeds with installing to the new outbound IPsec SAs. However, this may increase the latency to complete the process. As an advantage, no traffic is sent over the network until the IPsec SAs are completely operative. In any case other alternatives may be possible. Finally, it is worth mentioning that the Security Controller associates a lifetime to the new IPsec SAs. When this lifetime expires, the NSF will send a sadb-expire notification to the Security Controller in order to start the rekeying process. 4. The flow is protected with the IPsec SA established by the Security Controller. “ We have also clarified proactive and reactive and the operations associated in a text below "Instead of installing IPsec policies in the SPD and IPsec SAs in the SAD in step 3 (proactive mode), it is also possible that the Security Controller only installs the SPD entries in step 3 (reactive mode). In such a case, when a data packet requires to be protected with IPsec, the NSF that saw first the data packet will send a sadb-acquire notification that informs the Security Controller that needs SAD entries with the IPsec SAs to process the data packet. In such as reactive mode, since IPsec policies are already installed in the SPD, the Security Controller installs first the new IPsec SAs in NSF A and B with the operations described in step 3 but without sending any IPsec policies. Again, if some of the operations installing the new inbound/outbound IPsec SAs fail, the Security Controller stops the process and performs a rollback operation by deleting any new inbound/outbound SAs that had been successfully installed.” We hope this text also helps. Thank you very much again. El 23 jul 2019, a las 12:31, Valery Smyslov mailto:smyslov.i...@gmail.com> > escribió: Hi Rafa, Hi Valery: El 22 jul 2019, a las 18:07, Valery Smyslov < <mailto:
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
t;> during this, and SC must properly deal with all this events, >> making proper roll-back on the other NSF. > > Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you may > see we mention: > > "Once the Security Controller receives confirmation from A and B, the > controller knows that the inbound > IPsec A are correctly installed.” > > Having said this. Maybe this text after the description of steps 1, 2 and 3 > may help: > > “If some of the operations in step 1 fails (e.g. the NSF1 reports an error > when the Security Controller is trying to install anew new inbound IPsec SA) > the Security Controller must perform rollback operations by removing any new > inbound SA that had been successfully installed during step 1. > > If step 1 is successful but some of the operations in step 2 fails (e.g. the > NSF1 reports an error when the Security Controller is trying to install the > new outbound IPsec SA), the Security Controller must perform a rollback > operation by deleting any new outbound SA that had been successfully > installed during step 2 and by deleting the inbound SAs created in step 1. > > If the steps 1 an 2 are successful and the step 3 fails the Security > Controller will avoid any rollback of the operations carried out in step 1 > and step 2 since new and valid IPsec SAs were created and are functional. The > Security Controller may reattempt to remove the old inbound and outbound SAs > in NSF1 and NSF2 several times until it receives a success or it gives up. In > the last case, the old IPsec SAs will be removed when the hard lifetime is > reached." > > Yes, this text would help. > > Thank you, > Valery. > > Btw, you can also find some text about NSF state loss in section 5.3.2. > > >> >> With IKE case RFC7296 contains very specific advices what >> to do in case of packet loss, delay etc (e.g in case of >> simultaneous rekeying). I'd like to see the same advices >> for SC's behavior in case of network issues. >> >> Regards, >> Valery. >> >> >> >> >> 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 >> <mailto: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 mailto:r...@um.es>> >>> Sent: Monday, July 22, 2019 6:11 PM >>> To: Valery Smyslov mailto:smyslov.i...@gmail.com>> >>> Cc: Rafa Marin Lopez mailto:r...@um.es>>; Yoav Nir >>> mailto:ynir.i...@gmail.com>>; i2nsf@ietf.org >>> <mailto:i2nsf@ietf.org>; ip...@ietf.org <mailto:ip...@ietf.org>; Fernando >>> Pereñíguez García >> <mailto:fernando.perenig...@cud.upct.es>>; m...@tail-f.com >>> <mailto:m...@tail-f.com>; Gabriel Lopez mailto: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 >>> <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"). >>>>
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Rafa, Hi Valery: El 22 jul 2019, a las 18:07, Valery Smyslov mailto:smyslov.i...@gmail.com> > escribió: Hi Yoav, I think that it is not the performance of the SC that would matter, but the possible delays in the network. If we think of the network connecting the SC and the NSFs as of one close to "ideal", then we have no problems. Otherwise the SC must be prepared to deal with network issues. Note, that in case of reactive SA setup and in case of rekeying the SC must manage two NSFs in a synchronized manner, and any of these NSF can go offline or reboot or stop responding during this, and SC must properly deal with all this events, making proper roll-back on the other NSF. Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you may see we mention: "Once the Security Controller receives confirmation from A and B, the controller knows that the inbound IPsec A are correctly installed.” Having said this. Maybe this text after the description of steps 1, 2 and 3 may help: “If some of the operations in step 1 fails (e.g. the NSF1 reports an error when the Security Controller is trying to install anew new inbound IPsec SA) the Security Controller must perform rollback operations by removing any new inbound SA that had been successfully installed during step 1. If step 1 is successful but some of the operations in step 2 fails (e.g. the NSF1 reports an error when the Security Controller is trying to install the new outbound IPsec SA), the Security Controller must perform a rollback operation by deleting any new outbound SA that had been successfully installed during step 2 and by deleting the inbound SAs created in step 1. If the steps 1 an 2 are successful and the step 3 fails the Security Controller will avoid any rollback of the operations carried out in step 1 and step 2 since new and valid IPsec SAs were created and are functional. The Security Controller may reattempt to remove the old inbound and outbound SAs in NSF1 and NSF2 several times until it receives a success or it gives up. In the last case, the old IPsec SAs will be removed when the hard lifetime is reached." Yes, this text would help. Thank you, Valery. Btw, you can also find some text about NSF state loss in section 5.3.2. With IKE case RFC7296 contains very specific advices what to do in case of packet loss, delay etc (e.g in case of simultaneous rekeying). I'd like to see the same advices for SC's behavior in case of network issues. Regards, Valery. 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 < <mailto:smyslov.i...@gmail.com> 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 < <mailto:r...@um.es> r...@um.es> Sent: Monday, July 22, 2019 6:11 PM To: Valery Smyslov < <mailto:smyslov.i...@gmail.com> smyslov.i...@gmail.com> Cc: Rafa Marin Lopez < <mailto:r...@um.es> r...@um.es>; Yoav Nir < <mailto:ynir.i...@gmail.com> ynir.i...@gmail.com>; <mailto:i2nsf@ietf.org> i2nsf@ietf.org; <mailto:ip...@ietf.org> ip...@ietf.org; Fernando Pereñíguez García < <mailto:fernando.perenig...@cud.upct.es> fernando.perenig...@cud.upct.es>; <mailto:m...@tail-f.com> m...@tail-f.com; Gabriel Lopez < <mailto:gab...@um.es> 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 < <mailto:smyslov.i...@gmail.com> 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
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Valery: > El 22 jul 2019, a las 18:07, Valery Smyslov escribió: > > Hi Yoav, > > I think that it is not the performance of the SC that would matter, > but the possible delays in the network. If we think of the network > connecting the SC and the NSFs as of one close to "ideal", then we have > no problems. Otherwise the SC must be prepared to deal with > network issues. Note, that in case of reactive SA setup and in case > of rekeying the SC must manage two NSFs in a synchronized manner, > and any of these NSF can go offline or reboot or stop responding > during this, and SC must properly deal with all this events, > making proper roll-back on the other NSF. Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you may see we mention: "Once the Security Controller receives confirmation from A and B, the controller knows that the inbound IPsec A are correctly installed.” Having said this. Maybe this text after the description of steps 1, 2 and 3 may help: “If some of the operations in step 1 fails (e.g. the NSF1 reports an error when the Security Controller is trying to install anew new inbound IPsec SA) the Security Controller must perform rollback operations by removing any new inbound SA that had been successfully installed during step 1. If step 1 is successful but some of the operations in step 2 fails (e.g. the NSF1 reports an error when the Security Controller is trying to install the new outbound IPsec SA), the Security Controller must perform a rollback operation by deleting any new outbound SA that had been successfully installed during step 2 and by deleting the inbound SAs created in step 1. If the steps 1 an 2 are successful and the step 3 fails the Security Controller will avoid any rollback of the operations carried out in step 1 and step 2 since new and valid IPsec SAs were created and are functional. The Security Controller may reattempt to remove the old inbound and outbound SAs in NSF1 and NSF2 several times until it receives a success or it gives up. In the last case, the old IPsec SAs will be removed when the hard lifetime is reached." Btw, you can also find some text about NSF state loss in section 5.3.2. > > With IKE case RFC7296 contains very specific advices what > to do in case of packet loss, delay etc (e.g in case of > simultaneous rekeying). I'd like to see the same advices > for SC's behavior in case of network issues. > > Regards, > Valery. > > > > > 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 > <mailto: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 mailto:r...@um.es>> >> Sent: Monday, July 22, 2019 6:11 PM >> To: Valery Smyslov mailto:smyslov.i...@gmail.com>> >> Cc: Rafa Marin Lopez mailto:r...@um.es>>; Yoav Nir >> mailto:ynir.i...@gmail.com>>; i2nsf@ietf.org >> <mailto:i2nsf@ietf.org>; ip...@ietf.org <mailto:ip...@ietf.org>; Fernando >> Pereñíguez García > <mailto:fernando.perenig...@cud.upct.es>>; m...@tail-f.com >> <mailto:m...@tail-f.com>; Gabriel Lopez mailto: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 >> <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", dependin
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Yoav,
I think that it is not the performance of the SC that would matter,
but the possible delays in the network. If we think of the network
connecting the SC and the NSFs as of one close to "ideal", then we have
no problems. Otherwise the SC must be prepared to deal with
network issues. Note, that in case of reactive SA setup and in case
of rekeying the SC must manage two NSFs in a synchronized manner,
and any of these NSF can go offline or reboot or stop responding
during this, and SC must properly deal with all this events,
making proper roll-back on the other NSF.
With IKE case RFC7296 contains very specific advices what
to do in case of packet loss, delay etc (e.g in case of
simultaneous rekeying). I'd like to see the same advices
for SC's behavior in case of network issues.
Regards,
Valery.
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 mailto: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 mailto:r...@um.es> >
Sent: Monday, July 22, 2019 6:11 PM
To: Valery Smyslov mailto:smyslov.i...@gmail.com> >
Cc: Rafa Marin Lopez mailto:r...@um.es> >; Yoav Nir
mailto:ynir.i...@gmail.com> >; i2nsf@ietf.org
<mailto:i2nsf@ietf.org> ; ip...@ietf.org <mailto:ip...@ietf.org> ; Fernando
Pereñíguez García mailto:fernando.perenig...@cud.upct.es> >; m...@tail-f.com
<mailto:m...@tail-f.com> ; Gabriel Lopez mailto: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 < <mailto:smyslov.i...@gmail.com>
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 install
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
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 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
> Sent: Monday, July 22, 2019 6:11 PM
> To: Valery Smyslov
> Cc: Rafa Marin Lopez ; Yoav Nir ;
> i2nsf@ietf.org; ip...@ietf.org; Fernando Pereñíguez García
> ; m...@tail-f.com; Gabriel Lopez
>
> 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 > <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 di
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
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
Sent: Monday, July 22, 2019 6:11 PM
To: Valery Smyslov
Cc: Rafa Marin Lopez ; Yoav Nir ;
i2nsf@ietf.org; ip...@ietf.org; Fernando Pereñíguez García
; m...@tail-f.com; Gabriel Lopez
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 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 )
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 a
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 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
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi Yoav,
Hi, Valery
[no hats]
Thanks for that.
I think this demonstrates that the current document is not enough and we will
need some follow-up documents explaining when to use either case.
I don’t think it’s very useful for the controller to distribute a policy (SPD
entries) but no SAs (SAD entries) in the IKE-less case. It makes sense in the
IKE case because the NSFs can then use IKE to generate the SAs, but in the
IKE-less case that would mean that one NSF gets a packet that should be
protected, sends a message to the controller, which generates an SA and sends
it to both the requester and the other NSF. This seems high latency.
I think the case for IKE-less is where the controller sends SPD entries and SAD
entries at the same time (perhaps later updating the SAD entries to rekey). In
that case the action of the controller is to bring up a tunnel. For example,
if the user (or application) decides that communications between node A and
node B should be encrypted, the controller will send both policy and keys at
the same time to make that tunnel.
Sure that will make things more static and the concerns expressed in
my message will gone.
However, other concerns appear in this case. First, you'll lose some
of ipsec functionality -
an ability to have per-connection IPsec SA, when each TCP connection
is protected with
its own SA (don't ask me when I last time saw this in real life,
please :-)). Then, in this
case a situation is possible when (some of) installed SAs are never
used. You preinstall
them regardless of the traffic, and traffic can never happen. Not
that it is a big deal,
but still...
Regards,
Valery.
Yoav
On 20 Jul 2019, at 10:38, Valery Smyslov mailto:smyslov.i...@gmail.com> > wrote:
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).
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.
I didn't find this discussion in the draft (sorry if I missed it).
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>
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’
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Hi, Valery
[no hats]
Thanks for that.
I think this demonstrates that the current document is not enough and we will
need some follow-up documents explaining when to use either case.
I don’t think it’s very useful for the controller to distribute a policy (SPD
entries) but no SAs (SAD entries) in the IKE-less case. It makes sense in the
IKE case because the NSFs can then use IKE to generate the SAs, but in the
IKE-less case that would mean that one NSF gets a packet that should be
protected, sends a message to the controller, which generates an SA and sends
it to both the requester and the other NSF. This seems high latency.
I think the case for IKE-less is where the controller sends SPD entries and SAD
entries at the same time (perhaps later updating the SAD entries to rekey). In
that case the action of the controller is to bring up a tunnel. For example,
if the user (or application) decides that communications between node A and
node B should be encrypted, the controller will send both policy and keys at
the same time to make that tunnel.
Yoav
> On 20 Jul 2019, at 10:38, Valery Smyslov wrote:
>
> 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).
>
> 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.
>
> I didn't find this discussion in the draft (sorry if I missed it).
>
> 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 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
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
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).
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.
I didn't find this discussion in the draft (sorry if I missed it).
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 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
Re: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
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 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
>> 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: mailto:i-d-annou...@ietf.org>>
>> Cc: i2nsf@ietf.org
>> Responder a: 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/
>>
