Hi Valery,
Hi Alejandro,
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.
OK, but then you should clearly state your requirement.
Otherwise it is possible to drive situation to absurdum.
For example, for a sake of device simplicity, you may
get rid of IPsec at all and send all the traffic that needs protection
to SDN via existing TLS connection/ The SDN then will route
it to appropriate peer. It would work and will make devices
even more dumber (to be clear - I don't propose this,
it is just an example of corner case solution that in theory would work).
I see your point and agree the document may need to state it if not
completely clear implicitly.
It's a trade-off between simplicity (use as few protocols/functionality
as possible), performance (use as few memory/disk/CPU resources as
possible, this includes not using SSH/TLS other than for the control
channel), and security (be as secure as possible, but not overkilling
for the requirements of the scenario).
> 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.
It depends. If you use PRNG instead of true RNG, then you'll have no PFS.
I think it is a fair assumption that an SDN controller, which is far
from being a constrained device, will have a true RNG.
> 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.
In ideal world - yes. In real world - I'm not so sure.
Imagine you have an SA expired and the SDN installs a new SA
on the peers, but one of SDN-peer TLS connection failed because off
the temporary network problem, so you have a new SA partially installed.
What is the peer that didn't receive a new SA supposed to do?
Continue to use an old one despite the fact that it is expired?
Block all traffic? Something else?
In fact, I think the SDN-based approach performs even better than IKE in
this regards.
Imagine what happens if the corresponding IKE rekey process fails for
the very same temporary network problem. In the best case, CHILD SAs are
deleted after a hard expiration, and they will need to be re-created
when triggered by the SPD again. This is roughly identical to the SDN
approach. But, typically, when an IKE rekey fails, the initiator will
likely close the entire IKE_SA thinking the other peer is down, which
would result into having to recreate the IKE_SA (including the DH
exchange), and all the associated CHILD_SAs afterwards.
How NAT traversal is to be done in IKE-less case? I understand, that
NATs are also controlled by SDN, but does SDN pre-install NAT mappings?
That's a good question. I would say so, yes.
But, would that generate problems if the NAT box is not included in your
SDN (e.g. it belongs to the mall centre or similar)?
These are exactly the sort of situations that need to be figured out.
Regards,
Alejandro
Regards,
Valery.
Regards,
Alejandro
> Regards,
> Valery Smyslov.
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
