Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

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
 > IPsec@ietf.org
 > https://www.ietf.org/mailman/listinfo/ipsec