Re: [Mip4] One implementation of RREQ/RREP time synchronization

["Charles E. Perkins" <[e-mail]>]

Hello Alexandru,

The existing specification does not require NTP.  I think that it's not
required for replay protection, and that your suggested method
should be fine.  I don't think there should be any additional
protocol mandates placed on MIPv4, especially after so much time,
and that it would cause many existing implementations to become
non-compliant.

Regards,
Charlie P.


On 3/21/2013 8:51 AM, Alexandru Petrescu wrote:
> The specification RFC 5944 "Mobile IPv4" has a textual description about
> an error Code 133 'Denied by home agent, registration Identification
> mismatch'.  This is sent by the HA to MR when the MR's time is way back
> (or ahead) in time, like after having lost power.
>
> However, the spec doesn't say that the MR SHOULD send a new RREQ to the
> HA, and not neither does it say what to put in that RREQ.
>
> We wrote an implementation of a method to realize this: MR receive Code
> 133, update its time, send a new RREQ; this method is based on the
> discussion in this email list MIP4.
>
>   This code is executed in MR:
>   t0 = time (); obtain time of this computer
>   ID1 = t0;
>   Send to HA RREQ containing ID1;
>   Receive RREP Code-133, and extract ID2=RREP.Identification;
>   t1 = time ();
>   set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2;
>   send RREQ to HA containing updated time;
>   receive RREP with Code = 0 (successful).
>
> This interoperates ok with a Home Agent from manufacturer.
>
> Remark there is a speculation at the calculation of time (t1-t0)/2 which
> means half of the total RTT.  But never an RTT is precisely half-half.
>
> We are not sure it is a good thing to synchronize time this way (rather
> than say NTP), and we are not sure either whether it is secure enough.
>
> Alex
>


-- 
Regards,
Charlie P.