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

Hi Alex,

I agree with Charlie, No need to change anything.

Your proposed procedure is what many implementation has been using for a long time.
In addition, I have the following comments:

1. Adjusting the MR timer considering the half the trip time is a good idea and implementation specific. If I remember correctly, I believe the HA allows for a difference of 7 seconds and that's a lot of time.

2. Since you started by saying that the MR lost its time, I would suggest that when you build the Identification field of the RRG to use a good random number generator for the 32 lower bits of the Identification ID. If that random number generator is expensive for such MR, then you can have the MR uses just a counter and keep track of that counter so it does not send a RRQ with the same counter twice; unless the 32 lower bits rolls and if that ever happens, it will take a very looooong time before ever happened. <more than 4 billion available in these 32 bits> 

This simple implementation will for sure eliminate any fear of replay protection.

Best Regards,
Ahmad

-----Original Message-----
From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Charles E. Perkins
Sent: Thursday, March 21, 2013 12:28 PM
To: Alexandru Petrescu
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization

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.

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/