If the two clocks do not run at exactly the same rate, we run the risk of the offset values becoming invalid. To counteract this effect, we must update the offsets during normal communications, perhaps once a minute. In fact, one of the offsets can be updated using the timestamp values in ongoing echo-request and echo-reply packets. For both offsets to be updated, we would need to make this exchange into a three-way echo sequence. I won't bother to fill in any details, but it's pretty clear how this can be done. A problem remains: dealing with variable packet delays on the Internet. To protect against excessively long delays during the transmission of the echo-request or -reply, the originator should consider the reply packet invalid if it arrives too long after the request was sent. The maximum allowable delay should be half the timestamp acceptance interval (so maybe 5 seconds), in order to allow for further drift. This doesn't solve the problem completely, but I think it is good enough. Finally, there is the possibility that the system clock on one of the hosts may undergo a large discontinuous jump, for example if the system administrator resets the system time. This would disrupt CIPE's encrypted communications. (Note that small changes in the system time are usually implemented by slightly increasing or decreasing the clock rate for a short while and thus would not cause any problem.) It would be possible to reinitialize the timestamp offsets in these situations, but I think they probably occur so infrequently that it's not necessary to worry about them. PROTECTION AGAINST ADDRESS STEALING Address stealing is a denial-of-service form of replay attack, peculiar to CIPE. The idea is that an attacker can intercept and store an encrypted CIPE packet, and then resend it using a forged source UDP address. The victim will note the new address and believe it, thinking its peer has dynamically changed to the new address. Until it learns otherwise, it will send all its messages to the wrong address. If this can be done simultaneously to both hosts, they may never re-establish communications. The proposed solution is that a CIPE implementation should not blindly accept a new UDP source address, since the address is not encrypted or subject to any sort of authentication. Rather, the new address should be accepted only if it belongs to a properly timestamped out-of-band packet, and only if the timestamp value is larger than the timestamp in any previously received packet (to protect against replays). Even this is not as secure as it could be. If an attacker can intercept the first packets sent from the new address and substitute forged copies in their place (or at least insure that the forged copies arrive before the original packets), it will be successful. On the other hand, if an attacker can intercept packets and block or delay them, then it can carry out a much simpler denial-of-service. [Still, the gold standard for accepting changes in secured values like the peer address runs more like this: A new address is accepted only if it is also stored in encrypted form within the packet itself. A new packet type could be defined for this purpose. With this proviso, an attacker would not be able to deceive the victim, since it could not encrypt the forged address. An objection is that often a host does not know its own UDP address (if it is behind a firewall that uses NAT, for example). That presents no difficulty; we can add a field to the echo-reply packet which should contain the sending UDP address of the corresponding echo-request. Thus a host can learn its UDP address simply by asking its peer. However, I believe this whole scheme probably represents an unnecessary level of complication.] The weakness with this plan is that it is not completely transparent. When dynamic address changes occur they will not be recognized immediately but only after receipt of the next packet containing a new timestamp. If the roving host is aware that its address has changed then it can immediately create such a packet; otherwise communications will be disrupted in one direction for some period of time. Perhaps a way around the weakness could be found as follows. When a host receives a valid encrypted packet with a new source address, it could speculatively send an encrypted echo-request to the new address. Receipt of the timestamped reply would quickly re-establish proper communications.