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

[Alejandro Pérez Méndez <[e-mail]>]

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
>>   > [e-mail]
>>   > https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec