In the current vision of Casper Proof of Stake protocol, the validators (who are staking), when eligible, need to bet on the finality of blocks. More technically speaking, each bet has to specify for each block height: which block will most likely win, and with what probability. Validators will be constantly updating their bets, thereby converging to consensus. So if it becomes apparent that majority of other validators prefer another block (by switching to it and increasing their bets on it), you'd need to update your bet quickly, to agree with the majority, or risk being left on the losing side.
Therefore, at the crucial moments, when you need to watch the consensus emerging, and participate in it, you are most vulnerable to DDOS or other downtime.
EDIT (addition on the betting time windows):
It is unclear to me how quickly the betting game can advance. Vitalik's blog article (https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/) says that blocks should appear around every 5 seconds, but does not say anything about how fast the bets may be changed. The thing is - if the Casper is a contract, then it will only be able to take bets into account once they are included into blocks. Both blocks and bets are produced by a group of current validators. They would probably run some kind of combinatorial optimisation (if there is enough time) to figure out how to bet :)