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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 21 March 2013 16:39 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mip4@ietfa.amsl.com
Delivered-To: mip4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9E21F8DEA for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 09:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.18
X-Spam-Level:
X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfczp3RGJkPp for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 09:39:38 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 30CBB21F8DE9 for <mip4@ietf.org>; Thu, 21 Mar 2013 09:39:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LGdP65008155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 17:39:25 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LGdP2E031293; Thu, 21 Mar 2013 17:39:25 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LGdLNT008009; Thu, 21 Mar 2013 17:39:25 +0100
Message-ID: <514B378F.302@gmail.com>
Date: Thu, 21 Mar 2013 17:38:39 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Charles E. Perkins" <charliep@computer.org>
References: <514B2C6E.5020803@gmail.com> <514B4335.2040107@computer.org>
In-Reply-To: <514B4335.2040107@computer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>
Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 16:39:39 -0000

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