Re: [tcpinc] Resumption safety (was "Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)")

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> The issue is not tcpcrypt specific. TLS, IPsec and other
> security protocols that use counter-based cipher modes 
> are likely to be vulnerable to VM cloning/resumption problem as well.

Note, that VM cloning/resumption operations are most likely trying to
indicate the changing status to the operating system.

Even without any security if you clone a VM, allow the both of them to
run, the TCP sessions connected from those two devices to servers are
going to be messed up. 

This means that when you clone the VM, VM system might change the MAC
address of the virtual network card, so that you will not have
duplicate MAC addresses in the same virtual network. To do that they
most likely use some kind of plug and play virtual network interface
and remove that interface and then reinstall new interface with new
MAC. This also of course triggers DHCP and they will get new
IP-addresses, thus all TCP state will get destroyed (btw, does this
remove ability to use tcpinc resumption, i.e., can you do tcpinc
resumption using different IP?).

On other case where you take snapshot of VM, run it forward for a
moment, and then stop it and resume back to previous snapshot, the
situation is similar, i.e., the resumed VM will have different TCP
session state anyways, thus VM should not even try to keep that
intact. This means that on resumption VM system most likely also fakes
a network link status change, i.e., just like you had disconnected the
ethernet cable and put it back in. This usually triggers operating
system to rerun the DHCP, which might get new IP address etc, but in
case of resumption they might actually get the same IP back, but some
operating systems immediately tear down all TCP connections when the
link is broken, thus TLS (and tcpinc) TCP connections would get
broken, and they would fall back to resumption etc.

All of these are trying to indicate the operating system that
something has changed. For example IPsec SAs are quite commonly tied
to the specific interface, meaning that when you remove the interface
those get teared down and new SAs are created (perhaps using IKE
resumption). Or if only IP-address changes, then IKE will run mobike
to move the SAs to new IP-address, and if mobike is not available it
will tear down the SAs and recreate them. They might also send
operating system indications that machine is resuming from the sleep,
which might again do some kind of cleaning up operations.

I.e., the VM system vendors are trying to make things work, meaning
they will try to do tricks that will trigger proper response in the
operating systems.

This might also include things like virtual true random number
generator device (which would require support from the operating
system) to solve the issue with the random numbers in the VMs.

So if VMs can solve this issue by forcing resumption they will try to
do that as that makes things just work better. With TLS, IKEv2 etc
this will work as we have fresh nonces that get used in those cases.
I think tcpinc should also try to work for those cases, i.e., the
resumption should include something that make sure that it is using
fresh keys. 

> That's why I agree that we shouldn't take any steps now (in a hurry and for 
> tcpcrypt only). The problem should be recognized and addressed 
> in a more generic way.

I disagree on that. I do not think the issue is with the existing
traffic keys, it is what you do when traffic keys are already gone
(i.e., VM resume operations done by the operating system cleaned
them), but you want to do resumption to recreate them.

Current VM systems are tuned for working with protocols like TCP,
IPsec and TLS, and they try to do things that makes them work. If same
mechanism work also for tcpinc, then tcpinc will get those for free.
If not, then we need to wait for VM and operating system vendors to
find out a way to get things working with tcpinc.
-- 
[e-mail]