Subject: issue 62 - rdlast

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2004 10:48:02 +0200

Tuomas,

> CURRENT TEXT: Section 5.3.4.1: See the last two bullets,
> especially the sentence: "RDlast is updated in any case."
> 
> PROBLEM: I think the last bullet has been accidentally written as a
> separate bullet. It should be a sub-case of the second last
> bullet. Otherwise, an attacker can use the updating of RDlast to
> increase the replay window.
> 
> (Details of the attack: Honest node sends message m1 
> at time t=10 and message m2 at time t=20. At time 
> t=21, the timestamp on the second message expires, 
> i.e., the receiver stops considering replays of 
> message m2 as valid. At time t=25, the attacker 
> replays m1. Because TSnew<TSlast, the receiver updates 
> RDlast but not TSlast. This effectively increases the 
> replay windows by 5 time units. Attacker can now 
> replay message m2 and it will be accepted.) 
> If TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is 
> true and TSnew<TSlast, then there is no great harm in 
> updating RDlast. However, I don't understand why it 
> needs to be updated.
> 
> PROPOSAL: Make the last bullet a sub-case of the second last
> bullet. Delete the sentence "RDlast is updated in any case."  Most
> importantly, if TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is
> false, then the message should be ignored, regardless of whether
> TSnew<TSlast or not.

Agreed. But this is complicated. Lets see if I got this
right. Here's the new text for the combined last two bullets:

    o  When a message is received from a known peer, i.e., one that
       already has an entry in the cache, the time stamp is checked
       against the previously received SEND message:

         TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz

       If this does not hold, the message SHOULD be silently discarded.

       If it does hold, the message is processed.  However, if TSnew <
       TSlast, which is possible if packets arrive rapidly and out of
       order, TSlast MUST NOT be updated, i.e., the stored TSlast for a
       given node MUST NOT ever decrease.  Otherwise TSlast and RDlast
       SHOULD be updated.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.