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

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 16:51:10 +0100

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 21 Mar 2013 10:28:21 -0700

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.

-- 
Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 17:38:39 +0100

Charles,

Thanks for the reply.

Le 21/03/2013 18:28, Charles E. Perkins a écrit :
>
> Hello Alexandru,
>
> The existing specification does not require NTP.

Right.

But one implementation of that specification requires that the MR has
good timekeeping otherwise the Registration fails.

So how could one have good timekeeping on the Mobile Router?  Maybe NTP?
  Maybe synchronize the time by using RegReq/Rep?  Maybe GPS/Galileo?

All these are unspecified in the MIP4 RFC.  I am not requesting it
modified, I am just saying how it is.

> I think that it's not required for replay protection,

How else to do replay protection than with timespamps?

> 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.

Right.  No new mandate.

Just exposed some operational problem.

Alex

> Regards, Charlie P.
>> 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).
>>
>> 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
>>
>
>

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 21 Mar 2013 16:43:55 +0000

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: [email-masked] [mailto:[email-masked]] 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:
> 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.
>
> Code 133, update its time, send a new RREQ; this method is based on 
> the discussion in this email list MIP4.
>
> which means half of the total RTT.  But never an RTT is precisely half-half.
>
> (rather than say NTP), and we are not sure either whether it is secure enough.
>
> Alex
>

--
Regards,
Charlie P.

--
Mip4 mailing list: [email-masked]
    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/