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

[Rafa Marin-Lopez <[e-mail]>]

Hi Tero:

Thanks for this discussion. Really interesting and productive in my opinion. My comments inline
> El 19 jul 2017, a las 10:17, Tero Kivinen <[e-mail]> escribió:
> 
> Rafa Marin-Lopez writes:
>>    I.e. any TLA would love to get their hands on all the traffic keys in
>>    one location, and then be able to decrypt any traffic going inside any
>>    of the IPsec tunnels.
>> 
>>    If controller only has the PSKs or similar to do the authentication
>>    between peers, then that means that the TLA needs to do active attack
>>    for each connection they want to break.
>> 
>>    Beause of this I think it is always best not to move the transport
>>    keys outside the boxes that needs them, i.e., keep them only on the
>>    nodes doing actual encryption / decryption.
>> 
>>    Also knowing that the controller most likely keeps all kind of logs
>>    and takes backup of the configurations it is keeping, this also makes
>>    the backups suitable targets for attacks, as they allow decryption
>>    previously stored flows of traffic, and this can be done years later
>>    when one of those backups accidently finds its way to wrong hands.
>> 
>> [Rafa] In reality, the controller can forget immediately the
>> credentials that has been generated. As a security measure , the
>> controller does not need to store any keys it has distributed.
> 
> No it cannot. The keys needs to be installed in multiple nodes, which
> means that when it generates them it needs to store them until it is
> sure that every single device needing them has them.
[Rafa] But that is clear, isn’t it?. If the controller generates them then there is a short period of time where the key is there. No doubt about it.

My point is that the SDN controller does not need to store them once they are distributed.

> 
> Also if any single device restarts, it will need new keys, and those
> keys again needs to be destributed to all other entities sharing SA
> keys with the node. Also even if if could remove the keys quite
> quickly after generating them, in practice I do not think that is
> going to happen, as operators want to be able to see what is the
> configuration that was sent to node, which then requires controller to
> keep configuration available. 

[Rafa] One thing is to keep certain configuration about the SA and another to store the keys in the controller. A good security practice is to not store the keys. 

Moreover the YANG model in the device may dictate that the variable with the key has only writing permissions and it cannot be read posteriorly. 

But, of course, if a centralized entity is taking control of everything and that entity decides to not play nicely (storing keys for example), we have a problem. That happens in SDN world regardless IPsec. If we do not want to go to a centralized paradigm, it is fine. Get rid of SDN for management and let stay in the distributed way. 

But I think this is something general. If you do not trust in the “trusted” entity then we have a problem. No doubt. In fact, the area of securing the SDN controller itself is a vast area of contribution and an important topic nowadays.

> 
>>    This I think is important question, i.e., what is the gain for not
>>    running IKEv2 between the nodes?
>> 
>> [Rafa] As Yoav mentioned, simpler devices. 
> 
> I do not really belive that. You need security protocol to be able to
> transmit the configuration to the nodes, and that security protocol
> will require similar resource than what IKEv2 needs.

[Rafa] The device needs to handle a single SA (TLS or SSH) with the controller. As that will be happen regardless the management of IPsec for tackling other aspects such as routing, IDS, firewalls, etc. 

On the other hand, the number of IPsec SAs that device has to handle can be many. 

> To be able to do
> the actual ESP traffic for links will require much more resources than
> running IKE to setting up the SA.
> Yes, you can leave few kilobytes of
> code out from the flash, as you do not need to implement IKEv2.
> 
> Also you loose all kind of features too, like ability to spport
> roaming clients (i.e., laptop, or phone etc connecting to network
> through VPN, or actually connecting IPsec to any other node that is
> not directly controlled by the controller).

[Rafa] This is the reason we also have case 1 (ikev2 in the nsf). I think it is important to note that we do not propose case 1 vs case 2. 
We have two cases and depending on the deployment one may choose case 1 or case 2. 

In other words, we are not against on having IKEv2 in the NSF at all. On the contrary it has clear advantages. We are just stating that there is also another possibility (case 2) with advantages too.

> 
> Note, that the controller cannot run IKEv2 in behalf of any of nodes
> it is controlling, as that is forbidden by the IPsec (IKE and Child SA
> are tied together so that if one goes down, the other MUST go down
> too). See section 2.4 of RFC7296 end of 4th paragraph (line 14 of page
> 28). 

[Rafa] In the case you mention, if an IKE SA is in the controller (this case would be part of Road Warrior, which is TBD though), the controller will know the IKE SA is down. As a consequence the Controller will remove the child SAs. 

Thus, if the IKE SA goes down the other goes down, correct?

In any case, in my opinion, case 1 in our I-D could be better for Road Warrior. No problem with that.

> 
> Also if you are limiting yourself to the endpoint-to-endpoint
> transport mode (section 1.1.2 of RFC7296) with policy given by the
> controller, you do not need full IKEv2 implementation, you can
> implement minimal IKEv2 (RFC7815), with exception that you also need
> to implement the responder side also.
> 
> Using the frequently generated PSKs distributed from the controller,
> and minimal IKEv2, will give you much better security than when you
> transport traffic keys from controller.

[Rafa] Yes, that is one option. My comment here in the past was you would 
still need other features coming from the controller since minimal ikev2 does not provide you all of them.

As I see it, minimal ikev2 in the device is still case 1 somehow. But we can introduce a note about minimal IKEv2 in our I-D as well, of course.

> 
> Btw, on Friday there will be presentation in ipsecme where they
> implemented minimal IKEv2 with GDOI modifications (i.e., IKEv2 +
> multicast key distribution) in device which having 256 kB of flash,
> and 32 kB of ram, and that implementation included the full network
> support also, not only IKEv2…

[Rafa] Good to know. 
> 
>> [Rafa] Basically, the SDN controller will know when to do the rekey. Please,
>> see the YANG model in our draft. There is notification “expire”
> 
> Ah, sorry, I have not read the draft yet, as I have been too busy with
> other things, but if there is two way communication between the node
> and controller, than that works fine.

[Rafa] Yes, there is two way communication between the node and the controller.

Thanks.

> -- 
> [e-mail]
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: [phone] Fax: [phone] e-mail: [e-mail]
-------------------------------------------------------