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 Mari
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, whe
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
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
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
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
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 followin
Rafa and Yoav:
[IDR co-chair hat on] and Caveat – I am not a IPSEC or security expert.
>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
Hi Tero:
> El 22 jul 2019, a las 16:52, Tero Kivinen escribió:
>
> Rafa Marin-Lopez writes:
>> 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:
Hi Yoav:
> El 21 jul 2019, a las 3:23, Yoav Nir escribió:
>
> 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.
[Authors] The objective of the cu
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
> "seriou
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)
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)
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 cas
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 af
15 matches
Mail list logo
