Hi Valery, all,
>
> In general, central distribution of session keys looks much less secure,
> than running IKEv2 on them.
That's arguable, yes. But being less secure does not mean being useless.
Coming to my previous comment, we don't use RSA with 8192 bit keys for
everything. Although it is more secure, there are scenarios were a
lighter approach is enough. If running IKE is too much for your devices,
the IKE-less option might work for you if your security contraints are
fewer. This SDN-based approach does not need to solve everyone's
problems for every possible scenario. Neither does Kerberos, IPsec
itself nor any other security protocol.
> You loose PFS property,
I don't see why. Actually, keys on the controller are generated by a
secure RNG so every key you generate is completely unrelated to the
previous one. That's indeed an advantage, rather than the opposite.
> you loose
> the property that no one but the peers know the session keys etc.
Right.
> It is more fragile too. You must perform periodical rekey (update keys)
> and this must be done synchronously.
You have to do it by pairs, does not seem that difficult. And, as IKE
does, you create the new ones and, once created, delete the old ones. I
don't see the synchrony problem that important.
> All the rekey problems that were
> solved by IKE will arise again.
Prior IKE we had a phone call / email / SSH based rekeying. I don't
think having an automated central entity using a secure control protocol
such as NETCONF over SSH/TLS is exactly the same.
Regards,
Alejandro
> Regards,
> Valery Smyslov.
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
