Hi I2NSF WG,
There will be a demo for I2NSF Framework Hackathon Project
at Parc Mont-Royal (2nd floor) from 18:10-19:40 today:
https://datatracker.ietf.org/meeting/105/floor-plan?room=parc-mont-royal#2nd-floor
The slides file is located at:
https://github.com/IETF-Hackathon/ietf105-project-presen
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
Need your presentation slides ASAP!
Thank you
Linda
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
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
On Tue, Jul 16, 2019 at 02:42:35PM +0200, Rafa Marin-Lopez wrote:
> 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:
Hey! I'm sorry I've missed thi
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 Ben,
Thanks for your clarification.
I will reflect your comments in the revision as follows:
OLD:
Thus, the IP address(es) corresponding to the target URL
needs to be obtained from the certificate in TLS versions prior to
1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-sess
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:
I put that on my to-read queue. Cannot promise when I have time
to read
12 matches
Mail list logo
