[Mip4] One implementation of RREQ/RREP time synchronization

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

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mip4@ietfa.amsl.com
Delivered-To: mip4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E375821F9128 for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 08:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.188
X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GASUDp7FcVN5 for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 08:51:58 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 28EAB21F910E for <mip4@ietf.org>; Thu, 21 Mar 2013 08:51:57 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr []) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LFpvVb012936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mip4@ietf.org>; Thu, 21 Mar 2013 16:51:57 +0100
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr []) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LFpvmS013802 for <mip4@ietf.org>; Thu, 21 Mar 2013 16:51:57 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [] (is010446-4.intra.cea.fr []) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LFprdc016888 for <mip4@ietf.org>; Thu, 21 Mar 2013 16:51:56 +0100
Message-ID: <514B2C6E.5020803@gmail.com>
Date: Thu, 21 Mar 2013 16:51:10 +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: Mobile IPv4 Mailing List <mip4@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [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 15:51:59 -0000

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.