VPN is a horrible mommy as we all know especially when it comes to wireless. LET'S BE CLEAR ALL WHO CAN HEAR that reverting to VPN would be very bad. ...good you added that, GT. However, I just read a different article, which I thought was more revealing. This is a one-way "attack" which reportedly is understood by ARP frames, which makes a little more sense why they used the term "router" as I see now. There is very little data different from one ARP frame to another.
Another point of clarity is that the entire encryption reportedly isn't recovered and interesting traffic can't therefore decoded.
Now, let's provide some clear information about countermeasures and ways to protect yourself.
1) implement rekeying - any serious enterprise WiFi infrastructure product provides a rekeying interval either based on time or qty of frames. Make sure you test your clients (especially your old ones) to make sure they handle the rekeying gracefully. You might find that you may not know, but your TKIP network might already be implementing this. Implementing rekeying alone should make you nearly immune from any issue by staying with TKIP.
2) implement AES - all of the articles mention using AES protects you from this. However, please note that even when you implement AES and have a SINGLE client who can only support TKIP the entire cell groupwise cipher reverts to TKIP. The pairwise cipher (which early info indicates that this attack focuses on) can still be AES...as long as you implement this. I can see another possibility of being able to look at other traffic encrypted with the groupwise cipher (broadcast/multicast traffic) being able to be decrypted. It'd therefore be an easy extension from ARP to use other traffic to provide similar results.
Also, you PSK users out there... Use long keys. We have a lot space avail...63 or 64 bytes if I'm not mistaken. So, therefore, if you use upwards of that many bytes for your PSK auth then you are exponentially increasing the time involved in an attack with each added byte.
BTW, the attack is provided in tkiptun-ng as part of Aircrack-ng.
There really doesn't appear to be a lot of juicy info here and anything that I'm particularly concerned about yet. Let's see over the next few months what this might be extended to if anything at all.