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

[Tero Kivinen <[e-mail]>]

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.

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. 

>     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. 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).

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). 

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.

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] 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.
-- 
[e-mail]