<< | Thread Index | >> ]    [ << | Date Index | >> ]


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.





<< | Thread Index | >> ]    [ << | Date Index | >> ]